Chapter 11. Troubleshooting client access to services in the other forest

After configuring a trust between your Identity Management (IdM) and Active Directory (AD) environments, you might experience issues where a client in one domain is not able to access a service in the other domain. Use the following diagrams to troubleshoot the issue.

11.1. Flow of information when a host in the AD forest root domain requests services from an IdM server

The following diagram explains the flow of information when an Active Directory (AD) client requests a service in the Identity Management (IdM) domain.

If you have trouble accessing IdM services from AD clients, you can use this information to narrow your troubleshooting efforts and identify the source of the issue.

diagram showing how an AD client communicates with an AD Domain Controller and an IdM server

  1. The AD client contacts the AD Kerberos Distribution Center (KDC) to perform a TGS Request for the service in the IdM domain.
  2. The AD KDC recognizes that the service belongs to the trusted IdM domain.
  3. The AD KDC sends the client a cross-realm ticket-granting ticket (TGT), along with a referral to the trusted IdM KDC.
  4. The AD client uses the cross-realm TGT to request a ticket to the IdM KDC.
  5. The IdM KDC validates the Privileged Attribute Certificate (MS-PAC) that is transmitted with the cross-realm TGT.
  6. The IPA-KDB plugin might check the LDAP directory to see if foreign principals are allowed to get tickets for the requested service.
  7. The IPA-KDB plugin decodes the MS-PAC, verifies, and filters the data. It performs lookups in the LDAP server to check if it needs to augment the MS-PAC with additional information, such as local groups.
  8. The IPA-KDB plugin then encodes the PAC, signs it, attaches it to the service ticket, and sends it to the AD client.
  9. The AD client can now contact the IdM service using the service ticket issued by IdM KDC.

Additional resources

11.2. Flow of information when a host in an AD child domain requests services from an IdM server

The following diagram explains the flow of information when an Active Directory (AD) host in a child domain requests a service in the Identity Management (IdM) domain. In this scenario, the AD client contacts the Kerberos Distribution Center (KDC) in the child domain, then contacts the KDC in the AD forest root, and finally contacts the IdM KDC to request access to the IdM service.

If you have trouble accessing IdM services from AD clients, and your AD client belongs to a domain that is a child domain of an AD forest root, you can use this information to narrow your troubleshooting efforts and identify the source of the issue.

diagram showing how an AD client in a chile domain communicates with multiple layers of AD Domain Controllers and an IdM server

  1. The AD client contacts the AD Kerberos Distribution Center (KDC) in its own domain to perform a TGS Request for the service in the IdM domain.
  2. The AD KDC in child.ad.example.com, the child domain, recognizes that the service belongs to the trusted IdM domain.
  3. The AD KDC in the child domain sends the client a referral ticket for the AD forest root domain ad.example.com.
  4. The AD client contacts the KDC in the AD forest root domain for the service in the IdM domain.
  5. The KDC in the forest root domain recognizes that the service belongs to the trusted IdM domain.
  6. The AD KDC sends the client a cross-realm ticket-granting ticket (TGT), along with a referral to the trusted IdM KDC.
  7. The AD client uses the cross-realm TGT to request a ticket to the IdM KDC.
  8. The IdM KDC validates the Privileged Attribute Certificate (MS-PAC) that is transmitted with the cross-realm TGT.
  9. The IPA-KDB plugin might check the LDAP directory to see if foreign principals are allowed to get tickets for the requested service.
  10. The IPA-KDB plugin decodes the MS-PAC, verifies, and filters the data. It performs lookups in the LDAP server to check if it needs to augment the MS-PAC with additional information, such as local groups.
  11. The IPA-KDB plugin then encodes the PAC, signs it, attaches it to the service ticket, and sends it to the AD client.
  12. The AD client can now contact the IdM service using the service ticket issued by IdM KDC.

Additional resources

11.3. Flow of information when an IdM client requests services from an AD server

The following diagram explains the flow of information when an Identity Management (IdM) client requests a service in the Active Directory (AD) domain when you have configured a two-way trust between IdM and AD.

If you have trouble accessing AD services from IdM clients, you can use this information to narrow your troubleshooting efforts and identify the source of the issue.

Note

By default, IdM establishes a one-way trust to AD, which means it is not possible to issue cross-realm ticket-granting ticket (TGT) for resources in an AD forest. To be able to request tickets to services from trusted AD domains, configure a two-way trust.

diagram showing how an IdM client communicates with an IdM server and an AD Domain Controller

  1. The IdM client requests a ticket-granting ticket (TGT) from the IdM Kerberos Distribution Center (KDC) for the AD service it wants to contact.
  2. The IdM KDC recognizes that the service belongs to the AD realm, verifies that the realm is known and trusted, and that the client is allowed to request services from that realm.
  3. Using information from the IdM Directory Server about the user principal, the IdM KDC creates a cross-realm TGT with a Privileged Attribute Certificate (MS-PAC) record about the user principal.
  4. The IdM KDC sends back a cross-realm TGT to the IdM client.
  5. The IdM client contacts the AD KDC to request a ticket for the AD service, presenting the cross-realm TGT that contains the MS-PAC provided by the IdM KDC.
  6. The AD server validates and filters the PAC, and returns a ticket for the AD service.
  7. The IPA client can now contact the AD service.

Additional resources