davenesbitt.com

I was in a design and planning meeting at a Higher Ed client today. They are deploying AD/Exchange for the first time and looking to hook it up to the existing MIIS implementation we’ve put in. Two issues in particular generated much discussion.

First, the OU structure for users was proposed to be as simple as possible: OU=Users (with alphabetical sub-divisions if necessary). I should probably also mention that there are about 60,000 user accounts here. There was initially some opposition from some old-time directory die-hards (not me, I hasten to add) whose instinct was to replicate the current very complex NDS OU hierarchy and have OUs for each department. The problem with this approach, of course, is that departmental hierarchies change constantly (the current NDS one is well out of date). It’s true that MIIS/ILM can fairly easily be programmed to manage OU structure automatically by provisioning and renaming OU objects in the remote directory, and we are often asked to do this, but unless there’s a really good reason to have a complex hierarchy, why bother? Personally, I prefer a big bucket for all my users – it makes things much simpler. After all, the main original argument for having a directory hierarchy was to make enable local security boundaries to be enforced per OU. With group policy in AD, it’s just not necessary any more as ACLs and permissions are applied per group, not per OU. Old habits die hard though and some old directory guys seem very fond of their complex DITs. Personally, after some of the arguments I sat through deploying X.500 to Government organizations during the 90s (when it was all so new and exciting), I’ll be glad if I never see a DN longer than 4 or 5 layers ever again.

Secondly, especially in Higher Ed, we often run into issues where we have a person who exists with two distinct contexts within existing databases – a student who is also a member of staff (and vice-versa). These are sometimes undergrads that have a part-time job at the college, or research students who also do paid research work. The problems arise when these people enter the identity management system from two distinct feeds (one from HR, one from the Student DB). In an ideal world, they would be entered into each database with a unique identifier that relates to the other system (e.g. their student number gets entered into the HR system when they enrol as a member of staff) that would allow automatic joining of both accounts to their single metaverse (or equivalent non-MIIS term) entry. It’s not always that simple to convince database owners to modify their systems though, so very often we have go ahead initially with what we have – and that often leads to two discrete identities in the IdM system, which can also lead to two accounts in target systems (such as AD). At first glance this seems bad – after all we’re hoping to reduce duplicate and unnecessary accounts, aren’t we? But if the cure is prohibitively expensive or disruptive in the short term, then it may be expedient to live with this for a while. After all, we often use separate user accounts in AD to separate security contexts and enable auditing – it’s best practice to log in a separate administrator account from your normal day-to-day account. Might not this practice stretch to any situation where security separation and auditing is required? The example of a web-based E-Learning environment was discussed where a student who is also a member of staff might need to use the application in two distinct contexts: once as a teacher planning courses and marking coursework and once as a student (where having access to marking schemes wouldn’t be a great idea...). In cases like this where separation of duty can’t be enforced by simple group membership, then two distinct accounts, whilst unintuitive and harder to administer, might be the right approach.

We didn’t reach any ground-breaking conclusions this week. The simple OU structure looks like being the preferred approach and more investigation is required to decide whether or not we unify existing dual accounts into one in the short term. As always, I’d be interested in your thoughts.