Integrating MIT Kerberos and Active Directory
How to integrate MIT Kerberos and Active Directory in a Cloudera Manager cluster.
Several different subsystems are involved in servicing authentication requests, including the Key Distribution Center (KDC), Authentication Service (AS), and Ticket Granting Service (TGS). The more nodes in the cluster and the more services provided, the heavier the traffic between these services and the services running on the cluster.
As a general guideline, Cloudera recommends using a dedicated Active Directory instance (Microsoft Server Domain Services) for every 100-200 nodes in the cluster. However, this is just a loose guideline. Monitor utilization and deploy additional instances as needed to meet the demand.
krb5.conf
) as follows:
[libdefaults]
udp_preference_limit = 1
...
This is especially useful if the domain controllers are not on the same subnet as the cluster or are separated by firewalls.
In general, Cloudera recommends setting up the Active Directory domain controller (Microsoft Server Domain Services) on the same subnet as the cluster and never over a WAN connection which results in considerable latency and affects cluster performance.
Troubleshooting cluster operations when Active Directory is being used for Kerberos authentication requires administrative access to the Microsoft Server Domain Services instance. Administrators may need to enable Kerberos event logging on the Microsoft Server KDC to resolve issues.
Deleting Cloudera Manager roles or nodes requires manually deleting the associate Active Directory accounts. Cloudera Manager cannot delete entries from Active Directory.
Integrating MIT Kerberos and Active Directory
Prior to release 5.1, clusters managed by Cloudera Manager could not integrate directly with a Microsoft Active Directory KDC. Rather, integrating the Cloudera Manager cluster with an Active Directory KDC required the additional setup of a local MIT KDC (local, meaning in the same subnet as the cluster).
- An MIT Kerberos KDC is running in the same subnet as the cluster and that a Kerberos REALM is local to the cluster
- A Microsoft Server Active Directory instance (Microsoft Server Domain Services) is running elsewhere on the network, in its own Kerberos realm.
- Create principals for all services running on the cluster in the MIT Kerberos realm local to the cluster.
- Set up one-way cross-realm trust from the MIT Kerberos realm to the Active Directory
realm, as detailed in
Configuring a Local MIT Kerberos Realm to Trust Active Directory
below.
The result of this setup is that Active Directory principals (users) can authenticate to the cluster without needing service principals.
Configuring a Local MIT Kerberos Realm to Trust Active Directory
On the Active Directory Server
On the MIT KDC Server
netdom
command on the Active Directory Server.
kadmin: addprinc -e "enc_type_list" krbtgt/YOUR-LOCAL-REALM.COMPANY.COM@AD-REALM.COMPANY.COM
where the enc_type_list parameter specifies the types of encryption this cross-realm krbtgt principal can support—AES, DES, or RC4. You can specify multiple encryption types using the parameter in the command above, what's important is that at least one of the encryption types corresponds to the encryption type found in the tickets granted by the KDC in the remote realm. For example:
kadmin: addprinc -e "rc4-hmac:normal des3-hmac-sha1:normal" krbtgt/YOUR-LOCAL-REALM.COMPANY.COM@AD-REALM.COMPANY.COM