[Freeipa-users] IPA-AD Login

[Jakub Hrozek]

On Fri, Feb 05, 2016 at 06:21:56PM -0600, Alan P wrote:
> Thanks jhrozek, I have already seen it and applied to my IPA server, but it didn't have any significant impact, at least for AD users. In krb5kdc log, when I try to login with an IPA user in Windows, I can see the next:
> 
> Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): AS_REQ (6 etypes {18 17 23 24 -135 3}) 172.19.21.37: NEEDED_PREAUTH: ipa.user at IPA.AD.EXAMPLE.COM for krbtgt/IPA.AD.EXAMPLE.COM at IPA.AD.EXAMPLE.COM, Additional pre-authentication required
> Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12
> Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): AS_REQ (6 etypes {18 17 23 24 -135 3}) 172.19.21.37: ISSUE: authtime 1454716332, etypes {rep=18 tkt=18 ses=18}, ipa.user at IPA.AD.EXAMPLE.COM for krbtgt/IPA.AD.EXAMPLE.COM at IPA.AD.EXAMPLE.COM
> Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12
> Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): TGS_REQ (5 etypes {18 17 23 24 -135}) 172.19.21.37: ISSUE: authtime 1454716332, etypes {rep=18 tkt=18 ses=18}, ipa.user at IPA.AD.EXAMPLE.COM for krbtgt/AD.EXAMPLE.COM at IPA.AD.EXAMPLE.COM
> Feb 05 17:52:12 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12
> Feb 05 17:58:45 master.ipa.ad.example.com krb5kdc[14081](info): TGS_REQ (5 etypes {18 17 23 24 -135}) 172.19.21.37: ISSUE: authtime 1454716332, etypes {rep=18 tkt=18 ses=18}, ipa.user at IPA.AD.EXAMPLE.COM for cifs/master.ipa.ad.example.com at IPA.AD.EXAMPLE.COM
> Feb 05 17:58:45 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12
> Feb 05 17:58:47 master.ipa.ad.example.com krb5kdc[14081](info): TGS_REQ (5 etypes {18 17 23 24 -135}) 172.19.21.37: LOOKING_UP_SERVER: authtime 0,  ipa.user at IPA.AD.EXAMPLE.COM for ProtectedStorage/master.ipa.ad.example.com at IPA.AD.EXAMPLE.COM, Server not found in Kerberos database
> Feb 05 17:58:47 master.ipa.ad.example.com krb5kdc[14081](info): closing down fd 12
> 
> 
> In Windows, I can't find something related.
> 
> Any other suggestion?

Which part of the login is slow? Acquiring ticket with kinit or
establishing the user groups etc? Usually it's the latter, so looking at
sssd logs and checking what takes so long is the best way forward in
most cases. You can also confirm if the group resolution takes a long
time with:
    sss_cache -E; id $aduser at addomain