One Way Trust - MIT KDC to Active Directory

[#1]

One Way Trust - MIT KDC to Active Directory

Many security environments have strict policies on allowing administrative access to Active Directory. Some performance issues can also require that Hadoop cluster principals for Kerberos are not created directly in AD. To aid in these situations, it may be preferable to use a local MIT KDC in the Hadoop cluster to manage service principals while using a one-way trust to allow AD users to utilze the Hadoop environment. This tutorial describes the steps necessary to create such a trust.

The following assumptions are made for this tutorial:

• An existing HDP cluster
• Cluster has Kerberos enabled with an MIT KDC
• The MIT KDC realm name is HDP.HORTONWORKS.COM
• The MIT KDC server is named kdc-server.hdp.hortonworks.com
• The AD domain/realm is AD.HORTONWORKS.COM

Step 1: Configure the Trust in Active Directory

Create a KDC definition in Active Directory

On the AD server, run a command window with Administrator privileges and create a definition for the KDC of the MIT realm:

ksetup /addkdc HDP.HORTONWORKS.COM kdc-server.hdp.hortonworks.com

Create the Trust in Active Directory

On the AD server, create an entry for the one-way trust. The password used here will be used later in the MIT KDC configuration of the trust:

netdom trust HDP.HORTONWORKS.COM /Domain:AD.HORTONWORKS.COM /add /realm /passwordt:BadPass#1

Step 2: Configure Encryption Types

In order for the MIT realm to trust tickets generated by the AD KDC, the encryption types between both KDCs must be compatible. This means that there must be at least one encryption type that is accepted by both the AD server as well as the MIT KDC server.

Specify Encryption Types in Active Directory

On the AD server, specify which encryption types are acceptible for communication with the MIT realm. Multiple supported encryption types are specified on the command line separated by spaces:

ksetup /SetEncTypeAttr HDP.HORTONWORKS.COM AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96 RC4-HMAC-MD5 DES-CBC-MD5 DES-CBC-CRC

Specify Encryption Types in MIT KDC

By default, all of the encryption types are accepted by the MIT KDC. If security concerns require that the encryption types be limited, this is done in the /etc/krb5.conf file:

[libdefaults]
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 arcfour-hmac-md5 des-cbc-crc des-cbc-md5

Step 3: Enable Trust in MIT KDC

To complete the trust configuration, the trust must be added to the MIT KDC.

Add Domain to MIT KDC Configuration

In the /etc/krb5.conf file, add the AD domain to the [realms] section:

[realms]
HDP.HORTONWORKS.COM = {
  kdc = kdc-server.hortonworks.com
  admin_server = kdc-server.hortonworks.com
  default_domain = hdp.hortonworks.com
}
AD.HORTONWORKS.COM = {
  kdc = ad-server.hortonworks.com
  admin_server = ad-server.hortonworks.com
  default_domain = ad.hortonworks.com}

Create Trust User

In order for the trust to work, a principal combining the realms in the trust must be created in the MIT KDC. The password for this user must be the same as the password used to create the trust on the AD server:

kinit admin/admin@HDP.HORTONWORKS.COM
kadmin -q "addprinc krbtgt/HDP.HORTONWORKS.COM@AD.HORTONWORKS.COM"

Step 4: Configure AUTH_TO_LOCAL

The Hadoop auth_to_local parameter must be changed to properly convert user principals from the AD domain to usable usernames in the Hadoop cluster. In Ambari, add the following rules to the auth_to_local variable in HDFS -> Configs -> Advanced -> Advanced core-site.xml -> hadoop.security.auth_to_local

RULE:[1:$1@$0](^.*@AD\.HORTONWORKS\.COM$)s/^(.*)@AD\.HORTONWORKS\.COM$/$1/g
RULE:[2:$1@$0](^.*@AD\.HORTONWORKS\.COM$)s/^(.*)@AD\.HORTONWORKS\.COM$/$1/g

[#2]

This article is very illustrative but as most of the references in this topic doesn't addresses the problem of Linux users authentication against AD with the previous hosts and kerberos client configurations. For SSSD to work with AD you will have to setup your host's default krb5.keytabs to point to the AD principals (obtained when joining the host to the AD domain) and this is conflicting with the configuration described in the article where the host is supposed to be associated to the MIT KDC realm and default domain.

How do we resolve this conflict?

[#3]

RULE:[1:$1@$0](^.*@AD\.HORTONWORKS\.COM$)s/^(.*)@AD\.HORTONWORKS\.COM$/$1/g

I am not quiet sure if the brackets arountd (.*) are really necessary.