K5Wiki - User contributions [en]

Projects/KerberosDelegationACL

2014-09-10T21:38:01Z

ShawnEmery:

{{project-early}}

'''Background'''

Customers would like greater access controls for constrained delegation. The current implementation provides ACLs for S4U2Proxy requests to restrict which target services the KDC can issue for proxy principals, but does not have provisions for which user principals that the proxy principal can request service tickets on behalf of.

'''Design'''

The proposed solution is implemented in the LDAP back-end only. The proposed attributes and classes are:

attributeTypes: ( <OID to be under KIT>
NAME 'memberPrincipal'
DESC 'Principal names member of a groupOfPrincipals group'
EQUALITY caseExactIA5Match
SUBSTR caseExactSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26)

objectClasses: ( <OID to be under KIT>
NAME 'groupOfPrincipals'
SUP top AUXILIARY
MUST ( cn )
MAY ( memberPrincipal ))

attributeTypes: ( <OID to be under KIT>
NAME 'AllowToImpersonate'
DESC 'Principals that can be impersonated'
SUP distinguishedName)

attributeTypes: ( <OID to be under KIT>
NAME 'AllowedTarget'
DESC 'Target principals alowed to get a ticket for'
SUP distinguishedName)

objectClasses: ( <OID to be under KIT>
NAME 'Krb5DelegationACL'
SUP groupOfPrincipals STRUCTURAL
MAY ( AllowToImpersonate $ AllowedTarget ))

Groupings are proposed given that one instance could be used across multiple entries instead of having to define these multiple times for each entry.

groupOfPrincipals is first created (which may contain a single principal) for clients and targets, and then joining all together into an 'ACL object'.

Note that in the schema, lack of AllowToImpersonate means ALL clients can be impersonated. This may not be adhere to conservative security practices, but is in line with the general behavior for constrained delegation access, has better usability, and performance. We haven't implemented it yet, but also you could have regexes in memberPrincipal for additional flexibility.

This schema allows us to resolve the ACL using a single LDAP query (if your LDAP server supports the dereference control). The implementation could try the dereference control query first and then fall-back to a join control query after the first query fails.

We find this schema was the optimal compromise between the flexibility we needed and the complexity we wanted to allow, and simpler ones would prevent us from doing what's needed in a useful manner.

The only drawback is that you cannot fit this into kadmin as it is, because it requires to be able to represent grouping mechanism and ACL objects, it would be nice if kadmin could be extended so that it is flexible enough to allow this kind of representation.

'''Use Cases'''

The main use case is to restrict which user principals are allowed to be impersonated by the proxy principal for the target service principal. Administrators that want to limit access to certain users for target services can use the ACL design without needing to update target service applications/systems to use interpret authorization data. This assumes a non-cross realm environment.

This use case can be expanded to allow for a set of multiple users to be impersonated by a set of proxy principals for a set of target principals. This is accomplished with out having to maintain separate ACL lists for various target services by using groupings similar to network groups.

'''Potential Conflicts with Existing Implementations'''

The closest functionality to Kerberos Delegation ACLs can be found in Windows 2012. This configuration can be accomplished in Windows by setting the PrincipalsAllowedToDelegateToAccount attribute to the proxy services for the target services. The following procedures gives an example on how this is accomplished:

---begin procedures---

In regards to Windows Server 2012: The "Delegation" tab is still present through the AD Users and Computers interface, but has the traditional behavior of the front-end selecting which resource services it can delegate to, instead of selecting which front-end services can delegate to the resource service. The security tab is not present in the AD Users and Computers interface, but rather through the AD Administrative Center. So to emulate the functionality of the Delegation ACL (using the same actors as described in the KerberosDelegationACL project page), in the AD environment:

1. Create a group "allowed-users" with "shawn@KERBEROS.ORG" and "simo@KERBEROS.ORG" as members.
2. Select "ldap-server-1"s and "ldap-server-2"s security tab and add "allowed-users".
3. Create another group "http-ldap-delegation" with "HTTP/http-proxy-1.kerberos.org@KERBEROS.ORG", "HTTP/http-proxy-2.kerberos.org@KERBEROS.ORG", and "HTTP/http-proxy-3.kerberos.org@KERBEROS.ORG" as members.
4. Then restrict the delegation group to the resource with the following invocation:
set-adcomputer ldap-server-1 -PrincipalsAllowedToDelegateToAccount http-ldap-delegation
set-adcomputer ldap-server-2 -PrincipalsAllowedToDelegateToAccount http-ldap-delegation

So above, the KDC will restrict the resource ticket issuance for S4U2Proxy requests to http-ldap-delegation. The user access to the resource will be controlled by the allowed-users group, which differs from the Kerberos Delegation ACL project by the fact that the authorization is performed by the application rather than enforced by the KDC. Note that the above should also be supported through x-realms.

