GSS-Proxy Question with respect to gssproxy and mod_auth_gssapi

[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.

[Simo Sorce]

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).


HTH,
Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[Jason Keltz]

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.

[Simo Sorce]

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.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[Jason Keltz]

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.

[Simo Sorce]

On Mon, 2020-10-19 at 12:40 -0400, Jason Keltz wrote:
>  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? 
They can:
 - impersonate any user to the server
 - impersonate the server
 - acquire tickets and contact other services using the server's
identity.

Definitely not recommended to hand untrusted users a keytab.

However you do not need to use the server's key for password
verification.

You could use a key specifically used for password verification only,
and not used for any other purposes.
You should make sure such key cannot acquire credentials either, by
properly marking the principal in the KDC, to protect separate service
with lax configuration on principal mappings.

So you could create a principal like:
HTTP/password.verification.only(a)YOUR.REALM
And extract a key for that principal in the keytab you then use in
mod_auth_gssapi authentication.

In this case you must *not* set an acceptor name, so that whatever is
in the keytab will be used.

You will keep gssproxy current configuration to protect the actual
service key instead for when users present valid GSSAPI credentials and
do normal negotiation.

HTH,
Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

[Jason Keltz]

On 10/19/2020 12:53 PM, Simo Sorce wrote:
>  On Mon, 2020-10-19 at 12:40 -0400, Jason Keltz wrote:
> > 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?
>  They can:
>    - impersonate any user to the server
>    - impersonate the server
>    - acquire tickets and contact other services using the server's
>  identity.
>
>  Definitely not recommended to hand untrusted users a keytab.
>
>  However you do not need to use the server's key for password
>  verification.
>
>  You could use a key specifically used for password verification only,
>  and not used for any other purposes.
>  You should make sure such key cannot acquire credentials either, by
>  properly marking the principal in the KDC, to protect separate service
>  with lax configuration on principal mappings.
>
>  So you could create a principal like:
>  HTTP/password.verification.only(a)YOUR.REALM
>  And extract a key for that principal in the keytab you then use in
>  mod_auth_gssapi authentication.
>
>  In this case you must *not* set an acceptor name, so that whatever is
>  in the keytab will be used.
>
>  You will keep gssproxy current configuration to protect the actual
>  service key instead for when users present valid GSSAPI credentials and
>  do normal negotiation. 
I apologize in advance because I'm new to all of this.

I've already done exactly that as part of my original setup - I created 
"httpd-www-svc" in Kerberos.  I extracted the SPN for 
HTTP/httpd-www-svc(a)MY.REALM to a separate file.  That's the file I was 
trying to use with gssproxy to allow Apache to access without it needing 
to be readable by "www".

I'm not sure how to configure the KDC to protect the service.  I assume 
it's by adding an entry to /etc/krb5.conf?

But then you said "You will keep gssproxy current configuration to 
protect the actual service key instead for when users present valid 
GSSAPI crendeitalss and do normal negotiation.".  That part I'm not sure 
about.  If you have time, can you possibly give more description, and 
possibly an example configuration?

Thanks,

Jason.

[Simo Sorce]

On Mon, 2020-10-19 at 13:06 -0400, Jason Keltz wrote:
>  On 10/19/2020 12:53 PM, Simo Sorce wrote:
>  > On Mon, 2020-10-19 at 12:40 -0400, Jason Keltz wrote:
>  > > 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?
>  > They can:
>  >   - impersonate any user to the server
>  >   - impersonate the server
>  >   - acquire tickets and contact other services using the server's
>  > identity.
>  > 
>  > Definitely not recommended to hand untrusted users a keytab.
>  > 
>  > However you do not need to use the server's key for password
>  > verification.
>  > 
>  > You could use a key specifically used for password verification only,
>  > and not used for any other purposes.
>  > You should make sure such key cannot acquire credentials either, by
>  > properly marking the principal in the KDC, to protect separate service
>  > with lax configuration on principal mappings.
>  > 
>  > So you could create a principal like:
>  > HTTP/password.verification.only(a)YOUR.REALM
>  > And extract a key for that principal in the keytab you then use in
>  > mod_auth_gssapi authentication.
>  > 
>  > In this case you must *not* set an acceptor name, so that whatever is
>  > in the keytab will be used.
>  > 
>  > You will keep gssproxy current configuration to protect the actual
>  > service key instead for when users present valid GSSAPI credentials and
>  > do normal negotiation.
>  
>  I apologize in advance because I'm new to all of this.
>  
>  I've already done exactly that as part of my original setup - I created 
>  "httpd-www-svc" in Kerberos.  I extracted the SPN for 
>  HTTP/httpd-www-svc(a)MY.REALM to a separate file.  That's the file I was 
>  trying to use with gssproxy to allow Apache to access without it needing 
>  to be readable by "www".
>  
>  I'm not sure how to configure the KDC to protect the service.  I assume 
>  it's by adding an entry to /etc/krb5.conf? 
Given you speak about SPN I am going to assume this is a realm served
by Active Directory.
If that's the case you should be fine because by default AD does not
allow AS requests with SPNs (it requires you to use the UPN for that),
however a clever user could extract the key and figure out what is the
UPN to reassemble a keytab, so all you need to do is to configure the
account so that it cannot login anywhere (but can still perform
authentication).

If the KDC is an MIT KDC you'd have to disable TIX on the principal
(IIRC) via kadmin.

>  But then you said "You will keep gssproxy current configuration
> to 
>  protect the actual service key instead for when users present valid 
>  GSSAPI crendeitalss and do normal negotiation.".  That part I'm not sure 
>  about.  If you have time, can you possibly give more description, and 
>  possibly an example configuration? 
I am assuming you wan to allow users to login transparently and not be
asked for a password if they do have a kerberos ticket.

To do that you need to provide mod_auth_gssapi with a keytab that
contains keys for HTTP/actual.fqdn.of.the.server@REALM

