R: Multiple AD domains and MIT Kerberos
Eric Schwarz
eric.schwarz.nrla at statefarm.com
Wed Mar 7 08:03:22 EST 2007
Thanks so much for the assistance. We got it to work with no CAPATH...
The administrators of the iBM WebSEAL device that is leveraging the
keytab file did not have the correct configuration. Your assistance was
key to making this happen and I greatly appreciate your help!
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: Douglas E. Engert [mailto:deengert at anl.gov]
Sent: Monday, March 05, 2007 10:27 AM
To: Eric Schwarz
Cc: jaltman at secure-endpoints.com; kerberos at mit.edu
Subject: Re: R: Multiple AD domains and MIT Kerberos
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