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' );

}

Migrating

photo: DSCF-Photographer

Today I migrated Blogs@Baruch, the 10k user WordPress installation I manage, to a new server. Our previous server was unable to handle the system’s activity. We had been in a Jumpbox environment, which our colleagues at the Baruch Computing and Technology Center had directed us towards a few years back out of concerns about the resources available to manage a LAMP stack alongside the dozens of other virtual environments the school manages. Problem was, Jumpbox only supports 32-bit lamp environments, which max out at 4 gb of ram… simply not enough for the amount of traffic and usage that we get, especially given the propensity of certain processes in WordPress to eat up a ton of ram. We were getting to the point where the server needed to be rebooted almost daily over the past month in order to clear out processes that were locking things up. My comrade-in-arms Tom Harbison and I were on constant alert, interrupting family dinners, story time with our children, and, most horrifyingly, college basketball games to get the site back online and verify that no damage had been done. As a colleague told me, “that’s just no way to live.”

Moving to a more robust server became necessary if our system was going to continue to grow and evolve in response to community need, which is becoming ever more intense. We began discussions in mid-winter about where we’d move Blogs@Baruch. Our choices were to host externally, perhaps with Cast Iron Coding (where our cousin UMW Blogs is hosted) or with a host like Softlayer (where another CUNY WordPress install is hosted); or to ask BCTC to build and deploy a new server for us. Both decisions were feasible, yet both had costs and benefits. Hosting outside would give us total control over the environment, though at a monetary cost that might be difficult to maintain down the road. It would also require making outside systems interact with CUNY systems… let’s just say that has been a problem in the past. Hosting at the College would get us in-house support, but also make us dependent upon an IT department which has a specific set of pressures upon it to keep the systems of the college running, to be responsive to the needs of users here and also the demands of CUNY central administration.

In the end, we decided to continue to host Blogs@Baruch at the College, for a few reasons. The most important is that Mikhail Gershovich, Tom and I very much see this project and the others at CUNY like it as efforts not only to foster certain pedagogical and communicative opportunities for members of our community, but also as tools in a larger battle to push our university and others in a particular direction in their approaches to supporting educational and information technology. It may very well have been easier to go to outside hosting: we could have moved more swiftly, wouldn’t have had to address the same security concerns, and could have bypassed bureaucracy altogether. But if one of our goals is to encourage the broader adoption of free and open source software within higher education, then taking the easy way through risks limiting the potential impact of our experiment. I’m proud that our College values this project and has given it support in tough economic times. That support isn’t only monetary, but also the valuable and highly in-demand time of our CIO Arthur Downing and his staff at BCTC. This project is as much theirs as ours, a point they’ve articulated through their support for this migration. We think the extent to which the system is homegrown adds to its vitality, and makes it a strong model for what open university publishing platforms can be with just a few of the right people saying “yes.”

It’s fitting that this migration happened on the Day of the Digital Humanities, when many of my colleagues at the intersection of humanities and technology across the world are sharing details and reflections about their workdays. In the course of my week — often in the course of a day — I visit classes and help students with projects, consult with faculty about assignment and course design, oversee the work and writing of graduate student fellows, build WordPress themes, research plugins, help develop programs and workshops, speak with staff members about their use of social media, advise projects elsewhere at CUNY, and occasionally write, present, or teach a class. Through this all, I must make sure the platform that propels much of my work remains viable and growing. This last bit is the least familiar to me of my tasks: though I administer a system I’m no system administrator, and I often need help. It’s ultimately much easier for me to call Phil or John or Patrick in the building next door than to dig through forums or to push my friends and connections for free advice (or to get on their calendars for the paid version).

Managing a platform like this has complicated my understandings of both university information technology and open source software deployment. Yes, much of the fetishization of security in IT comes from a fear of litigation, from uncertainty and doubt about the motives of users, and from a proprietary mindset that weighs the cost and risk of every moving bit. We should push back against that culture. But security isn’t always only about these things; it’s also about ensuring the stability, functionality, and sustainability of a system so that its users can reap the most benefits. That sometimes may mean denying users the ability to do certain things on the system, or at least channeling them into a process that helps them do those things in a way that doesn’t risk compromising stability (especially if they’re expecting and relying upon stability). Conversely, it also means going to bat for users with the powers that be and expanding a system’s capabilities so that we can all ultimately do more.

