-
Title
Active Roles Dynamic Group functionality and Best Practices -
Description
This article outlines Active Roles Dynamic Group functionality and best practices.
-
Resolution
Functionality
Dynamic Groups allow for the automation of group membership based on rules, which can consist of explicit include/exclude queries and specific objects.
Possible membership rules can be any combination of the following rule sets:
- Include Explicitly
- Include by Query
- Include Group Members
- Exclude Explicitly
- Exclude by Query
- Exclude Group Members
When multiple rules are configured, the order of precedence is as follows:
- Exclude Explicitly
- Include Explicitly
- Exclude by Query
- Exclude Group Members
- Include by Query
- Include Group Members
Dynamic Groups are updated constantly, as Active Roles polls for DirSync requests every 2 seconds and then updates any Dynamic Group that matches a rule - whether it is adding or removing a user from the group, it will do so immediately.
For all versions of Active Roles prior to 7.5.5, 7.6.3, 8.0.1, 8.1.1, Dynamic Groups will not be updated immediately if there are more than 1000 changes per request. For instance, if a bulk update is performed that exceeded 1000 changes to the Dynamic Group, Active Roles will ignore the immediate update, and it will then be updated when the Dynamic Group Updater scheduled task runs (default 3:00 AM UTC). Otherwise, you may click Rebuild on the Members tab of the group to force the update.
Starting in Active Roles 7.5.5, 7.6.3, 8.0.1, and 8.1.1, this limitation has been removed. Dynamic Groups will now update immediately, regardless of the number of changes.
In general, the membership list of a Dynamic Group is updated in any of these cases:- Membership rule has been modified.
- Group type has been changed.
- Membership list has been modified by an external tool, such as Active Directory Users and Computers.
- Rebuild of the membership list has been initiated manually, from the Members tab in the Dynamic Group Properties dialog box.
- Given a membership rule based on linked attributes (such as Include Group Members), the forward link attribute (such as Members) has been modified.
Potential IssuesFor versions prior to 7.5.3:
When the Dynamic Group Updater scheduled task runs, the conditions are evaluated and then a membership list is created and then processed one by one. During this time, if the Dynamic Group Updater scheduled task detects an error during the update, it halts the update and the group may end up in an incorrect membership state. In this scenario, the Dynamic Group must be manually rebuilt by opening the group and clicking Rebuild. A rebuild will clear all Dynamic Group members and then re-add them.Starting in 7.5.3, Active Roles performs a Delta operation on all rebuilds, and will no longer clear the entire group membership, unless the rules have been modified to cause this.
For Active Roles 8.2.1 SP6 and later:
The Dynamic Group logic was redesigned and functions as follows:
- The Dynamic Group Checker builtin Scheduled Task is no longer in use
- Dynamic Group cache is refreshed during Active Roles service start
- Membership updates are performed as Delta changes
- Any change to accountNameHistory will force an evaluation/rebuild
- Dynamic Group updates are added to a queue:
- High Priority - actions such as Rebuild
- Normal queue - normal changes to objects
- Members are not emptied
Best Practices
Nested Dynamic Groups
Nesting should always be used cautiously in any scenario. Particularly with Dynamic Groups, do the following:
- Ensure that the service to evaluate and apply rule changes is set the same for the main Dynamic Group and any nested Dynamic Groups contained in the rules (they must all use the same service).
- Ensure there are no duplicate rules that could contain the same set of objects in multiple rules and nested rules.
General Best Practices
- Avoid conflicting rules when possible (both Include and Exclude same objects).
- Custom LDAP searches cannot use wildcards for values that contain a DistinguishedName or a CanonicalName, as these are natively restricted by Microsoft's API. For more information. see this Microsoft resource.
- Avoid Nesting if possible.
- Monitor the Active Roles Event log for any errors.
- If you do not intend to include members from multiple domains, ensure the option Enable cross-domain membership is not enabled. This setting is found on the policy Built-In Policy - Dynamic Groups, found under Configuration | Policies | Administration | Builtin
Note: This setting can slow down Dynamic Group processing even if you only have a single Managed Domain, as it is designed to have extra checks in place. - If you have a large number of Dynamic Groups, it is advisable to spread the distribution of updates across multiple Active Roles services if possible, keeping in mind the notes above in the Nested Dynamic Groups section. Dynamic Group processing can be resource-intensive, depending on the configured rules. For a large number of Dynamic Groups, it is also suggested to set up a dedicated Active Roles job server and specific DC to handle all the Dynamic Group processing. Enhancement ID 234907 has been created to change current Dynamic Group functionality so that the scheduled tasks can be load-balanced across multiple Active Roles Administration Services.
- By default, only mail-enabled and non-deprovisioned users are included for Distribution Groups. For further information, refer to KB 40873.
Membership Rules Best Practices
1. Always Design for Early Exit
Rule evaluation speed is entirely about how fast you can stop evaluating.
✅ Best practice: Ensure every Dynamic Group has at least one early‑exit rule from:
[0x4] Exclude Explicitly
[0x6] Exclude Group Members
[0x2] Exclude by Query
🚫 Anti‑pattern
Groups that begin evaluation at [0x1] Include by Query for every object.
✅ Why it matters
- Early exits prevent worst‑case evaluation paths
- Reduces CPU, LDAP, and queue exhaustion
- Improves deterministic behavior under load
2️. Keep [0x1] Include by Query Minimal and Singular
✅ Best practice: Avoid a "Starts with" or "Contains" style query if an "Is (exactly)" option exists.
🚫 Anti‑pattern
(employeeType=R*)
(employeeType=*Regular*)
Include queries should identify candidates, not define the universe.
✅ Best practice
Limit [0x1] rules to one simple, high‑selectivity condition, such as:
(employeeType=Regular)
🚫 Anti‑pattern
Large OR‑driven [0x1] rules:
(| (attr=A)(attr=B)(attr=C)(attr=D)... )
✅ Why it matters
- [0x1] is evaluated late and frequently
- Complex filters scale linearly with directory size
- Simpler filters dramatically reduce evaluation cost
3️. Convert Inclusion Logic into Exclusion Logic Wherever Possible
“Everyone except X” should never be written as “include everyone who matches X”.
✅ Best practice: Invert logic and move complexity into [0x2] or [0x6].
Instead of:
[0x1] Include by Query: (&(employeeType=Regular)(department=SALES OR SELLING OR SALESPERSON...))
Use:
[0x1] Include by Query: (employeeType=Regular)
[0x2] Exclude by Query: (!(department=SALES OR SELLING OR SALESPERSON...))
✅ Why it matters
- LDAP engines short‑circuit on failures faster than matches
- Most objects exit early
- Shrinks average evaluation time per object
4️. Use [0x6] Exclude Group Members for High‑Cardinality Conditions
Group membership is cheaper than repeated attribute comparisons.
✅ Best practice:
Create helper groups for:
- Contractors
- Service accounts
- Resource users
- Known exceptions
Reference them via [0x6]
[0x6] Exclude Group Members: CN=DG‑Excluded‑Users
✅ Why it matters
- Group membership checks are binary
- Eliminates massive OR chains
- Centralizes exception logic
- Safer and easier to audit
5. Never Stack Expensive Groups Without Guards
Dynamic Group cost multiplies when expensive rules stack.
✅ Best practice:
If a Dynamic Group references or overlaps other Dynamic Groups:
- Add an early [0x6] or [0x2] guard
- Ensure failures exit before nested expansion
🚫 Anti‑pattern
Enterprise Dynamic Groups referencing other enterprise DGs without exclusions.
6. Prefer Query Exclusions Over Query Inclusions
Negative filters short‑circuit faster than positive ones.
✅ Best practice
Use [0x2] Exclude by Query to prune:
- Secondary users
- Resource users
- Service users
- Deprecated accounts
✅ Why it matters
- Reduces rule‑path depth
- Prevents fallback evaluation
- Stabilizes performance under spikes
-
Change Request
234907