Integrating with Active Directory; or, Why it Ain’t All Bad Being Official

This guy’s official.
cc licensed http://www.flickr.com/photos/dkscully/5038201085/

I just completed a major overhaul of the authentication process by which users log in to Blogs@Baruch. Previously, users were able to create accounts on the system as long as they had a Baruch email address. Just over a year ago, however, our CIO requested that we implement Active Directory authentication, and we’ve been working towards this for some time. Now, any user in the college’s Active Directory can simply log into the system, and doing so creates their account.

Several technical issues needed to resolved before we could make the switch. The two biggest were the inadequacy for our purposes of existing ad integration plugins and the process by which existing local WordPress users would be migrated to AD accounts. I worked with my friend Boone Gorges to address these issues, using Glatze’s Active Directory Integration plugin as the base. We had considered using Curtis Grymala’s fork of Glatze’s plugin, and Curtis was very generous in taking the time to explain his modifications to us, but ultimately we concluded Glatze’s plugin seemed to get us closer to where we needed to get.

Boone ultimately wrote a plugin called BLSCI-AD (get it on git) which combines all of the specific functions that we needed for this project. It fixed some problems Glatze’s plugin had working with WordPress multisite, addresses some fallback account assurances we needed (users who were not successfully migrated to AD — about 8% of our 10k+ users — are still able to log into the system using their old credentials), and, most importantly, runs a check of all existing users against the email addresses present in AD. When it finds a match, if the WordPress username and AD username aren’t the same, it changes the user’s WordPress username to the one in AD. While the migration is being performed a record is generated, sortable by successes, failures, and with additional data like user creation date, migration attempted date, and last activity date. The usernames of those whose migrations fail are manually editable through the report page, and every user’s previous ID remains recoverable.

This is really a remarkable bit of code, not least because of the hilarious and helpful PHP comments Boone strews throughout. There’s a lot of justifiable love for Boone on the web, but personally I enjoy working with him because he appreciates the complicated contexts in which we work, gets and supports the mission of our project, and approaches each contract as a collaborative puzzle–solving experience. Thanks, Boone!

I did have some mixed feelings about this transition, and I’ve been struggling to put them into some sort of order over the past few days. Blogs@Baruch began as an independent experiment, resistant to centralization and institutional oversight, and hostile to any outside efforts to control. But as we’ve grown and responded to community need certain pressures have been put upon us: all incoming freshmen do work on our system, and several programs, centers, and projects use us for their web presence. The college sees this as a space worth supporting and building along the trajectory we’ve already established. One goal they’ve had which over time came to implicate us was to simplify access to and unify logins for the various services the college offers. We had some concerns about this as an effort to establish control over Blogs@Baruch, but were satisfied through conversations with BCTC that this wasn’t the case. Tom Harbison (who along with Craig Stone helped us through the migration tremendously) and I have been granted the administrative rights to create Active Directory users. We’ve also been assured that all users who have had access to Blogs@Baruch in the past will continue to have access into the future regardless of their current relationship with the school. These are meaningful choices, especially in a place like CUNY.

So, while I’m a bit skittish about the implications of centralization (and a touch nervous about the performance implications of SSL admin rule now in place), I’m tremendously pleased about this technical accomplishment, and also about its impact on user management. Any user who is currently active in Baruch’s Active Directory can now simply log in to Blogs@Baruch with the same account they use to log into the wifi and into the school’s computers. If they had an account, all their stuff is there; if they didn’t, a user is silently created for them against their AD profile (it feels as though the user already existed).

I know that there’s some resistance to the fetishization of single sign-on out there in the hipster web, and I certainly am sympathetic to those arguments. If the experience is meaningful enough, folks will log in however they can to get it. We have a lot of that on Blogs@Baruch. But we also have users who are completely new to such experiences, who might be resistant for reasons cultural or philosophical, or who have been compelled to use the system by a faculty member. Those users now have zero technical barriers to entering the system, and I’m curious about what kind of serendipity that just might lead to.

A couple other technical notes. We use Boone’s Simple Import Users plugin to allow faculty members to easily bulk add users to individual sites. As part of this project, he wrote an AD check into that plugin so that if users haven’t been created in WordPress yet when their email addresses are entered into the import users field, an account is created for them. I hacked that plugin a bit to change the defaults and simplify the email generation options.

