R: Multiple AD domains and MIT Kerberos

Douglas E. Engert deengert at anl.gov
Mon Mar 5 11:26:39 EST 2007



Eric Schwarz wrote:
>  Jeffrey,
> 
> After reading up a lot on this I would like to request your patience one
> more time...
> 
> Based on the diagram I have attached, we have a user account in the
> DOM1.EXAMPLE.COM domain of a forest you can see. That resource is
> accessed via SPN http/webcontent.dom1.example.com at DOM1.EXAMPLE.COM. The
> UNIX machines hosting the web content are also in the DOM1.EXAMPLE.COM
> realm. Based on
> http://www.faqs.org/faqs/kerberos-faq/general/section-48.html it appears
> that I must define in the [capaths] section of the krb5.conf the
> transitive trusts for the forest if I want users from any other AD
> domain to be able to access the resource outside of DOM1.EXAMPLE.COM.
> Thus I have tried to construct a krb5.conf file that would be
> appropriate. Is this anywhere near correct?

The default for the capaths is to work up and down the realm name
which looks like your case, so you should not need a [capaths]
section. But it looks like you may have some errors,
see below.

There is a test program in the MIT source code
src/lib/krb5/krb/t_walk_rtree.c that will show the path
taken between two realms and sho all the TGTs needed.
The program is not normally built, you can do a
make t_walk_rtree in that directory. then
setenv KRB5_CONFIG to the test krb5.conf


You give it a starting and ending realm, and it shows the
intermediate realms, if any. These are the realms that can
be in the transited field.


