Who Added This User to Domain Admins? How to Find Out in Seconds

You open Active Directory Users and Computers and notice an account in Domain Admins that you don't recognise. Today it was Henry Allen, a sales engineer. Nobody on the team remembers adding him, and the questions arrive at once. Who did it? When? From which machine? Was it approved? And what else has that person changed?

It is one of the most common questions Active Directory admins ask, and it keeps coming up on Microsoft Q&A, from getting an email when a privileged group changes to knowing when users are added to a security group. Membership of Domain Admins gives full control of every user, computer, group and policy in the domain, so an unexplained new member is either an honest mistake or the first sign of an attack. Either way, you need the answer in minutes, not after an afternoon of digging.

Why the built-in tools make this hard

Windows does record group membership changes, but turning those records into an answer is where teams get stuck:

There is no single place to look. The change is written to the Security log of whichever domain controller handled it. With several domain controllers, and often more than one forest, you first have to find the right one.
The evidence may already be gone. Security logs have a size limit and overwrite their oldest events. On a busy domain controller, last week's change can be overwritten long before anyone goes looking.
Nothing is captured if auditing is off. Group changes are logged only while the right audit policy is enabled on your domain controllers. If it is off on a domain controller, that domain controller keeps no record of the change.
Privileged groups don't all log the same event. Domain Admins, Enterprise Admins and the built-in Administrators group record membership changes under different events, so watching for one quietly misses the others.
You only get half the story. The membership event names the account that made the change, but not the workstation or IP address it came from. Finding the source means matching it to a separate logon event by hand.
Nobody is told when it happens. Windows does not raise an alert when a privileged group changes. Unless you have built your own alerting, you find out by chance, often weeks later.
The log doesn't tell you what the change means. It records that a member was added, not that a sales account now controls the whole domain, how many other accounts sit in the same group, or whether this admin has been doing it all week.

Active Identity Guardian collects these changes from your domain controllers continuously, keeps them in one searchable audit trail and checks what each change does to your exposure. Here is the same question, answered in the demo.

Find who added the user to Domain Admins

1Search the audit trail for the group

Open Audit Events and search for Domain Admins over the last 7 days, or click the Privileged group changes scenario. Every change to the group, from every domain controller in every forest, appears in one list with the newest first.

Audit Events in Active Identity Guardian, searched for Domain Admins over the last 7 days, showing eight changes with who made each one and from which workstation — 1 Search for the group. 2 Today's change, scored risk 10: Sam Wright added Henry Allen to Domain Admins at 10:45 from workstation FB-ADM-04. The panels above the list already show who has been changing the group and from where.

Two things stand out before you click anything. Every Domain Admins change carries the highest risk score, and some are flagged New IP for actor, meaning the admin made the change from an IP address not previously seen for them.

2Open the change to see who, when and where

Click the row. The summary answers the original question in one view: the account that made the change, the domain controller that recorded it, the source IP and workstation, how the admin connected, and the membership value before and after.

The audit event detail: event 4728 on FB-DC-02.fabrikam.com, changed by FABRIKAM\sam.wright from 10.20.5.23 on workstation FB-ADM-04, adding CN=Henry Allen to Domain Admins — 1 Who made the change and from where: FABRIKAM\sam.wright, IP 10.20.5.23, workstation FB-ADM-04, over a network connection such as Active Directory Users and Computers. 2 The member that was added.

The workstation and IP are already joined to the change, so there is no hunting through logon events to work out where it came from. Show all by user lists everything else Sam Wright has changed, which is usually the next question.

3Check what else has happened to the group

The History tab shows every recorded change to Domain Admins, newest first. In the demo it shows six additions in a week, four of them by the same admin from the same workstation. A single addition may be routine. A pattern like this deserves a conversation.

The History tab for Domain Admins, listing six membership changes in the past week with the admin and workstation behind each — The group's change history: who added whom, when, and from which workstation.

See the risk the change created

Knowing who made a change is half the job. The other half is knowing what it means for your security. Active Identity Guardian re-evaluates the directory against its exposure rules on a schedule (every 30 minutes in the demo), so the new membership doesn't sit unnoticed.

4The new exposure appears on its own

At the next evaluation, 17 minutes after the change, Henry Allen appeared under Exposures with a critical User in Domain Admins finding. It is open and unassigned, ready for someone to take ownership and set a due date.

The exposure finding for Henry Allen: critical, risk 10, User in Domain Admins, first seen at 11:02 on the same day, status open and unassigned — 1 First seen at 11:02, 17 minutes after the change. 2 The rule it breaks: User in Domain Admins, critical.

5Check exactly why it was flagged

The Evidence tab shows the attribute the rule matched and a snapshot of the account at the moment it was detected, so the finding can be checked rather than taken on trust.

The Evidence tab: why it matched, memberOf contains CN=Domain Admins, with a snapshot of Henry Allen's account — 1 Why it matched: Henry Allen's `memberOf` now includes Domain Admins.

6Review every Domain Admins member in one place

Expand the User in Domain Admins rule to see every flagged member across all your forests, with owner and status for each. The rule also explains the risk, maps it to MITRE ATT&CK, NIST and CIS, and comes with a runbook and verification steps.

The User in Domain Admins rule expanded: a description mapped to MITRE ATT&CK, CIS and NIST, and a table of 13 flagged accounts with status and owner — 1 Thirteen accounts flagged across both forests, each with an owner and a status, so the clean-up can be tracked.

7Get told next time

Under Settings > Notifications, findings can be sent to email (SMTP or Office 365) and Microsoft Teams. Set the finding scope to All findings and keep a finding is detected for the first time ticked, and the next unexpected Domain Admins member reaches your inbox or Teams channel after the next evaluation, instead of weeks later.

Settings, Notifications: alerts to email over SMTP or Office 365 and to Microsoft Teams, with a finding scope and a choice of when to notify — 1 What is sent and when: choose **All findings** to include exposures such as a new Domain Admins member. 2 Where it goes: email or Microsoft Teams. (The demo is read-only, so these settings can't be changed there.)

What to do next

Confirm the change. Ask the admin who made it, and check it against a change request. Now you know who, when and from where, that is a short conversation.
Remove what isn't needed. If the membership wasn't approved, take the account out of Domain Admins and review what it could reach while it was there.
Keep the group small. Day-to-day user accounts shouldn't hold domain-wide admin rights. Use separate administrative accounts and grant the narrowest rights that do the job.
Make it someone's job. Assign the finding an owner and a due date, so it is tracked to closure instead of forgotten.

Summary

A new Domain Admins member is recorded only on the domain controller that handled the change, and often without the machine it came from.
In Active Identity Guardian, one search shows every change to the group across all domain controllers and forests, with who, when, the source IP and workstation, and before-and-after values.
The same change raises a critical exposure at the next evaluation, so the risk is tracked with an owner until it is fixed, and notifications can send it straight to email or Microsoft Teams.