I also wrote a function into our BuddyPress theme to pull in the user’s Active Directory Description:

function DisplayedUserDescription() {
$user_meta = get_userdata(bp_displayed_user_id());
echo '
<div class="bp-widget">' . '
' . '' . 'Active Directory Description: ' . '' . '' . $user_meta->description. '' . '
' . '</div>
';
}

add_action( 'bp_after_profile_field_content', 'DisplayedUserDescription' );

And, finally, I hacked together a file (placed in mu-plugins) that changed the login page across the installation:

/*
Plugin Name: Login Hacks
Plugin URI:
Description:
Author: Luke Waltzer
Version: 1.0.0
Author URI:
*/

//Change Wrong Password Error Text

add_filter('login_errors',
            create_function('$no_login_error',
                            "return '

You now must log in to Blogs@Baruch with your Baruch user name.

If you do not remember your password, please follow the reset link below.

';"));

//Change Login Field Names Text

function wp_field_names_change($translated_text, $text, $domain){

	switch ($text) {
		case 'Username':
			return 'Baruch Username';
		break;
	}

	switch ($text) {
		case 'Password':
			return 'Baruch Password';
		break;
	}

	return $translated_text;
}
add_filter('gettext', 'wp_field_names_change', 1, 3 );

//Remove Register link

function remove_register_text ( $text ) {
         if ($text == 'Register'){$text = '' ;}
                return $text;
         }
add_filter( 'gettext', 'remove_register_text' );

//Change Reset Password Link Below Login Form

function remove_lostpassword_text ( $text ) {
         if ($text == 'Lost your password?'){$text = '
<h3 style="text-align: center;"><a href="https://mypassword.baruch.cuny.edu/" target="_blank">Reset Your Baruch College Password</a>

You now must log into Blogs@Baruch with your Baruch username.

All previous users of Blogs@Baruch will still be able to access their accounts after they are no longer affiliated with the school. We may however need to assist you in creating a new account and affiliating all content you previously produced with that new account.

If you are unable to log in, please email us at <a href="mailto:blsciblogs@baruch.cuny.edu">blsciblogs@baruch.cuny.edu</a> for assistance.</h3>
' ;}
                return $text;
         }
add_filter( 'gettext', 'remove_lostpassword_text' );

}

9 thoughts on “Integrating with Active Directory; or, Why it Ain’t All Bad Being Official”

  1. Solid. Thanks for putting this all into perspective. Sometimes those of us who thrive “outside the system” have knee-jerk reactions against becoming part of the system, even when that integration would be beneficial. And it sounds like the details you’ve worked out with your IT folks – stuff like guaranteed access for alumni – really will prove to be beneficial. Kudos to you and your team for wrestling with these issues.

  2. Whew! Mazel tov! It sounds like some real magic happened there, and I think it’s great that you struggled with all the implications…not just technical implications. Yes, single-signon is sometimes fetishized, but not everything that is fetishized is automatically a bad thing. Think, for example, of feet. 🙂

  3. You know, I’ve been thinking about doing this on UMW Blogs for all the reasons you list here, some sense of consistency and unification amongst applications. We can authenticate against AD for umw.edu because we have it, and to here it was smooth for your 10,000 users is very encouraging,

    I like the idea of alumni keeping access, allowing a space for people to remain, and making it just a tad easier is not a sacrifice if you aren’t being told that given this choice you can’t do x, y, and z. And if the FERPA issues don’t emerge all the better.

    Interestingly enough, my associate provost talks about state or federal legislation that would make authentication of web-based learning spaces for online learning necessarily authenticated against the network ID and password. This would enable us to provide the same idea of protection and confidence as something like umw.edu or canvas. The issue is, how would such an idea of authenticating start to change the idea for public tools like twitter—how could you authenticate that?

    I keep telling Anto that easy is the key right now, and I am thinking this is the case and you, Tom, and Boone rock for making it happen.

  4. How elegant! I wonder if there is any AD maintenance involved…is this something that you don’t have to worry about with each new batch of freshmen? Where is the AD info getting pulled from? I also wonder about the security issues. Great work, guys.

Comments are closed.