Active Directory | Can I exclude users from User-Related Active Directory Actionable Alerts?

Overview 💥

Liongard’s Active Directory Inspector supports excluding specific users from user-related actionable alerts and metrics by using a Security Group named RoarExclude.

When a metric or action rule includes the RoarExclude filter, any user who is a direct member of that Security Group will be omitted from the metric results and related actionable alerts.

Why This Happens? 🤔

Many organisations need to suppress alerts for service or break-glass accounts, test accounts, or specially-managed users. Liongard provides the RoarExclude exclusion pattern so partners can centrally manage which users are ignored by prebuilt and custom user-related metrics and actionable alert rules without modifying each rule individually.

This is implemented as a membership check on the MemberOfStr field at the Users object level in RoarPath/metric queries.

Common Scenarios 🧑‍🏫

Scenario	Result with `RoarExclude`
Service accounts used by automation that would otherwise trigger stale password alerts	Excluded from those metrics if added to `RoarExclude`.
Test users used by IT for lab work	Excluded so test churn does not generate partner alerts.
Hybrid environments (on-prem AD synchronized with Azure AD)	Works if `RoarExclude` is a Security Group and is synchronized via AAD Connect.

Steps to Resolve 👨‍💻

(Use these step-by-step instructions to create, verify, and apply RoarExclude.)

1️⃣ Create the `RoarExclude` Security Group

Open Active Directory Users and Computers (ADUC) on a domain controller or a machine with RSAT.
Right-click the OU where you want the group → New → Group.
- Group name: RoarExclude (exactly, case-sensitive).
- Group scope: Global or Universal (choose per your design).
- Group type: Security — must not be a Distribution Group.
Click OK to create.

Note: If you use Azure AD Connect, ensure this group is included in sync scope so that RoarExclude exists in Azure AD as needed.

2️⃣ Add Direct Members to `RoarExclude`

