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