---end procedures---

There a couple of benefits that the proposed project entails that justifies why having different implementations for somewhat similar functionality:

1. Policy decisions can be made by the KDC w/o having to rely on updating application servers to perform the policy enforcement against the user.
2. Bindings are/can be user-to-service controlled providing finer granular authorization to said services.

'''Documentation'''

Kerberos Delegation ACLs allow for fine-grained access controls for Services For Users to Proxy (S4U2Proxy) (i.e. Constrained Delegation) requests. This allows a set of users to have access to a specified set of services through set of proxy services. This binding is referenced during S4U2Proxy requests to determine if the KDC will accept or reject the client request. Currently this configuration is only supported when using LDAP as a backend to the KDC. The following documents how to configure an example ACL for S4U2Proxy requests:

We want to allow our HTTP server cluster to impersonate 2 users (shawn and simo) against the LDAP server cluster:

First we create a group of users:

dn: cn=allowed-users,dc=kerberos,dc=org
objectclass: groupOfPrincipals
cn: cn=allowed-users
memberPrincipal: shawn@KERBEROS.ORG
memberPrincipal: simo@KERBEROS.ORG

Then a group of target servers (we assume there may be multiple copies all equally accessible):

dn: cn=LDAP-Servers,dc=kerberos,dc=org
objectclass: groupOfPrincipals
cn: LDAP-Servers
memberPrincipal: ldap/ldap-server-1.kerberos.org@KERBEROS.ORG
memberPrincipal: ldap/ldap-server-2.kerberos.org@KERBEROS.ORG

Finally we create the allow rule which binds clients, targets, and the proxy service:

dn: cn=http-ldap-delegation,dc=kerberos,dc=org
objectclass: groupOfPrincipals
objectclass: Krb5DelegationACL
cn: http-ldap-delegation
AllowToImpersonate: cn=allowed-users,dc=kerberos,dc=org
AllowedTarget: cn=LDAP-Servers,kdc=kerberos,dc=org
memberPrincipal: HTTP/http-proxy-1.kerberos.org@KERBEROS.ORG
memberPrincipal: HTTP/http-proxy-2.kerberos.org@KERBEROS.ORG
memberPrincipal: HTTP/http-proxy-3.kerberos.org@KERBEROS.ORG

'''Testing'''

Currently the GSS-API test suite provides S4U test modules which could be expanded to include Kerberos Delegation ACL tests that tests both success and failure conditions:

----------------

Assertion: KDACL1

allowed users: user1, user2
specified proxy service: proxy1, proxy2
allowed target: service1, service2

where proxy1 requests a service ticket to service2 on behalf of user1.

Expectation: S4U2Proxy request succeeds
----------------

Assertion: KDACL2

allowed users: user1, user2
specified proxy service: proxy1, proxy2
allowed target: service1, service2

where proxy1 requests a service ticket to service2 on behalf of user3.

Expectation: S4U2Proxy request fails
----------------

Assertion: KDACL3

allowed users: user1, user2
specified proxy service: proxy1, proxy2
allowed target: service1, service2

where proxy3 requests a service ticket to service2 on behalf of user1.

Expectation: S4U2Proxy request fails
----------------

Assertion: KDACL4

allowed users: user1, user2
specified proxy service: proxy1, proxy2
allowed target: service1, service2

where proxy1 requests a service ticket to service3 on behalf of user1.

Expectation: S4U2Proxy request fails
----------------

Assertion: KDACL5

allowed users: user1, user2
specified proxy service: proxy1, proxy2
allowed target: service1, service2

where proxy2 requests a service ticket to service1 on behalf of user2.

Expectation: S4U2Proxy request succeeds

Projects/KerberosDelegationACL

2014-09-03T05:21:22Z

ShawnEmery:

{{project-early}}

'''Background'''

Customers would like greater access controls for constrained delegation. The current implementation provides ACLs for S4U2Proxy requests to restrict which target services the KDC can issue for proxy principals, but does not have provisions for which user principals that the proxy principal can request service tickets on behalf of.

'''Design'''

The proposed solution is implemented in the LDAP back-end only. The proposed attributes and classes are:

attributeTypes: ( 2.16.840.1.113730.3.8.11.20
NAME 'memberPrincipal'
DESC 'Principal names member of a groupOfPrincipals group'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15)

objectClasses: ( 2.16.840.1.113730.3.8.12.6
NAME 'groupOfPrincipals'
SUP top AUXILIARY
MUST ( cn )
MAY ( memberPrincipal ))

attributeTypes: ( 2.16.840.1.113730.3.8.11.21
NAME 'AllowToImpersonate'
DESC 'Principals that can be impersonated'
SUP distinguishedName)