So, that’s where we are with Blogs@Baruch: we’ve just expanded the system’s capability so that it can do what it already does better and faster, and so that we can see if it can also do some new things. It’s also where I am in my work as an educational technologist: mediating between the growing needs of an exploding community of users and the capabilities and demands of an institutional structure that sometimes gets us and sometimes doesn’t. And it’s where I am in my thinking as a digital humanist: wondering every day how emerging technologies are helping and forcing us to rethink the work — all of the work– that we do in the university.

The Challenges of Turning Inwards

(95/365) Eh?!
Creative Commons License photo credit: Sarah G…

Over the past few years I’ve approached the digital humanities with a touch of skepticism. Much of this has had to do with my own career path and anxieties: I did digital history from the mid-1990s through 2003 or so, and since then — even while writing a traditional history dissertation — have worked primarily as an educational technologist focused on pedagogy, curriculum development, and open learning initiatives. These two fields overlap in many important ways, and have much to learn from one another (a dynamic that I and others have attempted to tease out). Yet I regarded the rise of the digital humanities with a certain amount of bemusement since much of what was regularly being heralded as new felt to be the logical next stage of something already familiar to me. I finished my Ph.D. in 2009 and found that there were better opportunities in educational technology awaiting me than on the history job market. As I was making this move, the excitement and celebration and “woo-hoo!” that surrounded the digital humanities put me off a bit. It seemed discordant with the state of the field that I had come to know watching very few of my colleagues and friends land desirable jobs.

Over the past six months I’ve pushed myself to examine these feelings more closely, an effort that began when my pal Matt Gold asked me to contribute to a volume he’s editing on debates in the digital humanities and culminated in my attendance at my first THATCamp this past weekend at George Mason’s Roy Rosenzweig Center for History and New Media. I’ve emerged with a fuller and more complex take on the digital humanities, one that’s softer if still a bit critical (then again, I’m critical of everything). I was struck by a few things about THATCamp in relationship to other academic conferences: the earnestness of the curiosity that infused the enterprise, the genuine commitment to openness and sharing that so many attendees possessed, and the democratic willingness so many folks had to engage with whomever approached them. I was pleased to leave with a handful of ideas for projects to pursue. I needed a shot of adrenaline at the end of a relatively demanding year where I regularly felt that my professional autonomy was being made tenuous by circumstance. THATCamp delivered some inspiration, and for that I’m thankful.

Still though, after submitting an essay to Matt and my trip this past weekend, I feel as though some of the assumptions I had about the digital humanities have been reaffirmed even as I have come to understand them more deeply. One common theme threaded through several of the sessions and conversations that I had and observed at THATCamp: many attendees are working through some sort of frustration with their home institution.

The first session I attended, on whether or not “digital literacy is a done deal,” emerged out of attempts at the University of Mary Washington to launch a “Digital Knowledge Initiative.” Jeff McClurken, who proposed the session, argued that the DKI grew out of a sense that much of the experimentation that has been happening on UMWBlogs wasn’t filtering throughout the entire school and hadn’t been institutionalized in a way that was sustainable, scalable, and truly transformational. Martha Burtis, who also contributed to the proposal, noted her discomfort with an initiative that might disembed the building towards digital fluency from other curricula. Separating out those pedagogical processes ultimately might weaken them. Both positions reflect the desire to compel others at the institution to embrace lessons that can be drawn from the digital humanities about the role of technology in nurturing humanistic inquiry which revolve around openness, sharing, experimentation, visualization, embracing discomfort, and tapping into imagination. Much of the rest of the discussion focused on the challenges of compelling reticent colleagues to integrate such values into their own work, particularly the self- de-centering required of so many who’re steeped in research and teaching from very narrow niches.

