On 16.03.23 09:09, Alexander Bokovoy wrote:
On to, 16 maalis 2023, Ronald Wimmer wrote:
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?
Kerberos based login (I assume to SSH server) will authenticate against
SSH daemon. That's all it needs to do, no TGT delegation is needed for
that.
NFS client needs to authenticate to NFS server and if it uses GSSAPI, it
needs a valid service ticket to nfs/... service. If that ticket does not
exist in the credentials cache associated with the user under which a
process trying to access an NFS mount runs, then NFS client would try to
obtain the service ticket. To do that, it needs a TGT.
When you logged in via SSH protocol, if you have authenticated with
Kerberos, your TGT is not delegated by default, hence your credential
cache after login will not have a TGT and NFS client could not obtain a
service ticket to nfs/... service.
So "trusted for delegation" only refers to the TGT delegation, right?
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
