On Mon, 2020-10-19 at 10:14 -0400, Jason Keltz wrote:
On 10/19/2020 8:59 AM, Simo Sorce wrote:
On Fri, 2020-10-16 at 16:39 -0400, Jason Keltz wrote:
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.
Hi Jason, I assume you have a custom install of gssproxy as well here.
So 2 questions.
- what libkrb5 version do you have installed ?
- Have you configured gssproxy as a GSSAPI mechanism ?
See man 8 gssproxy-mech for more info on how to do (2).
Hi Simo,
Thanks for your message.
I'm actually just using the OS provided gssproxy. I don't have a custom install of that.
In terms of libkrb5, in /usr/lib64 I see:
lrwxrwxrwx 1 root root 14 May 6 12:22 /usr/lib64/libkrb5.so -> libkrb5.so.3.3 lrwxrwxrwx 1 root root 14 May 6 12:22 /usr/lib64/libkrb5.so.3 -> libkrb5.so.3.3 -rwxr-xr-x 1 root root 967760 Mar 31 2020 /usr/lib64/libkrb5.so.3.3 lrwxrwxrwx 1 root root 21 May 6 12:22 /usr/lib64/libkrb5support.so -> libkrb5support.so.0.1 lrwxrwxrwx 1 root root 21 May 6 12:22 /usr/lib64/libkrb5support.so.0 -> libkrb5support.so.0.1 -rwxr-xr-x 1 root root 67104 Mar 31 2020 /usr/lib64/libkrb5support.so.0.1
I see /etc/gss/mech.d/gssproxy.conf containing:
# GSS-API mechanism plugins # # Mechanism Name Object Identifier Shared Library Path Other Options gssproxy_v1 2.16.840.1.113730.3.8.15.1 /usr/lib64/gssproxy/proxymech.so <interposer>
... which is just the default setup, but I don't see any reason why it wouldn't work at this point.
Ah, sorry, I just realized this is for password based authentication.
Unfortunately hand-over for that operation is not supported in the gssproxy version you are using.
In fact it is something I am working on upstream krb5 now, to provide a proper interface via gss_acquire_cred_from() that will allow me to change proxy to allow password based validation to be performed via the proxy.
So I am afraid what you are experiencing is expected at this time, for password based authentication apache needs direct access to a key it can use.
Simo.