Constrained delegation cross realm

Peter Mogensen apm at
Fri Apr 4 04:44:38 EDT 2014


Currently cross-realm S4U2proxy is explicitly disabled in 

For some use cases it could be useful to do this however. Unfortunately 
the decision to enable it in cases where the security implications are 
understood is not just a small patch to the code... it actually affects 
the on-the-wire protocol. More specifically: How is signing of 
AD-SIGNEDPATH done and with which key.

I found this old discussion: 

Are there any news on this issue?
Like Loves suggestion to checksum the AD-SIGNEDPATH with the target 
realm cross-realm key when issuing cross-ream TGTs?


PS: Also ... if anyone has pointers to the intention of the 
"method_data" field of KRB5SignedPath. Is it just an unspecified 
typed-hole for applications to put stuff into or was there a specific 
use case behind the design?

More information about the krbdev mailing list