Log Dejargonizer

Windows Security Log · Event 4729

Event 4729: A member was removed from a global group

An account lost membership of a domain group. The part that catches people out is that it does not take effect straight away — an existing Kerberos ticket still carries the old membership until it expires, so the account keeps its access for up to ten hours.

Also written as Event ID 47294729 group removal

What it means for you

On a personal computer

This is a business network event and will not appear on a home PC.

For an analyst

Recorded on the domain controller that processed the change. The critical operational detail is ticket lifetime: group membership is baked into a Kerberos TGT when it is issued, so removing someone from Domain Admins does not revoke their current session. Until that ticket expires — ten hours by default — they still hold the privilege. During an incident, disable the account and revoke sessions rather than relying on a group removal.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
A member was removed from a security-enabled global group.

Subject:
  Security ID:    CORP\jbrooks-adm
  Account Name:   jbrooks-adm
  Account Domain: CORP
  Logon ID:       0x3E9A11

Member:
  Security ID:    CORP\svc-update
  Account Name:   CN=svc-update,CN=Users,DC=corp,DC=example

Group:
  Security ID:    CORP\Domain Admins
  Group Name:     Domain Admins
  Group Domain:   CORP

The fields that decide it

Everything else in the log line is context.

TargetUserName
The global group that lost a member.
  • Domain AdminsDomain-wide privilege being withdrawn. Confirm it was requested.
  • A group granting application accessRemoval here often surfaces as a user reporting something stopped working the next day.
MemberName
The account removed, written as a distinguished name.
MemberSid
The account's security identifier, which is what actually carried the access.
SubjectUserName
Who made the change.
SubjectLogonId
The session responsible. Join to the 4624 for the source address.

Ordinary reasons this happens

Most of the time it is one of these.

  • Offboarding, where group removal is part of withdrawing access.
  • A role change moving someone between teams and their associated groups.
  • Access reviews removing membership that could not be justified.
  • Identity management tooling enforcing a role model, which can produce these in bulk on a schedule.
  • Removing temporary privilege granted for a specific project.

When it is not ordinary

Removing an account added earlier in the same intrusion.

What gives it awayA removal shortly after the matching 4728, from the same session, with no change record for either.

ATT&CK T1070

Withdrawing the security team's own access.

What gives it awayRemoval of monitoring, security, or backup accounts from groups they depend on, which reduces visibility across the whole domain rather than one machine.

ATT&CK T1531

Locking out a competing administrator during an incident.

What gives it awayAn administrative account removed from Domain Admins by an account that has recently behaved unusually.

ATT&CK T1531

What to do next

  1. Check whether the same account was added recently — add then remove is the tracks-covering pattern.
  2. Confirm a leaver or change record exists.
  3. Remember the removal is not immediate. If this is an incident response action, disable the account and revoke its sessions too, or it retains the privilege until its ticket expires.
  4. Check whether the removed account belongs to security, monitoring, or backup tooling.
  5. Look at what the account did between being added and being removed, if both happened recently.
  6. For bulk removals, confirm whether identity tooling ran a scheduled reconciliation.

Queries to run

kql 
SecurityEvent | where EventID == 4729 | project TimeGenerated, Computer, Group = TargetUserName, Member = MemberName, RemovedBy = SubjectUserName | order by TimeGenerated desc
kql Domain privilege granted and revoked inside a day. Legitimate access changes rarely look like this. 
let added = SecurityEvent | where EventID == 4728 | project AddTime = TimeGenerated, Group = TargetUserName, Member = MemberName;
let removed = SecurityEvent | where EventID == 4729 | project RemTime = TimeGenerated, Group = TargetUserName, Member = MemberName, By = SubjectUserName;
added | join kind=inner removed on Group, Member | where RemTime - AddTime < 24h | project AddTime, RemTime, Group, Member, By
powershell Current membership, which is what matters when you are checking whether a removal actually happened. 
Get-ADGroupMember 'Domain Admins' | Select-Object SamAccountName, objectClass

Common questions

Does removing someone from a group take effect immediately?

No, and this surprises people during incidents. Group membership is written into a Kerberos ticket when it is issued, so an account with a current ticket keeps the old membership until that ticket expires — ten hours by default. To cut access now, disable the account and revoke its sessions rather than relying on the group change.

Why would an attacker remove a group membership?

Two reasons. If they added an account to a privileged group to do a job, removing it afterwards cleans up the evidence — and the removal is often the event that survives when the addition was missed. Separately, removing your monitoring or security accounts from the groups they need reduces what defenders can see, which is the point.

How do I find who removed an account from a group?

The Subject section names the account that made the change, along with its Logon ID. Join that Logon ID to the matching Event 4624 to find where they were signed in from. On a domain controller these events are low volume, so reading them all is practical.

Read next

Vendor documentation

Last reviewed 28 August 2026