mod_auth_kerb and mod_authnz_ldap bring Apache web apps into the Enterprise

Wednesday, January 28th, 2009

The majority of companies out there have implemented some sort of Windows Active Directory system that they use to connect and manage desktop systems, servers, printers, and other networked assets in a “secure” way. I use secure in quotes because the security largely depends on individual implementations. In any event, the Open Source community builds some pretty cool web apps on top of Apache that would be very useful for collaborating, code management, etc. One of the pain points for companies choosing Open Source web solutions has been the custom authentication and authorization implemented in the applications.

mod_auth_kerb extends Apache’s Basic Auth functionality to authenticate enterprise users against Windows Active Directory using Kerberos tickets supported by Windows. mod_authnz_ldap can use the Active Directory LDAP server to evaluate any available LDAP field against administrator defined ACL. For example, Company X decides to use an Open Source web application but want to restrict access to those in the Active Directory Administrators group; mod_authnz_ldap can use the LDAP server to pull the Active Directory group for the user it’s authenticating and determine whether they are part of the Administrators group.

Here’s a quick summary of how to get it working:

  1. Ensure that your Apache is build with –enable-ldap –enable-authnz-ldap –with-ldap.
  2. Configure Apache to use mod_kerb_auth/Kerberos as it’s AuthType:
    http://koo.fi/tech/2008/06/18/apache-http-authentication-to-active-directory-with-kerberos/
  3. Configure Apache to use mod_authnz_ldap to authorize access based on LDAP data:
    Global Apache configurations:
    LDAPTrustedMode SSL
    (optional) LDAPTrustedGlobalCert CA_DER /etc/apache2/ssl/AOL_Member_CA.der # If the SSL certificate on ldaps is not recognized
    LDAPVerifyServerCert off

    Directory Apache configurations:
    RequireSSL # because you don’t want Active Directory credentials in the clear
    AuthLDAPURL ldaps://directoryserver:port/dc=somewhere,dc=com?cn SSL # where CN is the unique username
    AuthLDAPRemoteUserIsDN off
    AuthLDAPBindDN DNUsername
    AuthLDAPBindPassword DNPassword
    require ldap-attribute ldapfieldname = “ldapfieldvalue”
    require ldap-attribute ldapfieldname = “ldapfieldvalue”

  4. Set Apache’s LogLevel to debug and start troubleshooting. Having an LDAP browser available to test will help you determine where the issues are when troubleshooting.

I ran into a small problem while getting this setup. I found that mod_auth_kerb was modifying the Apache Basic Auth “user” field from the username provided at login to username@realm. This might not be a problem in most cases, but for my implementation, username@realm was no where to be found in the Active Directory LDAP data. So, I did the following quick hacks to the mod_auth_kerb source code and recompiled:

  • Comment out user = apr_pstrcat(r->pool, user, “@”, realm, NULL);
  • Changed MK_USER = apr_pstrdup (r->pool, name); to MK_USER = apr_pstrdup (r->pool, sent_name);

This small change makes mod_auth_kerb return the username instead of username@realm. I’ve emailed the maintainers of mod_auth_kerb to see if they would consider adding an configuration flag to enable the stripping of @realm.

mod_auth_kerb supports SPNEGO (Windows Integrated Authentication support in IE and Firefox) which can provide Single Sign On for Windows users authenticated to the Active Directory.

Since mod_auth_kerb and mod_authnz_ldap simply hook the Apache Basic Auth functionality, applications can leverage the Apache server to provide a username to the underlying web application.

Here are a couple apps you might want to test your new authentication with:

Posted in Enterprise Security, Implementation Security, Research, Security Architecture | Comments