Step 3: Set up a Local KDC and Default Domain for the Hadoop Cluster

  Important:

If you have existing Kerberos host keytabs at your site, it's important that you read this section to prevent your existing host keytabs from becoming invalid.

If you use the following instructions to use Cloudera Manager to enable Hadoop security on your cluster, the Cloudera Manager Server will create the hdfs, mapred, oozie, HTTP, hue, and host principals and then generate keytabs for those principals. Cloudera Manager will then deploy the keytab files on every host in the cluster.

  Note:

The following instructions illustrate an example of creating and deploying the principals and keytab files for MIT Kerberos. (If you are using another version of Kerberos, refer to your Kerberos documentation for instructions.)

When to Use kadmin.local and kadmin

When performing the Kerberos commands in this document, you can use kadmin.local or kadmin depending on your access and account:

  • If you have root access to the KDC machine, but you don't have a Kerberos admin account, use kadmin.local.
  • If you don't have root access to the KDC machine, but you do have a Kerberos admin account, use kadmin.
  • If you have both root access to the KDC machine and a Kerberos admin account, you can use either one.

To start kadmin.local on the KDC machine, or kadmin from any machine, run this command:

$ sudo kadmin.local

OR:

$ kadmin
  Note:

In this guide, kadmin is shown as the prompt for commands in the kadmin shell, but you can type the same commands at the kadmin.local prompt in the kadmin.local shell.

  Note:

Running kadmin.local may prompt you for a password because it is being run via sudo. You should provide your Unix password. Running kadmin may prompt you for a password because you need Kerberos admin privileges. You should provide your Kerberos admin password.

Setting up a Local KDC and Default Domain for the Hadoop Cluster

If your site already has a working KDC and keytabs for any of the principals that Cloudera Manager creates, as described in the following sections, the Cloudera Manager Server will randomize the key stored in the keytab file and consequently cause your existing host keytabs to become invalid. The recommended approach to prevent your existing host keytabs from becoming invalid is to use a dedicated local MIT Kerberos KDC and default realm for the Hadoop cluster and create all Hadoop hdfs, mapred, oozie, HTTP, hue, and host service principals in that realm. You can also set up one-way cross-realm trust from the local KDC and realm to your existing central MIT Kerberos KDC, or to an existing Active Directory realm. Using this method, there is no need to create service principals in the central MIT Kerberos KDC or in Active Directory, but principals (users) in the central MIT KDC or in Active Directory can be authenticated to Hadoop. The steps to implement this approach are as follows:

  1. Install and configure a local MIT Kerberos KDC that is dedicated to storing the service principals for your Hadoop cluster.
  2. Configure a default Kerberos realm for the cluster you want Cloudera Manager to manage and set up one-way cross-realm trust between the local KDC and either your central KDC or Active Directory. Follow the appropriate instructions below for your deployment: Using a Local MIT KDC with a Central MIT KDCUsing a Local MIT KDC with Active Directory

Using a Local MIT KDC with a Central MIT KDC

  Important:

