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@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@AD.EECS.YORKU.CA' 'J1$' j1# klist Ticket cache: FILE:/tmp/krb5cc_1004_aGasjVy28U Default principal: J1$@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@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@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.
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@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$@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@AD.EECS.YORKU.CA' 'J1$' j1# klist Ticket cache: FILE:/tmp/krb5cc_1004_aGasjVy28U Default principal: J1$@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@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@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$@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@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@lists.fedorahosted.org To unsubscribe send an email to gss-proxy-leave@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/gss-proxy@lists.fedorahosted.or...
gss-proxy@lists.fedorahosted.org