unable to authenticate as "username" to cluster after enabling kerberos

[#1]

I enabled kerbros using MIT KDC. MIT KDC has a trust setup with Active Directory. Say my AD realm was "EXAMPLE.COM" and local realm was "HADOOP.CLUSTERNAME.EXAMPLE.COM".

When i do a kinit <username>@EXAMPLE.COM, i'm able to get a kerberos ticket from the Active Directory. Now this should allow me to use hadoop as "username". However, instead it allows me to use only if i'm "username@EXAMPLE.COM".

Ex 1:

once authenticated with kerberos:

hadoop fs -put <localfile> /user/<username>/ - doesn't allow

But,

hadoop fs -mkdir /user/<username>@EXAMPLE.COM

hadoop fs -put <localfile> ---- this works

Ex 2:

hbase shell

user "username" has permission to access a table but, won't be allowed to access the table unless "username@EXAMPLE.COM" has access to table (or in other words):

after kinit <username>@EXAMPLE.COM

grant '<username>','R','tablename' --- will not allow me to access the table whereas grant '<username@EXAMPLE.COM>','R','tablename' will allow me to access the table.

[#2 · Accepted solution]

@Narendra Neerukonda

There is a place in the Ambari UI to set "additional realms". This is a comma-delimited list of realm names that Ambari will use to generate special auth-to-local rules. For each realm, Ambari will add the following rule

RULE:[1:$1@$0](.*@REALM)s/@.*//

For your example, you will add "EXAMPLE.COM" to the additional realms field. Ambari will then add the following rule to all auth-to-local rule properties it knows about:

RULE:[1:$1@$0](.*@EXAMPLE.COM)s/@.*//

Then principal names like user@EXAMPLE.COM will be translated into "username" when services are perform auto-to-local rule translations.

The "Additional Realms" field is found in the administrative Kerberos view... not to be confused with the Kerberos service view.

Make sure that you have also edited the krb5.conf template that Ambari uses to generate the krb5.conf files so that the realm is known to the Kerberos infrastructure. I assume that you already did this since you are able to kinit as a user from EXAMPLE.COM. Also, make sure that you established a trust relationship between the MIT KDC and the Active Directory. Else, even though you are able to kinit, services will not trust Kerberos tokens for that user and fail authentication. Looking at the error you are seeing, I assume you did this as well since the user appears to have been authenticated.

[#3]

Thanks @Robert Levas This fixed it.

[#4]

@Narendra Neerukonda Awesome... I am glad that I could help. Be sure to accept my answer to close out this issue.