cross realm and capaths question

[Markus Moeller]

"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 ?
>
>>
>> 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
> TGS-REQ for krbtgt/DOM1.TOP.COM to DOM2.TOP.COM
> TGS-REP krbtgt/TOP.COM
> TGS-REQ for krbtgt/TOP.COM to DOM2.TOP.COM
> TGS-REP krbtgt/TOP.COM
> TGS-REQ for krbtgt/TEST.HOME to TOP.COM
> TGS-REP unkown Principal
> TGS-REQ for krbtgt/DOM1.TOP.COM to TOP.COM
> TGS-REP krbtgt/DOM1.TOP.COM
> 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)
>
>
>>
>>>   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