> 
> [libdefaults]
>         default_realm = DOM1.EXAMPLE.COM
>         default_keytab_name = FILE:/etc/krb5/krb5.keytab
>         default_tkt_enctypes = des-cbc-md5 des-cbc-crc
>         default_tgs_enctypes = des-cbc-md5 des-cbc-crc
> 
> 
> [realms]
>         EXAMPLE.COM = {
>                 kdc = dc23.EXAMPLE.COM:88
>                 admin_server = dc23.EXAMPLE.COM:749
>                 default_domain = EXAMPLE.COM
> 
>         }
>         DOM1.EXAMPLE.COM= {
>                 kdc = dc72.DOM1.EXAMPLE.COM:88
>                 admin_server = dc72.DOM1.EXAMPLE.COM:749
>                 default_domain = DOM1.EXAMPLE.COM
> 
>         }
>         DOM2.EXAMPLE.COM = {
>                 kdc = dc44.DOM2.EXAMPLE.COM:88
>                 admin_server = dc44.DOM2.EXAMPLE.COM:749
>                 default_domain = DOM2.EXAMPLE.COM
> 
>         }
>         SUBDOM.DOM2.EXAMPLE.COM = {
>                 kdc = dc9.SUBDOM.DOM2.EXAMPLE.COM:88
>                 admin_server = dc9.SUBDOM.DOM2.EXAMPLE.COM:749
>                 default_domain = SUBDOM.DOM2.EXAMPLE.COM
> 
>         }
> 
> [domain_realm]
>         .dom1.example.com = DOM1.EXAMPLE.COM
> 
> [logging]
>         kdc = FILE:/var/krb5/log/krb5kdc.log
>         admin_server = FILE:/var/krb5/log/kadmin.log
>         default = FILE:/var/krb5/log/krb5lib.log
> 
> [capaths]
>        EXAMPLE.COM = {
>                DOM1.EXAMPLE.COM = .
>                DOM2.EXAMPLE.COM = .
>                SUBDOM.DOM2.EXAMPLE.COM = DOM2.EXAMPLE.COM
>        }
>        DOM1.EXAMPLE.COM = {
>                EXAMPLE.COM = .
>                DOM2.EXAMPLE.COM = EXAMPLE.COM
>                SUBDOM.DOM2.EXAMPLE.COM = DOM2.EXAMPLE.COM
>        }
>        DOM2.EXAMPLE.COM = {
>                EXAMPLE.COM = .
>                DOM1.EXAMPLE.COM = .

The above should be DOM1.EXAMPLE.COM = EXAMPLE.COM
The way you have it, it is assumed the DOM2.EXAMPLE.COM and
DOM1.EXAMPLE.COM share a common key. It the server uses
this, but fines  EXAMPLE.COM in the transited field,
it will reject the entry.

>                SUBDOM.DOM2.EXAMPLE.COM = .
>        }
>        SUBDOM.DOM2.EXAMPLE.COM = {
>                DOM2.EXAMPLE.COM = .
>                EXAMPLE.COM = DOM2.EXAMPLE.COM
>                DOM1.EXAMPLE.COM = EXAMPLE.COM

This should be  DOM1.EXAMPLE.COM = DOM2.EXAMPLE.COM
as your ways says  EXAMPLE.COM shares a key with
SUBDDOM.DOM2.EXAMPLE.COM

./t_walk_rtree SUBDOM.DOM2.EXAMPLE.COM DOM1.EXAMPLE.COM
krbtgt/SUBDOM.DOM2.EXAMPLE.COM at SUBDOM.DOM2.EXAMPLE.COM
krbtgt/EXAMPLE.COM at SUBDOM.DOM2.EXAMPLE.COM
krbtgt/DOM1.EXAMPLE.COM at EXAMPLE.COM


>        }
> 
> 
> Thanks so much and again I appreciate the indulgence :)
> 
> Eric Schwarz 
> MCSE, MCT, Security+ 
> Server/ Active Directory- Team Lead
> Windows Security Services C01910 
> Systems Technology 
> 
> phone-  (309) 763-2873 
> mobile-  (309) 319-3238
> email-    eric.schwarz.nrla at statefarm.com  
> hpsd-    SERVER-WINSECURITY (WG2716) 
>               WinSecurity Change Management (WG2811)
> 
> 
> -----Original Message-----
> From: Eric Schwarz 
> Sent: Saturday, March 03, 2007 5:36 AM
> To: 'jaltman at secure-endpoints.com'
> Cc: kerberos at mit.edu
> Subject: RE: R: Multiple AD domains and MIT Kerberos
> 
> Jeffrey,
> 
> Thank you so much for replying!
> 
> Q. Would the [domain_realm] entry look like this-
> 
> 	[domain_realm]
>         	host.example.com = SUBDOM.DOM2.EXAMPLE.COM
> 
> Is this correct?
> -----------------------------------------
> 
> Q. Is there any need to map any of the other AD domain names within
> [domain_realm]? There is only a single resource SPN being accessed in
> this case and it is host.example.com.
> 
> -----------------------------------------
> 
> Q. In this scenario then the UNIX machine would be in the
> SUBDOM.DOM2.EXAMPLE.COM AD domain and that is listed under the 
> 
> 	[libdefaults]
>         	default_realm = SUBDOM.DOM2.EXAMPLE.COM
> 
> Is this correct?
> -----------------------------------------
> 
> Q. So in this example there is no need for a [capath] entry? 
> 
> -----------------------------------------
> 
> Q. Is there any need to list any KDC for any realms/ domains outside of
> SUBDOM.DOM2.EXAMPLE.COM in the [realms] section?
> 
> -----------------------------------------
> With this in place, a user account located in any of the four domains
> should be able to access http://host.example.com based on the SPN
> http/host.example.com being registered on the account in the
> SUBDOM.DOM2.EXAMPLE.COM AD domain? 
> 
> Is this correct?
> 
> -----------------------------------------
> 
> I cannot express enough gratitude for the assistance!
> 
> Eric Schwarz 
> MCSE, MCT, Security+ 
> Server/ Active Directory- Team Lead
> Windows Security Services C01910 
> Systems Technology 
> 
> phone-  (309) 763-2873 
> mobile-  (309) 319-3238
> email-    eric.schwarz.nrla at statefarm.com  
> hpsd-    SERVER-WINSECURITY (WG2716) 
>               WinSecurity Change Management (WG2811)
> 
> 
> -----Original Message-----
> From: Jeffrey Altman [mailto:jaltman at secure-endpoints.com] 
> Sent: Friday, March 02, 2007 4:01 PM
> To: Eric Schwarz
> Cc: kerberos at mit.edu
> Subject: Re: R: Multiple AD domains and MIT Kerberos
> 
> if the host name is host.example.com and the service principal is
> http/host.example.com at SUBDOM.DOM2.EXAMPLE.COM then the domain realm
> entry for host.example.com should be SUBDOM.DOM2.EXAMPLE.COM
> 
> Jeffrey Altman
> Secure Endpoints Inc.
> 
> 
> Eric Schwarz wrote:
>> Hello,
>>
>> We have a situation where we are trying to get AIX Kerberos to
> interoperate with Microsoft w2k3 AD 4-domain forest. The challenge is to
> get the krb5.conf configuration to allow for the SPN to be registered in
> an account that is not in the root domain of the forest. Example-
>> Forest-
>>
>> Example.exm
>> Dom1.example.exm
>> Dom2.example.exm
>> SubDom.Dom2.example.exm
>>
>> How do you configure the krb5.conf file to understand that the keytab
> file is coming from an account in Dom1.example.exm (SPN=
> http\web.example.com), yet the AIX machine should allow any Windows
> account from any of the domains in the forest to authenticate to the AIX
> machine? We believe it would have something to do with the [realms]
> and/or [capath] settings... but cannot get it configured to accept
> authentication from all domains unless the account with the target SPN
> is in the root domain and all sub-domains then share a contiguous name
> space. As son as we place the target SPN on a sub-domain account only
> users from that domain can authenticate... all other domains cannot.
>> Any help would be appreciated.
>>
>> Thanks!
>>
>> Eric Schwarz 
>> MCSE, MCT, Security+ 
>> Server/ Active Directory- Team Lead
>> Windows Security Services C01910 
>> Systems Technology 
>>
>> phone-  (309) 763-2873 
>> mobile-  (309) 319-3238
>> email-    eric.schwarz.nrla at statefarm.com  
>> hpsd-    SERVER-WINSECURITY (WG2716) 
>>               WinSecurity Change Management (WG2811)
>>
>>
>> ________________________________________________
>> Kerberos mailing list           Kerberos at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>> ------------------------------------------------------------------------
>>
>> ________________________________________________
>> Kerberos mailing list           Kerberos at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444



More information about the Kerberos mailing list