On ti, 16 tammi 2018, Robbie Harwood via FreeIPA-users wrote:
Chris Moody via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org>
writes:
> 2018-01-15T21:55:24Z INFO Configured /etc/krb5.conf for IPA realm
>
IPA.XYZ.COM
> 2018-01-15T21:55:24Z DEBUG Starting external process
> 2018-01-15T21:55:24Z DEBUG args=keyctl search @s user
> ipa_session_cookie:host/sfca-do-1.xyz.com@IPA.XYZ.COM
> 2018-01-15T21:55:24Z DEBUG Process finished, return code=1
> 2018-01-15T21:55:24Z DEBUG stdout=
> 2018-01-15T21:55:24Z DEBUG stderr=keyctl_search: Required key not available
I'm not familiar with what IPA's trying to do here, but this looks like
a problem? Can someone else comment?
No, this is not a problem. We check if a
session cookie, stored in a
Kerberos ccache, is available. If not, we don't have a cached cookie, no
big deal, we have to run authentication flow.
> I have tried manually setting /etc/krb5.conf to the contents that
get>
> generated & display during the verbose client-install process (as seen
> above), that manually spell out the KDC details, and am able to run a
> 'kinit admin' just fine from the CLI on the client, so kerberos DOES
> function from the client. It talks to the KDC beautifully and
> authenticates just fine... so I'm not sure how the client-install
> process is getting confused/lost when trying to find/contact the KDC.
Someone else who knows more than me: how is the install different than a
normal kinit?
Install generates own krb5.conf in /tmp and uses that one to perform
a
discovery. Then it configures /etc/krb5.conf according to what was
discovered and how ipa-client-install was called.
It may be that discovery process doesn't work well because DNS lacks SRV
or TXT records, for example. In this case re-running ipa-client-install
with explicit realm/domain info might help. There are more
considerations in ipa-client-install manual page.
--
/ Alexander Bokovoy