Each service in HDP must have its own principal. As services do not login with a password to acquire their tickets, their principal's authentication credentials are stored in a keytab file, which is extracted from the Kerberos database and stored locally with the service principal. First you must create the principal, using mandatory naming conventions. Then you must create the keytab file with that principal's information and copy the file to the keytab directory on the appropriate service host.
Create a service principal using the
kadminutility:kadmin: addprinc -randkey $principal_name/$fully.qualified.domain.name@YOUR-REALM.COM
You must have a principal with administrative permissions to use this command. The randkey is used to generate the password.
Note that in the example each service principal's name has appended to it the fully qualified domain name of the host on which it is running. This is to provide a unique principal name for services that run on multiple hosts, like DataNodes and TaskTrackers.
The addition of the hostname serves to distinguish, for example, a request from DataNode A from a request from DataNode B. This is important for two reasons:
If the Kerberos credentials for one DataNode are compromised, it does not automatically lead to all DataNodes being compromised
If multiple DataNodes have exactly the same principal and are simultaneously connecting to the NameNode, and if the Kerberos authenticator being sent happens to have same timestamp, then the authentication would be rejected as a replay request.
The
$principal_namepart of the name must match the values in the table below:Note that the NameNode, Secondary NameNode, and Oozie require two principals each.
Table 13.1. Service Principal Names
Service Name Mandatory Principal Name NameNode
nnANDHTTPSecondary NameNode
nnANDHTTPJobTracker
jtTaskTracker
ttDataNode
dnHBase Master
hbaseHBase RegionServer
hbaseZooKeeper
zookeeperHCatalog Server
hcatOozie
oozieandHTTPWebHCat (Templeton)
HTTPFor example: To create the principal for a DataNode service, issue this command:
kadmin: addprinc -randkey dn/$DataNode-Host@EXAMPLE.COM
Extract the related keytab file and place it in the keytab directory (by default
/etc/krb5.keytab) of the appropriate respective components:kadmin: xst -norandkey -k $keytab_file_name $principal_name/fully.qualified.domain.name
You must use the mandatory names for the
$keytab_file_name; variable shown in this table.Table 13.2. Service Keytab File Names
Service Name Mandatory Keytab File Name NameNode
nn.service.keytabAND
spnego.service.keytabSecondary NameNode
nn.service.keytabAND
spnego.service.keytabJobTracker
jt.service.keytabTaskTracker
tt.service.keytabDataNode
dn.service.keytabHBase Master
hbase.service.keytabHBase RegionServer
hbase.service.keytabZooKeeper
zookeeper.service.keytabHCatalog Server
hcat.service.keytabOozie
oozie.service.keytabAND
spnego.service.keytabTempleton
spnego.service.keytabFor example: To create the keytab files for the NameNode, issue these commands:
kadmin: xst -k nn.service.keytab nn/<namenode-host> kadmin: xst -k spnego.service.keytab HTTP/<namenode-host>
When you have created the keytab files, copy them to the
keytabdirectory of the respective service hosts.Set appropriate permissions for the keytabs.
Secure all the keytabs. Execute the following command on all the hosts on your cluster:
chown -R root:hadoop /etc/security/keytabs chmod -R g+rX,o= /etc/security/keytabs
On the NameNode, execute the following command:
chown hdfs:hadoop /etc/security/keytabs/nn.service.keytab chmod 400 /etc/security/keytabs/nn.service.keytab
Execute the following command on all the slave nodes:
chown hdfs:hadoop /etc/security/keytabs/dn.service.keytab chown mapred:hadoop /etc/security/keytabs/tt.service.keytab chmod 400 /etc/security/keytabs/*.service.keytab
Verify that the correct keytab files and principals are associated with the correct service using the
klistcommand. For example, on the NameNode:klist –k -t /etc/security/nn.service.keytab
Do this on each respective service in your cluster.