attributeTypes: ( 2.16.840.1.113730.3.8.11.22
NAME 'AllowedTarget'
DESC 'Target principals alowed to get a ticket for'
SUP distinguishedName)

objectClasses: ( 2.16.840.1.113730.3.8.12.7
NAME 'Krb5DelegationACL'
SUP groupOfPrincipals STRUCTURAL
MAY ( AllowToImpersonate $ AllowedTarget ))

Groupings are proposed given that one instance could be used across multiple entries instead of having to define these multiple times for each entry.

groupOfPrincipals is first created (which may contain a single principal) for clients and targets, and then joining all together into an 'ACL object'.

Note that in the schema, lack of AllowToImpersonate means ALL clients can be impersonated. This may not be adhere to conservative security practices, but is in line with the general behavior for constrained delegation access, has better usability, and performance. We haven't implemented it yet, but also you could have regexes in memberPrincipal for additional flexibility.

This schema allows us to resolve the ACL using a single LDAP query (if your LDAP server supports the dereference control). The implementation could try the dereference control query first and then fall-back to a join control query after the first query fails.

We find this schema was the optimal compromise between the flexibility we needed and the complexity we wanted to allow, and simpler ones would prevent us from doing what's needed in a useful manner.

The only drawback is that you cannot fit this into kadmin as it is, because it requires to be able to represent grouping mechanism and ACL objects, it would be nice if kadmin could be extended so that it is flexible enough to allow this kind of representation.

'''Use Cases'''

The main use case is to restrict which user principals are allowed to be impersonated by the proxy principal for the target service principal. Administrators that want to limit access to certain users for target services can use the ACL design without needing to update target service applications/systems to use interpret authorization data. This assumes a non-cross realm environment.

This use case can be expanded to allow for a set of multiple users to be impersonated by a set of proxy principals for a set of target principals. This is accomplished with out having to maintain separate ACL lists for various target services by using groupings similar to network groups.

'''Potential Conflicts with Existing Implementations'''

The closest functionality to Kerberos Delegation ACLs can be found in Windows 2012. This configuration can be accomplished in Windows by setting the PrincipalsAllowedToDelegateToAccount attribute to the proxy services for the target services. The following procedures gives an example on how this is accomplished:

---begin procedures---

In regards to Windows Server 2012: The "Delegation" tab is still present through the AD Users and Computers interface, but has the traditional behavior of the front-end selecting which resource services it can delegate to, instead of selecting which front-end services can delegate to the resource service. The security tab is not present in the AD Users and Computers interface, but rather through the AD Administrative Center. So to emulate the functionality of the Delegation ACL (using the same actors as described in the KerberosDelegationACL project page), in the AD environment:

1. Create a group "allowed-users" with "shawn@KERBEROS.ORG" and "simo@KERBEROS.ORG" as members.
2. Select "ldap-server-1"s and "ldap-server-2"s security tab and add "allowed-users".
3. Create another group "http-ldap-delegation" with "HTTP/http-proxy-1.kerberos.org@KERBEROS.ORG", "HTTP/http-proxy-2.kerberos.org@KERBEROS.ORG", and "HTTP/http-proxy-3.kerberos.org@KERBEROS.ORG" as members.
4. Then restrict the delegation group to the resource with the following invocation:
set-adcomputer ldap-server-1 -PrincipalsAllowedToDelegateToAccount http-ldap-delegation
set-adcomputer ldap-server-2 -PrincipalsAllowedToDelegateToAccount http-ldap-delegation

So above, the KDC will restrict the resource ticket issuance for S4U2Proxy requests to http-ldap-delegation. The user access to the resource will be controlled by the allowed-users group, which differs from the Kerberos Delegation ACL project by the fact that the authorization is performed by the application rather than enforced by the KDC. Note that the above should also be supported through x-realms.

---end procedures---

There a couple of benefits that the proposed project entails that justifies why having different implementations for somewhat similar functionality:

1. Policy decisions can be made by the KDC w/o having to rely on updating application servers to perform the policy enforcement against the user.
2. Bindings are/can be user-to-service controlled providing finer granular authorization to said services.

'''Documentation'''

Kerberos Delegation ACLs allow for fine-grained access controls for Services For Users to Proxy (S4U2Proxy) (i.e. Constrained Delegation) requests. This allows a set of users to have access to a specified set of services through set of proxy services. This binding is referenced during S4U2Proxy requests to determine if the KDC will accept or reject the client request. Currently this configuration is only supported when using LDAP as a backend to the KDC. The following documents how to configure an example ACL for S4U2Proxy requests:

We want to allow our HTTP server cluster to impersonate 2 users (shawn and simo) against the LDAP server cluster:

First we create a group of users:

dn: cn=allowed-users,dc=kerberos,dc=org
objectclass: groupOfPrincipals
cn: cn=allowed-users
memberPrincipal: shawn@KERBEROS.ORG
memberPrincipal: simo@KERBEROS.ORG

