Support Questions

Find answers, ask questions, and share your expertise
Announcements
Celebrating as our community reaches 100,000 members! Thank you!

Kerberos Integration to Active Directory failed: kinit: Preauthentication failed while getting initial credentials

avatar
Expert Contributor

Hi,

I am trying to enable Kerberos on my cluster (Ambari 2.4.2, HDP 2.5.3, Centos 7.3).

I have started following this guide:

https://community.hortonworks.com/articles/82536/configuring-ambari-and-hadoop-for-kerberos-using-a....

It also has a video inside.

After "Install Kerberos Client" step, it failed during "Test Kerberos Client" step. It failed with following shell exception:

resource_management.core.exceptions.ExecutionFailed: Execution of '/usr/bin/kinit -c /var/lib/ambari-agent/tmp/kerberos_service_check_cc_bd98b56f3fb825bccff406ea5b89a680 -kt /etc/security/keytabs/kerberos.service_check.031517.keytab mybigdev-031517@hadoopad.local' returned 1. kinit: Preauthentication failed while getting initial credentials

Then I applied another guide:

https://www.ibm.com/support/knowledgecenter/SSPT3X_4.2.0/com.ibm.swg.im.infosphere.biginsights.admin...

I got certificate of Active Directory in to following file:

/etc/pki/ca-trust/source/anchors/activedirectory.pem

run the following commands as root user to trust CA certificate:

update-ca-trust enable
update-ca-trust extract
update-ca-trust check

then added trust in Java certificate file:

   mycert=/etc/pki/ca-trust/source/anchors/activedirectory.pem sudo keytool -importcert -noprompt -storepass changeit -file ${mycert} -alias ad -keystore /etc/pki/java/cacerts

It didn't work. Error was the same. I exit Kerberos wizard for any change and restart ambari-server.

I tried following command:

keytool -importcert -file activedirectory.pem -noprompt -storepass changeit -alias ad -keystore /usr/java/jdk1.8.0_73/jre/lib/security/cacerts

after this I listed certificates in my cert files in both location (/etc/pki/java and /usr/java/jdk...)

My alias was there:

*******

*******

Alias name: ad

Creation date: Mar 15, 2017

Entry type: trustedCertEntry

Owner: CN=hadoopad-HADOOPDC-CA, DC=hadoopad, DC=local

Issuer: CN=hadoopad-HADOOPDC-CA, DC=hadoopad, DC=local

...

*****

*****

I also tried

addent -password -p ${user} -k 1 -e rc4-hmac

but it didn't change anything

then I uncommented following encryption types entries but it didn't change anything either:

#default_tgs_enctypes = {{encryption_types}} #default_tkt_enctypes = {{encryption_types}}

Now I need you guys' comments.

Thanks in advance...

1 ACCEPTED SOLUTION

avatar
@Sedat Kestepe

The issue is with your realm name - hadoopad.local. Realm names should be in all uppercase characters in both the client (Ambari) configuration as well as on the server (AD, MIT KDC, etc...). So the realm name should be HADOOPAD.LOCAL. If the Active Directory was not set up with the uppercase form, it will need to be fixed.

View solution in original post

7 REPLIES 7

avatar
@Sedat Kestepe

The issue is with your realm name - hadoopad.local. Realm names should be in all uppercase characters in both the client (Ambari) configuration as well as on the server (AD, MIT KDC, etc...). So the realm name should be HADOOPAD.LOCAL. If the Active Directory was not set up with the uppercase form, it will need to be fixed.

avatar
Expert Contributor

@Robert Levas thanks for the answer.

I'll try that tomorrow morning (in 12 hours)

There was a setting before starting kerberization:

Under Advanced kerberos-env section:

"Enable case insensitive username rules"

I have checked this one so thougth it would be enough. Isn't it?

If so, does it mean that we cannot connect an HDP cluster to an Active Directory if AD realm was defined with lower case letters?

avatar

"Enable case insensitive username rule" is related to how principal names are translated into local username. This happens after the Kerberos authentication process and helps to convert uppercase characters in principal names to lowercase characters which may be needed when Active Directory is involved.

If the Active Directory was created with a lowercase realm/domain name it is unlikely that authentication and/or validation attempts will work from the Hadoop cluster. However I think it may be possible if the Active Directory is on Windows 2008 server.

avatar
Expert Contributor

Worked! It is the upper case!

Thank you @Robert Levas!

avatar
Expert Contributor

Follow up question...

Reverting AD Realm name seems to be a long process and risky.

Can anybody confirm @Robert Levas ?

Does anybody have comments on this?

The thing is; I didn't see it was mentioned anywhere in guides but see it first time here.

I even read that host names and domain names should be in lower case in a Hortonworks blog.

https://hortonworks.com/blog/enabling-kerberos-hdp-active-directory-integration/

"

DOMAIN_REALM

provides a translation from a domain name or hostname to a Kerberos realm name. The tag name can be a host name, or a domain name, where domain names are indicated by a prefix of a period (.). Host names and domain names should be in lower case. "

avatar
New Contributor

Reverting AD Realm name seems to be a long process and risky.

Instead of changing Realm in AD change it in Ambari,

You can use the same realm in caps (Like HADOOPAD.LOCAL if it is in lower case in AD ) in Ambari at the time of kerberos enabling, It will work.

avatar
Master Guru

Changing REALM to UPPERCASE in Ambari helps. No need to change in AD(it worked for me on windows server 2012 r2)