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.

Hi craig mcfarlane 

There are a couple of ways of doing that

1) Don't grant uses permissions over the (dynamic) groups objects they shouldn't be able to manage. As Johnny says if they are all ARS Admin, people delegated permissions appropriate for the relveant sets of teams, the ARS Full Admin group is for the Active Roles product administrator, not for normal day to day, as it give configurational access to the product, meaning anyone with it could change anything.

2) Have a workflow which intercepts changes made to dynamic groups, set its start condition by for members of particular groups, within an area of AD, where the attribute used to store DG rule is updated. Then remove the change from the request, or just use a Break/Stop activity step to make it error... (removing the value from the request just makes it so that an attribute isn't changed, however the person making the change would assume its happened).

There are a couple of other ways, but from my point of view, its better to not grant users permissions in the first place, rather than add deny permissions. For everything else there are workflows and script modules.

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.