Then a group of target servers (we assume there may be multiple copies all equally accessible):

dn: cn=LDAP-Servers,dc=kerberos,dc=org
objectclass: groupOfPrincipals
cn: LDAP-Servers
memberPrincipal: ldap/ldap-server-1.kerberos.org@KERBEROS.ORG
memberPrincipal: ldap/ldap-server-2.kerberos.org@KERBEROS.ORG

Finally we create the allow rule which binds clients, targets, and the proxy service:

dn: cn=http-ldap-delegation,dc=kerberos,dc=org
objectclass: groupOfPrincipals
objectclass: Krb5DelegationACL
cn: http-ldap-delegation
AllowToImpersonate: cn=allowed-users,dc=kerberos,dc=org
AllowedTarget: cn=LDAP-Servers,kdc=kerberos,dc=org
memberPrincipal: HTTP/http-proxy-1.kerberos.org@KERBEROS.ORG
memberPrincipal: HTTP/http-proxy-2.kerberos.org@KERBEROS.ORG
memberPrincipal: HTTP/http-proxy-3.kerberos.org@KERBEROS.ORG

'''Testing'''

Currently the GSS-API test suite provides S4U test modules which could be expanded to include Kerberos Delegation ACL tests that tests both success and failure conditions:

----------------

Assertion: KDACL1

allowed users: user1, user2
specified proxy service: proxy1, proxy2
allowed target: service1, service2

where proxy1 requests a service ticket to service2 on behalf of user1.

Expectation: S4U2Proxy request succeeds
----------------

Assertion: KDACL2

allowed users: user1, user2
specified proxy service: proxy1, proxy2
allowed target: service1, service2

where proxy1 requests a service ticket to service2 on behalf of user3.

Expectation: S4U2Proxy request fails
----------------

Assertion: KDACL3

allowed users: user1, user2
specified proxy service: proxy1, proxy2
allowed target: service1, service2

where proxy3 requests a service ticket to service2 on behalf of user1.

Expectation: S4U2Proxy request fails
----------------

Assertion: KDACL4

allowed users: user1, user2
specified proxy service: proxy1, proxy2
allowed target: service1, service2

where proxy1 requests a service ticket to service3 on behalf of user1.

Expectation: S4U2Proxy request fails
----------------

Assertion: KDACL5

allowed users: user1, user2
specified proxy service: proxy1, proxy2
allowed target: service1, service2

where proxy2 requests a service ticket to service1 on behalf of user2.

Expectation: S4U2Proxy request succeeds

Projects/KerberosDelegationACL

2014-09-01T04:00:37Z

ShawnEmery:

{{project-early}}

'''Background'''

Customers would like greater access controls for constrained delegation. The current implementation provides ACLs for S4U2Proxy requests to restrict which target services the KDC can issue for proxy principals, but does not have provisions for which user principals that the proxy principal can request service tickets on behalf of.

'''Design'''

The proposed solution is implemented in the LDAP back-end only. The proposed attributes and classes are:

attributeTypes: ( 2.16.840.1.113730.3.8.11.20
NAME 'memberPrincipal'
DESC 'Principal names member of a groupOfPrincipals group'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15)

objectClasses: ( 2.16.840.1.113730.3.8.12.6
NAME 'groupOfPrincipals'
SUP top AUXILIARY
MUST ( cn )
MAY ( memberPrincipal ))

attributeTypes: ( 2.16.840.1.113730.3.8.11.21
NAME 'AllowToImpersonate'
DESC 'Principals that can be impersonated'
SUP distinguishedName)

attributeTypes: ( 2.16.840.1.113730.3.8.11.22
NAME 'AllowedTarget'
DESC 'Target principals alowed to get a ticket for'
SUP distinguishedName)

objectClasses: ( 2.16.840.1.113730.3.8.12.7
NAME 'Krb5DelegationACL'
SUP groupOfPrincipals STRUCTURAL
MAY ( AllowToImpersonate $ AllowedTarget ))

Groupings are proposed given that one instance could be used across multiple entries instead of having to define these multiple times for each entry.

groupOfPrincipals is first created (which may contain a single principal) for clients and targets, and then joining all together into an 'ACL object'.

Note that in the schema, lack of AllowToImpersonate means ALL clients can be impersonated. This may not be adhere to conservative security practices, but is in line with the general behavior for constrained delegation access, has better usability, and performance. We haven't implemented it yet, but also you could have regexes in memberPrincipal for additional flexibility.

This schema allows us to resolve the ACL using a single LDAP query (if your LDAP server supports the dereference control). The implementation could try the dereference control query first and then fall-back to a join control query after the first query fails.

We find this schema was the optimal compromise between the flexibility we needed and the complexity we wanted to allow, and simpler ones would prevent us from doing what's needed in a useful manner.

