|Subject:||Exception OU in Delegated Environment|
|Posted by:||Tim Chin (donotemailme)|
|Date:||Mon, 25 Sep 2006|
I've been trying to create a new OU that nobody can rename or delete inside
an existing OU that a group of people have limited access to. The users
have been delegated the ability to create/delete OUs and write all
properties to OUs. Other than that they have the ability to create/delete
computer accounts as well as full control to all computer account objects.
I can get the rename to work as expected by turning off inheritance on the
OU and giving only domain admins, enterprise admins, and SYSTEM permissions
to modify it and it's contents. However, I can't stop users from deleting
it when Authenticated users have the generic read permission. It's like,
once they know it's an OU, they can delete it due to their parent's ACE of
'Create/Delete OUs'. I figured that inheritance would end that, but it
doesn't. I also tried to deny the delete property of the OU itself to a
test user, but still had no luck.
Is there something that I'm missing or is this expected behavior? If it's
expected behavior, does anyone have any clue for a workaround? The only
other option I seem to have is to make this OU a top-level OU where nobody
has perms and create a peer OU where they do have perms. I really don't
want to do this as it deepens the minimum OU depth to 3 in my environment
and it's also a pretty goofy concept.
Any help is appreciated.