ipa-certupdate sets a temporary ccache in run_with_args() but sets the environment variable for the ccache after the kinit_keytab()
If the kinit fails for some reason then the finally will fail in deleting KRB5CCNAME from the environment, hiding the error for the kinit failure.
So I think either the setting of ccache be moved up or a different test be used to determine if KRB5CCNAME is in the environment.
I don't know how this host got into this situation but I have an enrolled client and /etc/krb5.keytab is gone.
Run ipa-certupdate
Amazingly the value for host was wrong in /etc/ipa/default.conf which contributed to this. kinit was failing because it was trying to get the wrong principal.
The host value seems to be a red herring as I can't reproduce it by changing that.
To reproduce I did:
ipa-client-install ... ipa-rmkeytab -k /etc/krb5.keytab -r REALM
Indeed it just returns:
did not receive Kerberos credentials
Buried in the exception traceback is:
gssapi.raw.misc.GSSError: Major (851968): Unspecified GSS failure. Minor code may provide more information, Minor (2529639053): No Kerberos credentials available (default cache: MEMORY:)
Which also isn't that helpful to an end-user.
The user's ticket isn't used for this command, it generates its own. I think that clarifying this would help. Something like:
"Obtaining credentials for {hostname} from {keytab} failed: {exception}"
hostname = ipalib.constants.FQDN
Metadata Update from @rcritten: - Issue set to the milestone: None (was: FreeIPA 4.8.7)
https://github.com/freeipa/freeipa/pull/5936
master:
ipa-4-9:
Metadata Update from @frenaud: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.