The only drawback is that you cannot fit this into kadmin as it is, because it requires to be able to represent grouping mechanism and ACL objects, it would be nice if kadmin could be extended so that it is flexible enough to allow this kind of representation.

'''Use Cases'''

The main use case is to restrict which user principals are allowed to be impersonated by the proxy principal for the target service principal. Administrators that want to limit access to certain users for target services can use the ACL design without needing to update target service applications/systems to use interpret authorization data. This assumes a non-cross realm environment.

This use case can be expanded to allow for a set of multiple users to be impersonated by a set of proxy principals for a set of target principals. This is accomplished with out having to maintain separate ACL lists for various target services by using groupings similar to network groups.

'''Potential Conflicts with Existing Implementations'''

After investigating w2k12, there could be a way to deploy something with similar functionality.

---begin procedures---

In regards to Windows Server 2012: The "Delegation" tab is still present through the AD Users and Computers interface, but has the traditional behavior of the front-end selecting which resource services it can delegate to, instead of selecting which front-end services can delegate to the resource service. The security tab is not present in the AD Users and Computers interface, but rather through the AD Administrative Center. So to emulate the functionality of the Delegation ACL (using the same actors as described in the KerberosDelegationACL project page), in the AD environment:

1. Create a group "allowed-users" with "shawn@KERBEROS.ORG" and "simo@KERBEROS.ORG" as members.
2. Select "ldap-server-1"s and "ldap-server-2"s security tab and add "allowed-users".
3. Create another group "http-ldap-delegation" with "HTTP/http-proxy-1.kerberos.org@KERBEROS.ORG", "HTTP/http-proxy-2.kerberos.org@KERBEROS.ORG", and "HTTP/http-proxy-3.kerberos.org@KERBEROS.ORG" as members.
4. Then restrict the delegation group to the resource with the following invocation:
set-adcomputer ldap-server-1 -PrincipalsAllowedToDelegateToAccount http-ldap-delegation
set-adcomputer ldap-server-2 -PrincipalsAllowedToDelegateToAccount http-ldap-delegation

So above, the KDC will restrict the resource ticket issuance for S4U2Proxy requests to http-ldap-delegation. The user access to the resource will be controlled by the allowed-users group, which differs from the Delegation ACL project by the fact that the authorization is performed by the application rather than enforced by the KDC. Note that the above should also be supported through x-realms.

---end procedures---

The benefits of the proposed project justifies having differences between the vendor implementations:

1. Policy decisions can be made by the KDC w/o having to rely on updating application servers to perform the policy enforcement against the user.
2. Bindings are/can be user-to-service controlled providing finer granular authorization to said services.

'''Documentation'''

Kerberos Delegation ACLs allow for fine-grained access controls for Services For Users to Proxy (S4U2Proxy) (i.e. Constrained Delegation) requests. This allows a set of users to have access to a specified set of services through set of proxy services. This binding is referenced during S4U2Proxy requests to determine if the KDC will accept or reject the client request. Currently this configuration is only supported when using LDAP as a backend to the KDC. The following documents how to configure an example ACL for S4U2Proxy requests:

We want to allow our HTTP server cluster to impersonate 2 users (shawn and simo) against the LDAP server cluster:

First we create a group of users:

dn: cn=allowed-users,dc=kerberos,dc=org
objectclass: groupOfPrincipals
cn: cn=allowed-users
memberPrincipal: shawn@KERBEROS.ORG
memberPrincipal: simo@KERBEROS.ORG

Then a group of target servers (we assume there may be multiple copies all equally accessible):

dn: cn=LDAP-Servers,dc=kerberos,dc=org
objectclass: groupOfPrincipals
cn: LDAP-Servers
memberPrincipal: ldap/ldap-server-1.kerberos.org@KERBEROS.ORG
memberPrincipal: ldap/ldap-server-2.kerberos.org@KERBEROS.ORG

Finally we create the allow rule which binds clients, targets, and the proxy service:

dn: cn=http-ldap-delegation,dc=kerberos,dc=org
objectclass: groupOfPrincipals
objectclass: Krb5DelegationACL
cn: http-ldap-delegation
AllowToImpersonate: cn=allowed-users,dc=kerberos,dc=org
AllowedTarget: cn=LDAP-Servers,kdc=kerberos,dc=org
memberPrincipal: HTTP/http-proxy-1.kerberos.org@KERBEROS.ORG
memberPrincipal: HTTP/http-proxy-2.kerberos.org@KERBEROS.ORG
memberPrincipal: HTTP/http-proxy-3.kerberos.org@KERBEROS.ORG

'''Testing'''

Currently the GSS-API test suite provides S4U test modules which could be expanded to include Kerberos Delegation ACL tests that tests both success and failure conditions:

----------------

Assertion: KDACL1

