client not found in Kerberos database
by 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.
2 years, 6 months
GSS-Proxy Question with respect to gssproxy and mod_auth_gssapi
by Jason Keltz
Hi.
I've been trying to get gssproxy working with httpd and mod_auth_gssapi
on CentOS 7.8. Albeit, I'm not using the httpd from CentOS, but a later
2.4.39.
I setup the httpd keytab. I setup mod_auth_gssapi and was able to
access my page with Kerberos auth no problem at all.
Next, I wanted to get things working with gssproxy.
I created /etc/gssproxy/80-httpd.conf
[service/HTTP]
mechs = krb5
cred_store = keytab:/xconf/httpd/keytab/httpd-www-svc.keytab
cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
euid = www
My web user is "www".
My keytab file is in the given location. I change permission to 600,
owned by root.
I added to the Service section of /etc/systemd/system/httpd.service:
Environment=GSS_USE_PROXY=yes
I restart httpd and gssproxy.
My test protected page is under a .htaccess as follows:
AuthType GSSAPI
AuthName "GSSAPI Login"
GssapiBasicAuth On
GssapiLocalName on
Require valid-user
When I visit the page and I don't have a ticket, I get prompted for my
username and password. Access is denied.
When I visit my page Apache outputs:
[Thu Oct 15 15:04:12.311614 2020] [auth_gssapi:error] [pid 28584:tid
13995355614
1824] [client 130.63.97.125:57910] GSS ERROR gss_acquire_cred[_from]()
failed to
get server creds: [Unspecified GSS failure. Minor code may provide
more inform
ation (Keytab FILE:/etc/krb5.keytab is nonexistent or empty)]
... so I know that it's not really using gssproxy because if it was, it
wouldn't be looking at /etc/krb5.keytab.
I enabled debugging on gssproxy, level 3, but when I access the page,
gssproxy doesn't log anything. This is printed when I start gssproxy
and doesn't change:
[2020/10/15 23:23:26]: Service: HTTP, Keytab:
/xconf/httpd/keytab/httpd-www-svc.keytab, Enctype: 23
[2020/10/15 23:23:26]: Service: nfs-server, Keytab: /etc/krb5.keytab,
Enctype: 17
[2020/10/15 23:23:26]: Service: nfs-client, Keytab: /etc/krb5.keytab,
Enctype: 17
[2020/10/15 23:23:26]: Debug Enabled (level: 3)
[2020/10/15 23:23:26]: Problem with kernel communication! NFS server
will not work
[2020/10/15 23:23:26]: Failed to get peer's SELinux context (92:Protocol
not available)
[2020/10/15 23:23:26]: Client connected (fd = 10)[2020/10/15 23:23:26]:
(pid = 24902) (uid = 0) (gid = 0)[2
I assume the "Problem with kernel communication" error is just because
there is no nfs-server running here, but the gssproxy file exists.
Of course if I go back and insert into the .htaccess:
GssapiCredStore keytab:/xconf/httpd/keytab/httpd-www-svc.keytab
... and I make the file readable by "www" then it works, but that, of
course isn't using gssproxy either.
I read a bug report on Redhat about there being an issue with using
"GssapiLocalName on" so I removed that and it didn't make a difference.
So what is the magic bit that I'm missing to tell httpd to actually use
gssproxy? I thought the only thing was the USE_GSS_PROXY=yes
Does the application itself need to be aware of gssproxy, or is that
hidden from the application?
I even tried adding to the httpd.service:
Environment=KRB5_TRACE=/tmp/log
... hoping this would give me *something* but the file didn't even get
created.
Any feedback that you can provide would be helpful.
Jason.
2 years, 6 months
