It is now possible to allow constrained delegation of credentials so that a service can impersonate a user when communicating with another service w/o requiring the user to actually forward their TGT. This makes for a much better method of delegating credentials as it prevents exposure of the short term secret of the user. I added a relatively simple access control method that allow the KDC to decide exactly which services are allowed to impersonate which users against other services. A simple grouping mechanism is used so that in large environments, clusters and otherwise classes of services can be much more easily managed. The grouping mechanism has been built so that lookup is highly optimized and is basically reduced to a single search that uses the derefernce control. Speed is very important in this case because KDC operations time out very quickly and unless we add a caching layer in ipa-kdb we must keep the number of searches down to avoid client timeouts. The grouping mechanism is very simple a groupOfPrincipals object is introduced, this Auxiliary class have a single optional attribute called memberPrincipal which is a string containing a principal name. A separate objectclass is also introduced called ipaKrb5DelegationACL, it is a subclass of groupOfPrincipals and is a Structural class. It has 2 additional optional attributes: ipaAllowedTarget and ipaAllowToImpersonate. They are both DNs. The memberPrincipal attribute in this class contains the list of principals that are being considered proxies[1]. That is: the principals of the services that want to impersonate client principals against other services. The ipaAllowToImpersonate must point to a groupOfPrincipal based object that contains the list of client principals (normally these are user principals) that can be impersonated by this service. If the attribute is missing than the service is allowed to impersonate *any* user. The ipaAllowedTarget DN must point to a groupOfPrincipal based object that contains the list of service principals that the proxy service is allowed target when impersonating users. A target must be specified in order to allow a service to access it impersonating another principal. At the moment no wildcarding is implemented so services have to be explicitly listed in their respective groups. I have some idea of adding wildcard support at least for the ipaAllowToImpersonate group in order to separate user principals by REALM. So you can say all users of REALM1 can be impersonated by this service but no users of REALM2. It is unclear how this wildcarding may be implemented, but it must be simple to avoid potentially very expensive computations every time a ticket for the target services is requested. I have briefly tested this patch by manually creating a few objects then using the kvno command to test that I could get a ldap ticket just using the HTTP credentials (in order to do this I had to allow also s4u2self operations for the HTTP service, but this is *not* generally required and it is *not* desired in the IPA framework implementation). This patchset does not contain any CLI or UI nor installation changes to create ipaKrb5DelegationACL obujects. It is indeed yet unclear where we want to store them (suggestions are welcome) and how/when we may want to expose this mechanism through UI/CLI for general usage. The initial intended usage is to allow us to move away from using forwarded TGTs in the IPA framework and instead use S4U2Proxy in order to access the ldap service. In order to do this some changes will need to be made in installation scripts and replica management scripts later. How to test: Create 2 objects like these: dn: cn=ipa-http-delegation,... objectClass: ipaKrb5DelegationACL objectClass: groupOfPrincipals cn: ipa-http-delegation memberPrincipal: HTTP/ipaserver.example.com@EXAMPLE.COM ipaAllowedTarget: cn=ipa-ldap-delegation-targets,... dn: cn=ipa-ldap-delegation-targets,... objectClass: groupOfPrincipals cn: ipa-ldap-delegation-targets memberPrincipal: ldap/ipaserver.example.com@EXAMPLE.COM In order to test with kvno which pretend to do s4u2self too you will need to allow the HTTP service to impersonate arbitrary users. This is done with: kdamin.local modprinc +ok_to_auth_as_delegate HTTP/ipaserver.example.com NOTE: Do not grant +ok_to_auth_as_delegate in production without carefully considering the outcome. This flags grants a service the ability to impersonate any user to itself, which, combined with the permission to proxy, means it will be allowed to impersonate any user to the target service w/o any explicit user permission/delegation. This flag is *NOT* necessary to permit proxying, it is used in this example only because the kvno utility is hardwired to test both s4u2self and s4u2proxy at the same time and would fail to operate without it. Then run kvno as follows: # Init credntials as HTTP kinit -kt /etc/httpd/conf/ipa.keytab HTTP/ipaserver.example.com # Perform S4U2Self kvno -U admin HTTP/ipaserver.example.com # Perform S4U2Proxy kvno -k /etc/httpd/conf/ipa.keytab -U admin -P HTTP/ipaserver.example.com ldap/ipaserver.example.com If this works it means you successfully impersonated the admin user with the HTTP service against the ldap service. Cleanup by removing the self-impersonation flag: modprinc -ok_to_auth_as_delegate HTTP/ipaserver.example.com Simo. [1] Note that here I use the term proxy in a different way than it is used in the krb interfaces. It may seem a bit confusing but I think people will understand it better this way. In this document 'client' connects to 'proxy' which impersonates 'client' against 'service'. In the Code/API the 'client' connects to 'server' which impersonates 'client' against 'proxy'.