cross-realm authentication problem
Bjoern Tore Sund
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.
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. 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?
-BT
--
Bj�rn Tore Sund Phone: 555-84894 Email: bjorn...@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.
Christopher D. Clausen
> 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?
Kerberos works the other way. The CLIENT needs to know what realm the
server is in. The server doesn't really inform the client of its realm.
Windows doesn't have a krb5.conf file for SSPI creds. You probably want
to look into trying to use the netdom.exe trust command (possibly with
/addTLN or AddTLNEX) to add the domain to realm mappings for Windows
clients to use. Your KDC may need to support referrals for this to
work.
What are the URLs / hostnames of the two different web servers? It is
possible that mappings exist for one name and not the other domain?
Or, can you downgrade to the older krb5 libs on your RHEL5 web server to
see if that gets things working?
-----
I'd consider why you have multiple realms in the first place. It would
be much easier to just use Active Directory as one single realm.
<<CDC
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?
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.
>
> -BT
--
Douglas E. Engert <DEEn...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Guillaume Rousse
> krb5-1.6.1 supports RC4 and DES (plus others).
> Windows 2003 only supports RC4 and DES.
> krb5-1.3.1 only supports DES.
cross-realm relationship by default. You have to install the Windows
2003 Resource kit*service pack2* to change this setting, using ktpass
command:
ktpass /MITRealmName DOMAINE.UNIX /TrustEncryp RC4
--
BOFH excuse #85:
Windows 95 undocumented "feature"
Bjoern Tore Sund
>
>
> 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.
Bjørn Tore Sund
I'd like to thank Douglas Engert, Christopher Clausen and Guillaume
Rosse for the help with this matter. Netdom.exe was indeed the answer,
and as I was pestering our main AD honcho on the matter he started to
remember (I still don't...) that I'd pulled up that command to him
before - and the RHEL4 server where everything was working had indeed at
some vague past point in time been added as a trusted server in AD.
I'll go sit in a corner and feel embarassed now.
Christopher D. Clausen
> I'd like to thank Douglas Engert, Christopher Clausen and Guillaume
> Rosse for the help with this matter. Netdom.exe was indeed the
> answer, and as I was pestering our main AD honcho on the matter he
> started to remember (I still don't...) that I'd pulled up that
> command to him before - and the RHEL4 server where everything was
> working had indeed at some vague past point in time been added as a
> trusted server in AD.
Can you let us know what exact command you actually ran that worked?
<<CDC
Bjørn Tore Sund
Since we don't have a separate dns domain for different OSes, only
different Kerberos realms, we need to map each server separately:
netdom.exe trust UIB.NO /domain:UNIX.UIB.NO /addtln:servername.fqdn
Knowing what to google for helps, this question has appeared again and
again over the years on this mailing list.
http://mailman.mit.edu/pipermail/kerberos/2005-September/008497.html is
detailed and gives a good run-through.