If you do this you'll have single-sign-on experience.

You want to keep that keytab private, let's call it keytab-P

If you are the only person with access to the web server user, then all
you need to do is to just make sure only the webserver user can read
keytab-P, and you do not need gss-proxy at all.

However if you are using gss-proxy I assume that this is some sort of
shared account so you want to use gss-proxy to keep the keytab-P secret
from other users and accessible only from root.

In this case keytab-P is your keytab:/xconf/httpd/keytab/httpd-www-
svc.keytab which you'll keep segregated from the www user.

At this point SSO works, but password authentication doesn't work.

To fix that you create a new completely arbitrarily named principal,
say: PASSWORD-CHECK/invented-name@REALM and extract a keytab with a key
for this principal, let's call this keytab-K

Put keytab-K in a place where apache can read it, and give ownership to
apache.

Just add GssapiCredStore keytab:/path/to/keytab-K to your apache
configuration and now BasicAuth has a key to use for password checks.

Basically you end up using to distinct keytabs.

Normally, because GSS-Proxy interposes, there is no confusion of which
keytab is used, and if some odd configuration makes mod_auth_gssapi
"not" work through gssprosy it will simply fail to authenticate with
its keytab-K because users don't get tickets for a non-HTTP-randomly-
named service when they connect to your server.


There is a chance to try to attack the server if a malicious user gain
access to keytab-K and can force a fallback from gss-proxy auth to
local GSSAPI auth. To mitigate that you can set also the environment
variable:
GSSPROXY_BEHAVIOR=REMOTE_FIRST

Note that unfortunately you can't use GSSPROXY_BEHAVIOR=REMOTE_ONLY
which would be better, because in that case the shim that intercept
gss_acuire_cred_with_password() will cause an error to be returned :-/


This is as far as I can go with this workaround, it is not perfect and
may cause you some heartburn if you have issues, as it is a rather
complex and nuanced setup. But it should work.

HTH,
Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

GSS-Proxy Question with respect to nfs root

[Jason Keltz]

Hi.

I have a system configured to use krb5 NFS mounts on CentOS 7 along with 
gss-proxy.  It's a bit of a different setup because the Kerberos server 
is part of Samba AD.  Nonetheless, NFS mounts are working perfectly.  
The one thing I can't seem to figure out is NFS root.  I've seen 
instructions online for adding translations to /etc/idmapd.conf, and I 
tried that, and it wasn't working.  I then found instructions from Red 
Hat to do this type of setup in /etc/krb5.conf instead:

[realms]
…
EXAMPLE.COM = {
…
auth_to_local = 
RULE:[2:$1/$2@$0](host/[e-mail])s/.*/root/
auth_to_local = DEFAULT
}

This also doesn't seem to solve the problem.  These lines, I'm assuming, 
go on the NFS server.

I even tried changing "host/nfsclient.example.com(a)EXAMPLE.COM" to .* for 
my test setup to see if anything would happen, but it didn't.  It's not 
clear how I can verify whether those lines are being processed.

It wasn't even clear whether the "auth_to_local" lines were required in 
addition to the NFS translation lines, or separately.

I did my research and discovered what those lines mean.  I also 
discovered those lines are required instead of the NFS translation lines 
when using gss-proxy.

The problem is, I can't really figure out how to debug this issue.  With 
rpc.idmapd debugging I was seeing the following:

rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=user
rpc.idmapd: nfs4_uid_to_name: calling nsswitch->uid_to_name
rpc.idmapd: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
rpc.idmapd: nfs4_uid_to_name: final return value is 0
rpc.idmapd: Server : (user) id "0" -> name "root(a)eecs.yorku.ca"
rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=group
rpc.idmapd: nfs4_gid_to_name: calling nsswitch->gid_to_name
rpc.idmapd: nfs4_gid_to_name: nsswitch->gid_to_name returned 0
rpc.idmapd: nfs4_gid_to_name: final return value is 0
rpc.idmapd: Server : (group) id "0" -> name "root(a)eecs.yorku.ca"
rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=user
rpc.idmapd: nfs4_uid_to_name: calling nsswitch->uid_to_name
rpc.idmapd: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
rpc.idmapd: nfs4_uid_to_name: final return value is 0
rpc.idmapd: Server : (user) id "65534" -> name
"nfsnobody(a)eecs.yorku.ca"
rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=group
rpc.idmapd: nfs4_gid_to_name: calling nsswitch->gid_to_name
rpc.idmapd: nfs4_gid_to_name: nsswitch->gid_to_name returned 0
rpc.idmapd: nfs4_gid_to_name: final return value is 0
rpc.idmapd: Server : (group) id "65534" -> name
"nfsnobody(a)eecs.yorku.ca"

(with no NFS translation lines in place)..

It makes sense that root(a)eecs.yorku.ca is not a valid Kerberos user.  
root is just a local user.

Might someone have a suggestion on how to debug the processing of the 
auth_to_local lines?

I've turned on gssproxy debugging level 2, but not really seeing anything.

Thanks,

Jason.

GSS-Proxy Question with respect to nfs root

[Simo Sorce]

In which direction do you care for translation ?

GSS-Proxy does indeed uses only krb5.conf for authentication mapping
purposes, but what you should below seem to be a id -> name
translation, perhaps in order to set permissions ?

Are you having issues at authentication time ?
With gss-proxy debug at level 3 you should see the full data exchanged
as part of a GSS Accept_Sec_Context call, in the reply you should see
what name was used.

Also keep in mind that normally NFS servers by default squash root to
nobody, not sure if this is a factor. (In general using root over NFS
is discouraged).

Simo.

