Apache, mod_auth_ldap and active directory

Posted on September 3rd, 2006 by phil and tagged .

The scenario - CentOS 4.3 with standard Apache setup. Do a 'yum install httpd' to install Apache and a 'yum install mod_authz_ldap' to install the LDAP authentication module we'll be using.

For any other platforms, it shouldn't be much different.

The next thing we need to do is setup some things on AD. Active Directory works on the basis that you need to bind to it to authenticate. OpenLDAP allows anonymous binded users to authenticate ... unfortunately Active Directory does not AFAIK (at least this is what it took to get it to work for me)

Logon to the AD server and:

1. In 'Active Directory Users & Computers', right click the appropiate domain. Go to 'New' -> 'User'

2. Run through the screens. Declick 'user must change password and next logon' and do not create an Exchange mailbox for them. I called the user 'anonbinduser' even though strictly it doesn't allow anonymous binding.

3. Note down or remember the password. We will be binding using this user, so we'll need to use this password as the bind password.


Please note, I use Active Directory and AD interchangeably in the article. They mean the same thing!

Note: it may make your life easier double check that the user you've just created doesn't have their password expire in X days/months time. Right click on the user and go to 'Properties'. Click the 'Account' tab and it should be there. At least it is on my version here.

Next, we need to get the LDAP DN. If you're not sure about this, run ldp.exe (there may be some equivalent if this isn't available on your Windows system).

Click 'Connection' -> 'Connect' from the top menu and then accept the defaults (which should be connecting to 'localhost'). You should get a connection. Now click 'Connection' -> 'Bind' from the top menu and enter in a known username and password that's good. The previous user we setup in AD should work if you haven't got your own.

If you now go to 'Browse' -> 'Search' off the top menu (CTRL+S should do it also) and just press enter. You should get a list of all of the objects on the system, or maybe even the list of all users. It should be fairly obvious.

>> Dn: CN=Joe Muck,CN=Users,DC=office,DC=test,DC=ie
	4> objectClass: top; person; organizationalPerson; user; 
	1> cn: Joe Muck; 
	1> description: Mucker Joe; 

So, we can see the DN that most Users are under is:

CN=Users,DC=office,DC=test,DC=ie

That's the DN we need to tell LDAP to search under.

Now we should be able to create a file called /etc/httpd/conf.d/auth_ldap.conf. The /etc/httpd/conf.d/${CONFILE}.conf is the way CentOS works. You can edit the httpd.conf file directly but it's not advised.

By default, in an Apache install only httpd.conf is read by Apache. However, the CentOS guys have made it a little easier for applications to enter Apache directives, without editing httpd.conf directly.

On FreeBSD, your httpd.conf file should be in /usr/local/etc/apache/httpd.conf (For apache 1.x) or /usr/local/etc/apache2/httpd.conf (For apache 2.x) if you installed via ports. Most Linux distributions put your Apache configuration in /etc/ somewhere.

<Location />
    AuthType basic
    AuthName "Enter Domain Password"
    AuthAuthoritative Off

    AuthLDAPURL ldap://192.168.1.1/CN=Users,DC=office,DC=test,DC=ie?sAMAccountName
    AuthLDAPBindDN CN=anonbinduser,CN=Users,DC=office,DC=test,DC=ie
    AuthLDAPBindPassword testing
    AuthLDAPRemoteUserIsDN Off
    AuthLDAPAuthoritative Off

    AuthUserFile /var/www/data/htpasswd

    Require valid-user
</Location>

The AuthLDAPBindPassword should be set to the password you set for anonbinduser.

AuthLDAPRemoteUserIsDN sets the REMOTE_USER variable to be the DN username, i.e. in our Joe Muck example above, the username would be 'jmuck' instead of 'Joe Muck'. Spaces and other weird characters can cause problems for some applications.

The AuthLDAPAuthoritative directive is interesting. It means that if LDAP authentication fails, we can fall through. That's what the AuthUserFile directive is for below underneath. If LDAP authentication fails off the AD server, then the "backup" is to use file based authentication. I had one or users that weren't on AD that I wanted to give access to and this allowed me to do so.

If that isn't relevant to you, remove the AuthLDAPAuthoritative and AuthUserFile directives.

The <Location /> directive means that *every* single page on this server is protected. Location is based on the URL match (you can also use LocationMatch to use a regexp) not the filesystem path.

If you need to override that for specific URLs (so that they're publically accessible), you can do the following:

<Location "/pub">
    Order allow,deny
    Allow from any
    Satisfy any
</LocationMatch>