Kerberos trust

[Todd Grayson]

There are a couple of approaches for establishing trust on the AD side.
You have command line for ksetup that can be used, or the AD gui works as
well (the domains and trusts management console).  kadmin side on the mit
kdc you have to update your krb5.conf to provide the AD realm in the
[realms] section, and within [domain_realm] if there are special fqdn to
REALM mappings that need to exist.

Generally for Hadoop the optimal implementation is one way cross realm
trust where the cluster MIT KDC trusts that users from the AD domain/REALM
have been properly authenticated by the trusted realm, and that the
representation of their user (principal name) is valid for access.

Effectively on the AD side its netdom trust, then ksetup to describe the
realm and if necessary DNS mapping to the kerberos realm (much like the
domain_realm section of the krb5.conf, but the windows registry version of
it).

then on the MIT side its a kadmin addprinc and setting the proper
encryption types that are common with AD and setting the same password
defined on AD.

netdom trust and ksetup examples that are correct for AD / MIT kerberos
http://blog.godatadriven.com/cross-realm-trust-kerberos.html

Microsoft ksetup docs
ksetup addkdc
https://technet.microsoft.com/en-us/library/hh240197.aspx
ksetup addhosttorealmmap (!) for smoothing domain / realm mappings from
windows desktop client side.

the netdom trust is a global command, the ksetup commands are machine
specific, I think microsoft documents using global policy to establish
things in a uniform way for a large set of windows desktops if needed...

There are some pretty good examples online;  The google machine comes back
with some write-ups on this with the string:

kerberos one way cross-realm trust MIT AD

our cloudera writeup that is specific to MIT / AD cross realm trust is
generic enough to apply to your open source hadoop deployment as well.

On Wed, Apr 13, 2016 at 2:02 PM, Russ Allbery <eagle at eyrie.org> wrote:

> 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/>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>



-- 
Todd Grayson
Business Operations Manager
Customer Operations Engineering
Security SME