Below you’ll find a link to a TechEd Europe session earlier this week.
I just finished watching the 2nd half, which is much more interesting than the 1st half (which presents all the problems we all know about). Microsoft has finally revealed their planned just in time administration (JIT) approach in broad strokes.
Some of the major points:
- Next version of Windows will have capability where group members can have a TTL that AD automatically respects (AD has had TTL capability for a long time, but this is the first time I think anything has used it)
- There is a new forest trust type for admin access. Very little said about this
- There is a concept of a bastion forest. The purpose here is twofold:
a) isolate your elevated account risk
b) have a known place of goodness (i.e. you may already have bad actors in your forest that you don’t know about)
- There is some newly extended capability leveraging sidHistory such that you can now stick the SID of well-known groups on objects (this is key to allowing the bastion forest accounts/groups to “own” objects in your existing forest)
- Next version of Windows will know that when it goes to issue a logon token, the TTL of that token should be constrained by the smallest TTL of your security group memberships
- There are capabilities in MIM.vNext (was FIM) that permit workflow behaviors such that pre-defined “candidates” can self-elevate themselves subject to approval workflows you design and TTLs you specify
- A key point: you don’t need to move any of your existing environment to Windows 10 to take advantage of this new goodness. You deploy a new Windows 10 forest, setup the elements required to support the stronger access management scenario you need (in that new forest), map them to your existing groups, and empty those existing groups. At that point, no one has access by default, and everyone has to use the JIT mechanism.
I’ve gotten a couple “huh?” sorts of inquiries related to my parenthetical comment above about how AD has had TTL capability for a long time. Mostly about how Microsoft might get something like this to work and whether this TTL stuff happens in AD or MIM. My educated guess is the TTL stuff happens in AD, not MIM.
Here are a few breadcrumbs to allow you to get a handle on this yourself.
entry-TTL attribute http://msdn.microsoft.com/en-us/library/ms675669(v=vs.85).aspx
dynamicObject (auxiliary) object class http://msdn.microsoft.com/en-us/library/ms682219(v=vs.85).aspx
If you aren’t really into schema, I can’t say I blame you, but you are missing out on understanding a bunch of details. An auxiliary class is one that can be added to an existing directory object. In contrast, a structural class is the class that must be specified at the time of creation of the object. The structural class determines a bunch of things e.g. what defaultSecurityDescriptor the object has. An auxiliary class is typically used to “add” capability without the permanent overhead of modifying an existing structural class. Another important detail here is that you can “layer” (or inherit) structural classes on top of each other—the most common example of that is the computer object class layered on top of the user object class (and you can layer many times, e.g. the gMSA class is layered on top of the computer class).
Now, with those breadcrumbs, the only real mystery to me here is how Microsoft managed to take these existing mechanisms and get them to apply the “automatic deletion” not at the object level as is currently the limit of this existing AD mechanism, but at the attribute level.
In other words, today, you could add a dynamicObject class to any group object and set an entryTtl value. When that TTL expired, the group would be deleted. And there are likely use cases for that scenario (automated clean-up of the group sprawl if the owners don’t “re-authorize” keeping the group around), but that’s different than the use case here where one value of a multivalued attribute (member) on a group object gets deleted when a TTL reaches zero.
So put another way, assuming my educated guess that AD is performing this new group member TTL capability, then there’s some real neat stuff here under the covers. And that neat stuff may be highly relevant to a bunch of other use cases. I’d have to reflect on this, but I can imagine there are use cases where you’d want some other attribute’s value to expire after a period of time.