Red Hat Summit Red Hat SummitSuporteConsoleDesenvolvedoresComeçar um testeContato

Este conteúdo não está disponível no idioma selecionado.

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

Troubleshoot cross-forest authentication by tracing the Kerberos ticket requests and referrals between environments. These logic flows help isolate failures in the service request chain.

Analyze the Kerberos communication path for Active Directory (AD) clients requesting services in the Identity Management (IdM) domain. This sequence identifies how KDCs handle cross-realm referrals and PAC validation.

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.

Authenticating a client from an Active Directory (AD) child domain involves a multi-step Kerberos referral chain through the AD forest root KDC before reaching the Identity Management (IdM) KDC for final validation.

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.

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

Accessing Active Directory (AD) services from an Identity Management (IdM) client requires a two-way trust to facilitate cross-realm ticket-granting tickets (TGT) and the generation of a Privileged Attribute Certificate.

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.
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2026 Red HatVoltar ao topo