client not found in Kerberos database

[Jason Keltz]

Hi..

I'm running CentOS 7 with the default gssproxy setup.  However, instead 
of the standard Kerberos server, I'm using Samba AD.

On every CentOS 7 system joined to the domain and mounting NFS, my logs 
are constantly showing errors like:

Nov 12 08:32:51 j1 gssproxy[853]: (OID: { 1 2 840 113554 1 2 2 }) 
Unspecified GSS failure.  Minor code may provide more information, 
Client 'host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA' not found in Kerberos 
database

When I move many systems to the domain, there will be hundreds of these 
errors.  I'd like to resolve the issue that is causing the errors.

j1 (a test host) is actually j1.eecs.yorku.ca which is joined to the 
realm AD.EECS.YORKU.CA.

j1.eecs.yorku.ca does a forward lookup to an IP.  The reverse lookup of 
that IP goes back to j1.eecs.yorku.ca.

j1.ad.eecs.yorku.ca doesn't even exist in DNS.  However, when J1 is 
joined to the domain (using net ads join), entries for 
j1.ad.eecs.yorku.ca are added to the keytab.  I also add entries for 
host/j1.eecs.yorku.ca.

The following works:

j1# kinit -k -t /etc/krb5.keytab -S 
'host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA' 'J1$'
j1# klist
Ticket cache: FILE:/tmp/krb5cc_1004_aGasjVy28U
Default principal: J1$(a)AD.EECS.YORKU.CA

Valid starting       Expires              Service principal
11/12/2020 08:41:41  11/12/2020 18:41:41 
host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA
     renew until 11/19/2020 08:41:41

That's from the same system where gssproxy reports that 
host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA is not found in Kerberos database.

Obviously, the errors are harmless because NFS mounting works, and 
everything else works, but the logs would be a lot quieter if I could 
figure out how to stop these errors.

Any thoughts?

Jason.

[Simo Sorce]

On Thu, 2020-11-12 at 08:47 -0500, Jason Keltz wrote:
>  Hi..
>  
>  I'm running CentOS 7 with the default gssproxy setup.  However, instead 
>  of the standard Kerberos server, I'm using Samba AD.
>  
>  On every CentOS 7 system joined to the domain and mounting NFS, my logs 
>  are constantly showing errors like:
>  
>  Nov 12 08:32:51 j1 gssproxy[853]: (OID: { 1 2 840 113554 1 2 2 }) 
>  Unspecified GSS failure.  Minor code may provide more information, 
>  Client 'host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA' not found in Kerberos 
>  database
>  
>  When I move many systems to the domain, there will be hundreds of these 
>  errors.  I'd like to resolve the issue that is causing the errors. 
In AD you cannot use the SPN alias to init credentials, you must use
the workstation UPN generally in the form of shortname$(a)REALM.TLD

>  j1 (a test host) is actually j1.eecs.yorku.ca which is joined to the
>
>  realm AD.EECS.YORKU.CA.
>  
>  j1.eecs.yorku.ca does a forward lookup to an IP.  The reverse lookup of 
>  that IP goes back to j1.eecs.yorku.ca.
>  
>  j1.ad.eecs.yorku.ca doesn't even exist in DNS.  However, when J1 is 
>  joined to the domain (using net ads join), entries for 
>  j1.ad.eecs.yorku.ca are added to the keytab.  I also add entries for 
>  host/j1.eecs.yorku.ca.
>  
>  The following works:
>  
>  j1# kinit -k -t /etc/krb5.keytab -S 
>  'host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA' 'J1$'
>  j1# klist
>  Ticket cache: FILE:/tmp/krb5cc_1004_aGasjVy28U
>  Default principal: J1$(a)AD.EECS.YORKU.CA 
As you can see here it appears now your AD KDC is giving you referrals
to resolve to the UPN instead of SPN.

>  Valid starting       Expires              Service principal
>  11/12/2020 08:41:41  11/12/2020 18:41:41 
>  host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA
>       renew until 11/19/2020 08:41:41
>  
>  That's from the same system where gssproxy reports that 
>  host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA is not found in Kerberos database. 
I think the -S above is tricking you, what you are telling kinit is to
kinit with whatever is the default key in the keytab and get a ticket
for the specified service.
you'll probably see a key for J1$(a)AD.EECS.YORKU.CA as first if you
klist -k /etc/krb5.keytab

While gss-proxy is probably configured to use 
host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA as the initiator cred instead
which cannot work.
This is because that's what rpc.gssd probably tries by default I think,
but it probably falls back to use the JI$ one if you can mount at all.

>  Obviously, the errors are harmless because NFS mounting works, and 
>  everything else works, but the logs would be a lot quieter if I could 
>  figure out how to stop these errors.
>  
>  Any thoughts? 
Take a look to see if the krb5_principal option could help.

Simo.

>  Jason.
>  _______________________________________________
>  gss-proxy mailing list -- gss-proxy(a)lists.fedorahosted.org
>  To unsubscribe send an email to gss-proxy-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]... 
-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc