hi
We've tested various scenarios all ending in more or less the same output: if using
Keberos-Auth to access a remote NFS share it is only working if you access the server
using password authentication (that is providing the password and then having Kerberos
tickets).
Our tested scenarios were:
1. starting from a windows client (providing a TGT) login to linux server (SSH and Sudo
access is perfectly granted by means of Kerberos auth); NFS access is denied; klist shows
no tickets "klist: Credentials cache keyring 'persistent:[uid]:[gid]' not
found")
2. starting from a windows client enforcing password auth (using IP instead of DNS name
for server), all is fine and klist shows all tickets as it was in the past
3. starting from a linux machine (after password auth and having Kerberos tickets) then
connect to another machine, same issue SSH/Sudo auth is OK, NFS share access is not
This is seen for both IDM local users and AD users (windows user is an AD user usually).
Initial ticket list from windows client:
Cached Tickets: (3)
#0> Client: rlinder @ USPLAB.LOCAL
Server: krbtgt/USPLAB.LOCAL @ USPLAB.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x60a10000 -> forwardable forwarded renewable pre_authent
name_canonicalize
Start Time: 7/22/2019 16:21:58 (local)
End Time: 7/23/2019 2:21:31 (local)
Renew Time: 7/29/2019 16:21:31 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
#1> Client: rlinder @ USPLAB.LOCAL
Server: krbtgt/USPLAB.LOCAL @ USPLAB.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent
name_canonicalize
Start Time: 7/22/2019 16:21:31 (local)
End Time: 7/23/2019 2:21:31 (local)
Renew Time: 7/29/2019 16:21:31 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
#2> Client: rlinder @ USPLAB.LOCAL
Server: cifs/labDC01.usplab.local @ USPLAB.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate
name_canonicalize
Start Time: 7/22/2019 16:21:58 (local)
End Time: 7/23/2019 2:21:31 (local)
Renew Time: 7/29/2019 16:21:31 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Then after a connection there are more tickets added
#0> Client: rlinder @ USPLAB.LOCAL
Server: krbtgt/USPLABLX.LOCAL @ USPLAB.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a10000 -> forwardable renewable pre_authent
name_canonicalize
Start Time: 7/22/2019 16:23:08 (local)
End Time: 7/23/2019 2:21:31 (local)
Renew Time: 7/29/2019 16:21:31 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
#1> Client: rlinder @ USPLAB.LOCAL
Server: krbtgt/USPLAB.LOCAL @ USPLAB.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x60a10000 -> forwardable forwarded renewable pre_authent
name_canonicalize
Start Time: 7/22/2019 16:21:58 (local)
End Time: 7/23/2019 2:21:31 (local)
Renew Time: 7/29/2019 16:21:31 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
#2> Client: rlinder @ USPLAB.LOCAL
Server: krbtgt/USPLAB.LOCAL @ USPLAB.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent
name_canonicalize
Start Time: 7/22/2019 16:21:31 (local)
End Time: 7/23/2019 2:21:31 (local)
Renew Time: 7/29/2019 16:21:31 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
#3> Client: rlinder @ USPLAB.LOCAL
Server: host/labidmclient.usplablx.local @ USPLABLX.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40ad0000 -> forwardable renewable pre_authent ok_as_delegate
name_canonicalize 0x80000
Start Time: 7/22/2019 16:23:09 (local)
End Time: 7/23/2019 2:21:31 (local)
Renew Time: 7/29/2019 16:21:31 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
#4> Client: rlinder @ USPLAB.LOCAL
Server: cifs/labDC01.usplab.local @ USPLAB.LOCAL
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate
name_canonicalize
Start Time: 7/22/2019 16:21:58 (local)
End Time: 7/23/2019 2:21:31 (local)
Renew Time: 7/29/2019 16:21:31 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
So far we had no luck in identifying the source why this happens (in our LAB and PROD
environment with different AD and IDM servers).
Rolf
-----Original Message-----
From: Rob Crittenden <rcritten(a)redhat.com>
Sent: 22 July 2019 16:26
To: Ronald Wimmer <ronaldw(a)ronzo.at>; FreeIPA users list
<freeipa-users(a)lists.fedorahosted.org>
Cc: Linder, Rolf <Rolf.Linder(a)united-security-providers.ch>
Subject: Re: [Freeipa-users] Re: Automounting homeshares partially stopped working
Ronald Wimmer wrote:
On 22.07.19 16:18, Rob Crittenden wrote:
> Rolf Linder via FreeIPA-users wrote:
>> Hi all
>>
>> We've seen the same issue at our site too.
>> Kerberos SSO logins do not work for (remote) NFS access anymore. We
>> can access the share when using password login (or after SSO login
>> by using kinit). Any hints would be greatly appreciated...
> You'll need to be sure that the user had a TGT in order to do the mount.
On a Windows machine the user automatically gets one upon login. The
strange thing is that it always works when I login from my Linux
client machine and that it does not when I am coming from Windows...
An assumption here since your workflow isn't completely clear but do you actually have
a ticket on the Linux machine after sshing in from Windows? Sure seems like you
don't.
rob