allowed users: user1, user2
specified proxy service: proxy1, proxy2
allowed target: service1, service2

where proxy1 requests a service ticket to service2 on behalf of user1.

Expectation: S4U2Proxy request succeeds
----------------

Assertion: KDACL2

allowed users: user1, user2
specified proxy service: proxy1, proxy2
allowed target: service1, service2

where proxy1 requests a service ticket to service2 on behalf of user3.

Expectation: S4U2Proxy request fails
----------------

Assertion: KDACL3

allowed users: user1, user2
specified proxy service: proxy1, proxy2
allowed target: service1, service2

where proxy3 requests a service ticket to service2 on behalf of user1.

Expectation: S4U2Proxy request fails
----------------

Assertion: KDACL4

allowed users: user1, user2
specified proxy service: proxy1, proxy2
allowed target: service1, service2

where proxy1 requests a service ticket to service3 on behalf of user1.

Expectation: S4U2Proxy request fails
----------------

Assertion: KDACL5

allowed users: user1, user2
specified proxy service: proxy1, proxy2
allowed target: service1, service2

where proxy2 requests a service ticket to service1 on behalf of user2.

Expectation: S4U2Proxy request succeeds

Projects/KerberosDelegationACL

2014-06-25T16:28:33Z

ShawnEmery:

{{project-early}}

'''Background'''

Customers would like greater access controls for constrained delegation. The current implementation provides ACLs for S4U2Proxy requests to restrict which target services the KDC can issue for proxy principals, but does not have provisions for which user principals that the proxy principal can request service tickets on behalf of.

'''Design'''

The proposed solution is implemented in the LDAP back-end only. The proposed attributes and classes are:

attributeTypes: ( 2.16.840.1.113730.3.8.11.20
NAME 'memberPrincipal'
DESC 'Principal names member of a groupOfPrincipals group'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15)

objectClasses: ( 2.16.840.1.113730.3.8.12.6
NAME 'groupOfPrincipals'
SUP top AUXILIARY
MUST ( cn )
MAY ( memberPrincipal ))

attributeTypes: ( 2.16.840.1.113730.3.8.11.21
NAME 'AllowToImpersonate'
DESC 'Principals that can be impersonated'
SUP distinguishedName)

attributeTypes: ( 2.16.840.1.113730.3.8.11.22
NAME 'AllowedTarget'
DESC 'Target principals alowed to get a ticket for'
SUP distinguishedName)

objectClasses: ( 2.16.840.1.113730.3.8.12.7
NAME 'Krb5DelegationACL'
SUP groupOfPrincipals STRUCTURAL
MAY ( AllowToImpersonate $ AllowedTarget ))

Groupings are proposed given that one instance could be used across multiple entries instead of having to define these multiple times for each entry.

groupOfPrincipals is first created (which may contain a single principal) for clients and targets, and then joining all together into an 'ACL object'.

Note that in the schema, lack of AllowToImpersonate means ALL clients can be impersonated. This may not be adhere to conservative security practices, but is in line with the general behavior for constrained delegation access, has better usability, and performance. We haven't implemented it yet, but also you could have regexes in memberPrincipal for additional flexibility.

This schema allows us to resolve the ACL using a single LDAP query (if your LDAP server supports the dereference control). The implementation could try the dereference control query first and then fall-back to a join control query after the first query fails.

We find this schema was the optimal compromise between the flexibility we needed and the complexity we wanted to allow, and simpler ones would prevent us from doing what's needed in a useful manner.

The only drawback is that you cannot fit this into kadmin as it is, because it requires to be able to represent grouping mechanism and ACL objects, it would be nice if kadmin could be extended so that it is flexible enough to allow this kind of representation.

'''Use Cases'''

The main use case is to restrict which user principals are allowed to be impersonated by the proxy principal for the target service principal. Administrators that want to limit access to certain users for target services can use the ACL design without needing to update target service applications/systems to use interpret authorization data. This assumes a non-cross realm environment.

This use case can be expanded to allow for a set of multiple users to be impersonated by a set of proxy principals for a set of target principals. This is accomplished with out having to maintain separate ACL lists for various target services by using groupings similar to network groups.

'''Example'''

We want to allow our HTTP server cluster to impersonate 2 users (shawn and simo) against the LDAP server cluster:

First we create a group of users:

dn: cn=allowed-users,SUFFIX
objectclass: groupOfPrincipals
cn: cn=allowed-users
memberPrincipal: shawn@KERBEROS.ORG
memberPrincipal: simo@KERBEROS.ORG

Then a group of target servers (we assume there may be multiple copies all equally accessible):

dn: cn=LDAP-Servers,SUFFIX
objectclass: groupOfPrincipals
cn: LDAP-Servers
memberPrincipal: ldap/ldap-server-1.kerberos.org@KERBEROS.ORG
memberPrincipal: ldap/ldap-server-2.kerberos.org@KERBEROS.ORG

