Mikkel Kruse Johnsen wrote:
> Hi All
>
> Still haven't fixed this, but after reading more about it, I found
> someone who said that Microsoft when implementing the Kerberos protocol
> had changed something (big surprise) and instead of making it the
> clients job to figure out whitch server to contact they made it the
> servers job.
Yest that would be:
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-referrals-09.txt
Abstract
The memo documents a method for a Kerberos Key Distribution Center
(KDC) to respond to client requests for Kerberos tickets when the
client does not have detailed configuration information on the realms
of users or services. The KDC will handle requests for principals in
other realms by returning either a referral error or a cross-realm
TGT to another realm on the referral path. The clients will use this
referral information to reach the realm of the target principal and
then receive the ticket.
This is draft-09. Draft-00 was from 2001, and included authors from
University of Washington, Microsoft, Cisco and MIT. So its not so much
a big surprise. On the other hand is show Microsoft is willing to work
with the standard committees.
(Personally, I thing this is a good idea, and would like to see the
other Kerberos vendors get this implemented even in draft form.)
There is some way in AD to use the Global Catalog, with TDO and
routing hints. (I have not done this, or found the article yet.)
Googling for: referral AD kerberos Global
can get you started.
Also look for: routing name suffixes across forests
and realm trust
If you find the commands please post to the list.
Meaning that the windows client always sends the request to
> the AD, even if it should contact the linux kerberos.
>
> On lInux i would think it goes like this:
>
> I have a ticket from the AD (HHK.DK).
> I go the the webserver named "sugi.cbs.dk"
> The Client sees that it is ".cbs.dk" and then contacts the linux
> kerberos.
>
> [domain_realm]
> .cbs.dk = CBS.DK
> cbs.dk = CBS.DK
> .hhk.dk = HHK.DK
> hhk.dk = HHK.DK
>
> It gets the krbtgt to CBS.DK realm and then the
> HTTP/sugi.cbs.dk at CBS.DK ticket.
> It works.
>
>
> On Windows:
>
> I have a ticket from the AD (HHK.DK)
> I go the the webserver named "sugi.cbs.dk"
> The client contacts the AD (ns1.hhk.dk).
> The server never gives me the krbtgt for CBS.DK
> It fails.
>
>
>
> How do I tell the AD that it should send back a krbtgt ad forward me to
> the linux kerberos. ?
> Should I use DNS for this ?
>
> Any help please
>
> /Mikkel
>
> On Tue, 2007-07-10 at 15:34 +0200, Mikkel Kruse Johnsen wrote:
>
>> Hi Markus
>>
>> That seems logical that it will try to contact the HHK.DK (the AD) for
>> a krbtgt when using windows.
>>
>> But under linux when using the HHK.DK realm I don't see why it
>> souldn't use the AD aswell. both the client and the server (where
>> mod_auth_kerb is installed and the same as the kerberos server) has
>> the krb5.conf file as: (ns1.hhk.dk is the AD)
>>
>> ...
>> [realms]
>> CBS.DK = {
>> kdc = kerberos.cbs.dk:88
>> admin_server = kerberos.cbs.dk:749
>> default_domain = cbs.dk
>> }
>> HHK.DK = {
>> kdc = ns1.hhk.dk:88
>> admin_server = ns1.hhk.dk:749
>> default_domain = hhk.dk
>> }
>> ....
>>
>> So it should never ask the linux server for the krbtgt. Also I only
>> see these lines in krb5kdc.log when accessing it.
>>
>> --
>> Jul 10 15:22:46 sugi.cbs.dk krb5kdc[21180](info): TGS_REQ (7 etypes
>> {18 17 16 23 1 3 2}) 130.226.36.170: ISSUE: authtime 1184073716,
>> etypes {rep=1 tkt=23 ses=16}, mkj.lib at HHK.DK for
>> HTTP/sugi.cbs.dk at CBS.DK
>> Jul 10 15:22:46 sugi.cbs.dk krb5kdc[21180](info): TGS_REQ (7 etypes
>> {18 17 16 23 1 3 2}) 130.226.36.170: ISSUE: authtime 1184073716,
>> etypes {rep=1 tkt=23 ses=16}, mkj.lib at HHK.DK for
>> HTTP/sugi.cbs.dk at CBS.DK
>> --
>>
>> Witch, I think, suggest that it never ask the linux server for the
>> krbtgt but the AD (I have to get access to the logs on the AD).
>>
>> Any other suggestion is welcome.
>>
>> /Mikkel
>>
>>
>> On Tue, 2007-07-10 at 14:59 +0200, Markus Schuh wrote:
>>
>>> Mikkel Kruse Johnsen wrote:
>>>> What I have is an MS Active Directory 2003 (but running in 2000 mode)
>>>> with realm "HHK.DK" then I have a Linux Kerberos server (RHEL5 64bit)
>>>> with realm "CBS.DK". I have made a two-way trust between them.
>>>> (http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/kerbstep.mspx#EVCAC).
>>> Only guessing -
>>> my kerberos, especially cross-realm, understanding is still limited.
>>>
>>> When logged in on Linux as mkj.lib at HHK.DK and accessing
>>> http://sugi.cbs.dk/ you communicate with the ticket granting service of
>>> CBS.DK to get krbtgt/CBS.DK at HHK.DK
>>> This succeeds.
>>>
>>> When logged in on the windows workstation which has joined HHK.DK, I
>>> think the problem is:
>>> The workstation asks your Win2003 Domain controller for a granting
>>> ticket. But the Domain controller is not able to give you such a
>>> granting ticket. (The question is: why?)
>>> Since modauthkerb offers Negotiation, and IE did not get a valid ticket,
>>> it falls back to NTLM.
>>> Since Firefox (per default) uses the same system dll (SSPI) for
>>> negotiation, the problem is the same here.
>>>
>>> Why do I think, the Windows DC rejects to give the user a granting
>>> ticket of a trusted domain?
>>>
>>> We use modauthkerb successfully on a linux server which has an account
>>> in our Win2003 Forest in Windows 2000 native mode. We have a two-way
>>> trust to another forest (in Windows 2000 native mode, too)
>>> But until now we were not able to authenticate successfully with user
>>> accounts of the other domain. I tried to debug the problem and found a
>>> statement on technet that we need Windows 2003 native mode on both sides
>>> to be able to do cross authentication.
>>> At this point I stopped my investigation because we found another
>>> solution (we use different reverse proxies)
>>>
>>> I'm still searching the technet article where I found these statement
>>> but I had no success, yet.
>>>
>> Mikkel Kruse Johnsen
>> Linet
>> Ørholmgade 6 st tv
>> 2200 København N
>>
>> Tlf: +45 2128 7793
>> email: mikkel at linet.dk
>> www: http://www.linet.dk
>> !DSPAM:46938aeb22014042098162!
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>>
>> !DSPAM:46938aeb22014042098162!
>> _______________________________________________
>> modauthkerb-help mailing list
>> modauthkerb-help at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/modauthkerb-help
>>
>>
>> !DSPAM:46938aeb22014042098162!
>
> Mikkel Kruse Johnsen
> Linet
> Ørholmgade 6 st tv
> 2200 København N
>
> Tlf: +45 2128 7793
> email: mikkel at linet.dk
> www: http://www.linet.dk
> ________________________________________________
> 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