Centos 6 Apache Kerberos AD SSO

I recently setup a RHEL / Centos 6 Apache websever at work that integrates with Active Directory (AD) and Kerberos for a single sign on (SSO) web resource. This took me a lot more time than I thought it would, but that’s because the tutorials I was reading were either wrong, or didn’t apply to my situation. I am outlining the steps I took below to help others who may wish to have a similar setup.

For my setup, I also added the Red Hat VM to the Windows 2008 r2 Active Directory Domain. You may choose not to do this, but your steps may be different that what I outline here. I have NOT setup any UNIX schema in Active Directory or installed any 3rd party software on the Domain Controllers. The AD schema is how it comes out of the box (for the purposes of this article)

Please note, this tutorial assumes you have root privileges and that SELinux is NOT in enforcing mode.

Packages

Here are the packages that I installed during this process. I am not 100% sure they are all required, but I’m pretty sure they are Feel free to test. This setup is currently in testing, and if I move it to production, I will definitely outline which packages are actually required.

httpd-2.2.15-15.el6_2.1.x86_64
mod_auth_kerb-5.4-9.el6.x86_64
mod_authz_ldap-0.26-15.el6.x86_64
openldap-clients-2.4.23-26.el6_3.2.x86_64
openldap-2.4.23-26.el6_3.2.x86_64

samba-winbind-clients-3.5.10-125.el6.x86_64
samba-client-3.5.10-125.el6.x86_64
samba-common-3.5.10-125.el6.x86_64
samba-winbind-3.5.10-125.el6.x86_64
samba-3.5.10-125.el6.x86_64

Step 1

After we have all of our packages install, we need to update the [global] section of /etc/samba/smb.conf

client ntlmv2 auth = yes
client use spnego principal = no
kerberos method = dedicated keytab
dedicated keytab file = /etc/krb5.keytab

The first two lines are for Network Level Authentication, which is the more secure / modern way of connection to Windows 2008 server systems. This is required for adding the webserver to the domain. If your domain does not implement ntlvm2 authentication, then you should probably leave this line out.

The second two lines are for designating a keytab file for kerberos. I’m not 100% sure this step is required, or is the best setup, but seems to work.

Also, we want to add the following to /etc/openldap/ldap.conf


REFERRALS off

This is required to ignore referral results from our ldap searches, which is how Apache will determine if a user is authorized or not.

Step 2

Next, let’s add our system to Active Directory using the authconfig-tui command. Be mindful of the choices and how they may affect your setup. Naturally, you must have an account on the domain that has permissions to add hosts. Also, DNS must be setup properly on your CentOS / RHEL 6 machine.

Options:

User Information
1. Use Winbind
Authentication
1. Use Shadow Passwords
2. Use Winbind Authentication
3. Local Authorization is sufficient
Security Model: ads
Domain: EXAMPLE
Domain Controllers: DC1.EXAMPLE.COM
ADS Realm: EXAMPLE.COM
Template Shell: /sbin/nologin
Select Join Domain
1. Enter just username, no domain
2. Enter Password
3. Save
4. Select OK

You can and should enter more than one domain controller if available. Unlike a Windows machine, Linux will only use whichever Domain Controller(s) you specify. Please note the ALL CAPS for steps 4-6.

After the machine has been added to the domain, you should run the following command to tell winbind to use our default domain for identify / authenticating AD users:

authconfig –update –enablewinbindusedefaultdomain

Step 3

Setup Kerberos keytab for Apache’s user.

Here’s the deal: Apache will need an AD user that has read access to directory structure in order to use the LDAP search function to limit users by id or group (or whatever else). So, we must setup a new (or use an existing) user in AD. I’m going to leave that part up to you to figure out, as I write Linux tutorials, not Windows . Anyway, note the new username and password.

Now, we need get a kerberos ticket for our AD user:

kinit mydomainuser

Next, create the keytab entry:

net ads keytab add HTTP -U mydomainuser

And finally, let’s give our apache user read privileges to our keytab file:

chmod g+r /etc/krb5.keytab && chgrp apache /etc/krb5.keytab

Step 4

Finally, it’s time to setup our Apache config. This is the trickiest part, and may take some patience to get nailed down correctly.

Add the following to a VirtualHost or your default config for Apache:


LogLevel debug
 <Directory />
 AuthType Kerberos
 KrbMethodNegotiate On
 AuthName "EXAMPLE.COM Domain Login"
 KrbMethodK5Passwd On
 KrbAuthRealms EXAMPLE.COM
 Krb5KeyTab /etc/krb5.keytab
 KrbLocalUserMapping on
 require valid-user

 AuthLDAPURL "ldap://dc1.example.com/dc=example,dc=com?sAMAccountName?sub?(objectClass=*)"
 AuthLDAPBindDN mydomainuser@example.com
 AuthLDAPBindPassword myPassW0rd
 require ldap-group CN=Domain Users,CN=Users,DC=example,DC=com
 </Directory>

Okay, a little about this section. The first line LogLevel debug is an apache directive that will give us more useful information in our error log for troubleshooting. I recommend using this as it will tell you where the problem may be during this ironing-out process.

Next, the Directory / line in html brackets tells us which directory our authentication statements apply to. ”/” is equal to the document root of the webserver, default /var/www/html or of the virtual host.

The next section is our Kerberos section. This are the settings for EXAMPLE.COM (note the CAPS). Of special note, the KrbLocalUserMapping on line tells apache that we’re going to trim the @EXAMPLE.COM portion of the name Kerberos gives us, which is important for the next section.

Finally, we have our LDAP section. This is where things get sticky. The first line is our ldap search string. Here, we’re connecting to our domain controller, and searching for sAMAccountName in the specified location. To the best of my knowledge, sAMAccountName is what our Kerberos section above gives us.

The next two lines should be self explanatory.

The last line tells Apache that we need to require a group from the ldap search output. In our example, we want only users that are part of the “Domain Users” group to be able to access the webpage. This can be any group, but it must be the exact dn from AD. Note, spaces don’t seem to affect this line. How do you get this line? We’ll, that’s the tricky part.

I recommond using the following command

ldapsearch -H ldap://dc1.example.com -b “dc=example,dc=com” -W “domain users” > /root/ldapsearch.out

The console will appear to just sit there after entering that command, but it’s actually waiting for the password of the domain user we requested the ticket for earlier. After you enter your password, press return. The search should return all objects that have a reference of domain users. Then, you should be able to search the output results (using vi or less) for Domain Users, using the ‘/’ key