On Tue, 2020-11-10 at 10:03 -0500, Jason Keltz wrote:
>  Hi.
>  
>  I have a system configured to use krb5 NFS mounts on CentOS 7 along with 
>  gss-proxy.  It's a bit of a different setup because the Kerberos server 
>  is part of Samba AD.  Nonetheless, NFS mounts are working perfectly.  
>  The one thing I can't seem to figure out is NFS root.  I've seen 
>  instructions online for adding translations to /etc/idmapd.conf, and I 
>  tried that, and it wasn't working.  I then found instructions from Red 
>  Hat to do this type of setup in /etc/krb5.conf instead:
>  
>  [realms]
>  …
>  EXAMPLE.COM = {
>  …
>  auth_to_local = 
>  RULE:[2:$1/$2@$0](host/[e-mail])s/.*/root/
>  auth_to_local = DEFAULT
>  }
>  
>  This also doesn't seem to solve the problem.  These lines, I'm assuming, 
>  go on the NFS server.
>  
>  I even tried changing "host/nfsclient.example.com(a)EXAMPLE.COM" to .* for 
>  my test setup to see if anything would happen, but it didn't.  It's not 
>  clear how I can verify whether those lines are being processed.
>  
>  It wasn't even clear whether the "auth_to_local" lines were required in 
>  addition to the NFS translation lines, or separately.
>  
>  I did my research and discovered what those lines mean.  I also 
>  discovered those lines are required instead of the NFS translation lines 
>  when using gss-proxy.
>  
>  The problem is, I can't really figure out how to debug this issue.  With 
>  rpc.idmapd debugging I was seeing the following:
>  
>  rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=user
>  rpc.idmapd: nfs4_uid_to_name: calling nsswitch->uid_to_name
>  rpc.idmapd: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
>  rpc.idmapd: nfs4_uid_to_name: final return value is 0
>  rpc.idmapd: Server : (user) id "0" -> name "root(a)eecs.yorku.ca"
>  rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=group
>  rpc.idmapd: nfs4_gid_to_name: calling nsswitch->gid_to_name
>  rpc.idmapd: nfs4_gid_to_name: nsswitch->gid_to_name returned 0
>  rpc.idmapd: nfs4_gid_to_name: final return value is 0
>  rpc.idmapd: Server : (group) id "0" -> name "root(a)eecs.yorku.ca"
>  rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=user
>  rpc.idmapd: nfs4_uid_to_name: calling nsswitch->uid_to_name
>  rpc.idmapd: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
>  rpc.idmapd: nfs4_uid_to_name: final return value is 0
>  rpc.idmapd: Server : (user) id "65534" -> name
> "nfsnobody(a)eecs.yorku.ca"
>  rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=group
>  rpc.idmapd: nfs4_gid_to_name: calling nsswitch->gid_to_name
>  rpc.idmapd: nfs4_gid_to_name: nsswitch->gid_to_name returned 0
>  rpc.idmapd: nfs4_gid_to_name: final return value is 0
>  rpc.idmapd: Server : (group) id "65534" -> name
> "nfsnobody(a)eecs.yorku.ca"
>  
>  (with no NFS translation lines in place)..
>  
>  It makes sense that root(a)eecs.yorku.ca is not a valid Kerberos user.  
>  root is just a local user.
>  
>  Might someone have a suggestion on how to debug the processing of the 
>  auth_to_local lines?
>  
>  I've turned on gssproxy debugging level 2, but not really seeing anything.
>  
>  Thanks,
>  
>  Jason.
>  
>  _______________________________________________
>  gss-proxy mailing list -- gss-proxy(a)lists.fedorahosted.org
>  To unsubscribe send an email to gss-proxy-leave(a)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/[e-mail]... 
-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

GSS-Proxy Question with respect to nfs root

[Jason Keltz]

Hi Simo,

I know that root over NFS is generally frowned upon.  I don't enable 
this on all the machines.  I enable it temporarily as required 
(no_root_squash in exports), then remove it afterwards, but I really 
would like to make it work so that as required, I can use it.

After hours of experimenting, I found this:

https://bugzilla.redhat.com/show_bug.cgi?id=1559185

The result of which was this:

https://access.redhat.com/articles/4040141

Since root doesn't have a Kerberos identity, I need to (I think) 
identify as the AD machine account, then somehow map the machine account 
to root:

j1# kinit -k 'J1$'
j1# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: J1$(a)AD.EECS.YORKU.CA

Valid starting       Expires              Service principal
11/10/2020 14:47:34  11/11/2020 00:47:34 
krbtgt/AD.EECS.YORKU.CA(a)AD.EECS.YORKU.CA
     renew until 11/17/2020 14:47:34

But when I write a file on an nfs export that is mounted with 
no_root_squash (that works fine with sec=sys of course), I get:

j1# cd /mnt
j1# touch rootfile
j1# ls -al rootfile
-rw-r--r-- 1 nfsnobody nfsnobody 0 Nov 10 14:49 rootfile

So I need identity J1$(a)AD.EECS.YORKU.CA to be mapped to "root".

I placed the lines into /etc/krb5.conf on the NFS server... Obviously in 
normal operation, I wouldn't map *everything* to root, but it's just a 
test afer all in a VM:

