No I don’t mean enrolling them in the ‘Guido school of Admins‘ I mean getting them to do the right thing without even telling them a thing. I mean preventing bad behaviour by using features of ActiveRoles Server.
Moving Objects around in AD can cause major issues!
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 can present a virtualised OU structure – Bruce Lee might have referred to this by saying “The art of Moving objects without moving objects” or was it the “Art of fighting without fighting” – Enter the Dragon.
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 objects in it.
What this means is that you can prevent an administrator creating a new parent OU and more importantly they can only move objects between the OUs you expose, i.e. when possible they can move the object from the ‘incorrect’ location to the correct OU location.
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 so here’s a solution that makes them appear in the right place when they are not.
The solution then 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
All I need to do now is set the street attribute on all the objects in the target OU using a simple powershell script and create an ARS policy that ensures that any objects created or moved to the OU get this value too which is a very simple PVG policy. The policy sets the attribute to the parentOU attribute value.
Then I set some additional membership rules to display any objects not in the target OU, i.e. are in the wrong OU path and Bobs your uncle.
Now when an admin users looks, he sees all the objects in the right location, almost anyway 🙂 The objects in the target OU ( the Managed Unit with the same name as 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.
Putting objects in an OU ‘just because’ is up there with cloning a user object for the new start ARRRRGGGHHHHH don’t do it! ( Please start working on a roles based design today)
I’ve requested a Product ENHANCEMENT with OneIdentity ( Quest ) 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. Maybe they will include it in the next release you never know.