I’ll be the first to admit that I’m not an expert at directory services.  Through my job’s history I’ve had logins to both Microsoft Active Directory and Novell Directory Services but that’s about the extent of my interaction.

That being said, I can certainly see the value of maintaining your users in a single location.  The Drupal community has offered up the LDAP module to bridge the gap between the users in your Directory and the list of users that Drupal stores.  Setting up the connection between the LDAP module and your directory is relatively straightforward and I won’t be covering that here.  Once configured, the module grants access to a user if the provided credentials match what it sees in the directory.

That’s all well and good, but you’ll still need to touch each new user that the LDAP module creates to assign a role for anything but the most basic of sites.  This means that you’re still in the business of managing two sets of users, which isn’t optimal.  Ideally, you’d be able to group users in your directory and have roles assigned automatically by Drupal as logins occur. 

Respect My Authoritah!
The ‘Authorization’ tab in the configuration for the LDAP module provides that functionality, and truly gets you away from user administration in your Drupal site.  Once configured, the LDAP module grants and revokes roles based on attributes stored in the users’ directory entry.  Let’s look at a specific user case to dig deeper into the configuration.

ACME Uses Active Directory
We recently had a client with exactly the situation that I’m describing: they’ve been managing users and groups via Microsoft Active Directory for years now, and that’s what they are comfortable with.  The directory credentials are being used by several systems in addition to Drupal, so the user management needs to stay in Active Directory.  Due to some requirements for workflow and approval processes for editing site content, we had several roles configured.  We needed to have those roles applied or revoked depending on corresponding group memberships in Active Directory.

The ‘Authorization’ tab in the configuration for the LDAP module requires two supporting modules to be enabled: LDAP Authorization and LDAP Authorization – Drupal Roles.

Once you’ve enabled those modules and returned to the LDAP configuration page, you should be able to click on the ‘Authorization’ tab to be presented with a disabled ‘drupal role’ configuration.  Click the ‘add’ link in the right column to adjust the settings.

I checked the box related to the server configuration that I setup on the ‘2. Servers’ tab, and also checked the box to enable this configuration.

This is the point in the configuration that will vary depending on how your directory is structured.  My client’s directory had all users grouped into a single container, although they were associated with other LDAP groups via the ‘memberOf’ attribute in their directory entry.  So let’s take a look at the options that the ‘Authorization’ tab provides and select the one that makes the most sense:

STRATEGY II.A DERIVE DRUPAL ROLES FROM DN IN USER’S LDAP ENTRY
This option doesn’t make sense for my client’s needs.  The group that I need to match against isn’t part of the user’s DN string.  Some organizations might have the need to create a more hierarchical structure in their directory, which would lend itself nicely to this option.

STRATEGY II.B DERIVE DRUPAL ROLES FROM ATTRIBUTE IN USER’S LDAP ENTRY
All of my client’s users have a ‘memberOf’ attribute that stores their association to other groups.  That architecture lends itself nicely to this option, and it’s what I wound up using to map LDAP groups to Drupal roles.  The actual role mapping takes place farther down the page, but the important thing is to check the ‘drupal roles are specified by LDAP attributes’ box and enter the attribute that group memberships are stored in. 

STRATEGY II.C DERIVE DRUPAL ROLES FROM LDAP GROUP ENTRIES
You’d want to use this option if your directory is structured where groups have an attribute that contains usernames to match against, rather than users having an attribute that contains a list of groups.  This is exactly the opposite of the approach in STRATEGY II.B.  I could have implemented this option since my client’s directory groups have a ‘member’ attribute that stores the DN string of any associated users.  But according to the help text that is provided, this option should only be used where it doesn’t make sense to use STRATEGY II.B.

The Final Step: Setting up the Mappings
Everything up to this point has pretty much been checking boxes and moving forward.  For the mappings, you’ll need to know some pretty specific details about your directory groups.  Namely, the ‘raw authorization id’ that you can associate to an existing Drupal role.  That authorization id should be relatively easy to figure out with any directory browser application.  You can either browse to a user and copy the authorization id’s from their ‘memberOf’ (may vary by directory) attribute …

OR you could browse to the group that you’d like to map to a Drupal role and copy the ‘distinguishedName’ (may vary by directory) value:

Once you’ve determined the authorization id of your group, it’s simply a matter of matching that up to one of the Drupal roles you’ve previously defined:

As you can see, I’ve actually mapped 3 roles based on other groups in my client’s directory.  For my configuration, I’ve kept the default settings in ‘Part IV’ of the form.  Once I click save at the bottom of the page, Drupal will start automatically assigning roles to users that Authenticate via LDAP.  In the instance that a user provides the correct credentials for their directory account, but no group is found that matches the role mapping, that user is simply created with the basic ‘Authenticated’ role.  For this reason, you should be very restrictive in granting permissions to users without roles.

So now that we’re all configured, what’s the payoff?  My client can continue to manage users’ access to resources via Active Directory, and any changes to those groups will automatically grant or revoke roles to Drupal users during the login process.  Effectively, no Drupal User administration is needed at all.  The only time you’d need to touch your Drupal users is to adjust roles permissions.  Pretty handy.