AD.EECS.YORKU.CA = {
  auth_to_local = RULE:[2:$1/$2@$0](*)s/*/root/
  auth_to_local = DEFAULT
}

... but it's not working.  I can't even find a way to determine how 
Kerberos is processing those auth_to_local lines.  I suspect it's not.

On both the client and the server, I updated /etc/gssproxy/gssproxy.conf 
which contained only "[gssproxy]", so I added:

[gssproxy]
debug=true
debug_level=3

I restarted gssproxy.

I re-mounted the share on the client.  gssproxy logs:

Nov 10 15:04:51 j1 gssproxy[6099]: [2020/11/10 20:04:51]: Client 
connected (fd = 11)[2020/11/10 20:04:51]:  (pid = 980) (uid = 0) (gid = 
0)[2020/11/10 20:04:51]:
Nov 10 15:04:51 j1 gssproxy[6099]: [CID 11][2020/11/10 20:04:51]: 
[status] Handling query input: 0x556fc251d640 (116)
Nov 10 15:04:51 j1 gssproxy[6099]: [CID 11][2020/11/10 20:04:51]: 
[status] Processing request [0x556fc251d640 (116)]
Nov 10 15:04:51 j1 gssproxy[6099]: [CID 11][2020/11/10 20:04:51]: 
[status] Executing request 6 (GSSX_ACQUIRE_CRED) from [0x556fc251d640 (116)]
Nov 10 15:04:51 j1 gssproxy[6099]: [CID 11][2020/11/10 20:04:51]: 
gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service 
"nfs-client", euid: 0,socket: (null)
Nov 10 15:04:51 j1 gssproxy[6099]: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" 
[  ] } input_cred_handle: <Null> add_cred: 0 desired_name: <Null> 
time_req: 4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } 
cred_usage: INITIATE initiator_time_req: 0 acceptor_time_req: 0 )
Nov 10 15:04:51 j1 gssproxy[6099]: gssproxy[6100]: (OID: { 1 2 840 
113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more 
information, Client &#39;host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA&#39; not 
found in Kerberos database
Nov 10 15:04:51 j1 gssproxy[6099]: GSSX_RES_ACQUIRE_CRED( status: { 
851968 { 1 2 840 113554 1 2 2 } 2529638918 "Unspecified GSS failure.  
Minor code may provide more information" "Client 
&#39;host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA&#39; not found in Kerberos 
database" [  ] } output_cred_handle: <Null> )
Nov 10 15:04:51 j1 gssproxy[6099]: [CID 11][2020/11/10 20:04:51]: 
[status] Returned buffer 6 (GSSX_ACQUIRE_CRED) from [0x556fc251d640 
(116)]: [0x7fd4a000a470 (232)]
Nov 10 15:04:51 j1 gssproxy[6099]: [CID 11][2020/11/10 20:04:51]: 
[status] Handling query output: 0x7fd4a000a470 (232)
Nov 10 15:04:51 j1 gssproxy[6099]: [2020/11/10 20:04:51]: [status] 
Handling query reply: 0x7fd4a000a470 (232)
Nov 10 15:04:51 j1 gssproxy[6099]: [2020/11/10 20:04:51]: [status] 
Sending data: 0x7fd4a000a470 (232)
Nov 10 15:04:51 j1 gssproxy[6099]: [2020/11/10 20:04:51]: [status] 
Sending data [0x7fd4a000a470 (232)]: successful write of 232
Nov 10 15:04:51 j1 gssproxy[6099]: [CID 11][2020/11/10 20:04:51]: 
[status] Handling query input: 0x556fc251d640 (116)
Nov 10 15:04:51 j1 gssproxy[6099]: [CID 11][2020/11/10 20:04:51]: 
[status] Processing request [0x556fc251d640 (116)]
Nov 10 15:04:51 j1 gssproxy[6099]: [CID 11][2020/11/10 20:04:51]: 
[status] Executing request 6 (GSSX_ACQUIRE_CRED) from [0x556fc251d640 (116)]
Nov 10 15:04:51 j1 gssproxy[6099]: [CID 11][2020/11/10 20:04:51]: 
gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service 
"nfs-client", euid: 0,socket: (null)
Nov 10 15:04:51 j1 gssproxy[6099]: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" 
[  ] } input_cred_handle: <Null> add_cred: 0 desired_name: <Null> 
time_req: 4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } 
cred_usage: INITIATE initiator_time_req: 0 acceptor_time_req: 0 )
Nov 10 15:04:51 j1 gssproxy[6099]: gssproxy[6100]: (OID: { 1 2 840 
113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more 
information, Client &#39;host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA&#39; not 
found in Kerberos database
Nov 10 15:04:51 j1 gssproxy[6099]: GSSX_RES_ACQUIRE_CRED( status: { 
851968 { 1 2 840 113554 1 2 2 } 2529638918 "Unspecified GSS failure.  
Minor code may provide more information" "Client 
&#39;host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA&#39; not found in Kerberos 
database" [  ] } output_cred_handle: <Null> )
Nov 10 15:04:51 j1 gssproxy[6099]: [CID 11][2020/11/10 20:04:51]: 
[status] Returned buffer 6 (GSSX_ACQUIRE_CRED) from [0x556fc251d640 
(116)]: [0x7fd4a000a470 (232)]
Nov 10 15:04:51 j1 gssproxy[6099]: [CID 11][2020/11/10 20:04:51]: 
[status] Handling query output: 0x7fd4a000a470 (232)
Nov 10 15:04:51 j1 gssproxy[6099]: [2020/11/10 20:04:51]: [status] 
Handling query reply: 0x7fd4a000a470 (232)
Nov 10 15:04:51 j1 gssproxy[6099]: [2020/11/10 20:04:51]: [status] 
Sending data: 0x7fd4a000a470 (232)
Nov 10 15:04:51 j1 gssproxy[6099]: [2020/11/10 20:04:51]: [status] 
Sending data [0x7fd4a000a470 (232)]: successful write of 232

gssproxy frequently logs the &quot;host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA&quot; 
not found in Kerberos database even though it is:

# klist -k /etc/krb5.keytab | grep -i 
host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA
    1 host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA
    1 host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA
    1 host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA
    1 host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA
    1 host/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA
    1 restrictedkrbhost/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA
    1 restrictedkrbhost/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA
    1 restrictedkrbhost/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA
    1 restrictedkrbhost/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA
    1 restrictedkrbhost/j1.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA

This may have something to do with the fact that j1.eecs.yorku.ca is 
joined to AD.EECS.YORKU.CA, but it seems to work otherwise for NFS just 
fine because in krb5.conf I list:

[domain_realm]
  ad.eecs.yorku.ca = AD.EECS.YORKU.CA
  .ad.eecs.yorku.ca = AD.EECS.YORKU.CA
  eecs.yorku.ca = AD.EECS.YORKU.CA
  .eecs.yorku.ca = AD.EECS.YORKU.CA

I also have: rdns=false in [libdefaults]

Anyway, when I try to write a file as a regular system user (user "jas" 
group "tech") gssproxy logs:

ov 10 15:12:39 j1 gssproxy[6099]: [2020/11/10 20:12:39]: Failed to get 
peer's SELinux context (92:Protocol not available)
Nov 10 15:12:39 j1 gssproxy[6099]: [2020/11/10 20:12:39]: Client 
connected (fd = 11)[2020/11/10 20:12:39]:  (pid = 980) *(uid = 1004) 
(gid = 1000)*[2020/11/10 20:12:39]:
Nov 10 15:12:39 j1 gssproxy[6099]: [CID 11][2020/11/10 20:12:39]: 
[status] Handling query input: 0x556fc251d640 (116)
Nov 10 15:12:39 j1 gssproxy[6099]: [CID 11][2020/11/10 20:12:39]: 
[status] Processing request [0x556fc251d640 (116)]
Nov 10 15:12:39 j1 gssproxy[6099]: [CID 11][2020/11/10 20:12:39]: 
[status] Executing request 6 (GSSX_ACQUIRE_CRED) from [0x556fc251d640 (116)]
Nov 10 15:12:39 j1 gssproxy[6099]: [CID 11][2020/11/10 20:12:39]: 
gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service 
"nfs-client", euid: 1004,socket: (null)
Nov 10 15:12:39 j1 gssproxy[6099]: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" 
[  ] } input_cred_handle: <Null> add_cred: 0 desired_name: <Null> 
time_req: 4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } 
cred_usage: INITIATE initiator_time_req: 0 acceptor_time_req: 0 )
Nov 10 15:12:39 j1 gssproxy[6099]: gssproxy[6100]: (OID: { 1 2 840 
113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more 
information, No credentials cache found
Nov 10 15:12:39 j1 gssproxy[6099]: GSSX_RES_ACQUIRE_CRED( status: { 
851968 { 1 2 840 113554 1 2 2 } 2529639107 "Unspecified GSS failure.  
Minor code may provide more information" "No credentials cache found" [  
] } output_cred_handle: <Null> )
Nov 10 15:12:39 j1 gssproxy[6099]: [CID 11][2020/11/10 20:12:39]: 
[status] Returned buffer 6 (GSSX_ACQUIRE_CRED) from [0x556fc251d640 
(116)]: [0x7fd4a000a470 (176)]
Nov 10 15:12:39 j1 gssproxy[6099]: [CID 11][2020/11/10 20:12:39]: 
[status] Handling query output: 0x7fd4a000a470 (176)
Nov 10 15:12:39 j1 gssproxy[6099]: [2020/11/10 20:12:39]: [status] 
Handling query reply: 0x7fd4a000a470 (176)
Nov 10 15:12:39 j1 gssproxy[6099]: [2020/11/10 20:12:39]: [status] 
Sending data: 0x7fd4a000a470 (176)
Nov 10 15:12:39 j1 gssproxy[6099]: [2020/11/10 20:12:39]: [status] 
Sending data [0x7fd4a000a470 (176)]: successful write of 176
Nov 10 15:12:39 j1 gssproxy[6099]: [CID 11][2020/11/10 20:12:39]: 
[status] Handling query input: 0x556fc251d640 (116)
Nov 10 15:12:39 j1 gssproxy[6099]: [CID 11][2020/11/10 20:12:39]: 
[status] Processing request [0x556fc251d640 (116)]
Nov 10 15:12:39 j1 gssproxy[6099]: [CID 11][2020/11/10 20:12:39]: 
[status] Executing request 6 (GSSX_ACQUIRE_CRED) from [0x556fc251d640 (116)]
Nov 10 15:12:39 j1 gssproxy[6099]: [CID 11][2020/11/10 20:12:39]: 
gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service 
"nfs-client", euid: 1004,socket: (null)
Nov 10 15:12:39 j1 gssproxy[6099]: GSSX_ARG_ACQUIRE_CRED( call_ctx: { "" 
[  ] } input_cred_handle: <Null> add_cred: 0 desired_name: <Null> 
time_req: 4294967295 desired_mechs: { { 1 2 840 113554 1 2 2 } } 
cred_usage: INITIATE initiator_time_req: 0 acceptor_time_req: 0 )
Nov 10 15:12:39 j1 gssproxy[6099]: gssproxy[6100]: (OID: { 1 2 840 
113554 1 2 2 }) Unspecified GSS failure.  Minor code may provide more 
information, No credentials cache found
Nov 10 15:12:39 j1 gssproxy[6099]: GSSX_RES_ACQUIRE_CRED( status: { 
851968 { 1 2 840 113554 1 2 2 } 2529639107 "Unspecified GSS failure.  
Minor code may provide more information" "No credentials cache found" [  
] } output_cred_handle: <Null> )
Nov 10 15:12:39 j1 gssproxy[6099]: [CID 11][2020/11/10 20:12:39]: 
[status] Returned buffer 6 (GSSX_ACQUIRE_CRED) from [0x556fc251d640 
(116)]: [0x7fd4a000a4a0 (176)]
Nov 10 15:12:39 j1 gssproxy[6099]: [CID 11][2020/11/10 20:12:39]: 
[status] Handling query output: 0x7fd4a000a4a0 (176)
Nov 10 15:12:39 j1 gssproxy[6099]: [2020/11/10 20:12:39]: [status] 
Handling query reply: 0x7fd4a000a4a0 (176)
Nov 10 15:12:39 j1 gssproxy[6099]: [2020/11/10 20:12:39]: [status] 
Sending data: 0x7fd4a000a4a0 (176)
Nov 10 15:12:39 j1 gssproxy[6099]: [2020/11/10 20:12:39]: [status] 
Sending data [0x7fd4a000a4a0 (176)]: successful write of 176

Sure enough, uid is indeed 1004 and gid is 1000.  The file shows that it 
worked:

% cd /mnt
j1% touch testfile1
j1% ls -al testfile1
-rw------- 1 jas tech 0 Nov 10 15:12 testfile1

Now I do the same thing as root on j1... ah... I get nothing in the log 
from gssproxy:

# touch rootfile1
j1# ls -al rootfile1
-rw-r--r-- 1 nfsnobody nfsnobody 0 Nov 10 15:16 rootfile1

But if I write the file as "jas" again, I do get the log output...

Hopefully, this will provide more detail.

Thanks,

Jason.

On 11/10/2020 2:41 PM, Simo Sorce wrote:
>  In which direction do you care for translation ?
>
>  GSS-Proxy does indeed uses only krb5.conf for authentication mapping
>  purposes, but what you should below seem to be a id -> name
>  translation, perhaps in order to set permissions ?
>
>  Are you having issues at authentication time ?
>  With gss-proxy debug at level 3 you should see the full data exchanged
>  as part of a GSS Accept_Sec_Context call, in the reply you should see
>  what name was used.
>
>  Also keep in mind that normally NFS servers by default squash root to
>  nobody, not sure if this is a factor. (In general using root over NFS
>  is discouraged).
>
>  Simo.
>
>  On Tue, 2020-11-10 at 10:03 -0500, Jason Keltz wrote:
> > Hi.
> >
> > I have a system configured to use krb5 NFS mounts on CentOS 7 along with
> > gss-proxy.  It's a bit of a different setup because the Kerberos server
> > is part of Samba AD.  Nonetheless, NFS mounts are working perfectly.
> > The one thing I can't seem to figure out is NFS root.  I've seen
> > instructions online for adding translations to /etc/idmapd.conf, and I
> > tried that, and it wasn't working.  I then found instructions from Red
> > Hat to do this type of setup in /etc/krb5.conf instead:
> >
> > [realms]
> > …
> > EXAMPLE.COM = {
> > …
> > auth_to_local =
> > RULE:[2:$1/$2@$0](host/[e-mail])s/.*/root/
> > auth_to_local = DEFAULT
> > }
> >
> > This also doesn't seem to solve the problem.  These lines, I'm assuming,
> > go on the NFS server.
> >
> > I even tried changing &quot;host/nfsclient.example.com(a)EXAMPLE.COM&quot; to .* for
> > my test setup to see if anything would happen, but it didn't.  It's not
> > clear how I can verify whether those lines are being processed.
> >
> > It wasn't even clear whether the "auth_to_local" lines were required
> in
> > addition to the NFS translation lines, or separately.
> >
> > I did my research and discovered what those lines mean.  I also
> > discovered those lines are required instead of the NFS translation lines
> > when using gss-proxy.
> >
> > The problem is, I can't really figure out how to debug this issue.  With
> > rpc.idmapd debugging I was seeing the following:
> >
> > rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=user
> > rpc.idmapd: nfs4_uid_to_name: calling nsswitch->uid_to_name
> > rpc.idmapd: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
> > rpc.idmapd: nfs4_uid_to_name: final return value is 0
> > rpc.idmapd: Server : (user) id "0" -> name
> &quot;root(a)eecs.yorku.ca&quot;
> > rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=group
> > rpc.idmapd: nfs4_gid_to_name: calling nsswitch->gid_to_name
> > rpc.idmapd: nfs4_gid_to_name: nsswitch->gid_to_name returned 0
> > rpc.idmapd: nfs4_gid_to_name: final return value is 0
> > rpc.idmapd: Server : (group) id "0" -> name
> &quot;root(a)eecs.yorku.ca&quot;
> > rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=user
> > rpc.idmapd: nfs4_uid_to_name: calling nsswitch->uid_to_name
> > rpc.idmapd: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
> > rpc.idmapd: nfs4_uid_to_name: final return value is 0
> > rpc.idmapd: Server : (user) id "65534" -> name
> &quot;nfsnobody(a)eecs.yorku.ca&quot;
> > rpc.idmapd: nfsdcb: authbuf=gss/krb5 authtype=group
> > rpc.idmapd: nfs4_gid_to_name: calling nsswitch->gid_to_name
> > rpc.idmapd: nfs4_gid_to_name: nsswitch->gid_to_name returned 0
> > rpc.idmapd: nfs4_gid_to_name: final return value is 0
> > rpc.idmapd: Server : (group) id "65534" -> name
> &quot;nfsnobody(a)eecs.yorku.ca&quot;
> >
> > (with no NFS translation lines in place)..
> >
> > It makes sense that root(a)eecs.yorku.ca is not a valid Kerberos user.
> > root is just a local user.
> >
> > Might someone have a suggestion on how to debug the processing of the
> > auth_to_local lines?
> >
> > I've turned on gssproxy debugging level 2, but not really seeing anything.
> >
> > Thanks,
> >
> > Jason.
> >
> > _______________________________________________
> > gss-proxy mailing list -- gss-proxy(a)lists.fedorahosted.org
> > To unsubscribe send an email to gss-proxy-leave(a)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/[e-mail]...

