Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 52. Using resource-based constrained delegation in IdM

Use resource-based constrained delegation (RBCD) in Identity Management (IdM) to control service access delegation at the resource level.

Unlike general constrained delegation, RBCD allows the service owner to grant delegation permissions rather than requiring a domain administrator. This is especially useful in IdM and Active Directory (AD) trust environments where delegation must span across forests.

Since 2019, Microsoft AD enforces the use of RBCD when both target and proxy services belong to different forests.

52.1. Resource-based constrained delegation in IdM
Copy link

Resource-based constrained delegation (RBCD) in Identity Management (IdM) gives service owners direct control over which services can delegate user credentials to their service, removing the need for domain administrator involvement in each delegation decision.

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 S4U2proxy feature 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.

Important

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.

52.2. Using RBCD to delegate access to a service
Copy link

Use resource-based constrained delegation (RBCD) in Identity Management (IdM) to grant one service the ability to act on behalf of a user towards another service, without requiring domain administrator intervention.

Delegate user credentials from the HTTP/client.example.test web service to the nfs/client.example.test file server on the same host. Since hosts manage their own local services, apply the RBCD rule directly to the client.example.test host object.

Prerequisites

  • You have access to the /etc/krb5.keytab file of the client.example.test host.
  • A nfs/client.example.test service keytab exists.
  • A keytab /path/to/web-service.keytab for HTTP/client.example.test exists.

Procedure

  1. On the client.example.test host, obtain a Kerberos ticket: 

    # kinit -k

  2. Define the RBCD ACL: 

    # ipa service-add-delegation nfs/client.example.test HTTP/client.example.test

-------------------------------------------------------
Added new resource delegation to the service principal "nfs/client.example.test@EXAMPLE.TEST"
-------------------------------------------------------
  Principal name: nfs/client.example.test@EXAMPLE.TEST
  Delegation principal: HTTP/client.example.test@EXAMPLE.TEST

Verification

To verify that the delegation is set up correctly, you can simulate a testuser user logging in through the HTTP service and performing a protocol transition to the NFS service.

  1. View the NFS service to verify that the delegation rule is present: 

    # ipa service-show nfs/client.example.test

  Principal name: nfs/client.example.test@EXAMPLE.TEST
  Principal alias: nfs/client.example.test@EXAMPLE.TEST
  Delegation principal: HTTP/client.example.test@EXAMPLE.TEST
  Keytab: True
  Managed by: client.example.test

  2. Obtain a Kerberos ticket for the HTTP service principal: 

    # kinit -kt http.keytab HTTP/client.example.test

  3. Verify that the ticket granting ticket is present: 

    # klist -f
Ticket cache: KCM:0:99799
Default principal: HTTP/client.example.test@EXAMPLE.TEST

Valid starting       Expires              Service principal
10/13/2023 14:39:23  10/14/2023 14:05:07  krbtgt/EXAMPLE.TEST@EXAMPLE.TEST
	Flags: FIA

  4. Perform a protocol transition on behalf of testuser: 

    # kvno -U testuser -P nfs/client.example.test
nfs/client.example.test@EXAMPLE.TEST: kvno = 1

  5. Verify that tickets obtained during protocol transition on behalf of testuser are present: 

    # klist -f
Ticket cache: KCM:0:99799
Default principal: HTTP/client.example.test@EXAMPLE.TEST

Valid starting       Expires              Service principal
10/13/2023 14:39:38  10/14/2023 14:05:07  HTTP/client.example.test@EXAMPLE.TEST
	for client testuser@EXAMPLE.TEST, Flags: FAT
10/13/2023 14:39:23  10/14/2023 14:05:07  krbtgt/EXAMPLE.TEST@EXAMPLE.TEST
	Flags: FIA
10/13/2023 14:39:38  10/14/2023 14:05:07  nfs/client.example.test@EXAMPLE.TEST
	for client testuser@EXAMPLE.TEST, Flags: FAT
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red HatBack to top