Finally we create the allow rule which binds clients, targets, and the proxy service:

dn: cn=http-ldap-delegation,SUFFIX
objectclass: groupOfPrincipals
objectclass: Krb5DelegationACL
cn: http-ldap-delegation
AllowToImpersonate: cn=allowed-users,SUFFIX
AllowedTarget: cn=LDAP-Servers,SUFFIX
memberPrincipal: HTTP/http-proxy-1.kerberos.org@KERBEROS.ORG
memberPrincipal: HTTP/http-proxy-2.kerberos.org@KERBEROS.ORG
memberPrincipal: HTTP/http-proxy-3.kerberos.org@KERBEROS.ORG

'''Potential Conflicts'''

After investigating w2k12, there could be a way to deploy something with similar functionality.

---begin procedures---

In regards to Windows Server 2012: The "Delegation" tab is still present through the AD Users and Computers interface, but has the traditional behavior of the front-end selecting which resource services it can delegate to, instead of selecting which front-end services can delegate to the resource service. The security tab is not present in the AD Users and Computers interface, but rather through the AD Administrative Center. So to emulate the functionality of the Delegation ACL (using the same actors as described in the KerberosDelegationACL project page), in the AD environment:

1. Create a group "allowed-users" with "shawn@KERBEROS.ORG" and "simo@KERBEROS.ORG" as members.
2. Select "ldap-server-1"s and "ldap-server-2"s security tab and add "allowed-users".
3. Create another group "http-ldap-delegation" with "HTTP/http-proxy-1.kerberos.org@KERBEROS.ORG", "HTTP/http-proxy-2.kerberos.org@KERBEROS.ORG", and "HTTP/http-proxy-3.kerberos.org@KERBEROS.ORG" as members.
4. Then restrict the delegation group to the resource with the following invocation:
set-adcomputer ldap-server-1 -PrincipalsAllowedToDelegateToAccount http-ldap-delegation
set-adcomputer ldap-server-2 -PrincipalsAllowedToDelegateToAccount http-ldap-delegation

So above, the KDC will restrict the resource ticket issuance for S4U2Proxy requests to http-ldap-delegation. The user access to the resource will be controlled by the allowed-users group, which differs from the Delegation ACL project by the fact that the authorization is performed by the application rather than enforced by the KDC. Note that the above should also be supported through x-realms.

---end procedures---

The benefits of the proposed project justifies having differences between the vendor implementations:

1. Policy decisions can be made by the KDC w/o having to rely on updating application servers to perform the policy enforcement against the user.
2. Bindings are/can be user-to-service controlled providing finer granular authorization to said services.

Projects/KerberosDelegationACL

2014-06-25T16:27:48Z

ShawnEmery:

{{project-early}}

'''Background'''

Customers would like greater access controls for constrained delegation. The current implementation provides ACLs for S4U2Proxy requests to restrict which target services the KDC can issue for proxy principals, but does not have provisions for which user principals that the proxy principal can request service tickets on behalf of.

'''Design'''

The proposed solution is implemented in the LDAP back-end only. The proposed attributes and classes are:

attributeTypes: ( 2.16.840.1.113730.3.8.11.20
NAME 'memberPrincipal'
DESC 'Principal names member of a groupOfPrincipals group'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15)

objectClasses: ( 2.16.840.1.113730.3.8.12.6
NAME 'groupOfPrincipals'
SUP top AUXILIARY
MUST ( cn )
MAY ( memberPrincipal ))

attributeTypes: ( 2.16.840.1.113730.3.8.11.21
NAME 'AllowToImpersonate'
DESC 'Principals that can be impersonated'
SUP distinguishedName)

attributeTypes: ( 2.16.840.1.113730.3.8.11.22
NAME 'AllowedTarget'
DESC 'Target principals alowed to get a ticket for'
SUP distinguishedName)

objectClasses: ( 2.16.840.1.113730.3.8.12.7
NAME 'Krb5DelegationACL'
SUP groupOfPrincipals STRUCTURAL
MAY ( AllowToImpersonate $ AllowedTarget ))

Groupings are proposed given that one instance could be used across multiple entries instead of having to define these multiple times for each entry.

groupOfPrincipals is first created (which may contain a single principal) for clients and targets, and then joining all together into an 'ACL object'.

Note that in the schema, lack of AllowToImpersonate means ALL clients can be impersonated. This may not be adhere to conservative security practices, but is in line with the general behavior for constrained delegation access, has better usability, and performance. We haven't implemented it yet, but also you could have regexes in memberPrincipal for additional flexibility.

This schema allows us to resolve the ACL using a single LDAP query (if your LDAP server supports the dereference control). The implementation could try the dereference control query first and then fall-back to a join control query after the first query fails.

