[Freeipa-users] Cannot login with GSSAPI to IPA client

[Simo Sorce]

On Wed, 2015-06-17 at 09:17 -0700, nathan at nathanpeters.com wrote:
> > On Tue, Jun 16, 2015 at 04:32:31PM -0700, nathan at nathanpeters.com wrote:
> >> I have 2 CentOS 6 clients both running FreeIPA client 3.0.0-42 and sssd
> >> 1.11.6-30.  The server is CentOS 7 / IPA 4.1.3
> >>
> >> When I try to log in using MIT kerberos and a valid ticket it works on
> >> one
> >> client, and fails on the other.  I have compared the /etc/krb5.conf,
> >> /etc/sssd/sssd.conf and /etc/openldap/ldap.conf files on both clients
> >> and
> >> they are identical (other than the hostnames).  I can't seem to find any
> >> other difference between the clients.
> >>
> >> Password authentication works on both machines.
> >>
> >> Here is the dub log of the failed login machine (sshd)
> >>
> >> I think the relevant line is the very last one where it postpones the
> >> login for some reason
> >>
> >> Postponed gssapi-with-mic for username from 10.5.5.57 port 15076 ssh2
> >
> > This message is in the other log as well and I think this is ok.
> >
> > Have you check if the keytab on the host with issue has the latest key
> > version?
> >
> > To check the call 'klist -k' as root on the server and then call 'kvno
> > host/...' with the principal shown in the klist output. Both kvno
> > numbers should be the same. If they differ call ipa-getkeytab on the
> > server to get a fresh keytab. Please note that you have to call kdestory
> > and kinit on the client to remove the old now invalid ticket from the
> > client's credential cache.
> >
> > HTH
> >
> > bye,
> > Sumit
> 
> Following those directions, I ran into some issues but I think I may have
> just interpreted them wrong.  Klist lists 4 principals all with the same
> name and kvno on that server.  Shouldn't there be just one?

Use the -e flag you will see each of them is for a different algorithm.
(Each key is derived differently based on the specific algorithm
supported)

We should probably stop requesting all keys and just get one AES key for
most cases, as that's the only one we really want to use anyway.

> ALso, when running kvno as root, I get back an error. I had to kinit
> first.  I got this even on a server that was working though so I assume
> that step was skipped above.
> 
> [root at fe1 home]# klist -k
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> ----
> --------------------------------------------------------------------------
>    1 host/fe1.ipadomain.net at IPADOMAIN.NET
>    1 host/fe1.ipadomain.net at IPADOMAIN.NET
>    1 host/fe1.ipadomain.net at IPADOMAIN.NET
>    1 host/fe1.ipadomain.net at IPADOMAIN.NET
> [root at fe1 home]# kvno host/fe1.ipadomain.net at IPADOMAIN.NET
> kvno: Credentials cache file '/tmp/krb5cc_0' not found while getting
> client principal name
> [root at fe1 home]# kinit username
> Password for username at IPADOMAIN.NET:
> [root at fe1 home]# kvno host/fe1.ipadomain.net at IPADOMAIN.NET
> host/fe1.ipadomain.net at IPADOMAIN.NET: kvno = 1

This is normal, you can obtain a ticket (that's what kvno does) only if
you have a TGT (which is stored in the Credentials Cache).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York