Community Articles
Find and share helpful community-sourced technical articles
Alert: Welcome to the Unified Cloudera Community. Former HCC members be sure to read and learn how to activate your account here.

Kerberos is a widely-used authentication system and is used throughout the Hadoop ecosystem, in particular, for strong authentication. The KDC, or key distribution center, is the name for the Kerberos server application that exposes the Authentication Service and Ticket Granting Service, as well as hosting the Kerberos principal database.

Active Directory is used in many enterprises for Identity and Access Management. A common architecture in enterprise deployment scenarios is to make use of a local cluster KDC (often using the MIT-KDC packaging) to host the service and host principals associated with the cluster, and to configure a one-way trust between the AD domain and the cluster realm. This has the advantage of offloading Kerberos traffic from the domain controller(s) and not all enterprises do not necessarily want to host cluster principals within their AD domain.

So how does a one-way trust work? The first thing to note is that the trust is instantiated by the existence of a special cross-realm principal. For example, if realm B.EXAMPLE.COM trusts realm A.EXAMPLE.COM, clients in the realm A.EXAMPLE.COM can authenticate to services in B.EXAMPLE.COM.

In order for a client of A.EXAMPLE.COM to access a service in the B.EXAMPLE.COM realm, both realms must share a key for a principal named krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM (and both keys must have the same key version number associated with them).

To access a cross-realm service, the user first contacts their home KDC's AS (AD domain controller which exposes the KDC service, in the scenario at-hand) asking for a TGT that will be used with the TGS of the foreign realm. If there is a direct trust relationship between the home realm and the foreign realm (practically materialized in shared inter-realm keys, per the above), the home KDC delivers the requested TGT.

The user then contacts the cluster MIT-KDC, in the foreign realm, presenting the cross-realm TGT and requesting a service ticket for the service in question. Finally, the user contacts the cluster service in question, presenting the service ticket. Therefore, we can conclude that the AD user needs to be able to contact the MIT-KDC server (usually tcp/88).

Please note this means that if the cluster is within a secured network zone which includes the MIT-KDC host, then there needs to be a firewall rule allowing AD clients to contact this host (again, usually over tcp/88). Please see diagram below.



  1. RFC 5868
  2. Kerberos and its Application in Cross-realm Operations
  3. RedHat: Setting up Cross-realm Authentication
Not applicable

It is a wonderful article . I have some doubt . Assume There is and There is . Both have parent and child trust configured. There is a user childuser in I have to delegate it to a constarined delegation user (kcduser ) which is in . Resource who is sitting in the .

As Referring your article , I need to get TGT ticket from (where kcduser and Resource is available) to access .

I need your input to confirm my understanding on this scenario .



Don't have an account?
Coming from Hortonworks? Activate your account here
Version history
Revision #:
2 of 2
Last update:
‎08-17-2019 01:02 PM
Updated by:
Top Kudoed Authors