Joining a multiple realm AD environment

[Markus Moeller]

Chris,

the configuration looks ok, assuming all SRV records are available. How did 
you login to the system via a kerberised client - server application (ssh, 
telnet, ftp) or using the console ?
It will not work through the console if you don't update pam.conf too. You 
need entries like (assuming that users are uniq over both domains and you 
have more users in LOC1.DOM.COM)
other auth sufficient  pam_krb5 REALM=LOC1.DOM.COM
other auth sufficient  pam_krb5 REALM=LOC2.DOM.COM
...

Regards
Markus


"Chris Penney" <penney at msu.edu> wrote in message 
news:111aefd0705110719q41b619eew55d5377246f08a3b at mail.gmail.com...
> Hello,
>
> At our site we have multiple AD realms (LOC1.DOM.COM, LOC2.DOM.COM,
> etc.) that all trust each other.  There are users setup in each realm
> that need to access the Linux systems I maintain.  Today, we have a
> completely independent realm (with our own principle for each user)
> that I want to do away with and just join the AD structure (ie. be
> assimilated ;) ).
>
> I have proven that with krb5-1.5.3 I can set my default realm to
> LOC1.DOM.COM and effectively login (my account is in LOC1).  Users
> from other realms cannot.  I'm curious what I need to do to make this
> work.  We have SRV records setup for kdc lookup.  I have not yet
> created a computer account for the system.  In /etc/krb5.conf I have:
>
> [libdefaults]
>    default_realm = LOC1.DOM.COM
>    dns_lookup_kdc = true
>    dns_lookup_realm = false
>    forwardable = true
>
> [realms]
>    LOC1.DOM.COM = {
>        auth_to_local = RULE:[1:$1@$0](.*@LOC2\.DOM\.COM)s/@.*//
>        auth_to_local = DEFAULT
>    }
>    LOC2.DOM.COM = {
>        auth_to_local = RULE:[1:$1@$0](.*@LOC1\.DOM\.COM)s/@.*//
>        auth_to_local = DEFAULT
>    }
>
> This doesn't seem to work.  Using 'tcpdump port kerberos' when a user
> in LOC2 logs in I only see LOC1 being queried.  I'm curious if I'm
> doing something wrong or if I simply need to get a computer account
> created for the box before trusts work.  I was hopeing to not approach
> the AD staff until I was more or less certain I knew what needed to be
> done.
>
> Thanks,
>
>   Chris
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>