AD Kerberos common problems
This article describes common issues that you may encounter during AD Kerberos configuration and their workarounds. For convenient visualization of an LDAP server contents, you can use Apache Directory Studio or any other suitable tool.
|
NOTE
In this section, a container denotes an LDAP entry called the base DN (search base) for service principals managed by the current user, that may contain the Organization Unit (OU), etc.
In the Manage Kerberos window, this entry is specified in the Container DN field.
|
Some cases with possible solutions are listed below.
Error creating HTTP principal on host in AD domain
Such an error occurs during the Manage Kerberos action if an AD host has a security update KB5008382, given that the cluster hosts are in AD domain. You can find the typical error message below.
######################## STDOUT ######################## adding new entry "CN=HTTP/dl-dev-h3-kdc.adp.local,OU=svc,OU=EIAP,DC=adp,DC=local" ######################## STDERR ######################## ldap_add: Constraint violation (19) additional info: 000021C7: AtrErr: DSID-03200E89, #1: 0: 000021C7: DSID-03200E89, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 90303 (servicePrincipalName)
How to solve
There are two workarounds:
-
Remove hosts from the AD domain and return them after kerberization.
-
Create an HTTP principal by AD Administrator before kerberization.
Create an HTTP principal
-
Authorize in AD server as an AD administrator with permissions to manage AD hosts. There are two ways to do that:
-
Log in to Windows AD server and go to AD Users and Computers. Then, create a principal
HTTP/<fqdn>@<realm>for each host. -
Prepare the environment (see Useful tips), then log in the console with ldap-client and run the following command:
ldapadd -H "ldaps://kru-win-new.fresh.com" -x -D administrator@FRESH.COM -w "mypassword" -f adduser.ldifExample contents of the adduser.ldif config file is presented below.
DN: CN=HTTP/kru-test-adps.ru-central1.internal,OU=Hadoop,DC=fresh,DC=com changetype: add objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user accountExpires: 0 userPrincipalName: HTTP/kru-test-adps.ru-central1.internal@FRESH.COM servicePrincipalName: HTTP/kru-test-adps.ru-central1.internal distinguishedName: CN=HTTP/kru-test-adps.ru-central1.internal,OU=Hadoop,DC=fresh,DC=com userAccountControl: 514
-
-
Run the Manage Kerberos action. In case you don’t have local admin permissions — disable the Set up principals and keytabs flag to skip their creation and make sure to provide all service principals and keytabs yourself.
-
To prepare Kerberos environment on host, you can install ldap client with all cluster settings by using Manage Kerberos with the Custom kerberization settings option enabled, and Setup Kerberos Clients and Cluster configuration flags activated.
Customize action -
It’s important to place HTTP principal in the same directory that you input into the Container DN field of the Manage Kerberos modal window, because the local admin should have permissions to control this principal.
This way, Kerberos will be enabled using the existing HTTP principal. The password of this principal will be generated and keytab will be written to all the hosts.
Principal already exists in another container
ADCM can not search/remove/re-create service principals in the containers that differ from the Container DN value specified while enabling/disabling Kerberos.
Since the current administrator may not have permissions for all the AD domain, such principals that exist in different containers with the same name lead to a conflict:
######################## STDERR ########################
ldap_add: Constraint violation (19)
additional info: 000021C8: AtrErr: DSID-03200BE8, #1:
0: 000021C8: DSID-03200BE8, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 90290 (userPrincipalName).
How to solve
Remove existing service principals from the old container manually. An example on how to do this is demonstrated below.
Example
-
Search for existing principals in all the domain’s containers, using the filter as shown below:
ldapsearch -H ldap://<ldap-server-url> -o ldif-wrap=no -x -W -D 'cn=userA,ou=kerberos,ou=adh,dc=foo,dc=bar' -b 'dc=foo,dc=bar' name=hdfs/test-principal-name.ru-central1.internal | grep dnWhere:
-
-b 'dc=foo,dc=bar'consists of the actual domain parts (e.g. 'dc=com,dc=hostname') corresponding to the Kerberos REALM. -
-o ldif-wrap=nodisables the ldapsearch results wrapping. Omitting this option truncates the results returned by ldapsearch sogrepmay not extract the full DN value required for removing principals.
The ldapsearch returns container DN(s) like the ones below:
# Example 1: dn: CN=hdfs/test-principal-name.ru-central1.internal,OU=e_ivanov_krb1_ou,OU=kerberos,OU=adh,DC=ad,DC=ranger-test # Example 2: dn: CN=del_me,CN=Users,DC=adh-sec,DC=com
-
-
Delete the existing conflicting principals. ADCM will re-create principals with an appropriate Container DN value. For example:
ldapdelete -H ldap://<ldap-server-url> -x -W -D 'cn=userA,ou=kerberos,ou=adh,dc=ad,dc=ranger-test' CN=hive/test-principal-name2.ru-central1.internal,OU=userB,OU=kerberos,OU=adh,DC=ad,DC=ranger-test -
After removing all the service principals from the container, run (Re)Enable Kerberos. The action should complete without conflicts.
Administrator has no permissions for the base_dn in the custom ldap.conf
In this case, while expanding a component on the new host or while adding a new service, you may get the following error:
<timestamp> DEBUG adcm_check ansible adcm_check: title: Hdfs-Datanode: Add principal, title: <principal-name>, message:######################## STDOUT ######################## ######################## STDERR ######################## ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)