On to, 16 maalis 2023, Ronald Wimmer wrote:
On 16.03.23 09:09, Alexander Bokovoy via FreeIPA-users 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.
Thanks for clarifying this. Up to now I thought that "trusted for
delegation" stands for all Kerberos credentials whereas it actually
refers to the TGT only, right?
That's only what matters for unconstrained delegation (OK_AS_DELEGATE).
For constrained delegation there is a special process through which a
server in the middle would request a service ticket from a KDC on behalf
of the user. This process assumes several things:
- KDC is configured to allow the issuance
- an application that requests a ticket follows a special process
- an application has a service ticket presented to it by the user
The process is described in the Microsoft's MS-SFU (Services for User)
Kerberos extensions and is fairly complex in itself.
When you login to SSH server, the SSH daemon will validate a service
ticket presented to it by the SSH client and will throw it away because
it is not needed anymore. You would have no Kebreros ticket in the
credential cache of your logged-in session on this machine. This means
the next application (NFS client) cannot perform its request to KDC to
ask for a ticket to NFS server on behalf of the user because:
- it does not have a user's service ticket to itself (host/.. service
that both NFS client and SSH server can share),
- this ticket, even if it was present there, is not forwardable
- NFS client also generally does not understand the special process
that KDC requires Kerberos clients to use to request constrained
delegation tickets.
GSSProxy knowns this process and if NFS client is configured to use
GSSProxy, it could also be configured to use constrained delegation as
well. However, this needs additional setup by administrators because:
- GSSProxy still has no user's service ticket to host/.. service, so it
has to use another extension to mint one for itself using S4U2Self
mechanism, impersonating the user. This is not a default setup, we
expect a TGT to be present in the credentials cache.
- This ticket needs to be allowed to be used for asking a ticket for
NFS service, by administrators.
In general the latter sequence is a no-go for a general server that
wants to mount NFS shares and act as a user on them while not having a
user's TGT. If it was, it would be then able to impersonate any users in
the realm for that purpose.
In FreeIPA there are only two places we set up constrained delegation by
default to allow IPA web framework to talk to LDAP service and to Samba
on user's behalf for management purposes. IPA web framework is able to
use both service tickets and mint own one because it also supports
transition between protocols -- e.g. users might authenticate to IPA web
framework with TLS client certificates and then IPA web framework would
operate with Kerberos on their behalf when talking to LDAP or Samba.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