GSS-Proxy Question with respect to nfs root

[Jason Keltz]

Hi Simo,

I've continued to experiment.

I noticed that in /etc/krb5.conf, if I define:

AD.EECS.YORKU.CA = {
     auth_to_local = RULE:[1:$1@$0](.*)s/.*/root/
     auth_to_local = DEFAULT
   }

... then any file I write actually gets mapped to root on the NFS 
client.  On the other hand if I use:

auth_to_local = RULE:[2:$1/$2@$0](.*)s/.*/root/

.. then it does not work.

I just want to see what gssproxy is seeing - user@REALM, or 
host/user@REALM because I can't make it work.  However, even with log 
level up high, gssproxy doesn't seem to divulge that information to me.  
How would I find it?

Jason.

GSS-Proxy Question with respect to nfs root

[Simo Sorce]

On Wed, 2020-11-11 at 16:24 -0500, Jason Keltz wrote:
>  Hi Simo,
>  
>  I've continued to experiment.
>  
>  I noticed that in /etc/krb5.conf, if I define:
>  
>  AD.EECS.YORKU.CA = {
>       auth_to_local = RULE:[1:$1@$0](.*)s/.*/root/
>       auth_to_local = DEFAULT
>     }
>  
>  ... then any file I write actually gets mapped to root on the NFS 
>  client.  On the other hand if I use:
>  
>  auth_to_local = RULE:[2:$1/$2@$0](.*)s/.*/root/
>  
>  .. then it does not work.
>  
>  I just want to see what gssproxy is seeing - user@REALM, or 
>  host/user@REALM because I can't make it work.  However, even with log 
>  level up high, gssproxy doesn't seem to divulge that information to me.  
>  How would I find it? 
How did you set the debug level ?