We find this schema was the optimal compromise between the flexibility we needed and the complexity we wanted to allow, and simpler ones would prevent us from doing what's needed in a useful manner.

The only drawback is that you cannot fit this into kadmin as it is, because it requires to be able to represent grouping mechanism and ACL objects, it would be nice if kadmin could be extended so that it is flexible enough to allow this kind of representation.

'''Use Cases'''

The main use case is to restrict which user principals are allowed to be impersonated by the proxy principal for the target service principal. Administrators that want to limit access to certain users for target services can use the ACL design without needing to update target service applications/systems to use interpret authorization data. This assumes a non-cross realm environment.

This use case can be expanded to allow for a set of multiple users to be impersonated by a set of proxy principals for a set of target principals. This is accomplished with out having to maintain separate ACL lists for various target services by using groupings similar to network groups.

'''Example'''

We want to allow our HTTP server cluster to impersonate 2 users (shawn and simo) against the LDAP server cluster:

First we create a group of users:

dn: cn=allowed-users,SUFFIX
objectclass: groupOfPrincipals
cn: cn=allowed-users
memberPrincipal: shawn@KERBEROS.ORG
memberPrincipal: simo@KERBEROS.ORG

Then a group of target servers (we assume there may be multiple copies all equally accessible):

dn: cn=LDAP-Servers,SUFFIX
objectclass: groupOfPrincipals
cn: LDAP-Servers
memberPrincipal: ldap/ldap-server-1.kerberos.org@KERBEROS.ORG
memberPrincipal: ldap/ldap-server-2.kerberos.org@KERBEROS.ORG

Finally we create the allow rule which binds clients, targets, and the proxy service:

dn: cn=http-ldap-delegation,SUFFIX
objectclass: groupOfPrincipals
objectclass: Krb5DelegationACL
cn: http-ldap-delegation
AllowToImpersonate: cn=allowed-users,SUFFIX
AllowedTarget: cn=LDAP-Servers,SUFFIX
memberPrincipal: HTTP/http-proxy-1.kerberos.org@KERBEROS.ORG
memberPrincipal: HTTP/http-proxy-2.kerberos.org@KERBEROS.ORG
memberPrincipal: HTTP/http-proxy-3.kerberos.org@KERBEROS.ORG

'''Potential Conflicts'''

After investigating w2k12, there could be a way to deploy something with similar functionality.

---begin procedures---

In regards to Windows Server 2012: The "Delegation" tab is still present through the AD Users and Computers interface, but has the traditional behavior of the front-end selecting which resource services it can delegate to, instead of selecting which front-end services can delegate to the resource service. The security tab is not present in the AD Users and Computers interface, but rather through the AD Administrative Center. So to emulate the functionality of the Delegation ACL (using the same actors as described in the KerberosDelegationACL project page), in the AD environment:

1. Create a group "allowed-users" with "shawn@KERBEROS.ORG" and "simo@KERBEROS.ORG" as members.
2. Select "ldap-server-1"s and "ldap-server-2"s security tab and add "allowed-users".
3. Create another group "http-ldap-delegation" with "HTTP/http-proxy-1.kerberos.org@KERBEROS.ORG", "HTTP/http-proxy-2.kerberos.org@KERBEROS.ORG", and "HTTP/http-proxy-3.kerberos.org@KERBEROS.ORG" as members.
4. Then restrict the delegation group to the resource with the following invocation:
set-adcomputer ldap-server-1 -PrincipalsAllowedToDelegateToAccount http-ldap-delegation
set-adcomputer ldap-server-2 -PrincipalsAllowedToDelegateToAccount http-ldap-delegation

So above, the KDC will restrict the resource ticket issuance for S4U2Proxy requests to http-ldap-delegation. The user access to the resource will be controlled by the allowed-users group, which differs from the Delegation ACL project by the fact that the authorization is performed by the application rather than enforced by the KDC. Note that the above should also be supported through x-realms.

---end procedures---

The benefits of the proposed project justifies having differences between the vendor implementations:

1. Policy decisions can be made by the KDC w/o having to rely on updating application servers to perform the policy enforcement against the user.
2. Bindings are/can be user-to-service controlled providing finer granular authorization to said services.

Projects/KerberosDelegationACL

2014-04-13T06:08:04Z

ShawnEmery:

Projects/KerberosDelegationACL

2013-10-25T01:45:46Z

ShawnEmery:

Projects/KerberosDelegationACL

2013-10-25T01:39:27Z

ShawnEmery:

Projects/KerberosDelegationACL

2013-10-25T01:38:30Z

ShawnEmery:

Projects/KerberosDelegationACL

2013-10-25T00:23:47Z

ShawnEmery: Kerberos delegation access control list for finer granularity in determining success in S4U2Proxy requests.