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.
1) what libkrb5 version do you have installed ?
2) 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.
Jason.