Delegated OUs!

For awhile now, we’ve been hoping to continue the work we envisioned back in 2006 (we called it “WinAuth phase 2” back then). And I believe we are on the cusp of embarking on that work. Hooray!

I’d like to thank everyone who filled out the survey. Your input is invaluable, and we’ll be following up on it. And if you haven’t yet filled it out, there is still time until March 3.

I did want to take a little bit of time and point out some of the high-level takeaways we’re seeing from survey responses.

First, everyone who took the survey wanted to leverage UWWI user accounts. That’s especially significant when you look at everyone who took it, and the broad spectrum of uses folks are interested in.

Second, there is a high degree of interest in including user attribute management in the project scope.

Third, almost everyone would move some computers in by the end of summer if they could. And about half of respondents have non-Windows computers they’d like to move in.

Fourth, in sharp contrast with what we heard a year ago, only 8% of respondents would *not* move computers in if we offered no migration assistance. 1/3 of respondents would like some migration assistance, but the majority of folks are more interested in a self-migration option.

Finally, the concerns and open feedback questions made it clear that there is quite a bit of education we need to do about what functionality is already in UWWI, what existing departmental processes might need to change if you adopted a Delegated OU, and the need to continue a dialogue about you’d like UWWI to be.

These high-level takeaways are very likely to shape the actual project work.

For example, it seems clear to me that opening the doors is the highest priority. So hammering out use policies, defining support processes, and documenting all the details that y’all will need are the important deliverables there.

In contrast, the migration tools and process we thought were the most critical piece of the project, now seem to be a much lower priority. Among that work, I’d still prioritize a bulk group import tool, because feedback from the ISchool pilot made it clear that this was the most painful part of their self-migration process.

Then in the middle of the priorities, we need to re-engage on user attribute management. We’ll need to discuss the user attributes y’all highlighted, see if workarounds reduce the perceived need or not, and then prioritize those most widely needed.

We’ve been around the block with some of you a few times on envisioning a solution to the multiple affiliation (or unclear affiliation) issue for user attribute management. In other words, how do we figure out who should be authorized to assert an attribute value for any given user? Our last idea for solving this conundrum seemed to have pretty good support, but I’m not sure how widely the idea has been shared. Basically, the idea is to initially put the management of these attributes into the hands of the users by leveraging the UW NetID manage page. But instead of forcing users to know a obscure attributes values, such as an UNC path for their home directory, instead the user is presented with a friendly choice of various departments. For example, in the UI they might pick the “Ischool Home Directory”, and the UI will map that choice to the obscure formula that ISchool uses for its home directory paths. We might further simplify things by allowing the user to choose “all ISchool UWWI values” in that UI–or to assert that the ISchool is their local IT support org. And this last possibility conceivably could open the door for us to allow departmental IT folks to assert values without the direct involvement of the end user.

Now, taking a step back, let’s touch on the concerns raised in the survey responses. Not everything is roses. 🙂

There are various 3rd party application integration challenges that we’ll need to look more closely at. Weaker password policies in the UW NetID system than some of you require are clearly an issue which will need more attention, and we’ll work to support changes there.

Concerns about losing control of access control to your computing resources is clearly something we’ll need to address. That one is a bit tough, because while it has some educational components to it, and there are definitely steps you can take to reduce your risk, at the end of the day this issue is really about trust. Are UW Tech domain admins trustworthy? Will you be compromised by some other department in UWWI? We’ll do everything we can to earn your trust, and if you have specific ideas about things we can do here, please send them.

Another concern that I’ve heard a couple times over the last few weeks both in and out of the survey responses is a concern that UWWI Delegated OUs might be “like the UW forest”. There are a couple concerns wrapped up in that, which include:

  • a concern about the high number of domain compromises which over time have happened in the UW forest and that similar things might occur,
  • a concern that UW Technology will be a “big brother” forcing things on folks that they don’t want
  • a concern that at some later date UW Technology might pull support for this out from under folks

Obviously these concerns get at the shared nature of this undertaking. Addressing these kinds of concerns can only happen via developing use policies which seek the common good and by securing the commitments of those departments which adopt a Delegated OU. So I’d encourage folks with concerns like this (and the access control one above) to take an active part in helping draft and vet those use policies.

Well, this has turned into another of my long write-ups. But regardless, I do want to end by saying that I’m excited about what’s ahead, and look forward to partnering with many of you!

Leave a Reply

Your email address will not be published. Required fields are marked *