On 10/19/2020 10:55 AM, Simo Sorce wrote:
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.
>> 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.
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.
Hi Simo,
This is unfortunate. I've spent a lot time trying to make this work.
However, it's good to know that it was just something I wasn't doing right.
What could a regular user do with the keytab file if they got a hold of
it - run a web server which purports to be the web server?
Jason.