Delegated OUs project kickoff today

This morning we had a project kick off. Hooray!

One outcome of this morning’s meeting was that a new mailing list called uwwi-discuss will be coming soon. It’s purpose will be to facilitate discussion about the UWWI service in a multi-way interaction. We’ll share project news with the community there, in addition to blog posts here, and hopefully get a feedback loop that’ll hopefully improve the quality of what the project delivers.

The uwwi-announce mailing list will continue to be for service announcements.

If you’d like to get on the uwwi-discuss mailing list, let me know.

Live@Edu Federation partnership with UW

For a press-release, see, and!C76EAE4D4A509FBD!2155.entry, for a Microsoft blog about it.

The Microsoft U.S. Public Sector CIO Summit is happening today, and there is a presentation and demo happening there with our very own Terry Gray presenting.

I’d say more, but this is a public blog, and we’re under NDA. 🙂

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!

What are you doing with ADMT?

So some astute reader asked what I was doing with ADMT, wondering whether there were some domain migrations happening.

No, no domain migrations happening just yet, but there’s a lot of background material here which is likely useful to hear about.

So each time an existing campus Exchange deployment has chosen to merge with the UW Exchange service, we’ve helped migrate those existing Exchange mailboxes into the UW Exchange service. The general process required to migrate involves having a sidHistory stamped on the destination user. So you might notice that some UWWI user accounts have sidHistory on them. And that’s because we’ve used ADMT as part of these Exchange migrations to allow the mailbox migration to happen.

However, these one-time migrations have not been smooth, nor have they been especially well designed. In one case, a department incorrectly asserted the wrong source user be mapped to a UWWI user, and we had to subsequently remove the sidHistory. Mapping the source users to the destination users has been a very time-consuming process.

And the ADMT implementation was to a box that has many other functions, and used a local sql express instance. When you use a local sql express instance with ADMT, it means that you can have only a single ADMT console doing migrations of any type.

So the work behind the prior blog post was to clean up this state of affairs while retaining the migration information associated with the migrations we’ve done in association with Exchange.

That work also serves another purpose which is to get us a bit closer to being ready to allow for migrations into UWWI. We some vision in terms of how migrations might work, and this is probably as good a time as any to share that vision. 🙂

So we envision this sort of workflow:

  1. You go to a webpage which explains the process, and which tells you what information you need to gather to start.This will involve a tool or directions on how to use ldifde to generate a list of your users and separately your groups.

    You’d then need to manually remove any users/groups you don’t want to migrate.

    And you’d want to pre-screen this list to make sure that the usernames are valid uw netids. And if not, you’d drop or rename those users.

    This webpage would also tell you that you need a trust to UWWI, to set a couple configuration settings on your domain/domain controllers to allow sidHistory migration. And there’d be some other details noted that would need to be ironed out, things like making sure specific users are authorized to go to the webapp and to the ADMT database.

  2. You’d then go to a web application/service of some sort where you’d submit the edited output of the tool/ldifde.
  3. The web app/service would check your submitted list for problems, like no uw netid, and give you back a webpage where you’d see details about the source/destination accounts so you could vet the user migration action. This would allow you to say no cop\barkills, displayName=Bart Kills is not the same person as netid\barkills, displayName=Brian Arkills, so drop cop\barkills until we can figure out what’s going on with that user.
  4. The web app/service would then carry out the migrations. Behind the scenes ClonePrincipal would be used to add the sidHistory, and we’d insert the right stuff into the ADMT database to make it look like ADMT had done the migration. We wouldn’t use ADMT itself because … well … ADMT has this bug. If a given destination user already has a sidHistory, then ADMT overwrites it. And that’s not good.
  5. Now, this is the step where things are really cool. You’d then download a copy of ADMT 3.1 and install it wherever you like. During installation, you’d point it at our ADMT database. Then you’d use the various ADMT wizards to migrate your own resources, in whatever timeframe meets your needs. No need to coordinate with UW Technology (and the best thing of all from my perspective is that I don’t have to be involved).You’d use the computer migration wizard to send out agents to your computers (on your schedule) that would automatically reACL them using all the migrated users/groups, would join them to the NETID domain, and reboot them.

There are a ton of details not fleshed out here, but as I said this is a vision. And the prior blog post was about getting things moving toward this vision.