Constrained delegation cross realm
apm at one.com
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