cross realm and capaths question

Mon Oct 1 10:29:44 EDT 2007

Markus Moeller wrote:
> "Markus Moeller" <huaraz at moeller.plus.com> wrote in message 
> news:fdoqar$890$1 at sea.gmane.org...
>> "Douglas E. Engert" <deengert at anl.gov> wrote in message 
>> news:46FEDD2E.9090109 at anl.gov...
>>> You say the KDCs are Windows DCs? and the TEST.HOME is not in the forest?
>>> I assume the client LDAP is using the MIT or Heimdal Kerberos, as the 
>>> capaths is only
>>> supported there. Windows uses referrals, where the client can ask its DC
>>> for a tgt, and the DC can return an error with a referral (or was it a 
>>> tgt for the
>>> next hop. I forgot all the details.)
>>>
>> Yes my DCs are Windows 2k3 and my clients run SLES 10 with krb5-1.4.3.
>>
>> BTW I don't think Windows can use referrals in this case or does DOM1 
>> forward all it knows about TEST.HOME to TOP.COM ? If so how ?

I think the AD referrals would be within a forest, but not sure.  \

>>
>>> Markus Moeller wrote:
>>>> I have a setup with 4 DCs. 3 DC build a forest and the fourth hangs of 
>>>> one
>>>> of the sub domains.
>>>>
>>>>                   TOP.COM
>>>>               /                         \
>>>>  DOM1.TOP.COM     DOM2.TOP.COM
>>>>      /
>>>> TEST.HOME
>>>>
>>> So in the krb5.man page example you r reals equate to these:
>>>
>>> TEST.ANL.GOV == TEST.HOME
>>> ANL.GOV      == DOM1.TOP.COM
>>> ES.NET       == TOP.COM
>>> NERSC.GOV    == DOM2.TOP.COM
>>>
>>>> There is full trust betweem TOP.COM and DOM1.TOP.COM and DOM2.TOP.COM.
>>>> TEST.HOME as only full trust to DOM1.TOP.COM.
>>>>
>>>> I try to connect from a user in DOM2.TOP.COM to a system in TEST.HOME 
>>>> with
>>>> the following krb5.conf on DOM2.TOP.COM systems.
>>>>
>>>> [domain_realm]
>>>>  top.com = TOP.COM
>>>>  .top.com = TOP.COM
>>>>  dom1.top.com = DOM1.TOP.COM
>>>>  .dom1.top.com = DOM1.TOP.COM
>>>>  dom2.top.com = DOM2.TOP.COM
>>>>  .dom2.top.com = DOM2.TOP.COM
>>>>  test.home = TEST.HOME
>>>>  .test.home = TEST.HOME
>>>>
>>>> [capaths]
>>>>  DOM2.TOP.COM = {
>>>>  TEST.HOME = DOM1.TOP.COM
>>> The above line may be the problem, it is telling the client that
>>> it can go to DOM1.TOP.COM.  But DOM1.TOP.COM and DOM2.TOP.COM dont
>>> share trust, so it may have fallen back and tries the direct approach,
>>> or it skipped the capaths altogether.
>>>
>>>     TEST.HOME = TOP.COM
>>>     TEST.HOME = DMO1.TOP.COM
>>>
>>> Try these instead, at least it is an easy test.
>> I did change and tested and get now error 28 
>> (KRB5KDC_ERR_PATH_NOT_ACCEPTED)
>>
>> I see
>>
>> TGS-REQ for krbtgt/TEST.HOME to DOM2.TOP.COM
>> TGS-REP unkown Principal

I think the MIT code firsts tries to get a ticket from the
client's realm before looking at the capath.

>> TGS-REQ for krbtgt/DOM1.TOP.COM to DOM2.TOP.COM
>> TGS-REP krbtgt/TOP.COM

Don't know why this one is here. If the client was
looking at the capaths, it should not have tried this.

>> TGS-REQ for krbtgt/TOP.COM to DOM2.TOP.COM
>> TGS-REP krbtgt/TOP.COM

Ok  as expected.

>> TGS-REQ for krbtgt/TEST.HOME to TOP.COM
>> TGS-REP unkown Principal

Again don't know why this on is here, its not on the capath.
(Most of my cross real experience was prior to 1.4.4.)

>> TGS-REQ for krbtgt/DOM1.TOP.COM to TOP.COM
>> TGS-REP krbtgt/DOM1.TOP.COM

OK as expected.

>> TGS-REQ for krbtgt/TEST.HOME to DOM1.TOP.COM
> 
> Does it help to know that the AP request part contains realm TOP.COM and 
> krbtgt/DOM1.TOP.COM ?
> 
>> TGS-REP error_code: KRB5KDC_ERR_PATH_NOT_ACCEPTED (28)

This looks like AD is checking the transited path, and does not like it.
RFC4120 section 2.7 does not require the KDC to check the transited field,
and the client may even ash the KDC to not check it, with the
DISABLE-TRANSITED-CHECK flag, but the KDC may still check.

AD does a lot more with trust the the MIT KDCs and may treat forests and
external realms differently. In your diagram, you are trying to context
TEST.COM not at the forest root. In most of the Microsoft documents they
talk about connecting forests at the root.

Google for: transitive trust active
leads to this:
http://technet2.microsoft.com/windowsserver/en/library/c3f3a3a5-f50a-4d60-afeb-9cbbfe51d94f1033.mspx?mfr=true

They talk about the "New Trust Wizard" handling some other cases. And in

http://technet2.microsoft.com/windowsserver/en/library/c3f3a3a5-f50a-4d60-afeb-9cbbfe51d94f1033.mspx?mfr=true

They talk about the different types of trust. I don't see
"External Transitive" which is what I think you are trying to do.
Although Realm Trust looks very close, but TGEST.COM is AD, not Kerberos.

Can you connect TEST.COM to TOP.COM? This woulf be forest trust.
Or can rename you TEST.COM to TEST.DOM1.TOP.COM and have it join the forest?
Then AD should not have any problems,and you would not need the capaths, as
the default ist to go up the tree then back down.

>>
>>
>>>>   DOM1.TOP.COM = TOP.COM
>>>>   TOP.COM = .
>>>>  }
>>>>  DOM1.TOP.COM = {
>>>>   DOM2.TOP.COM = TOP.COM
>>>>   TOP.COM = .
>>>>  }
>>>>  TEST.HOME = {
>>>>   DOM2.TOP.COM = TOP.COM
>>>>   TOP.COM = DOM1.TOP.COM
>>>>   DOM1.TOP.COM = .
>>>>  }
>>>>
>>>> A walk tree test gives me:
>>>>
>>>> #t_walk_rtree DOM1.TOP.COM TEST.HOME
>>>> krbtgt/DOM1.TOP.COM at DOM1.TOP.COM
>>>> krbtgt/TEST.HOME at DOM1.TOP.COM
>>>>
>>>> #t_walk_rtree DOM2.TOP.COM TEST.HOME
>>>> krbtgt/DOM2.TOP.COM at DOM2.TOP.COM
>>>> krbtgt/DOM1.TOP.COM at DOM2.TOP.COM
>>>> krbtgt/DOM1.TOP.COM at DOM1.TOP.COM
>>>> krbtgt/TEST.HOME at DOM1.TOP.COM
>>>>
>>>>
>>>>
>>>> But when I do a ldapsearch -H ldap://dc.test.home .... I get
>>>>
>>>>    additional info: SASL(-1): generic failure: GSSAPI Error: 
>>>> Miscellaneous
>>>> failure (KDC reply did not match expectations)
>>>>
>>>> An ethereal shows a TGS-REQ of krbtgt/TEST.HOME going to the 
>>>> DOM2.TOP.COM
>>>> instead to DOM1.TOP.COM.
>>>>
>>> Was there any other krb5 packets?
>>>
>> Yes there were. Mostly to DOM2.TOP.COM
>>
>>>> What is wrong inmy configuration ?
>>>>
>>>> Thank you
>>>> Markus
>>>>
>>>>
>>>>
>>>> ________________________________________________
>>>> 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
>>> ________________________________________________
>>> Kerberos mailing list           Kerberos at mit.edu
>>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>>
>> Thank you
>> Markus
>>
>>
>> ________________________________________________
>> Kerberos mailing list           Kerberos at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
> 
> Is there somewhere a better description what shoulud be in the capaths 
> section ?
> 
> Markus 
> 
> 
> 
> ________________________________________________
> 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