At level 1 you should already get logging of responses which include
the service name used.

However that will happen only at session establishment (At mount, or
the first time a new user walks into the mount point).

After session establishment gssproxy is not involved anymore.

HTH,
Simo.

>  Jason.
>  _______________________________________________
>  gss-proxy mailing list -- gss-proxy(a)lists.fedorahosted.org
>  To unsubscribe send an email to gss-proxy-leave(a)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/[e-mail]... 
-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc

GSS-Proxy Question with respect to nfs root

[Jason Keltz]

On 11/11/2020 4:34 PM, Simo Sorce wrote:

>  On Wed, 2020-11-11 at 16:24 -0500, Jason Keltz wrote:
> > Hi Simo,
> >
> > I've continued to experiment.
> >
> > I noticed that in /etc/krb5.conf, if I define:
> >
> > AD.EECS.YORKU.CA = {
> >       auth_to_local = RULE:[1:$1@$0](.*)s/.*/root/
> >       auth_to_local = DEFAULT
> >     }
> >
> > ... then any file I write actually gets mapped to root on the NFS
> > client.  On the other hand if I use:
> >
> > auth_to_local = RULE:[2:$1/$2@$0](.*)s/.*/root/
> >
> > .. then it does not work.
> >
> > I just want to see what gssproxy is seeing - user@REALM, or
> > host/user@REALM because I can't make it work.  However, even with log
> > level up high, gssproxy doesn't seem to divulge that information to me.
> > How would I find it?
>  How did you set the debug level ?
>
>  At level 1 you should already get logging of responses which include
>  the service name used.
>
>  However that will happen only at session establishment (At mount, or
>  the first time a new user walks into the mount point).
>
>  After session establishment gssproxy is not involved anymore.
>
>  HTH,
>  Simo. 
j1 will be mounting j2.

