Re: Trying to mount a KRB NFS share from windows in cross-domain trust

Trying to mount a KRB NFS share from windows in cross-domain trust

[Alexander Bokovoy]

On Срд, 20 жні 2025, Orion Poplawski wrote:
> On 8/20/25 10:23, Orion Poplawski wrote:
> > On 8/20/25 10:01, Orion Poplawski wrote:
> > On 8/20/25 00:51, Alexander Bokovoy wrote:
> > > On Аўт, 19 жні 2025, Orion Poplawski via gss-proxy wrote:
> > > > We have an IPA client in the NWRA.COM realm and are trying to do a krb5   
> > > > nfs mount from a Windows server in the AD.NWRA.COM realm.  The two        
> > > > realms are connected by a two way trust.  Mounting of CIFS shares works   
> > > > fine.
> > > > # mount -t nfs -v -o sec=krb5,vers=4.1 SERVER.ad.nwra.com:test_nfs /mnt   
> > > > mount.nfs: timeout set for Mon Aug 18 16:11:46 2025                       
> > > > mount.nfs: trying text-based options                                      
> > > > 'sec=krb5,vers=4.1,addr=10.X.X.X,clientaddr=10.X.X.X'                     
> > > > mount.nfs: mount(2): Permission denied                                    
> > > > mount.nfs: access denied by server while mounting SERVER.ad.nwra.com:test_nfs
> > > > I think this is the issue:
> > > > Aug 18 16:09:48 gssproxy[1121023]: [CID 11][2025/08/18 23:09:48]:         
> > > > gp_rpc_execute: executing 8 (GSSX_INIT_SEC_CONTEXT) for ser               
> > > > vice "nfs-client", euid: 0,socket: (null)                                 
> > > > Aug 18 16:09:48 gssproxy[1121023]:     GSSX_ARG_INIT_SEC_CONTEXT( call_ctx:
> > > > { "" [  ] } context_handle: <Null> cred_handle: {                         
> > > > [1]"host/[e-mail]" [ { "host/                         
> > > > [2][e-mail]" { 1 2 840 113554 1 2 2 } INITIATE 84879 0 [ { [
> > > > krb5.set.allowed... ] [ ................... ] } ] } ]                     
> > > > [ .............2..... ] 0 } target_name: [3]"[e-mail]"      
> > > > mech_type: { 1 2 840 113554 1 2 2 } req_flags: 2 time_req: 0 input_cb:    
> > > > <Null> input_token: <Null> [ { [ sync.modified.cr...                      
> > > > ] [ 64656661756c740 ] } ] )                                               
> > > > Aug 18 16:09:48 gssproxy[1121023]: [CID 11][2025/08/18 23:09:48]:         
> > > > Credentials allowed by configuration                                      
> > > > Aug 18 16:09:48 gssproxy[1121023]:     GSSX_RES_INIT_SEC_CONTEXT( status: 
> > > > { 851968 { 1 2 840 113554 1 2 2 } 2529638919 "Unspe                       
> > > > cified GSS failure.  Minor code may provide more information" "Server     
> > > > [4]krbtgt/[e-mail] not found in Kerberos datab                
> > > > ase" [  ] } context_handle: <Null> output_token: <Null> )                 
> > > > Aug 18 16:09:48 rpc.gssd[1120142]: WARNING: Failed to create krb5 context 
> > > > for user with uid 0 for server [5][e-mail].                          
> > > > nwra.com                                                                  
> > > > Aug 18 16:09:48 rpc.gssd[1120142]: WARNING: Failed to create machine krb5 
> > > > context with cred cache [6]FILE:/tmp/krb5ccmachine_NWR                    
> > > > A.COM for server SERVER.ad.nwra.com                                       
> > > > Aug 18 16:09:48 rpc.gssd[1120142]: ERROR: Failed to create machine krb5   
> > > > context with any credentials cache for server SERVER.ad.nwra.com          
> > > > Aug 18 16:09:48 rpc.gssd[1120142]: do_error_downcall(0x7f69a33a7700): uid 0
> > > > err -13                                                                   
> > > > Aug 18 16:09:48 rpc.gssd[1120142]: destroying client nfs/clnt59           
> > > > Aug 18 16:09:48 rpc.gssd[1120142]: freeing client nfs/clnt59              
> > > > Aug 18 16:09:48 rpc.gssd[1120142]: destroying client nfs/clnt58
> > > > Shouldn't [7]krbtgt/[e-mail] be [8]krbtgt/[e-mail]?
> > > In order for IPA client principal [9]host/[e-mail] to request a
> > > service ticket to a service [10]nfs/[e-mail], NWRA.COM
> > > KDC must being able to issue a cross-realm TGT and a referral to           
> > > AD.NWRA.COM's KDC. Cross-realm TGT is issued using                         
> > > [11]krbtgt/[e-mail] principal.
> > > Are you sure there is a two-way trust between the domains? If KDC on       
> > > NWRA.COM side answers that there is no [12]krbtgt/[e-mail] in  
> > > its database, this means the trust is not a two-way one.
> > Apparently I just assumed that the trust was two-way, but it wasn't.  I     
> > modified it to enable two way and now I can resolve                         
> > [13]krbtgt/[e-mail].  Now I'm getting to:
> > Aug 20 08:56:22 kronos.mry.nwra.com nfsidmap[41203]: nss_getpwnam: name     
> > 'SYSTEM@NT AUTHORITY' does not map into domain 'nwra.com'                   
> > Aug 20 08:56:22 kronos.mry.nwra.com nfsidmap[41205]: nss_name_to_gid: name  
> > 'SYSTEM@NT AUTHORITY' does not map into domain 'nwra.com'
> > Which looks like idmapping issues between linux and windows.  Time to read up
> > on that.
> > Thanks!
> > I did this in idmapd.conf:
> > SYSTEM@NT AUTHORITY = nobody
> > which seemed to move things forward.  Now on the server I get:
> > Server for NFS was unable to obtain security information for the GSS       
> > user account IPA\host/CLIENT.nwra.com.
> > So more idmapping, now on the windows side.
>
> actually, I wonder if that comes from hosts not having SIDs in IPA?
>
> # ipa host-show CLIENT --all | grep ipantsecurityidentifier

There are two problems here. You can associate SID with a principal in
IPA but that will not help because AD DC does not know how to resolve
those SIDs for a Kerberos service principal in IPA. We have no way to
provide this information in ipasam module in Samba DC. The module at
this point only supports users and groups, not services.

If you'd run NFS server on a Linux machine enrolled into Active
Directory, that should work over trust just fine. It is Windows Server
NFS server that needs a SID.

Trying to mount a KRB NFS share from windows in cross-domain trust

[Orion Poplawski]

On 8/21/25 07:39, Alexander Bokovoy wrote:
> On Срд, 20 жні 2025, Orion Poplawski wrote:
> > On 8/20/25 10:23, Orion Poplawski wrote:   > On 8/20/25 10:01, 
> > Orion Poplawski wrote:   >On 8/20/25 00:51, Alexander Bokovoy wrote: 
> >   >>On Аўт, 19 жні 2025, Orion Poplawski via gss-proxy wrote:   >>>We 
> > have an IPA client in the NWRA.COM realm and are trying to do a 
> > krb5     >>>nfs mount from a Windows server in the AD.NWRA.COM 
> > realm.  The two >>>realms are connected by a two way trust.  Mounting 
> > of CIFS shares works >>>fine.   >>># mount -t nfs -v -o 
> > sec=krb5,vers=4.1 SERVER.ad.nwra.com:test_nfs /mnt     >>>mount.nfs: 
> > timeout set for Mon Aug 18 16:11:46 2025 >>>mount.nfs: trying 
> > text-based options
> > > > > 'sec=krb5,vers=4.1,addr=10.X.X.X,clientaddr=10.X.X.X'   
> > > > > mount.nfs: mount(2): Permission denied >>>mount.nfs: access denied
> >
> > by server while mounting SERVER.ad.nwra.com:test_nfs
> >   >>>I think this is the issue:   >>>Aug 18 16:09:48 
> > gssproxy[1121023]: [CID 11][2025/08/18 23:09:48]:
> > > > > gp_rpc_execute: executing 8 (GSSX_INIT_SEC_CONTEXT) for ser 
> > > > > vice "nfs-client", euid: 0,socket:
> >
> > (null)                                   >>>Aug 18 16:09:48 
> > gssproxy[1121023]:     GSSX_ARG_INIT_SEC_CONTEXT( call_ctx:
> >   >>>{ "" [  ] } context_handle: <Null> cred_handle: {
> > > > > [1]"host/[e-mail]" [ { "host/ 
> > > > > [2][e-mail]" { 1 2 840 113554 1 2 2 } INITIATE
> >
> > 84879 0 [ { [
> >   >>>krb5.set.allowed... ] [ ................... ] } ] } 
> > ]                       >>>[ .............2..... ] 0 } target_name: 
> > [3]"[e-mail]" >>>mech_type: { 1 2 840 113554 1 2 2 } 
> > req_flags: 2 time_req: 0 input_cb:      >>><Null> input_token: <Null> 
> > [ { [ sync.modified.cr... >>>] [ 64656661756c740 ] } ] ) >>>Aug 18 
> > 16:09:48 gssproxy[1121023]: [CID 11][2025/08/18 23:09:48]:
> > > > > Credentials allowed by configuration >>>Aug 18 16:09:48
> >
> > gssproxy[1121023]: GSSX_RES_INIT_SEC_CONTEXT( status:   >>>{ 851968 { 
> > 1 2 840 113554 1 2 2 } 2529638919 "Unspe >>>cified GSS failure.  
> > Minor code may provide more information" "Server
> > > > > [4]krbtgt/[e-mail] not found in Kerberos
> >
> > datab                  >>>ase" [  ] } context_handle: <Null> 
> > output_token: <Null> ) >>>Aug 18 16:09:48 rpc.gssd[1120142]: WARNING: 
> > Failed to create krb5 context   >>>for user with uid 0 for server 
> > [5][e-mail]. >>>nwra.com   >>>Aug 18 16:09:48 rpc.gssd[1120142]: 
> > WARNING: Failed to create machine krb5   >>>context with cred cache 
> > [6]FILE:/tmp/krb5ccmachine_NWR >>>A.COM for server SERVER.ad.nwra.com
> > > > > Aug 18 16:09:48 rpc.gssd[1120142]: ERROR: Failed to create machine
> >
> > krb5     >>>context with any credentials cache for server 
> > SERVER.ad.nwra.com            >>>Aug 18 16:09:48 rpc.gssd[1120142]: 
> > do_error_downcall(0x7f69a33a7700): uid 0
> >   >>>err -13   >>>Aug 18 16:09:48 rpc.gssd[1120142]: destroying 
> > client nfs/clnt59             >>>Aug 18 16:09:48 rpc.gssd[1120142]: 
> > freeing client nfs/clnt59 >>>Aug 18 16:09:48 rpc.gssd[1120142]: 
> > destroying client nfs/clnt58   >>>Shouldn't 
> > [7]krbtgt/[e-mail] be [8]krbtgt/[e-mail]?
> >   >>In order for IPA client principal 
> > [9]host/[e-mail] to request a
> >   >>service ticket to a service 
> > [10]nfs/[e-mail], NWRA.COM
> >   >>KDC must being able to issue a cross-realm TGT and a referral 
> > to             >>AD.NWRA.COM's KDC. Cross-realm TGT is issued using
> > > > [11]krbtgt/[e-mail] principal.   >>Are you sure there
> >
> > is a two-way trust between the domains? If KDC on         >>NWRA.COM 
> > side answers that there is no [12]krbtgt/[e-mail] in
> > > > its database, this means the trust is not a two-way one.
> > >
> > > Apparently I just assumed that the trust was two-way, but it
> >
> > wasn't.  I       >modified it to enable two way and now I can resolve
> > > [13]krbtgt/[e-mail].  Now I'm getting to:   >Aug 20
> >
> > 08:56:22 kronos.mry.nwra.com nfsidmap[41203]: nss_getpwnam: name     
> >   >'SYSTEM@NT AUTHORITY' does not map into domain 
> > 'nwra.com'                     >Aug 20 08:56:22 kronos.mry.nwra.com 
> > nfsidmap[41205]: nss_name_to_gid: name >'SYSTEM@NT AUTHORITY' does 
> > not map into domain 'nwra.com'   >Which looks like idmapping issues 
> > between linux and windows.  Time to read up
> >   >on that. >Thanks!   > I did this in idmapd.conf:   > SYSTEM@NT 
> > AUTHORITY = nobody   > which seemed to move things forward.  Now on 
> > the server I get:   > Server for NFS was unable to obtain security 
> > information for the GSS         > user account 
> > IPA\host/CLIENT.nwra.com.   > So more idmapping, now on the windows 
> > side.   actually, I wonder if that comes from hosts not having SIDs 
> > in IPA?   # ipa host-show CLIENT --all | grep ipantsecurityidentifier
>
> There are two problems here. You can associate SID with a principal in
> IPA but that will not help because AD DC does not know how to resolve
> those SIDs for a Kerberos service principal in IPA. We have no way to
> provide this information in ipasam module in Samba DC. The module at
> this point only supports users and groups, not services.
>
> If you'd run NFS server on a Linux machine enrolled into Active
> Directory, that should work over trust just fine. It is Windows Server
> NFS server that needs a SID.

Thanks for the confirmation.  Is there a place that would be appropriate 
to file an RFE?

Trying to mount a KRB NFS share from windows in cross-domain trust

[Alexander Bokovoy]

On Чцв, 21 жні 2025, Orion Poplawski wrote:
> > > Time to read up
> > >   >on that. >Thanks!   > I did this in idmapd.conf:   > SYSTEM@NT 
> > > AUTHORITY = nobody   > which seemed to move things forward.  Now 
> > > on the server I get:   > Server for NFS was unable to obtain 
> > > security information for the GSS         > user account 
> > > IPA\host/CLIENT.nwra.com.   > So more idmapping, now on the 
> > > windows side.   actually, I wonder if that comes from hosts not 
> > > having SIDs in IPA?   # ipa host-show CLIENT --all | grep 
> > > ipantsecurityidentifier
> >
> > There are two problems here. You can associate SID with a principal in
> > IPA but that will not help because AD DC does not know how to resolve
> > those SIDs for a Kerberos service principal in IPA. We have no way to
> > provide this information in ipasam module in Samba DC. The module at
> > this point only supports users and groups, not services.
> >
> > If you'd run NFS server on a Linux machine enrolled into Active
> > Directory, that should work over trust just fine. It is Windows Server
> > NFS server that needs a SID.
>
> Thanks for the confirmation.  Is there a place that would be 
> appropriate to file an RFE?

We currently do not plan to add this but you can file an issue at
https://pagure.io/freeipa/issues/.