cross-realm authentication problem

[Douglas E. Engert]

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?

> 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.
> 
> 
> krb5.conf on the server looks like this:
> ===
> [libdefaults]
>   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
> 
> [realms]
>   UNIX.UIB.NO = {
>      auth_to_local = RULE:[1:$1@$0](.*@.*UIB.NO)s/@.*//
>   }
> 
> [domain_realm]
>   .uib.no = UNIX.UIB.NO
>   uib.no = UNIX.UIB.NO
> 
> [kdc]
>   profile = /var/kerberos/krb5kdc/kdc.conf
> 
> [capaths]
>   UIB.NO = {
>      UNIX.UIB.NO = .
>   }
> 
>   UNIX.UIB.NO = {
>      UIB.NO = .
>   }
> 
> [appdefaults]
>   pam = {
>     debug = false
>     ticket_lifetime = 650000
>     renew_lifetime = 650000
>     forwardable = true
>     proxiable = true
>     krb4_convert = false
>   }
> ===
> I have spent a lot of time fiddling with capaths, to no avail. 

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

  My
> .htaccess on both servers looks like this:
> ===
>    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.

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?

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/


> 
> -BT

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444