1.1.6. Creating Service Principals and Keytab Files for Hadoop 2.x

Open the kadmin.local utility on the KDC machine

/usr/sbin/kadmin.local

Create the service principals:

$kadmin.local
addprinc -randkey $primary_name/$fully.qualified.domain.name@EXAMPLE.COM

The -randkey option is used to generate the password.

Note that in the example each service principal's primary name has appended to it the instance name, the FQDN of the host on which it runs. This provides a unique principal name for services that run on multiple hosts, like DataNodes and NodeManagers. 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:

The principal name must match the values in the table below:

For example: To create the principal for a DataNode service, issue this command:

$kadmin.local
addprinc -randkey dn/$DataNode-Host@EXAMPLE.COM 

 In addition you must create four special principals for Ambari's own use.

	Note
	The names in table below can be customized in the Customize Services step of the Ambari Install Wizard. If this is the case in your installation, the principal names should match the customized names. For example, if the HDFS Service User has been set to hdfs1, the respective principal for the Ambari HDFS User should also be created as hdfs1.

These principals do not have the FQDN appended to the primary name:

Once the principals are created in the database, you can extract the related keytab files for transfer to the appropriate host:

$kadmin.local
xst -norandkey -k $keytab_file_name $primary_name/fully.qualified.domain.name@EXAMPLE.COM

You must use the mandatory names for the $keytab_file_name variable shown in this table.

Note

Some older versions of Kerberos do not support the xst -norandkey option. You can use the command without the -norandkey flag, except in cases where you need to copy a principal from one keytab file to another keytab file on a host. This might be a requirement if the Hadoop configurations on a host have keytab path properties that point to different keytab locations but have corresponding principal name properties that have the same values. In situations like this, you can use the two step kadmin/kutil procedure. This description assumes MIT Kerberos. If you are using another version, please check your documentation. Extract the keytab file information: $kadmin xst -k $keytab_file_name-temp1 $primary_name/fully.qualified.domain.name@EXAMPLE.COM xst -k $keytab_file_name-temp2 $primary_name/fully.qualified.domain.name@EXAMPLE.COM Write the keytab to a file. : $kutil kutil: rkt $keytab_file_name-temp1 kutil: rkt $keytab_file_name-temp2 kutil: wkt $keytab_file_name kutil: clear

For example: To create the keytab files for NameNode HTTP, issue this command:

$kadmin.local
xst -norandkey -k spnego.service.keytab HTTP/<namenode-host>

Note

If you have a large cluster, you may want to create a script to automate creating your principals and keytabs. To help with that, you can download a CSV-formatted file of all the required principal names and keytab files from the Ambari Web GUI. Select Admin view->Security->Enable Security-> and run the Enable Security Wizard, using the default values. At the bottom of the third page, Create Principals and Keytabs, click Download CSV.

When the keytab files have been created, on each host create a directory for them and set appropriate permissions.

mkdir -p /etc/security/keytabs/
chown root:hadoop /etc/security/keytabs
chmod 750 /etc/security/keytabs

Copy the appropriate keytab file to each host. If a host runs more than one component (for example, both NodeManager and DataNode), copy keytabs for both components. The Ambari Smoke Test User, the Ambari HDFS User, and the Ambari HBase User keytabs should be copied to the all hosts on the cluster.

	Important
	If you have customized service user names, replace the default values below with your appropriate service user, group, and keytab names.

Set appropriate permissions for the keytabs.

Verify that the correct keytab files and principals are associated with the correct service using the klist command. For example, on the NameNode:

klist –k -t /etc/security/keytabs/nn.service.keytab

Do this on each respective service in your cluster.