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?
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?
Cheers, Ronald
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.
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?
Cheers, Ronald
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.
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
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.
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?
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?
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.
On 16.03.23 09:50, Alexander Bokovoy wrote:
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.
Thanks for taking the time to give such a detailed answer! It clarified a lot. I really do appreciate that!
Cheers, Ronald
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Ronald Wimmer