cross-realm authentication problem

Fri May 29 09:19:28 EDT 2009

Douglas E. Engert wrote:
> 
> 
> Bjoern Tore Sund wrote:
>> I am trying to get cross-realm authentication to work between AD and 
>> our MIT Kerberos realm.  Windows client are in KLIENT.UIB.NO, Windows 
>> user accounts are in UIB.NO, Unix/Linux machines and accounts are in 
>> UNIX.UIB.NO.  User names in UIB.NO and UNIX.UIB.NO are the same.
>>
> 
> So KLIENT.UIB.NO and UIB.NO are AD and UNIX.UIB.NO is MIT? What version?

Correct.  Windows 2003 SP2 and MIT Kerberos 1.6.3.

>> KLIENT.UIB.NO and UIB.NO trust each other, UIB.NO and UNIX.UIB.NO have 
>> two-way trust enabled, transitive.
>>
>> I have one web server running RHEL4, apache 2.0.52 and Kerberos 1.3.4 
>> as provided by Redhat, self-compiled mod_auth_kerb 5.4, and another 
>> running RHEL5, apache 2.2.3 and Kerberos 1.6.1 as provided by Redhat, 
>> self-compiled mod_auth_kerb 5.4.  krb5.conf, .htaccess etc are 
>> identical on the two web servers, both have principals in UNIX.UIB.NO.
>>
>>  From Unix/Linux machines with user authenticated in UNIX.UIB.NO 
>> Kerberos negotiation works fine.  After choosing UNIX.UIB.NO as 
>> authentication domain on a Windows machine Kerberos negotiation works 
>> fine.  After authenticating against UIB.NO on a Linux machine (which 
>> have UNIX.UIB.NO as primary realm in krb5.conf) cross-realm 
>> authentication works fine. But using a Windows machine where the user 
>> is authenticated in UIB.NO I get cross-realm authentication only to 
>> the web server running RHEL4, not the one running RHEL5, I never even 
>> get a ticket for UNIX.UIB.NO from AD when trying to access the RHEL5 
>> server web page.  The only difference between the RHEL4 and RHEL5 
>> server should be the Kerberos and Apache versions.

>>   default_realm = UNIX.UIB.NO
>>   ticket_lifetime = 144h
>>   forwardable = yes
>>   proxiable = yes
>>   permitted_enctypes = des3-hmac-sha1 des-cbc-crc rc4-hmac des-cbc-md5
>>   default_tgs_enctypes = des-cbc-crc
>>   default_tkt_enctypes = des-cbc-crc
>>   dns_lookup_realm = true
>>   dns_lookup_kdc = true
>>   udp_preference_limit = 1

> 
> You should not need the capaths as the default it to assume
> a hierarchical realm tree, which you have.

Ok.  Didn't help to remove the whole capaths section either. :(

>> ===
>>    AuthType Kerberos
>>    AuthName "Kerberos Login "
>>    KrbMethodNegotiate on
>>    KrbMethodK5Passwd off
>>    KrbAuthRealms UNIX.UIB.NO
>>    KrbServiceName "HTTP"
>>    Krb5Keytab /etc/httpd/conf/radisson_http.keytab
>>    KrbLocalUserMapping on
>>    Require valid-user
>> ===
>>
>> Any ideas where I need to look to figure this one out?  It looks as if 
>> the RHEL5 server somehow fails to inform the windows client that it 
>> needs to get a TGT for UNIX.UIB.NO, but why then does the RHEL4 server 
>> provide this information?
> 
> The server does not inform the client. The client figures out it needs
> to do cross realm, and the KDC figures out what enctype to use for the
> server. With Windows, the Microsoft client code asks its KDC for a
> a referral. But you said both the web servers are in the same realm,
> and lod one works and the new one does not.

I thought the web server was supposed to use the www-authenticate: header 
not only to say that it supports Negotiate authentication but also which 
realm to negotiate with.  That was defined in HTTP 1.0 but I haven't 
found it for 1.1.  And indeed, neither of the two web servers use this 
field for that.  In fact, the http headers are identical except for the 
apache version:
HTTP/1.1 401 Authorization Required
Date: Fri, 29 May 2009 12:12:53 GMT
Server: Apache/2.0.52 (Red Hat)
WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm="Kerberos Login"
Content-Length: 401
Content-Type: text/html; charset=iso-8859-1

The first www.authenticate is added by KrbMethodnegotiate being on, the 
second by krbmethodk5passwd being on.  I can't figure out how the client 
figures out which realm to get a TGT for and then request a service 
ticket from without the HTTP header specifying this.  On the linux 
clients and servers I set a specific mapping from dns domain .uib.no to 
realm UNIX.UIB.NO, is there a way to do this on Windows?

> krb5-1.6.1   supports RC4 and DES (plus others).
> Windows 2003 only supports RC4 and DES.
> krb5-1.3.1   only supports DES.
> 
> So there might be some enctype issue were RC4 is being used.
> Does the keytab file for the RHEL have a RC4 and/or DES key?

Entry for principal HTTP/radisson.uib.no with kvno 4, encryption type 
Triple DES cbc mode with HMAC/sha1 added to keytab 
WRFILE:/tmp/radisson_http.keytab.
Entry for principal HTTP/radisson.uib.no with kvno 4, encryption type DES 
cbc mode with CRC-32 added to keytab WRFILE:/tmp/radisson_http.keytab.
Entry for principal HTTP/radisson.uib.no with kvno 4, encryption type 
ArcFour with HMAC/md5 added to keytab WRFILE:/tmp/radisson_http.keytab.

I'd understand that if it was the RHEL4 machine I couldn't talk to.

> Wireshark on the client can be very helpful, as you can see
> all the Krb5 requests and responses including enctypes.
> The KDC may be sending some error messages or sending a key
> with an enctype that is not in the keytab.
> 
> http://www.wireshark.org/

When trying to retrieve the web page from the RHEL5 server there is no 
attempt to contact a KDC at all.

-BT
-- 
Bjørn Tore Sund       Phone: 555-84894   Email:   bjorn.sund at it.uib.no
IT department         VIP:   81724       Support: http://bs.uib.no
Univ. of Bergen

When in fear and when in doubt, run in circles, scream and shout.