Dynamic Group rebuild are "polluting" user Change History

Hello, Mak.

This is more of a thought experiment, as I've never tested it, but you could possibly try making adjustments to where the "Built-in Policy - Change Tracking" policy is linked. By default it is linked to the Active Directory node. You could possibly create a query-based Managed Unit that contains all Dynamic Groups, then block the inheritance of that policy on this Managed Unit. Of course, this means you would lose all Change History on Dynamic Groups. If you wanted to get fancier, you could create a copy of that built-in policy and configure it such that it captures/tracks everything except the Members attribute and apply that to your Managed Unit.

Now, this might theoretically block the Change History for the Dynamic Groups themselves, but I'm not sure what, if any, impact this might have on the "Member Of" tracking on the users themselves. Might be worth a few minutes of testing, though.

Cheers!
Shawn

Do you have any Dynamic Group membership rules that reference Active Roles Virtual Attributes, or do you only have rules referencing Active Directory attributes?

Hi Shawn,

Thanks for that. I'll have a think and do some tests. I don't think we mind not having change history on all Dynamic Groups, as long as the change has been logged on the members, or the primary group and the account. 

I'll report back with results.

Cheers,

M

Hi Terrance,

We have only one Dynamic Group that references virtual attributes. This could of course change any time and we might create more.

With Dynamic Groups that reference only native Virtual Attributes, it is possible to create a dedicated Active Roles configuration to handle real-time Dynamic Group operations. This has a few advantages: mainly, it frees up resources in your primary Active Roles configuration for other operations, but it also removes Dynamic Group operations from the logging of your primary Active Roles configuration.

When using Dynamic Groups that reference Active Roles Virtual Attributes, this becomes a little bit more complicated. You'd have to import your Virtual Attributes into the new configuration and then set up something like an Active Roles Synchronization Service Workflow to keep them in sync between the configurations. Still might be a good idea if you are interested in improving performance or simplifying logging.

I've also had some customers configure a dedicated service account on a Dynamic Group job server within the same configuration, and then filter out operations made by that account in their auditing tools. This might be a simpler ask depending on your needs.

We are aware that the current logging needs to be improved and we are tracking a requested change to this specific product functionality under ER 431618.

Hi Shawn,

I've tested it and while it works on the item it's applied to, the config does not extend to users.
It basically blocks inheritance of that policy on the "All Dynamic Groups" managed unit and removes the option to view Change History. You can still see all the logs on user accounts and directly on Dynamic Groups. This might be because they're elsewhere in the tree and the policy still applies to them.
I'll try and test the policy scoping and its inheritance some more.

Cheers,

M

Hi Terrance,

Yes, I've seen requested change to the functionality you mention.

It will be really interesting to find out more about a dedicated Active Roles configuration to handle real-time Dynamic Group operations. Not just for the issue I've mentioned here, but for other setup we're working on. Is there a resource you could point me to for a dedicated config?

Cheers,

M