When manually kerborizing using Active Directory, Do we have to create 1 AD user per service principal or is there a way to assign multiple service principals to the same AD account? Eg : 1 AD account for hdfs service assigned to principals(1 per node)
Please point to any documentation that details the manual steps. Official document lacks details.
If you are using Ambari, Ambari will provide to you a CSV file of the expected principals. You are then expected to create the relevant accounts and keytab files and then distribute them to the appropriate hosts.
In Active Directory, each account may have a single userPrincipalName value. So there is a 1-to-1 mapping between principals and accounts in the Active Directory.
The servicePrincipalName value is a bit different in that Active Directory allows for a single account to have multiple service principal names assigned. However this will not work for a Hadoop cluster since each service needs to be able to authenticate as some account and Active Directory will not look up users base on a servicePrincipalNames for authentication. Meaning kinit will not work:
# kinit nn/host1.example.com@AD.EXAMPLE.COM kinit: Client not found in Kerberos database while getting initial credentials
Thanks for the clarification @Robert Levas. That's exact issue that we are facing.
Followup question. I think the next step is the user mapping. For example, in a 8 node cluster, we create 8 principals(syshdphdfs/_HOST@AD_DOMAIN) and 8 AD accounts for the hdfs service. Do we have to map local hdfs user(hdfs) to all the principals?
Thanks in advance.
The HDFS Kerberos identity is a user identity, not a service identity. So its principal name should be something like syshdphdfs@AD_DOMAIN. The AD account should have its userPrincipalName attribute set to syshdphdfs@AD_DOMAIN no value set in the servicePrincipalName attribute. The auth-to-local rule for this identity should be something like
For another identity, like the DataNode service identity, the principal name should be something like dn/host1.ad.dom@AD_DOMAIN. This should be set as the AD account's userPrincipalName and servicePrincipalName value. The auth-to-local riles for this identity should be something like
There is no need to create a separate rule for each dn/* principal name.
For more information on the auth-to-local rules syntax, see https://community.hortonworks.com/articles/14463/auth-to-local-rules-syntax.html.
In any case, Ambari will do this for you if you enable Kerberos using Ambari - even if choosing the "manual" option rather than an existing KDC or Active Directory option.
We are using Ambari and for some reason all the principal names have user/_HOST/@AD_DOMAIN format in the "Configure Identities" as well as the csv file that is being generated. I am assuming that we should go ahead and create the Service principals and the AD accounts as described by you and auth-to-local rules will take care of removing the host name when connecting to AD? Appreciate your help.
@Robert Levas Looks like there might be a bug in the version of the Ambari that we are using which is appending _HOST to the user principals too.
We started to work on the user principals(without the host name) and ran into an issue.
Keytab Creation :
ktpass -princ syshdpambari@AD_REALM -out c:\installs\keytabs\ambari.server.keytab -mapuser syshdpambari@ad_domain -mapop set -pass * -ptype KRB5_NT_PRINCIPAL -crypto AES256-SHA1 -kvno 1
kinit -kt ambari.server.keytab syshdpambari@AD_REALM
kinit : Preauthentication failed while getting initial credentials
Ambari does not automatically append _HOST to principal names. This comes from the Kerberos descriptor or user-specified data.
You should take a look at the user-specified and composite Kerberos descriptors to see if the value is there...
NOTE: replace CLUSTER_NAME with the name of your cluster.
Regarding the manually created Kerberos identity and keytab file, I am not sure why you are getting the Preauthentcation failure. I am not familiar with the AD tools used to export keytab files.
If you are testing kinit from a host other than the AD server, then make sure the clock on the host matches the clock on the AD server. I think a 5 minute difference is allowed, but that seems large to me.
Another option is to try to create the keytab file from a Linux host. Take a look at this article if you are interested in doing that - https://community.hortonworks.com/articles/82544/how-to-create-ad-principal-accounts-using-openldap....