Test cross realm kerberos

[#1]

I have Kerberos authentication working with a stand alone KDC. However, our next step is to allow users from another realm/domain to access the cluster. Obviously I followed the guide for cross realm configuration, but I am having little success. Does anyone know of another way to test the cross realm configuration without going through the cluster? Or at least how to turn on some more robust logging?

The authentication always stays on the local kdc and never tries to go out to the AD. I was under the impression that once the configurations with the cross realm principals were in place, kerberos would look first locally for an acount and then remotely. However I am guessing that I am completely off base. Here are my crossrealm entries in my KDC:

krbtgt/DATA.FOREST.COM@DATA.FOREST.COM
krbtgt/DATA.FOREST.COM@FOREST.COM
krbtgt/FOREST.COM@DATA.FOREST.COM

Here is my krb5.conf:

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = DATA.FOREST.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true

[realms]
DATA.FOREST.COM = {
kdc = ip-10-0-0-241.us-west-2.compute.internal
admin_server = ip-10-0-0-241.us-west-2.compute.internal
default_domain = data.forest.com

}
FOREST.COM = {
kdc = ip-10-0-0-251.us-west-2.compute.internal
admin_server = ip-10-0-0-251.us-west-2.compute.internal
default_domain = forest.com
}

[domain_realm]
.data.forest.com = DATA.FOREST.COM
data.forest.com = DATA.FOREST.COM
.forest.com = FOREST.COM
forest.com = FOREST.COM

Any assistance would be appreciated.

[#2 · Accepted solution]

The preferred way to test a cross-realm auth (in CDH context) is to try and obtain a cluster realm's service ticket when logged in as the remote realm.

kinit user@REMOTEREALM
kvno hdfs/namenode-host@LOCALREALM

If the service ticket obtaining fails, then Cross Realm Trust is broken.

A lot of people also oversee/misconfigure [domain_realm]. It exists to mean an automatic mapping of hostnames to their realms, and it factors greatly into the use of cross-realm trust when dealing with service authentication.

An ideal [domain_realm], if you have two cluster realms A (host1.a.com, host2.a.com) and B (mybhost.data.com, mychost.data.com) would look like:

[domain_realm]
host1.a.com=A
host2.a.com=A
mybhost.data.com=B
mychost.data.com=B

Or if you use the limited wildcard ability, if applicable range-wise:

[domain_realm]
.a.com=A
.data.com=B

This section helps Kerberos libraries and clients to find the right KDC to talk to when looking for a server under a specific realm (its the intelligence mapping that helps determine which service host lies in what realm).

Another thing to remember is that the communication isn't done in fallback manner. The trust works based on the key being the same on both ends (For the krbtgt principals). That is, an encrypted token generated on one end may be trusted on another end if it can decrypt it (and since you use the same key on both sides, this is possible). The path of communication therefore is purely dependent on reaching the correct KDC for the provided principal - something [domain_realm] would help with.

Does this help?

[#3]

Thanks this is very helpful. It seems that the problem was the encryption of the cross realm entries in the MIT KDC. Using kvno is a very quick way of testing.

[#4]

Glad to hear you were able to figure it out! In spirit of
https://xkcd.com/979/, please consider sharing more details of the solution
and marking the topic as solved for others with similar issues.

[#5]

To solve this I did a kinit <account>@FOREST.COM which goes to the remote (AD) domain and then klist -e to see what encryption types were being sent back. In my case we were getting aes256 and arcfour. The cross realm entries were only encrypted for arcfour, so I recreated the cross realm entries with all the encryption types being sent by the remote domain in my local KDC. So it looked like this:

addprinc -e "arcfour-hmac:normal aes256-cts-hmac-sha1-96:normal"  krbtgt/DATA.FOREST.COM@DATA.FOREST.COM
addprinc -e "arcfour-hmac:normal aes256-cts-hmac-sha1-96:normal"  krbtgt/DATA.FOREST.COM@FOREST.COM

after a restart of the local KDC things are working well. The most helpful piece was turning on debugging:

HADOOP_OPTS="-Dsun.security.krb5.debug=true"

Without the debugging I had no idea it was even trying to connect to the remote domain.

[#6]

Hi Harsha, 

I need your help in Setting up Cross-Realm Auth between 2 secured clusters. How can i reach you?

Thanks,

[#7]

Hi Harsha,

Need your help in setting up cross-realm Auth. How can i contact you ?

Thanks,

[#8]

Hello @Platform,

Since this is a community, you get the benefit of many people looking at your questions or issues.

We prefer to keep our discussions here public unless there are sensitive data involved.

Please start a new thread and explain what you have tried and what the result was and I and many others will be happy to help you out.

Thanks,

Ben

[#9]

Thanks... Following the cloudera Doc's I was able to sucessfully setup Cross-realm trust. Issue is with DNS.