Dynamic Groups - Deny changes

Practically speaking, no as you have to be an AR admin to manage dynamic group membership rules.

Here's some food for thought:

It's one thing to allow I.T. folks to use the MMC console as their interface to AD via Active Roles.

It's a HUGE risk to have too many people with administrative access to the Active Roles application itself.  i.e. you do not HAVE to be an AR admin to use the MMC.

Here's a suggestion I have if you want to allow semi-delegated management of dynamic groups:

Let's assume that you use the contents of certain virtual attributes that you setup for the purpose to control the membership of dynamic groups.  You could delegate access to the editing of those attributes and thus indirectly allow someone to manage dynamic group membership.  Maybe that's not your use case though.

Maybe you can elaborate on your use case a bit?

Thanks mate. Yes that pretty much the line I want to go down with VA and use that already on many groups.  However what i was looking to stop was someone adding a new query or an explicit entry to the dynamic group. 

Think about what I said about AR admins though.  I have found over the years that customers hand out admin right to the AR application way too freely - often for political reasons and then find themselves in a jam because someone made an AR configuration change that affects the productivity of the delegated admins community.

Think about what I said about AR admins though.  I have found over the years that customers hand out admin right to the AR application way too freely - often for political reasons and then find themselves in a jam because someone made an AR configuration change that affects the productivity of the delegated admins community.

Thanks mate. I fully understand what you are saying and in an ideal world or greenfield site this would be easy and straight forward. Over time we would get to that point. 

So is there no way of restricting individual dynamic groups? 

Stu.Pollock suggestions are spot on (and I agree with him regarding deny's in general).  I would take the groups that you want to restrict and place them all in a specific OU.  Use that OU as part of the start conditions for the workflow that Stu suggested that intercepts the change request.  So the middle part of your start condition would consist of:

1) Some security group containing the admins who's activities you want to restrict

2) The "restricted dynamic groups" OU

Thus changes made by the restricted admins on the groups in that OU would be "trapped".

The problem of course is that you then need to start putting in more controls over the membership of that restricted admins group and the movement of dynamic groups out of that OU.

Do you own Quest's Change Auditor product?  If not, you should have a look at it because even though you might not be able to restrict who is an AR admin or an admin in general, you could put into place some reporting and alerting on their activities.

Hi. No we don't have change auditor. will look in to it. Could I use a Managed Unit rather than an OU? The groups we want to control are in multiple places and cant right now be moved

Yes you can use a Managed Unit for the "container" in your workflow start conditions.

Just to muddy the waters. I want said Admin to be able to make changes to the DG via the Virtual Attribute ,but what I want to stop or control is them adding a new query or explicit entry. 

That goes back to what Stu mentioned about a workflow that blocks direct membership rule changes.

The membership rules are stored in the native property accountNameHistory and the VA edsaDGConditionsList so you want to watch for changes to these.

Ah i see. Ok, think i am getting my head around this now. 

Hi craig mcfarlane 

First, yes you could use a managed unit to take the workflow against, but the rules on that Managed Unit would need to be restricted to prevent the admin changing the rules to get around the workflow from stopping them doing something they shouldn't/

And yes, the workflow could be written in such a way to prevent them from changing a DG's rules, by removing the property being updated (which stored the rules) from the request. But if they were either in the same change or another change to set the VA that would remain (unless you us a block activity, at whcih point they'd need to re-do the change without the manual change to the DG property).

But you'd need a workflow to execute on setting that VA to do the update to the DG property, which should be triggered by the Admin Service, rather than the admin user.

I have the DG being updated via a VA and thats working fine. So if i can get the MU working to stop direct changes then im golden. 

Ok, so does this look right so far? I am little unsure of the filtering if the person requesting the change is a member of GroupABC