[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cross Realm Auth: how to resolve the issue of finding the 'Correct' realm of service for ms w2k client...
I'm not sure I understand what you mean....
or maybe we have different goals ?
I'll try to re-explain my problem in a better way:
I have two domains located in 2 different realms:
domain A is a win2k domain
domain B is a kerberos domain (a Heimdal kerberos
realm - I have to use heimdal bec I intend to use it
with openldap)
There exists a cross-realm trust between domain A and
domain B.
In domain A, there is a win2k prof machine, let's we
call it PC-1.
While in domain B, there is a win2k prof machine as
well: PC-2.
A user using PC-2 has successfully authenticated
himself to Kerberos Realm (domain B), and now the user
wants to access PC-1 in domain A. Theoritically, this
is possible since the cross-realm trust has been
established.
So, PC-2 sent a TGS to its KDC in domain B requesting
for service: host/PC-1@DOMAINB.COM (the short name of
PC-1). As I traced the code, I noticed that the KDC
was trying to find a match for PC-1, either in
krb5.conf or DNS entry (_kerberos.PC-1). Hence, the
KDC would only be able to return PC-2 a referral if I
have created a mapping entry for PC-1 in
[domain_realm] section of krb5.conf like the
following:
PC-1 = DOMAINA.COM
or if i created a DNS entry as the following:
_kerberos.PC-1 IN TXT DOMAINA.COM
I imagine that this will be very painful if I have to
create a mapping for every service that exists in the
domain, and imagine if there are lots of domain !
Any comments ?
--- Kevin Coffman <kwc@citi.umich.edu> wrote:
> We needed this referral support in our environment
> (using an MIT KDC
> for initial authentication to Windows). We started
> with a patch
> reported to have originated at Microsoft. It simply
> sent all referrals
> off to a domain specified in krb5.conf. We needed
> to support two
> Windows forests so we added code to use the service
> name to determine
> the correct destination for the referral. Our patch
> uses a new
> 'domain_referral' stanza in the krb5.conf file.
>
> This left the problem of short names, which give no
> clue as to which
> domain the referral should go. We punted on this
> issue. In the case of
> a short name, we send the referral to the "default"
> domain. In our
> case, the default domain is our production forest,
> rather than our test
> forest. I haven't heard of any complaints. An
> alternative would be to
> have another mapping of short names to referral
> domain.
>
> See
>
http://www.citi.umich.edu/u/kwc/krb5stuff/referrals.html
> for more
> info.
>
> K.C.
>
> > Hello,
> >
> > Quoting from the paper of Michael Swift, Irina
> > Kosinovsky and Johathan Trostle titled
> Implementation
> > of Crossrealm Referral Handling in the MIT
> Kerberos
> > Client:
> >
> > "The Windows 2000 client does not canonicalize
> names
> > at all, so the short name is sent to the KDC."
> >
> > Hence, if my understanding is correct, a request
> for
> > service: host/service-name.foo.org will be sent to
> MIT
> > Kerberos KDC as host/service-name@KERBEROS.REALM
> and
> > not as host/service-name.foo.org@KERBEROS.REALM
> >
> > How does MIT Kerberos determine the appropriate
> realm
> > to be used in issuing a referral ticket for the
> > client's request ? DNS ? Krb5.conf ? Does this
> mean
> > that every service-name must have an entry in the
> DNS
> > or Krb5.conf. For example:
> > serviceA = realmA
> > serviceB = realmB
> > Coz I think the KDC doesn't have any clue of the
> > domain of the service, only the service-name...
> >
> > Thanks in advance,
> > -lara-
> >
> > =====
>
=====
------------------------------------------------------------------------------------
La vie, voyez-vous, ca n'est jamais si bon ni si mauvais qu'on croit
- Guy de Maupassant -
------------------------------------------------------------------------------------
__________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online by April 15th
http://taxes.yahoo.com/filing.html