Open the RoarExclude group → Members tab → Add.
Add the user accounts you want excluded.
- Important: Users must be direct members (nested membership may not be evaluated depending on your metric's MemberOfStr contents). If you rely on nested groups, validate membership strings exported by the inspector.

3️⃣ Confirm Synchronization (Hybrid/Azure AD Connect)

If using Azure AD Connect, force a delta sync (or wait for scheduled sync) and then confirm the RoarExclude group exists in Azure AD.
Run Liongard Inspector for Active Directory (or wait for the next scheduled run) to pick up membership changes. Confirm the latest run status is Completed in the environment.

4️⃣ Apply the `RoarExclude` Filter to Metrics or Alerts

Prebuilt metrics/alerts: Many prebuilt metrics already include the RoarExclude filter (see list below). No change required if you use those directly.
Custom metrics/alert rules: Add the exclusion at the Users object level using the following RoarPath pattern:

Users[? <your condition> && !(contains(MemberOf, 'RoarExclude')]

Examples

Exclude from "stale password" users:

Users[?DaysSinceLastPasswordChange > `90` && !(contains(MemberOf, 'RoarExclude'))]

Exclude privileged users from a metric:

Users[?DaysSinceLastPasswordChange > `90` && Privileged == 'Yes' && !(contains(MemberOf, 'RoarExclude'))]

For help building RoarPath expressions, use the RoarPath Commands documentation or try the AI Query Companion to auto-generate and validate your expression.

Which Prebuilt Metrics / Alerts Already Include `RoarExclude`? 🧐

The following prebuilt metrics and alerts include the RoarExclude filter and typically require no changes to exclude users that are in the group:

Prebuilt Metrics (examples)

Active Directory: End of Life Workstations (Excludes Roar Group)
Active Directory: Age of Oldest Privileged User Password
Active Directory: Privileged Users with Stale Password List
Active Directory: Age of Oldest Non-Privileged User Password
Active Directory: Non-Privileged Users with Stale Password List

Prebuilt Actionable Alerts (examples)

Active Directory | Privileged User with Stale Password
Active Directory | User with Stale Password

If you don’t see a specific metric in your environment with the RoarExclude filter, you can clone and modify the metric to add the exclusion.

Additional Diagnostics (if exclusions are not working) 😉

Use this checklist and run these quick queries to validate where the issue lies.

Quick diagnostic checklist

Check	How to verify
Group name exact and case	ADUC → Group name must be `RoarExclude` exactly.
Group type	ADUC → Group Properties → Group type = Security.
Membership type	Ensure user is direct member. Test by removing and re-adding to confirm.
Inspector run status	In Liongard environment → Active Directory Inspector → verify last run is Completed.
MemberOfStr value	Export/preview Users object in the metric inspector to see `MemberOfStr` contents. Confirm string contains `RoarExclude`. Liongard
Azure AD sync	If hybrid, confirm group exists in Azure AD after AAD Connect sync.

✅ Useful commands & methods

ADUC: Inspect group membership.
PowerShell (on AD):

# Check group exists 
Get-ADGroup -Identity "RoarExclude"  

# List direct members 
Get-ADGroupMember -Identity "RoarExclude" | Select Name, SamAccountName, objectClass  

# Check if user is direct member 
Get-ADGroupMember -Identity "RoarExclude" | Where-Object { $_.SamAccountName -eq 'username' }

Inspect Liongard metric output: Temporarily modify (or preview) the metric to Users[].MemberOfStr so you can confirm whether the string returned includes RoarExclude.

Troubleshooting — Common Failures & Fixes 🚀

Symptom	Likely cause	Fix
User still appears in a metric after being added to `RoarExclude`	Inspector didn’t run since group change	Run CCDM (Clear Cache + Debug Mode) for the inspector or wait for next run; verify run completed.
`contains(MemberOfStr, 'RoarExclude')` returns false	MemberOfStr format may be different or contains full DN	Inspect `MemberOfStr` to see how groups appear (e.g., `CN=RoarExclude,OU=Groups,DC=domain,DC=com`) and adapt query: `!contains(MemberOfStr, 'RoarExclude')` generally works but consider matching on `RoarExclude` substring.
Group is Distribution, not Security	Distribution groups won’t be evaluated the same way for security-based membership checks	Convert to Security Group or create a parallel Security Group named `RoarExclude`.
Using nested groups	Membership nested in another group may not be visible in `MemberOfStr`	Add direct membership or change metric logic to evaluate nested group DNs.

Best Practices / Prevention 🧑‍🏫

Use Security groups only for RoarExclude. Do not use Distribution groups.
Prefer direct membership for excluded users to ensure consistent results. If you must use nested groups, validate MemberOfStr contains the nested DN pattern and adjust RoarPath accordingly.
Maintain a short, documented list of excluded users and review membership quarterly as part of housekeeping.
Use a naming convention for the RoarExclude group (and possibly a separate environment-scoped group) so it’s obvious why membership exists.
Document any manual metric customizations so future admins understand why RoarExclude was used.

When to Contact Support 🦁

Contact Liongard Support if:

You have validated group name/type, direct membership, and the inspector has completed but exclusions still do not apply.
You discover MemberOfStr lacks expected values (e.g., truncated or missing DNs).
You need help editing a prebuilt metric or actionable alert to include RoarExclude.
When you open a ticket, include:

Inspector Name and URL
The metric or alert name, and the RoarPath snippet you used.
A sample Users[].MemberOfStr output for the user(s) that are not being excluded.
Screenshots of ADUC showing group membership (if possible).
This accelerates triage by support.

Should I use `RoarExclude`? 🤷

Condition	Use `RoarExclude`?	Notes
Account is a non-human service account that triggers alerts	✅	Add to `RoarExclude` to avoid noisy alerts.
Temporary test account	✅ (short term)	Remember to remove when tests complete.
You need exclusions by department or tag	⚠️	Consider separate groups (e.g., `RoarExclude-Service`, `RoarExclude-Test`) and update metrics accordingly.
You require nested-group logic	⚠️	Validate `MemberOfStr` format; prefer direct membership where possible.

Use Liongard AI Query Companion to simplify RoarPath 🌟

If writing RoarPath queries is difficult or you want to iterate faster, try Liongard’s AI Query Companion (AI Assisted Query Builder). It can propose RoarPath expressions based on natural language prompts and show example outputs so you can validate quickly.

This is especially helpful for building exclusion filters like RoarExclude.

Summary 🤩

RoarExclude is a supported, partner-friendly method to exclude users from user-related actionable alerts and metrics.
It must be a Security Group named exactly RoarExclude. Users should be direct members to guarantee consistent exclusions.
Verify inspector runs and MemberOfStr contents when troubleshooting. Use the RoarPath !(contains(MemberOf, 'RoarExclude') pattern to apply exclusions.
Use AI Query Companion to speed up RoarPath creation and validation.

References 📚

Liongard Docs: Active Directory Inspector.
Liongard Docs: RoarPath Commands
Liongard Docs: How to Write a Custom Actionable Alert Rule.
Liongard Docs: How to Write a Metric.