On ma, 22 heinä 2019, Rolf Linder via FreeIPA-users wrote:
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")
By default, there is
no TGT delegation from Windows client to Linux
server, thus you don't get the TGT on the Linux side and thus NFS client
cannot request a service ticket to nfs/.. service principal.
As there is no TGT delegation, this is completely expected.
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
Yes, at this point you are doing actual TGT acquisition on Linux server
side by help of SSSD backend to your PAM authentication in sshd. This is
also expected.
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
Same as (1), TGT delegation does not happen, thus not possible to obtain
tickets to other services on the Linux server.
You need to decide for your environment whether you are allowing TGT
delegation from the client side to the Linux server. This is typically
controlled by the client itself.
For example, on Linux systems, if you are using 'ssh' client tool,
'ssh -K' would enable GSSAPI delegation (forwarding) of the credentials
from the client side. Corresponding ssh_config option is
GSSAPIDelegateCredentials
Forward (delegate) credentials to the server. The default is no.
On Windows side it depends on the SSH client at use. In PuTTY it is
controlled this way:
https://documentation.help/PuTTY/config-ssh-auth-gssapi-delegation.html
There are two other methods that are applied by coordinating activities
of the service that wants to use another service in the name of a user
and Kerberos KDC(s) that control both services and users. For that
configuration to be useful, you need to trust the service that obtains a
ticket to NFS service in lieu of the user and the application which
represents that original service has to know how to perform S4U2Proxy
operation. I don't think NFS client actually is capable to do that on
Linux. We use the latter approach in IPA framework -- when you connect
to IPA API end-point (with ipa CLI or Web UI), it is trusted to obtain
Kerberos ticket on your behalf to IPA LDAP server.
If you want concise overview of how it all works from Windows side, see
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-authsod/c...
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
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-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/freeipa-users@lists.fedoraho...
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland