Moving objects around in AD can cause major issues especially with LDAP based applications which always seem to , hard code the object DNs.
ARS Managed Units allow you to virtualise an AD OU Structure making it simpler to delegate rights and also provides a more logical view of AD and of course
a less cluttered view for the admins as they only see the objects they need to manage.
Another advantage is that administrators cannot create new objects in a Managed Unit. A managed Unit can contain an OU but you can't create object in it.
What this means is that you can prevent an administrator creating a new parent OU and more importantly only move objects between the OUs you expose.
You could achieve similar results with a complex delegation model but lets stop for a minute here, the AD is already a mess and you can't move the objects
around for fear of breaking things.
My solution is to create a Managed Unit that has a membership rule that includes only the immediate child objects of the targeted OU. This simple LDAP
query achieves this (&(objectCategory=organizationalUnit)(street=DisplayOUinMU)) all I need to do is set the street attribute on all the objects in the
target OU and create an policy that ensures that any objects created or moved to the OU get this value too which is a simple PVG policy.
Then I set some additional membership rules to display any objects not in the target OU, i.e. are in the wrong OU path.
Now when an admin users looks, he sees all the objects in the right location, almost anyway :-) The objects in the target OU are mostly from the wrong locations
BUT the admin can no longer create more objects in that location only in the correct OUs exposed via the MU.
This is driving the correct behavior with little management or even training overhead. Without this I found that admins, despite being told time and time again
would create more objects in the wrong OUs because related groups or service accounts were already in the wrong OU location.
I've requested a Product ENHANCEMENT as I think it would be good to have this as an an include rule in a similar way to the include group member rule. Then you would not need the PVG policy to set the attribute you would just include immediate child objects of the targeted OU. Even more useful would be the ability to further filter that to specific object types, e.g. just the users or groups or perhaps just the OUs.
