红帽全球峰会第 54 章 Using resource-based constrained delegation in IdM
You can use resource-based constrained delegation (RBCD) to allow access to a service. Using RBCD allows a granular control of delegation on a resource level. Access can be set by the owner of the service to which credentials are delegated. This is useful, for example, in an integration between Identity Management (IdM) and Active Directory (AD).
Since 2019, Microsoft AD enforces the use of RBCD when both target and proxy services belong to different forests.
54.1. Resource-based constrained delegation in IdM
RBCD allows for greater control over access delegation. This chapter covers the main differences between RBCD and general constrained delegation.
- RBCD versus general constrained delegation
Resource-based constrained delegation (RBCD) differs from general constrained delegation in multiple aspects:
- Granularity: In RBCD, delegation is specified at the resource level.
- Access granting responsibility: in RBCD, access is controlled by the service owner rather than by the Kerberos administrator.
In general constrained delegation, the Service for User to Proxy (S4U2proxy) extension obtains a service ticket for another service on behalf of a user. The second service is typically a proxy performing work on behalf of the first service, under the authorization context of the user. Using constrained delegation eliminates the need for the user to delegate their full ticket-granting ticket (TGT).
- How IdM uses constrained delegation
-
Identity Management (IdM) traditionally uses the Kerberos
S4U2proxyfeature to allow the web server framework to obtain an LDAP service ticket on a user’s behalf.
When IdM integrates with Active Directory (AD), the IdM framework also uses constrained delegation to operate on behalf of a user towards various services, including SMB and DCE RPC end-points on both the IdM and AD sides.
- How IdM can use RBCD
- When an application in an IdM domain operates on behalf of users against a different service, it requires a delegation permission. In general constrained delegation, this requires the domain administrator to explicitly create a rule to allow a first service to delegate user credentials to the next service. Using RBCD, the delegation permission can be created by the owner of the service to which the credentials are delegated.
For IdM-AD integration, when both services are part of the same IdM domain, the RBCD permission can be granted on the IdM side.
Currently, only services in the IdM domain can be configured with RBCD rules. If the target service is part of an AD domain, the permission can only be granted on the AD side. As AD domain controllers cannot resolve IdM service information to create the rule, this is not currently supported.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}