On 15.03.23 11:45, Alexander Bokovoy wrote:
On ke, 15 maalis 2023, Ronald Wimmer wrote:
On 15.03.23 10:12, Alexander Bokovoy via FreeIPA-users wrote:
On ti, 14 maalis 2023, Ronald Wimmer via FreeIPA-users wrote:
We enrolled a RHEL9 server (ipa client) in order to replace an old one (Centos 7.9). Unfortunately, windows users could not access their kerberized NFS home share.
Today I rechecked the server and saw that the "trusted for delegation" flag was not set. (it was set on the old Centos server) I enabled it and now it seems to work.
Was this probably just a coincidence or can it be explained somehow?
If you enrolled a new server, it does not have 'trusted for delegation' by default. If it is the same hostname, during enrollment the object in LDAP is removed, so all the flags on it are removed as well. For all purposes, this is a new object, nothing from old state is preserved.
The documentation says:
OK_AS_DELEGATE Use this flag to specify Kerberos tickets trusted for delegation. Active directory (AD) clients check the OK_AS_DELEGATE flag on the Kerberos ticket to determine whether the user credentials can be forwarded or delegated to the specific server. AD forwards the ticket-granting ticket (TGT) only to services or hosts with OK_AS_DELEGATE set. With this flag, system security services daemon (SSSD) can add the AD user TGT to the default Kerberos credentials cache on the IdM client machine.
Is it needed that the TGT ticket can be forwarded to the server in order to let the server fetch the NFS-Ticket needed?
Yes, in the current implementation. We are working on supporting resource-based constrained delegation (RBCD) which is required by Microsoft to allow delegation of user credentials without TGT.
Why do I only see the TGT and no NFS ticket on the target server?
Depends on how you have it set up. When using GSSProxy for NFS, it would be encrypted and not visible by the klist.
What I do not fully understand is the fact that I could login to that particular machine using my Kerberos credentials but NFS did not work. Why does a kerberized user login work without having "trusted for delegation" set on that particular target host?
Cheers, Ronald