Hide Forgot
Description of problem: Unfortunately I tried to kinit using keytab with different principal "ipa-dnskeysyncd" but the real principal was "ipa-dnskeysync" (without "d" at the end) I received error: Kerberos authentication failed: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529639107): No credentials cache found However the KRB5_TRACE output contains the real error: [70521] 1479316479.969563: Retrieving ipa-dnskeysyncd/vm-058-013.ipa.test from FILE:/etc/ipa/dnssec/ipa-dnskeysyncd.keytab (vno 0, enctype 0) with result: -1765328203/No key table entry found for ipa-dnskeysyncd/vm-058-013.ipa.test Version-Release number of selected component (if applicable): python-gssapi-1.2.0-1.fc24.x86_64 How reproducible: Always Steps to Reproduce: 1. try to kinit with principal that is not listed in keytab 2. 3. Actual results: Unspecified GSS failure. Minor code may provide more information, Minor (2529639107): No credentials cache found Expected results: Keytab contains no suitable keys for .... Additional info:
`kinit` is not a python-gssapi verb. Please provide the python code with which you encountered this error.
# dnf install python2-ipalib # KRB5_TRACE=/dev/stderr python -c 'from ipapython.ipautil import kinit_keytab; kinit_keytab("random/hostname@realm", "/etc/named.keytab", "/tmp/ccache")' [80267] 1479327791.128952: Retrieving random/hostname@realm from FILE:/etc/named.keytab (vno 0, enctype 0) with result: -1765328203/No key table entry found for random/hostname@realm [80267] 1479327791.130235: Retrieving random/hostname@realm from FILE:/etc/named.keytab (vno 0, enctype 0) with result: -1765328203/No key table entry found for random/hostname@realm Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1332, in kinit_keytab cred = gssapi.Credentials(name=name, store=store, usage='initiate') File "/usr/lib64/python2.7/site-packages/gssapi/creds.py", line 64, in __new__ store=store) File "/usr/lib64/python2.7/site-packages/gssapi/creds.py", line 148, in acquire usage) File "gssapi/raw/ext_cred_store.pyx", line 182, in gssapi.raw.ext_cred_store.acquire_cred_from (gssapi/raw/ext_cred_store.c:1892) gssapi.raw.misc.GSSError: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529639107): No credentials cache found ipautil.kinit_keytab basically calls gssapi.Credentials() https://github.com/freeipa/freeipa/blob/master/ipapython/ipautil.py#L1310
In this case, what has likely happened is that it tried the keytab, found nothing in the keytab, then moved on to the ccache, and didn't find their either. Which is correct? Well, they're both correct. If you want the errors from both separately, two calls will be needed (with different values for store).
Robie, I do not think this is right behavior. For me as application developer, the current behavior is far away from principle of least surprise. I agree that ccache is ephemeral and it is kind of expected that it might not exist, but keytab is very different. I as application developer certainly do not expect that keytab does not exist, so certainly do not expect the library to do not report this fact. Having said that, if there is a fatal error accessing/using a keytab, it should be reported right away. Even if you do not accept this approach, shouldn't the ordering of operations be: 1. try ccache 2. if ccache does not work, try keytab 3. if keytab did not work, report error from keytab attempt ? Thank you for reconsidering this.
(In reply to Petr Spacek from comment #4) > Robie, I do not think this is right behavior. For me as application > developer, the current behavior is far away from principle of least surprise. > > I agree that ccache is ephemeral and it is kind of expected that it might > not exist, but keytab is very different. I as application developer > certainly do not expect that keytab does not exist, so certainly do not > expect the library to do not report this fact. > > Having said that, if there is a fatal error accessing/using a keytab, it > should be reported right away. > > Even if you do not accept this approach, shouldn't the ordering of > operations be: > 1. try ccache > 2. if ccache does not work, try keytab > 3. if keytab did not work, report error from keytab attempt > ? > > Thank you for reconsidering this. `store` is a dict, not a list, so there's nothing in the python-gssapi that guarantees order. Nor is there in krb5; the underlying structure is a gss_const_key_value_set_t, which is approximately a dict. For the krb5 mech, in the initiation case, the order they happen to be tried is: ccache first, then client_keytab. This is not guaranteed (very little about the cred store functions is guaranteed), but I think this is probably the only sane order. There is Normally with GSSAPI one doesn't worry about specific ccaches, which is why these are extensions. Since both have been specified as possible stores, if both fail, it's not clear which should be reported. I will check with upstream in case they have any ideas, but it does not strike me as likely.
I appreciate that you will discuss this upstream. Thank you!
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.