On j2, I set gssproxy debug level to 1 via /etc/gssproxy/gssproxy.conf. 
I commented the auth_to_local lines I added to krb5.conf. I restarted 
gssproxy, and nfs-server.

On j1, I mount j2 as root.

All I see on the server is:

Nov 11 17:52:25 j2 gssproxy[30115]: [CID 12][2020/11/11 22:52:25]: 
gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service 
"nfs-server", euid: 0,socket: /run/gssproxy.sock
Nov 11 17:52:26 j2 gssproxy[30115]: [CID 12][2020/11/11 22:52:26]: 
gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service 
"nfs-server", euid: 0,socket: /run/gssproxy.sock

Now on j1 I cd into /mnt.  There is nothing new on j2 log.

In j1 log:

Nov 11 17:52:25 j1 gssproxy[24710]: [CID 13][2020/11/11 22:52:25]: 
gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service 
"nfs-client", euid: 0,socket: (null)
Nov 11 17:52:25 j1 gssproxy[24710]: gssproxy[24711]: (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
Nov 11 17:52:26 j1 gssproxy[24710]: [CID 13][2020/11/11 22:52:26]: 
gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service 
"nfs-client", euid: 0,socket: (null)
Nov 11 17:52:26 j1 gssproxy[24710]: gssproxy[24711]: (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

How do I know what the Kerberos server is seeing when root enters /mnt?

Jason.

GSS-Proxy Question with respect to nfs root

[Jason Keltz]

On 11/11/2020 5:57 PM, Jason Keltz wrote:

>  On 11/11/2020 4:34 PM, Simo Sorce wrote:
>
> > On Wed, 2020-11-11 at 16:24 -0500, Jason Keltz wrote:
> >> Hi Simo,
> >>
> >> I've continued to experiment.
> >>
> >> I noticed that in /etc/krb5.conf, if I define:
> >>
> >> AD.EECS.YORKU.CA = {
> >>       auth_to_local = RULE:[1:$1@$0](.*)s/.*/root/
> >>       auth_to_local = DEFAULT
> >>     }
> >>
> >> ... then any file I write actually gets mapped to root on the NFS
> >> client.  On the other hand if I use:
> >>
> >> auth_to_local = RULE:[2:$1/$2@$0](.*)s/.*/root/
> >>
> >> .. then it does not work.
> >>
> >> I just want to see what gssproxy is seeing - user@REALM, or
> >> host/user@REALM because I can't make it work.  However, even with log
> >> level up high, gssproxy doesn't seem to divulge that information to me.
> >> How would I find it?
> > How did you set the debug level ?
> >
> > At level 1 you should already get logging of responses which include
> > the service name used.
> >
> > However that will happen only at session establishment (At mount, or
> > the first time a new user walks into the mount point).
> >
> > After session establishment gssproxy is not involved anymore.
> >
> > HTH,
> > Simo.
>
>  j1 will be mounting j2.
>
>  On j2, I set gssproxy debug level to 1 via 
>  /etc/gssproxy/gssproxy.conf. I commented the auth_to_local lines I 
>  added to krb5.conf. I restarted gssproxy, and nfs-server.
>
>  On j1, I mount j2 as root.
>
>  All I see on the server is:
>
>  Nov 11 17:52:25 j2 gssproxy[30115]: [CID 12][2020/11/11 22:52:25]: 
>  gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service 
>  "nfs-server", euid: 0,socket: /run/gssproxy.sock
>  Nov 11 17:52:26 j2 gssproxy[30115]: [CID 12][2020/11/11 22:52:26]: 
>  gp_rpc_execute: executing 9 (GSSX_ACCEPT_SEC_CONTEXT) for service 
>  "nfs-server", euid: 0,socket: /run/gssproxy.sock
>
>  Now on j1 I cd into /mnt.  There is nothing new on j2 log.
>
>  In j1 log:
>
>  Nov 11 17:52:25 j1 gssproxy[24710]: [CID 13][2020/11/11 22:52:25]: 
>  gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service 
>  "nfs-client", euid: 0,socket: (null)
>  Nov 11 17:52:25 j1 gssproxy[24710]: gssproxy[24711]: (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
>  Nov 11 17:52:26 j1 gssproxy[24710]: [CID 13][2020/11/11 22:52:26]: 
>  gp_rpc_execute: executing 6 (GSSX_ACQUIRE_CRED) for service 
>  "nfs-client", euid: 0,socket: (null)
>  Nov 11 17:52:26 j1 gssproxy[24710]: gssproxy[24711]: (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
>
>  How do I know what the Kerberos server is seeing when root enters /mnt?
>  
I set KRB5_TRACE in the gssproxy systemd file, and was able to see that 
when I mount, this is logged:

31897] 1605136730.732640: Decrypted AP-REQ with server principal 
host/j2.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA: aes256-cts/D0C0
[31897] 1605136730.732641: AP-REQ ticket: J1$(a)AD.EECS.YORKU.CA -> 
host/j2.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA, session key aes256-cts/7182
[31897] 1605136730.732642: Negotiated enctype based on authenticator: 
aes256-cts
[31897] 1605136730.732643: Authenticator contains subkey: aes256-cts/75C8
[31897] 1605136730.732645: Creating AP-REP, time 1605136725.715634, 
subkey aes256-cts/5373, seqnum 215357562
[31897] 1605136730.732661: Destroying ccache MEMORY:internal_31902
[31897] 1605136730.732664: Decrypted AP-REQ with server principal 
host/j2.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA: aes256-cts/D0C0
[31897] 1605136730.732665: AP-REQ ticket: J1$(a)AD.EECS.YORKU.CA -> 
host/j2.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA, session key aes256-cts/7182
[31897] 1605136730.732666: Negotiated enctype based on authenticator: 
aes256-cts
[31897] 1605136730.732667: Authenticator contains subkey: aes256-cts/F956
[31897] 1605136730.732669: Creating AP-REP, time 1605136725.715654, 
subkey aes256-cts/9848, seqnum 677303300
[31897] 1605136730.732685: Destroying ccache MEMORY:internal_31902

When I change into the directory, as me, I see this:

[31897] 1605136635.104658: Decrypted AP-REQ with server principal 
host/j2.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA: aes256-cts/D0C0
[31897] 1605136635.104659: AP-REQ ticket: jas(a)AD.EECS.YORKU.CA -> 
host/j2.ad.eecs.yorku.ca(a)AD.EECS.YORKU.CA, session key aes256-cts/5FF0
[31897] 1605136635.104660: Negotiated enctype based on authenticator: 
aes256-cts
[31897] 1605136635.104661: Authenticator contains subkey: aes256-cts/F714
[31897] 1605136635.104663: Creating AP-REP, time 1605136635.34123, 
subkey aes256-cts/43E0, seqnum 389443622
[31897] 1605136635.104679: Destroying ccache MEMORY:internal_31902

But when I change into the directory as "root", nothing is logged into 
KRB5_TRACE.

I enable the auth_to_local rule: auth_to_local = 
RULE:[1:$1@$0](J1$.*)s/.*/root/ again, and it doesn't work but then I 
realized that the $ in J1 could be escaped, and the rule now becomes:

BUT...  auth_to_local = RULE:[1:$1@$0](J1\$@AD.EECS.YORKU.CA)s/.*/root/

... which finally works!!!

Persistence does pay off I guess. I'd still like your help understanding 
those other GSS errors, but I'll get back to that tomorrow as a separate 
issue.

Jason.

GSS-Proxy Question with respect to nfs root

[Simo Sorce]

On Wed, 2020-11-11 at 18:34 -0500, Jason Keltz wrote:
>  But when I change into the directory as "root", nothing is
> logged into 
>  KRB5_TRACE. 
Note that setting debug level to 3 would automatically ad KRB5_TRACE in
the logs (as the man page says :).

>  I enable the auth_to_local rule: auth_to_local = 
>  RULE:[1:$1@$0](J1$.*)s/.*/root/ again, and it doesn't work but then I 
>  realized that the $ in J1 could be escaped, and the rule now becomes:
>  
>  BUT...  auth_to_local = RULE:[1:$1@$0](J1\$@AD.EECS.YORKU.CA)s/.*/root/
>  
>  ... which finally works!!! 
Yes if you look carefully this seem to be an AD environment so the UPN
for a workstation is shortname$ instead of host/fqdn, so you have to
account for that in auth_to_local.

>  Persistence does pay off I guess. I'd still like your help
> understanding 
>  those other GSS errors, but I'll get back to that tomorrow as a separate 
>  issue. 
Glad you solved it.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc