Active Directory Privileged Group Monitoring: How to Alert When Someone Is Added to Domain Admins
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
The core monitoring requirement is simple: when an account is added to Domain Admins or any Tier 0 group outside of a documented change window, you need to know within minutes. The event exists in every Active Directory environment. The gap is almost always the alert -- either the event is not being forwarded to a SIEM, there is no analytics rule for it, or the alert goes to a queue no one monitors actively. This guide covers the full chain: verify audit policy, ensure events are forwarded, build the detection query, configure the alert, and document the expected baseline.
Verify Audit Policy Is Generating the Events
Event IDs 4728 and 4756 require 'Audit Security Group Management: Success' to be enabled in the audit policy. Verify: auditpol /get /subcategory:'Security Group Management' on a domain controller. The output should show 'Success' or 'Success and Failure' for the Security Group Management subcategory. If it shows 'No Auditing', enable it via GPO on the Default Domain Controllers Policy: Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy > Account Management > Audit Security Group Management = Success. After enabling, test by adding a test user to a test group on the DC and verifying Event ID 4728 appears in the Security event log. If you only see Event ID 4728 without the SubjectUserName and TargetUserName fields populated, verify that the account rights audit settings are correctly configured.
Define the Privileged Group Watchlist
Build a definitive list of all groups that should be monitored. Required minimum: Domain Admins (SID S-1-5-21-domain-512), Enterprise Admins (SID S-1-5-21-root-519), Schema Admins, Administrators (local admin on DCs), Backup Operators, Account Operators, Server Operators, Print Operators, DHCP Administrators (if present), DNS Admins (DnsAdmins). Also include custom Tier 0 groups specific to your environment: any group that has admin access to DCs, PAM vault admins, backup infrastructure admins, PKI admins. In Sentinel, create a watchlist called 'PrivilegedGroupSIDs' or 'PrivilegedGroupNames' with all monitored group names and SIDs. The analytics rule queries this watchlist so adding a new monitored group requires only a watchlist update, not a rule change.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Build the Detection Query
KQL for Sentinel to alert on additions to monitored groups: SecurityEvent | where EventID in (4728, 4756) | where TargetUserName in ('Domain Admins', 'Enterprise Admins', 'Schema Admins', 'Administrators', 'Backup Operators', 'Account Operators', 'Server Operators', 'DnsAdmins') | project TimeGenerated, EventID, Computer, SubjectUserName, TargetUserName, MemberName | extend Alert = strcat('ALERT: ', MemberName, ' added to ', TargetUserName, ' by ', SubjectUserName). For Splunk: index=windows EventCode IN (4728, 4756) Group_Name IN ('Domain Admins','Enterprise Admins','Schema Admins') | table _time, host, user, Group_Name, Subject_Account_Name, Member_Account_Name. Run this query on historical data first and examine the results: you will see any legitimate additions made during the lookback period. Document these as expected events and exclude them (or schedule the alert to only fire outside maintenance windows). The alert should fire within 5 minutes of event generation. Configure email + Teams notification.
Audit and Document the Baseline Membership
Alerting on changes requires knowing the correct baseline. For each monitored group, document every account that is currently a member, why they are a member, who approved it, and when it was last reviewed. PowerShell: Get-ADGroupMember -Identity 'Domain Admins' -Recursive | Get-ADUser -Properties Title, Department, Manager, Created, LastLogonDate | Select-Object SamAccountName, Name, Title, Department, Manager, Created, LastLogonDate, DistinguishedName | Export-Csv 'DomainAdmins-baseline.csv' -NoTypeInformation. Review the output: look for stale accounts (LastLogonDate over 90 days ago -- why is an account in Domain Admins that has not logged in for 90 days?), service accounts in Domain Admins (should never be there -- service accounts should use the minimum required permissions), contractor accounts that may have expired, and accounts with no documented business justification. Remove any account that cannot be justified. The baseline after this cleanup becomes the expected membership. Any future addition to that baseline triggers the alert.
Handle Legitimate Changes and Reduce Alert Fatigue
If your organization has a regular process for temporary Domain Admin grants (PAM just-in-time access, break-fix scenarios), implement a mechanism to suppress expected alerts: in Sentinel, create a watchlist of 'Expected Group Additions' that includes planned changes with a time window. Update the analytics rule to exclude entries in this watchlist. The workflow: before a planned Domain Admin grant, the change is logged in the ITSM with the account name, target group, and time window. The suppression watchlist is updated. The alert fires but is automatically closed by Sentinel matching it to the planned-change watchlist entry. Unexpected alerts (no matching watchlist entry, or an alert outside the planned time window) are the true positives. Also alert on Event ID 4729 and 4757 (member removed from group) for privileged groups -- unexpected removals may indicate an attacker covering tracks by removing accounts they added in a prior session, or a lockout scenario where a Domain Admin was removed.
The bottom line
Privileged group monitoring is a 2-hour configuration task with immediate, permanent security value. Verify the audit policy generates Event IDs 4728 and 4756, forward them to your SIEM, write the detection query, configure a P1 alert, and document the baseline membership. Once live, every unauthorized Domain Admin addition generates an alert within minutes. Review the baseline membership quarterly and remove all accounts that cannot be justified.
Frequently asked questions
What is the difference between Event ID 4728 and 4756?
Event ID 4728 fires when a member is added to a global security group. Event ID 4756 fires when a member is added to a universal security group. Domain Admins is a global security group (4728). Enterprise Admins is a universal security group (4756). Monitor both event IDs to cover all group types. There is also Event ID 4732 (member added to a local security group) which applies to the local Administrators group on servers -- monitor this for server-level admin access. To cover all three types in one query, use: EventID in (4728, 4732, 4756).
Does Microsoft Defender for Identity detect Domain Admins modifications?
Yes. MDI has a built-in alert for 'Suspicious additions to sensitive groups' that fires when an account is added to Domain Admins, Enterprise Admins, and other protected groups. It also applies machine learning to baseline expected modification patterns and flags deviations. MDI alerts appear in the Microsoft 365 Defender portal and can be integrated with Sentinel. If you have MDI deployed, you already have this detection -- verify it is configured and the alert severity is set appropriately. For environments without MDI, the Event ID 4728/4756 SIEM query is the fallback.
Should I also monitor nested group membership?
Yes. Domain Admins membership can be achieved by adding an account to a group that is nested inside Domain Admins. Event ID 4728 fires when the account is added to the nested group, but the TargetUserName will be the nested group name, not 'Domain Admins'. To detect this, also monitor additions to any group that is nested inside your Tier 0 groups. Use the PowerShell function Get-ADGroupMember with -Recursive to identify all nested groups, add them to your watchlist, and monitor additions to those groups as well.
How often should Domain Admins membership be reviewed?
Quarterly at minimum; monthly for high-risk industries. For every member: verify they still need Domain Admin access (role change, employment status), verify the account is actively used and not stale (LastLogonDate), verify MFA is enrolled and enforced for that account, and verify the account uses a dedicated admin account (not the personal daily-use account). The alert-on-change monitoring catches unauthorized additions in real time; the periodic review catches members who were legitimately added but no longer need the access.
What is the AdminCount attribute and how does it relate to privileged group membership auditing?
AdminCount=1 is stamped on accounts that are or were members of protected groups (Domain Admins, Enterprise Admins, Schema Admins, and others controlled by AdminSDHolder). SDProp sets AdminCount=1 and copies the AdminSDHolder ACL to these accounts. The attribute is NOT automatically cleared when an account is removed from a protected group -- accounts that were temporarily added to Domain Admins for a project and then removed still have AdminCount=1 indefinitely. This creates a population of accounts with AdminSDHolder-derived ACLs that are not reflected in current group membership. Audit accounts with AdminCount=1 that are NOT currently in any protected group: these orphaned AdminCount accounts have the restricted ACL but are invisible to group membership monitoring.
How do you configure real-time alerting for changes to Domain Admins, Enterprise Admins, and other Tier 0 groups?
Real-time alerting requires capturing Event ID 4728 (member added to security-enabled global group) and Event ID 4756 (member added to security-enabled universal group) in the Security log on domain controllers, then filtering to the specific Tier 0 group SIDs. In Microsoft Sentinel, create a scheduled analytics rule on SecurityEvent where EventID in (4728, 4756) and TargetSid in the list of protected group SIDs -- query Active Directory for protected group SIDs using Get-ADGroup to populate this list. Microsoft Defender for Identity raises the 'Sensitive group membership change' alert natively without requiring custom Sentinel rules. For on-premises SIEM without MDI: configure audit policies on DCs to capture 'Account Management' events, forward to SIEM via Windows Event Forwarding, then create correlation rules for membership changes to the specific protected group Distinguished Names. Alert severity should be Critical -- any production-hours addition to Domain Admins is expected to be rare (0-1 per quarter in mature environments) so alert fidelity is high without tuning.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.