A subsequent discussion that I attended extended a morning conversation about “inclusion” in the digital humanities while absorbing a session that had been proposed by Sheila Brennan on “documentation.” I have to say that while this investigation emerged out of earnest self-reflection and a genuine desire to make the digital humanities into a more fully representative field, parts of the conversation unsettled me. Though it wasn’t directly articulated, it was pretty clear from the conversation in the afternoon that most of the concern was about bringing scholars of color into the DH fold. While I agree that ensuring that tools and projects emerging out of the digital humanities are accessible is extremely important, the notion that those committed to the field need to put forth significant effort to make events like THATCamp more ethnically diverse is problematic. The THATCamp “movement” prides itself on openness and welcoming, and those feelings were certainly in full effect in Fairfax last weekend. A working group that focuses on targeting populations of humanities scholars who aren’t present in force at THATCamps risks reifying the insider/outsider us/them constructs that spurred the organization of this session in the first place.

There’s no easy answer to the conundrum of diversity in DH, but I do think that those trying to address this question would be as well or better served by looking inwards at the field than by organizing outreach. For instance, I’m curious how many disagreements there are at THATCamps, and to what extent real diversity might challenge notions of the “niceness” of the field? There’s also the question of politicization. Black and ethnic studies departments emerged in the wake of the civil rights movement, as part of broader efforts to explore untold histories in an effort to empower. I’ve not done research to verify this, and I feel a bit uncomfortable making the observation, but after a lifetime around higher education it certainly seems that scholars of color are still more likely to do their inquiry within this mission than outside of it. Research in these fields rarely pursues knowledge simply for its own sake, but rather does so regularly out of the sense that the process of making knowledge is political. That vibrancy and purpose has drawn me intellectually to the history of race and ethnicity. Does the fact that the digital humanities “movement” hasn’t articulated an explicitly radical agenda contribute to the lack of diversity at events like THATCamp? I really don’t know, but it seems a question worth asking. This is not a call for a more self-consciously radical digital humanities, but rather a call for more reflection about the nature and implications of true diversity within higher education.

Talk in that session turned to how digital humanists might reach out to such scholars on their campuses and draw them into projects or at least the conversation, and it was here where integration of documentation made the most sense. Good documentation is the best tool to make accessible what humanists are doing with technology, and ultimately to draw additional scholars in. A second conversation on documentation on Sunday morning extended this discussion, and it was particularly useful in suggesting tools for creating documentation and methods for integrating the creation of supporting materials into the production process. This discussion also focused on the frustrating art of imagining and addressing audiences not necessarily familiar with the language, methods, or processes of the digital humanities.

A final session asked “what can we learn from journalism?” Part of this conversation again constructed digital humanists as conduits for innovation to filter into their home institutions. A significant chunk of the work I do with Blogs@Baruch involves finding and sharing new models for teaching with technology across the curriculum and helping faculty members adapt those models to their pedagogical purposes. It’s here where I think the work of educational technologists and digital humanists most overlaps: for our work to be effective, we must have the ability to compel people into it, and that requires quite a different skillset than those that go into producing a new tool, visualization, or archive.

One of the most useful things that I got from conversations at THATCamp was some necessary perspective on how positively folks on the outside view the initiatives that I’m involved in at CUNY. Admittedly, most of this was likely out of broad familiarity with the CUNY Academic Commons, to which I’m a Community Advisor, but Blogs@Baruch is the Commons’ sister project, sharing an ethos, a politics, and circumstance that go far beyond software. I’m not shy about muscling Blogs@Baruch in on some of the Commons’ shine. What I think each of these projects shows — along with our other sisters — is that as frustrating as this process often is, a digital project becomes stronger as it grows organically within and in response to the concerns and uses of a distinct community, whether that be a college or an imagined user base. So much is to be gained from the networked conversations and experiences that happen within the digital humanities and at THATCamps. But the difficult work of turning that knowledge inwards — which often entails productively engaging resistance that can originate from both inside and outside our own selves — is at least as important.