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: [email protected] 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. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
