Delegating rights to edit Managed Units

Hey Lee,

Unfortunately this is not possible. Only ARS Admins can create Managed Units. More details in the KB below:

support.oneidentity.com/.../can-i-delegate-permissions-to-create-or-update-managed-units-to-a-user-

Thanks and I can see the reason why too and thinking about this it was obvious however ( or there is always a BUT) the users in question are ARS admins that I am trying to limit. I want to remove just a little from the ARS admin role but I don't want to prevent them from editing the managed Units and this means I have to give them full rights :-(.

I'd prefer they didn't stop me delegating that right but instead warned me of the consequences of doing do. I suspect this is partly because the change tracking policies don't work in the configuration container.

The argument is a little moot too because I can delegate access to the script modules which means if I do that, the users could modify the script to add any account they like to any group including domain admins. Take this to the extreme I could create a policy that would detect my account being disabled which would enable my account, reset the password to one of my choosing add it to the domain admins, removing all others from all priviledged groups making me the only person that could administer anything in my environment.

Following the logic of why I can't delegate access to create and manage MUs then I should not be able to manage any of the ARS configuration unless I am an ARS admin and that's currently not the case.

I generally try to dissuade customers from doing any kind delegation on the configuration of AR itself. Doing so is pretty much akin to delegating Enterprise Admins and that's just not a good idea.

To your latter point, the few times customers have insisted that they want to delegate management of AR configuration, I break into my dissertation about how if you do this, then you must put it in all sorts of stringent auditing / controls to prevent scenarios like you describe. Most then realize the potential folly of their wishes.

When you think about it, a big reason for putting in AR is to rein in admin rights in the first place and give people only the simple rights they need to fulfill CRUD for AD object management. The minute you step outside of that paradigm, things start to get sketchy from a control and auditing perspective.

The challenge is certainly not insurmountable and from a purely nerdy point of view, overcoming this could be somewhat "fun". But it seems to me that this is one of those problems that perhaps shouldn't be solved and certainly not without careful consideration of the broader potential security ramifications.

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.

Can you clarify your comment:

" 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. "

I'm not sure what, configuration-wise within in the product is delegated (out of the box) to anyone but an AR Admin?

It sounds to me like (probably not by choice) you have been forced to give everyone back the keys to the kingdom which were supposed to have been taken away when AR was installed in the first place.

I get that some people might prefer to perform certain tasks via ADUC but by allowing that and having "too many" AR Admins, you (probably not you personally) are still further confounding the value / role of AR in your environment - that of appropriate permissions delegation. Your comments about having to explain the whole AR Admins thing to auditors is a further example of that.

Have you ever tried to sell the idea of taking greater advantage of AR's automation & customization capabilities with a view to eliminating the use of ADUC? For example, having on-demand workflows for performing bulk operations.

PS If nothing else, I would be curious to know what kinds of tasks your colleagues think that ADUC is "better" for.