Kerberos cross-realm with AD

[Brian Candler]

On Mon, Feb 07, 2011 at 11:36:50AM +1100, Jean-Yves Avenard wrote:
> I have read the MIT documentation and created on both kdc
> krbtgt/M.DOMAIN.COM at MEL.DOMAIN.COM
> krbtgt/MEL.DOMAIN.COM at M.DOMAIN.COM
> 
> I then edited the kerberos krb5.conf with the appropriate capaths and
> configured AD to accept M.DOMAIN.COM issued tickets.
> 
> What I'm unclear about however, is do I need to configure all kerberos
> clients in a similar fashion or is this done only on the 2 kdcs ?
> 
> In particular, I have a FreeBSD server running MIT krb5 1.9 with
> mod_auth_kerb . It is set to accept M.DOMAIN.COM realm . Do I need to
> explicitely configures it to accept MEL.DOMAIN.COM realm, or because
> the two kdcs are configured to accept each other it will then be
> automatic ?

Depends what you mean.

The *authentication* should just work. Someone in MEL.DOMAIN.COM will be
able to get a ticket for host/freebsd.server at M.DOMAIN.COM, which that server
will be able to decrypt using its M.DOMAIN.COM keytab.

However you then may have an issue with *authorization*. For example, if you
ssh as "user" to freebsd.server, by default sshd will only authorize the
login for someone with a ticket "user at M.DOMAIN.COM" (i.e.  the realm of the
server itself)

Solution 1: you can put user at MEL.DOMAIN.COM in ~user/.k5login (or indeed,
any kerberos principals you want to be able to login as 'user').  Easy to
do, but doesn't scale well if you keep having to add and remove users across
all hosts.

Solution 2: you can map all users at MEL.DOMAIN.COM to users at M.DOMAIN.COM

In krb5.conf (on the FreeBSD server) this would be something like:

[realms]
 M.DOMAIN.COM = {
  auth_to_local = RULE:[1:$1@$0](^.*@MEL\.DOMAIN\.COM$)s/@MEL.DOMAIN.COM$//
  auth_to_local = DEFAULT
 }

WARNING: not tested. You need to triple-check that's right, as it could open
you up to various holes if not correct.  The syntax is interesting, to say
the least.  Also, you need to make sure that foo at M.DOMAIN.COM and
foo at MEL.DOMAIN.COM are never two different people.  But it's a one-off
config change on each host.

Solution 3: I don't know, maybe other people on this list have some ideas?

Regards,

Brian.