If you plan to use Oozie or the Hue Kerberos ticket renewer in your cluster, you must configure your KDC to allow tickets to be renewed, and you must configure krb5.conf to request renewable tickets. Typically, you can do this by adding the max_renewable_life setting to your realm in kdc.conf, and by adding the renew_lifetime parameter to the libdefaults section of krb5.conf. For more information about renewable tickets, see the Kerberos documentation.

  1. In the /var/kerberos/krb5kdc/kdc.conf file on the local dedicated KDC server host, (for example, KDC-Server-hostname.your-local-realm.com), configure the default realm for the Hadoop cluster by substituting YOUR-LOCAL-REALM.COMPANY.COM in the following realms property:
    [realms]
     YOUR-LOCAL-REALM.COMPANY.COM = {
  2. In the /etc/krb5.conf file on all cluster hosts and all Hadoop client user hosts, configure the default realm for the Hadoop cluster by substituting YOUR-LOCAL-REALM.COMPANY.COM in the following realms property. Also specify the local dedicated KDC server host name in the /etc/krb5.conf file (for example, KDC-Server-hostname.your-local-realm.company.com).
    [libdefaults]
     default_realm = YOUR-LOCAL-REALM.COMPANY.COM
    [realms]
     YOUR-LOCAL-REALM.COMPANY.COM = {
      kdc = KDC-Server-hostname.your-local-realm.company.com:88
      admin_server = KDC-Server-hostname.your-local-realm.company.com:749
      default_domain = your-local-realm.company.com
     }
     YOUR-CENTRAL-REALM.COMPANY.COM = {
      kdc = KDC-Server-hostname.your-central-realm.company.com:88
      admin_server = KDC-Server-hostname.your-central-realm.company.com:749
      default_domain = your-central-realm.company.com
     }
    [domain_realm]
     .your-local-realm.company.com = YOUR-LOCAL-REALM.COMPANY.COM
      your-local-realm.company.com = YOUR-LOCAL-REALM.COMPANY.COM
     .your-central-realm.company.com = YOUR-CENTRAL-REALM.COMPANY.COM
      your-central-realm.company.com = YOUR-CENTRAL-REALM.COMPANY.COM
  3. To set up the cross-realm trust in the local KDC, type the following command in the kadmin.local or kadmin shell on the local KDC host to create a krbtgt principal. Substitute your local KDC realm for YOUR-LOCAL-REALM.COMPANY.COM, and substitute your central KDC realm for YOUR-CENTRAL-REALM.COM. Enter a password when prompted. Note the password because you will need to enter the same exact password in the central KDC in the next step.
    kadmin:  addprinc krbtgt/YOUR-LOCAL-REALM.COMPANY.COM@YOUR-CENTRAL-REALM.COM 
  4. To set up the cross-realm trust in the central KDC, type the same command in the kadmin.local or kadmin shell on the central KDC host to create the exact same krbtgt principal and password.
    kadmin:  addprinc krbtgt/YOUR-LOCAL-REALM.COMPANY.COM@YOUR-CENTRAL-REALM.COM 
      Important:

    In order for a cross-realm trust to operate properly, both KDCs must have the same krbtgt principal and password, and both KDCs must be configured to use the same encryption type.

  5. To properly translate principal names from the central KDC realm into the local KDC realm for the Hadoop cluster, you must configure the Trusted Kerberos realms property of the HDFS service. Follow the instructions below.
  6. Open the Cloudera Manager Admin Console to access the Cloudera Manager Server.
  7. In the Cloudera Manager Admin Console, open the HDFS service > Configuration tab. Scroll down to the Trusted Kerberos realms property, click the pencil icon, and add the name of your central KDC realm. If you need to use more advanced mappings which do more than just allow principals from another domain, you may enter them in the Additional rules to map Kerberos principals to short names property. For more information about name mapping rules, see: Appendix C - Configuring the Mapping from Kerberos Principals to Short Names
  8. Each of your Hadoop client users must also place this information in their local core-site.xml file. The easiest way to do so is by using the Cloudera Manager Admin Console to generate a client configuration file. (See Deploying Client Configuration Files)
  9. Proceed to Step 4: If you are using AES-256 Encryption, install the JCE Policy File. Later in this procedure, you will restart the services to have the configuration changes in core-site.xml take effect.

Using a Local MIT KDC with Active Directory

  1. In the /var/kerberos/krb5kdc/kdc.conf file on the local dedicated KDC server host, (for example, kdc-server-hostname.cluster.corp.company.com), configure the default realm for the Hadoop cluster by substituting YOUR-LOCAL-REALM.COMPANY.COM in the following realms property:
    [realms]
     YOUR-LOCAL-REALM.COMPANY.COM = {
  2. In the /etc/krb5.conf file on all cluster hosts and all Hadoop client user hosts, configure both Kerberos realms. Note that the default realm and the domain realm should be configured as the local MIT Kerberos realm for the cluster.
    [libdefaults]
     default_realm = YOUR-LOCAL-REALM.COMPANY.COM
    [realms]
      AD-REALM.COMPANY.COM = {
        kdc = ad.corp.company.com:88
        admin_server = ad.corp.company.com:749
        default_domain = ad.corp.company.com
      }
      YOUR-LOCAL-REALM.COMPANY.COM = {
        kdc = kdc-server-hostname.cluster.corp.company.com:88
        admin_server = kdc-server-hostname.cluster.corp.company.com:749
        default_domain = cluster.corp.company.com
     }
    [domain_realm]
     .cluster.corp.company.com = YOUR-LOCAL-REALM.COMPANY.COM
      cluster.corp.company.com = YOUR-LOCAL-REALM.COMPANY.COM
     .corp.company.com = AD-REALM.COMPANY.COM
      corp.company.com = AD-REALM.COMPANY.COM
  3. To properly translate principal names from the Active Directory realm into the local KDC realm for the Hadoop cluster, you must configure the Trusted Kerberos realms property of the HDFS service. Follow the instructions below.
  4. Open the Cloudera Manager Admin Console to access the Cloudera Manager Server.
  5. In the Cloudera Manager Admin Console, open the HDFS service > Configuration tab. Scroll down to the Trusted Kerberos realms property, click the pencil icon, and add the name of your Active Directory realm. If you need to use non-trivial mapping rules, you may enter them in the Additional rules to map Kerberos principals to short names property. For more information about name mapping rules, see: Appendix C - Configuring the Mapping from Kerberos Principals to Short Names
  6. Each of your Hadoop client users must also place this information in their local core-site.xml file. The easiest way to do so is by using the Cloudera Manager Admin Console to generate a client configuration file. (See Deploying Client Configuration Files)
  7. On the Active Directory server host, type the following command to specify the local MIT KDC host name (for example, kdc-server-hostname.cluster.corp.company.com) and local realm (for example, YOUR-LOCAL-REALM.COMPANY.COM):
    ksetup /addkdc YOUR-LOCAL-REALM.COMPANY.COM kdc-server-hostname.cluster.corp.company.com
  8. On the Active Directory server host, type the following command to add the local realm trust to Active Directory:
    netdom trust YOUR-LOCAL-REALM.COMPANY.COM /Domain:AD-REALM.COMPANY.COM /add /realm /passwordt:<TrustPassword>
  9. On the Active Directory server host, type the following command to set the proper encryption type: On Windows 2003 RC2:
    ktpass /MITRealmName YOUR-LOCAL-REALM.COMPANY.COM /TrustEncryp <enc_type>

    On Windows 2008:

    ksetup /SetEncTypeAttr YOUR-LOCAL-REALM.COMPANY.COM <enc_type>

    where the <enc_type> parameter specifies AES, DES, or RC4 encryption. Refer to the documentation for your version of Windows Active Directory to find the <enc_type> parameter string to use.

      Important:

    Make the encryption type you specify is supported on both your version of Windows Active Directory and your version of MIT Kerberos.

  10. On the local MIT KDC server host, type the following command in the kadmin.local or kadmin shell to add the cross-realm krbtgt principal:
    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 will support: either AES, DES, or RC4 encryption. 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
      Note: The cross-realm krbtgt principal that you add in this step must have at least one entry that uses the same encryption type as the tickets that are issued by the remote KDC. If no entries have the same encryption type, then the problem you will see is that authenticating as a principal in the local realm will allow you to successfully run Hadoop commands, but authenticating as a principal in the remote realm will not allow you to run Hadoop commands.
  11. Proceed to Step 4: If you are using AES-256 Encryption, install the JCE Policy File. Later in this procedure, you will restart the services to have the configuration changes in core-site.xml take effect.