2

Greetings, I was wondering how one might link a Linux MIT Kerberos with a Windows 2003 Active Directory to achieve the following:

  1. A user, USER@WINDOWDIRECTORY.INTERNAL, attempts to log in at an Apache website, which runs on the same server as the Linux MIT Kerberos.

  2. The Apache module first asks the local Linux MIT Kerberos if he knows a user by that name or realm.

  3. The MIT Kerberos finds out it isn't responsible for that realm, and forwards the request to the Windows 2003 Active Directory.

  4. The Windows 2003 Active Directory replies positively and gives this information to the Linux MIT Kerberos, which in turn tells this to the Apache module, which grants the user access to its files.

    Here is an image of the situation: dfdfdf

The documentation I have read concerning this issue often differ from this problem:

  • Some discuss linking up a MIT Kerberos with an Active Directory to gain access to resources on the Active Directory server;

  • While another uses the link to authenticate Windows users to the MIT Kerberos through the Windows 2003 Active Directory. (My problem is the other way around.)

So what my question boils down to, is this:

Is it possible to have a Linux MIT Kerberos server pass through requests for a Active Directory realm, and then have it receive the reply and give it to the requesting service? (Although it's not a problem if the requesting service and the Windows 2003 Active Directory communicate directly.)

Suggestions and constructive criticism are greatly appreciated. :)

LATER EDIT

I'm having some issues with this. I've successfully configured mod_auth_kerb to do negotiation with the MIT Kerberos (in my case, EINDWERK.LAN), and if I fetch a ticket for the local MIT Kerberos with kinit on Ubuntu, I can surf to the Apache webserver without being prompeted for a login.

However, if I fetch a ticket from the Active Directory server (in my case, WINDOWS.LAN) and surf to the Apache webserver, I am greeted with a login prompt. Looking at the packets through Wireshark, it appears the Apache webserver is incorrectly attempting to use a TGT of EINDWERK.LAN for WINDOWS.LAN.

I have uploaded the Wireshark output for:

  1. A kinit for the Active Directory user "tester" (tester@WINDOWS.LAN), which succeeds (ignore KRB5KDC_ERR_PREAUTH_REQUIRED, there is no preauth here)

  2. One trip to the Apache webserver,where you can see that it goes wrong. [LINK]

EDIT: Yup, it always tries to authenticate with a TGT for EINDWERK.LAN. I'm going to try and create a trust between the AD and the MIT Kerberos and see if that fixes it.

EDIT2: Ok, by creating a trust (Here's a tutorial), everything seems to be checking out correctly, but I had to force rc4-hmac encryption for the tickets from the Active Directory, and the Apache HTTP service is encrypted in des3-cbc-sha1. Does anyone know how to delete a principal and encrypt its keys with a certain encryption?

Community
  • 1
Beerdude26
  • 101
  • 1
  • 7

2 Answers2

1

You can set up multiple realms in you /etc/krb5.conf file on Linux. See the realms section of the MIT Kerberos docs. You could configure your Windows realm there and users that log in with a principal that's part of that realm will be authenticated against your Windows 2003 Active Directory.

Then you just have to set up Apache with mod_auth_kerb and make sure to set the KrbAuthRealms configuration variable to include all the realms you'd like to be able to authenticate via Apache.

Unless I am missing something, this configuration is not that complicated and pretty standard practice when using multi-realm Kerberos configs.

Kamil Kisiel
  • 11,946
  • 7
  • 46
  • 68
  • Many thanks, I'll try that out tonight. I just wanted to double-check this with people more knowledgeable on the subject, as this is for a school project and my time is somewhat limited. I'll reply again once I have it running (or not) – Beerdude26 May 15 '10 at 12:38
1

Alright, by recreating my Kerberos database and adding principals with every enctype there was available (aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3) and then exporting the HTTP/link.to.website@REALM to a keytab for apache, Active Directory users are now able to log in as well.

Here's an example of adding a principal with every single encoding, and exporting it to a keytab:

addprinc -e "aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3" HTTP/www.eindwerk.lan

ktadd -e "aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3" -kt /etc/apache2/apache.keytab HTTP/www.eindwerk.lan

EDIT: Ok, this all seems to be working correctly, except that Internet Explorer always tries to get a ticket for HTTP/[TRUSTED_DOMAIN_NAME_IN_WIN_2003] on the first attempt. In my case, that translates to "HTTP/EINDWERK.LAN" while it should be "HTTP/NS.EINDWERK.LAN".

I've also noticed that trying to change the domain name of the trust [IMAGE] completely and absolutely breaks any cross-realm authentication: TGT's are exchanged correctly, but when your local Linux KDC tries to actually use the ticket, it discovers it can't decrypt it, throwing a "PROCESS_TGS: authtime 0, for HTTP/ns.eindwerk.lan@EINDWERK.LAN, No matching key in entry" error in the KDC log. The reason for this may very well be that many of the encryption mechanisms take the realm and username as a salt, so that domain name really needs to be set correctly.

Beerdude26
  • 101
  • 1
  • 7