Kerberos trust

Russ Allbery eagle at eyrie.org
Wed Apr 13 16:02:25 EDT 2016


Mauro Cazzari <mymagicid at gmail.com> writes:

> I'm relatively new to Kerberos, so please forgive me if my question
> might sound dumb.

> I'm trying to access a secured Hadoop environment from a Windows
> machine.  The Hadoop cluster uses its own realm. I installed MIT
> Kerberos on the Windows box and configured it so that I can successfully
> obtain tickets, but I'd like to see if there is a way to instead use the
> tickets that are generated through AD when I log on to Windows. My
> understanding is that a one-way trust between the AD and the cluster's
> KDC could solve the issue.  What's not clear is whether I need to define
> anything at all at the AD level. I'm thinking that since I'm trying to
> gain access to the realm associated with the Hadoop cluster, all I need
> to do is to add a principal to it for the AD realm, the one I want to
> trust. After that, I would change the krb5.conf file to make sure the AD
> realm is seen.

Even one-way trust requires making changes to both KDCs, since for any
type of trust you need to have a shared key between AD and the remote KDC.
The only difference between one-way trust and two-way trust is that you
have only one shared key instead of two shared keys.

In theory, one-way trust where you have a krbtgt/<hadoop-realm>@<ad-realm>
principal in both KDCs should be sufficient.  In practice, I have run into
no end of weird trouble with one-way trust, and strongly prefer to set up
two-way trust whenever I set up cross-realm trust just to avoid having my
head hurt later.

Note that you'll also have to configure the Windows side to know to do
cross-realm to the Hadoop realm when accessing those resources.  There are
probably ways to do this with local configuration, but I think
domain_realm mappings on Windows are usually also done with AD
configuration.  (Disclaimer: I've never done the AD side of this setup
myself.)

-- 
Russ Allbery (eagle at eyrie.org)              <http://www.eyrie.org/~eagle/>


More information about the Kerberos mailing list