Delegating rights to edit Managed Units

I can't disagree with you other than reiterating that they block one aspect but allow some which is kind of pointless and they should remove all of the delegation or allow everything to be delegated.

On a related note I love the fact that I can answer the audit question who can administer this object and what can this user administer by simply using the administration tab of the appropriate object. ARS admins however are not shown in this report so you have to say to the auditor - oh actually there are some other users who can do everything but they are not shown in the report they then start think well who else can't I see in that report and you end up with a lot more requests for native audit data :-(

My case scenario is that I want to force my fellow admin users in their day to day role via the Managed Unit abstraction I have built. Most admins are as stuck in thier ways as anyone else so if they can they will keep on doing it the same way as always and will bypass my MU design and go straight to AD. Despite the benefits of using the ARS MMC you would be amazed ( or probably not ) how many will still use ADU&C.

My fellow admins still need to be able to expand the MU model as requirements change and I don;t want to block that. These guys are all ARS admins on our 6.9 platform and can do anything they like. As it happens I'm the only one that actually does make these design changes but I'm not here 24 7 so they need the rights in case I am unavailable.

We use 2 admin accounts and all have 3 accounts in all. A personal employee account used for email etc and then we have 2 personal functional accounts one to administer servers and workstations and do general AD support type work and then another personal functional account that is a domain admin and used to do domain level administration. We use the appropriate account for each security tier we are working on to minimize the risks involved in using these accounts as is now recommended by most IT Security specialists, i.e. domain admin accounts are not used anywhere except when logging onto a Domain controller. Admin accounts are never used on workstations for interactive logon as it's a pain to ensure the credential footprint is not left behind.

Because of this limitation I will need to restrict the admin accounts further and find a way for the domain admin accounts to manage ARS without installing the MMC on the DCs. The obvious answer is to use temporal membership of the ARS admins group for the admin accounts so they can add themselves as step on to reconfiguring ARS. A little more messy than I was hoping for.

I can't disagree with you other than reiterating that they block one aspect but allow some which is kind of pointless and they should remove all of the delegation or allow everything to be delegated.

On a related note I love the fact that I can answer the audit question who can administer this object and what can this user administer by simply using the administration tab of the appropriate object. ARS admins however are not shown in this report so you have to say to the auditor - oh actually there are some other users who can do everything but they are not shown in the report they then start think well who else can't I see in that report and you end up with a lot more requests for native audit data :-(

My case scenario is that I want to force my fellow admin users in their day to day role via the Managed Unit abstraction I have built. Most admins are as stuck in thier ways as anyone else so if they can they will keep on doing it the same way as always and will bypass my MU design and go straight to AD. Despite the benefits of using the ARS MMC you would be amazed ( or probably not ) how many will still use ADU&C.

My fellow admins still need to be able to expand the MU model as requirements change and I don;t want to block that. These guys are all ARS admins on our 6.9 platform and can do anything they like. As it happens I'm the only one that actually does make these design changes but I'm not here 24 7 so they need the rights in case I am unavailable.

We use 2 admin accounts and all have 3 accounts in all. A personal employee account used for email etc and then we have 2 personal functional accounts one to administer servers and workstations and do general AD support type work and then another personal functional account that is a domain admin and used to do domain level administration. We use the appropriate account for each security tier we are working on to minimize the risks involved in using these accounts as is now recommended by most IT Security specialists, i.e. domain admin accounts are not used anywhere except when logging onto a Domain controller. Admin accounts are never used on workstations for interactive logon as it's a pain to ensure the credential footprint is not left behind.

Because of this limitation I will need to restrict the admin accounts further and find a way for the domain admin accounts to manage ARS without installing the MMC on the DCs. The obvious answer is to use temporal membership of the ARS admins group for the admin accounts so they can add themselves as step on to reconfiguring ARS. A little more messy than I was hoping for.