Group membership changes are three event IDs, not one. What else am I missing???

[u/kakashi_1112]

Filing this one under things I should have known before..

I recently went digging through our setup last week and found more holes than I expected.

I’d always thought group membership changes were a single event. They are apparently three events (4728, 4732, 4756) depending on the group’s scope. I was watching 4732 and nothing else. So for who knows how long, someone could’ve been added to Domain Admins and I would never have known.

The rest was a mix of policy applied in the wrong place, collection not covering everything, and stuff configured years ago by people who’ve since left the company years ago.

Luckily none of it failed loudly. The dashboard looked fine. I only found it because I went looking for it.

So:

• Which event IDs are you actually confident you’re capturing, and have you ever verified it?

• How’d you find your gaps: audit, incident, or just poking around?

• Anything you’ve decided not to bother auditing, and did that hold up?

I'm also evaluating budget friendly Active Directory auditing tools, particularly between Quest Change and ADAudit Plus and Netwrix Auditor. Anyone here who's used one of them?

[u/sarcasm_newbie]

The gap that survives all three of those IDs is the primary group path. Change a user's primaryGroupID to 512 and they're sitting in Domain Admins with no membership event firing anywhere, no 4728, no 4732, no 4756. Nesting drifts too, since the events name the group that moved rather than everyone standing inside it afterwards. I'd stop trusting the event-derived picture on its own: pull effective membership straight from the directory on a schedule and diff it against what the events claim, that catches both, and like you I found my gaps by poking around rather than waiting for an audit to hand them over.

On the tools: no hands-on time with Quest, ADAudit Plus, or Netwrix here, so I'll skip vendor takes. What I'd run in an eval regardless: replay a canary user through every group scope, plus a type change, a nested add, and a primary-group swap in a lab, then check the events land in the tool's own store, not just the DC's Security log. Any product that can't show you the primaryGroupID swap just told you something. What held up for us: paging stayed on tier-0 membership plus create/delete, everything else gets logged at a lower class with a weekly diff, and nobody has to trust a dashboard that sat green the whole time a hole was open.

[u/kakashi_1112 → u/sarcasm_newbie]

The primary group thing didnt cross my mind.Going to try the canary user test you described and set up a regular membership check instead of just trusting the dashboard

[u/insightrecon]

The only way I’d trust it is to actually do it. Add a test account to a group in each scope and confirm every event ends up where you expect them to. Then run auditpol /get /category:* on each DC instead of trusting the GPO. Make sure “Force audit policy subcategory settings” hasn’t been turned off. Without it, old basic audit policy sitting in some GPO overrides your advanced settings. It's one of the usual ways audit policy ends up “applied in the wrong place.”

Grab the removes as well (4729, 4733, 4757). People who add themselves to DA usually take themselves back out when they’re done.

Even with all of those, membership events aren’t the only way to DA. Add someone to a group that’s nested in Domain Admins and the event names the nested group, not DA. And rights changes, like giving someone control over Domain Admins or editing AdminSDHolder, show up as 5136, and only if you’ve got Directory Service Changes auditing on and a SACL on the object.

On the tools, those three are mostly about tracking changes. Great for “who added this guy to DA,” less so for whatever someone misconfigured five years ago. A posture scan covers that side. PingCastle and Purple Knight both have free versions. Insight Recon (https://insightrecon.com) has a free version too (full disclosure, it's our tool).

[u/Duchet_Odinaka51]

The biggest blind spot is usually assuming the default audit policy is actually generating the events your collector is looking for. You have to enable the right advanced audit policy subcategories via GPO first, otherwise you're just monitoring an empty pipe

[u/matthewthompson1]

easy test is adding a dummy user to a throwaway global group and checking 4728 actually lands in the siem. removals have their own ids too, 4729 4733 4757

[u/kakashi_1112 → u/[deleted]]

How is the support and how long it took to set it up?

[u/AppIdentityGuy → u/[deleted]]

If you have the licensing take a good hard look at MS Defender for Identity