Constrained Delegation

Shawn M Emery shawn.emery at
Sat Sep 7 02:59:55 EDT 2013

We were wanting to provide additional checks beyond constrained 
delegations where the proxy principal has access controls associated for 
which client principals are allowed to be delegated from.  I know that 
this could be controlled by creating authz data that the subsequent 
target service can check, but this seems rather inefficient in a 
non-cross-realm case in which the KDC can easily make these policy checks.

My draft proposal includes a new LDAP attribute of the proxy principal:


which would define the various client principals in which the proxy 
principal is allowed to delegate for.  Perhaps this could be tied into 
group memberships in order to reduce redundant definitions across proxy 
principals.  The ordering of checks by the KDC would be to check to make 
sure that the target principal is in the krbAllowedToDelegateTo set and 
if so then infer the krbAllowedToDelegateFor for the client principal.  
If not defined then then fall-back to the existing behavior of success 
else if the client is found in the krbAllowedToDelegateFor set then 
succeed else fail.  The pseudo-code would like the following:

     {DelegateTo} == proxy && {DelegateFor} == client -> succeed
     {DelegateTo} == proxy && {DelegateFor} == NULL -> succeed
     {DelegateTo} == proxy && {DelegateFor} != client -> fail

The code-points would entail the following:

/* Constrained delegation for */
#define KRB5_KDB_FLAGS_S4U \

#define KRB5_TL_CONSTRAINED_DELEGATION4_ACL 0x0700 /* Each entry is a 
permitted UPN */

##### A list of principals to which a service principal can delegate for.
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes:  (
                 NAME 'krbAllowedToDelegateFor'
                 EQUALITY caseExactIA5Match
                 SUBSTR caseExactSubstringsMatch

I just wanted to get your thoughts on the idea before I consider this 


More information about the krbdev mailing list