XPost: linux.debian.bugs.dist, linux.kernel   
   From: TWR@tylerwross.com   
      
   On 11/18/25 10:52 AM, Scott Mayhew wrote:   
   > Oh!  I see the problem.  If the automatically acquired service ticket   
   > for a normal user is using aes256-cts-hmac-sha1-96, then I'm assuming   
   > the machine credential is also using aes256-cts-hmac-sha1-96.   
   > Run 'klist -ce /tmp/krb5ccmachine_IPA.TWRLAB.NET' to check.  You can't   
   > use 'kvno -e' to choose a different encryption type.  Why are you doing   
   > that?   
      
   Aha! Thank you!   
      
   That's exactly the case: the machine credential is   
   aes256-cts-hmac-sha1-96.   
      
   So, taking a step back for context/background: this issue was escalated    
   to me by someone attempting to use constrained delegation via gssproxy.    
   In the course of troubleshooting that, we found (by examining the    
   krb5kdc logs on the IPA server) that the NFS service ticket acquired by    
   gssproxy had an aes256-cts-hmac-sha384-192 session key.   
      
   Not understanding that the machine and user tickets must having matching    
   enctypes, I ended up down this rabbit hole thinking the problem was with    
   the SHA2 enctypes. Sorry to bring you all with me on that misadventure.   
      
      
      
   The actual issue at hand then seems to be that gssproxy is requesting    
   (and receiving) a service ticket with an unusable (for the NFS mount)    
   enctype, when performing constrained delegation/S4U2Proxy.   
      
   krb5kdc logs of gssproxy performing S4U2Self and S4U2Proxy:Nov 18    
   18:06:51 directory.ipa.twrlab.net krb5kdc[8463](info): TGS_REQ (8 etypes    
   {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),    
   aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),    
   UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23),    
   camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) 10.108.2.105:    
   ISSUE: authtime 1763506600, etypes {rep=aes256-cts-hmac-sha1-96(18),    
   tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)},    
   host/nfsclient.ipa.twrlab.net@IPA.TWRLAB.NET for    
   host/nfsclient.ipa.twrlab.net@IPA.TWRLAB.NET   
   Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8463](info): ...    
   PROTOCOL-TRANSITION s4u-client=jsmith@IPA.TWRLAB.NET   
   Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8463](info): closing    
   down fd 4   
   Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8465](info): TGS_REQ (4    
   etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),    
   aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17)}) 10.108.2.105:    
   ISSUE: authtime 1763506600, etypes {rep=aes256-cts-hmac-sha1-96(18),    
   tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha384-192(20)},    
   host/nfsclient.ipa.twrlab.net@IPA.TWRLAB.NET for    
   nfs/nfssrv.ipa.twrlab.net@IPA.TWRLAB.NET   
   Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8465](info): ...    
   CONSTRAINED-DELEGATION s4u-client=jsmith@IPA.TWRLAB.NET   
   Nov 18 18:06:51 directory.ipa.twrlab.net krb5kdc[8465](info): closing    
   down fd 11   
      
      
   On the Fedora 43 client, gssproxy also acquires an   
   aes256-cts-hmac-sha384-192 service ticket, but the machine credential is    
   aes256-cts-hmac-sha384-192 and everything works as-expected.   
      
      
   TWR   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)