Problems with authenticating to a Win domain controller

Douglas E. Engert deengert at anl.gov
Thu May 29 10:17:18 EDT 2008



radaczynski at gmail.com wrote:
> On May 28, 5:47 pm, "Douglas E. Engert" <deeng... at anl.gov> wrote:
>> radaczyn... at gmail.com wrote:
>>> Hi,
>>> I've recently encountered a strange error when trying to get a ticket
>>> from a W2k domain controller. My setup is like this:
>>> 1. krb5.conf:
>>> [libdefaults]
>>>         default_realm = DOMAIN1.COM
>>>         forwardable = true
>>>         proxiable = true
>>>         dns_lookup_realm = false
>>>         dsn_lookup_kdc = false
>>>         v4_instance_resolve = false
>>>         v4_name_convert = {
>>>                 host = {
>>>                         rcmd = host
>>>                         ftp = ftp
>>>                 }
>>>                 plain = {
>>>                         something = something-else
>>>                 }
>>>         }
>>> [realms]
>>>         DOMAIN1.COM = {
>>>                 kdc = aaa.domain1.com:88
>>>         }
>>> [domain_realm]
>>>         .domain1.com = DOMAIN1.COM
>>>         domain1.com = DOMAIN1.COM
>>>         .domain2.com = DOMAIN2.COM
>>>         domain2.com = DOMAIN2.COM
>>> [appdefaults]
>>>         pam = {
>>>             debug=false
>>>             forwardable=true
>>>             krb4_convert=false
>>>         }
>>> DOMAIN2 is a trusted domain of DOMAIN1
>>> now, when i do this:
>>> kinit myu... at DOMAIN2.COM
>>> Password for myu... at DOMAIN2.COM:
>>> and i get a TGT:  renew until 05/29/08 08:55:12, Etype (skey, tkt):
>>> ArcFour with HMAC/md5, ArcFour with HMAC/md5, the principal is: krbtgt/
>>> DOMAIN2.... at DOMAIN2.COM
>>> then I try:
>>> kvno HTTP/test.domain1.... at DOMAIN1.COM
>>> and get:
>>> Server not found in Kerberos database while getting credentials
>> This might be some cross realm issue. To get a ticket from
>> DOMAIN1.COM requires you to first get a krbtgt/DOMAIN1.... at DOMAIN2.COM
>> from DOMAIN2.COM.
> 
> Can you please tell me how to do it with command line utilities from
> MIT kerberos?

The Kerberos Libraries do this for you.

> 
>> You set the dns_lookup_kdc = false, and did not define DOMAIN1.COM in
>> [realms] so you client can not find the KDCs for DOMAIN1.COM.
> 
> actually, I did - I did not define DOMAIN2.COM, for which I do obtain
> tgt's.
> 
>> It might be an issue that the cross realm trust is not set up as you
>> think it is.
> 
> doesn't the above prove that the cross realm trust is set up?

No. Getting a krbtgt/DOMAIN1.COM at DOMAIN2.COM and using it to get
another ticket at DOMAIN1.COM would prove it.

> 
>> To verify all if these for sure, use a trace program like Wireshark,
>> that can format the Kerberos packets.
> 
> I will do that and report back the results. Any hints for running it?

It has a GUI. Run as root on your client (windows or unix) and capture
all traffic on your interface. Look for the KRB5 packets.

> 
> 
>>> when I ty:
>>> kvno HTTP/test.domain1.... at DOMAIN2.COM
>>> I get:
>>> KDC reply did not match expectations while getting credentials
>> W2K may have returned a referral saying look in DOMAIN1.COM.
>> But the Kerberos lib does not handle today.
> 
> That's probably it -> I should look in DOMAIN1.COM, since the service
> principal is in DOMAIN1.COM.

You should also look in AD for the servicePrincipalName for HTTP/test.domain1.com
You can mmc.exe and ADSI Edit snapin on a windows client.
Or some other LDAP browser.

> 
> Thanks for the reply and any further hints anyone could give me.
> ________________________________________________
> 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