Back on 5/11/11, we made a minor change to the delegated OU permissions to ensure existing policy was enforced on object creations. This was intended to close a loophole, and we didn’t anticipate any impact to customers. But we ran into two customer impacts.
First some background:
We’ve never granted the ability to ‘change permissions’ at the top level of your OU. However, by allowing folks to create objects, we give them the ability to be the object owner. In either AD or NTFS, an object owner has two implicit permissions that *aren’t* explicitly in the ACL. These two permissions are:
- Modify Owner
- Change Permissions
In other words, the owner can make a different account the owner, and the owner can also set permissions on that object.
Since we allow delegated OU admins to create objects, they become the owner, and inherit the ability to set permissions. That is, prior to 5/11/2011 they could set permissions.
With WS2008, Microsoft provided a way to override the implicit permissions that an owner has. This can be done via the new “well-known sid” security principal called NT Authority\Owner Rights. If that principal is granted anything on an object, it overrides the implicit permissions.
So on 5/11/2011, you’ll see in the documented perms, that we’ve set “Allow ‘Owner Rights: Modify Owner”. This means that an object owner still can pass the ownership, but doesn’t have the ability to change permissions.
We didn’t think this change would mean much to everyday use, but it turns out it did.
Our first problem was with an ACE that the Active Directory Users and Computers tool puts in place–trying to be helpful. For example, when you create an OU, you may see a checkbox labeled “Protect container from accidental deletion.” When checked, that results in an inherited ACE applied to the OU. UWIT creates all the top-level delegated OUs, and on about 80% of those we checked that box. Prior to the above change, that didn’t cause a problem when an OU admin went to create a child OU because the creator/owner could still set the inherited permission on the child OU. But after the above change, this ACE would prevent the child OU from being created. We’ve since removed the problematic checkbox on all top-level delegated OUs, so this isn’t a problem moving forward.
The second problem was with delegating who could join a computer to a computer object an OU admin created in their delegated OU. Yep, as you probably can guess, with owner perms, prior to the change this was no problem, and after the change, this was a problem. In this case, the (computer) object was created, but the ACEs representing join perms were only set to the creator/owner, not what was specified. And no error message is raised about Active Directory Users and Computers failure to set the desired join permissions. We’ve fixed this problem by granting OU admins the ability to modify permissions on computer objects, and you’ll see that represented in the documented permissions too.
So in both of those cases, the behavior prior to 5/11/11 is in effect.
Finally, I should mention one other delegated OU permission change we made on 5/11/11. Because we grant pretty broad permissions, prior to 5/11 it was possible for OU admins to rename their delegated OU by themselves. But now they can’t rename their top-level OU. We don’t object to a name change of your top-level OU, but there are implications based on the many namespaces that are linked to that OU name. So we’d like to be involved in name changes of that top-level OU to ensure that everything dependent on that name is properly adjusted.