The Group That Kept Disappearing: Privileged Group Housekeeping in AD

September 16, 2026 · InfraScout Team

A per-server local-admin group vanishes from Active Directory, comes back, and vanishes again. Nobody deleted it by hand, and the automation that should manage it reports nothing useful. Hand the problem to InfraScout in a chat, and you end up with the full chain of causes, a documented map of which automation does what, delegation narrowed to exactly what the job needs, and a change ticket that describes it all.

The scenario below is a composite of a common pattern. The environment is a tiered AD: a Tier-0 admin area, one local-admin group per Tier-1 server, hybrid sync to Entra ID, and a scheduled Azure Automation runbook that calls a JEA endpoint on a domain controller to create and clean up those server groups.

The question you ask

Start with what you know and set the boundaries up front.

Our scheduled job that creates and removes per-server admin groups calls a JEA
endpoint on a domain controller. Check that the endpoint exists, tell me what it
exposes, and find out why the job fails. Stay read-only and ask me before any change.

The endpoint name you remember doesn't exist, so the AI listed every session configuration on the domain controller and surfaced a near-match. It then read the role capability file and the module behind it, and summarized the exposed functions, the virtual account the endpoint runs as, who is allowed to connect, and where transcripts are written.

One protected object, weeks of failed runs

The job failed with "Access is denied" at a specific line of the module. The AI read that line, checked how the virtual account was configured, checked delete permissions on the target objects, and then went to the JEA transcripts. Those gave per-run evidence the job's own output never had: every cleanup run for weeks had stopped on the same computer object, a cluster name object with accidental-deletion protection turned on.

The fix was a delete, so the AI stopped and showed a plan: the object's attributes, why it was stale, and the fact that protection had to be cleared first. You approved. The first attempt used the wrong cmdlet and printed output that looked like success. The AI caught the real error in stderr, corrected the command, verified that the object was gone, and logged the change. The next scheduled run completed cleanly.

Two automations in a loop

The cleanup job was fixed, but the group still disappeared. The AI correlated group deletion and creation events on two domain controllers with the JEA transcripts and saved the timeline as an insight. The pattern was clear: the cleanup job deleted the group, and a second automation, an identity-management system, recreated it shortly afterward. The two automations disagreed about which servers were valid, so they kept undoing each other's work.

The reason was in the module source. Its filter for valid servers relied on the operatingSystem attribute, and that attribute was empty for a set of Linux hosts joined to the domain. To the cleanup job, those servers didn't exist, so their admin groups looked like orphans.

Mapping the automation end to end

The next question was which runbook actually creates the groups. Using the Microsoft platform tools, the AI enumerated subscriptions and Automation accounts, found the runbook, compared its draft and published versions, and traced the published code to the JEA function it calls. It saved that runbook-to-function logic as baseline memory, so the next conversation starts from the map instead of rediscovering it.

Follow-up questions got answers from the code first and then from the directory. Is there an exclusion group? The code showed how exclusions work. Can the domain-join delegation group write operatingSystem? The ACL analysis showed it could not. The attribute belongs to no property set, so none of the existing rights covered it.

Changes you approve, verified afterward

The AI first found where the domain-join delegation actually lives: once, at the domain root, inherited downward. It proposed adding the attribute-level permission there rather than duplicating delegation on every OU. You approved the exact change, and the AI applied it and verified that it was inherited where expected.

Then you steered the design. Instead of widening an existing group, you asked for a dedicated service account and group with create and delete rights on the server admin groups' OU. The AI checked the existing naming and OU conventions, proposed a plan, and waited for approval. The first create failed on the 20-character limit for a user's sAMAccountName. The AI removed the partially created objects, retried with a compliant name, and verified the result.

Last came the paperwork. With a ticketing MCP server connected alongside InfraScout, the AI drafted a change ticket and asked for the ticket type and assignee instead of guessing. When you corrected the stated purpose of the new account, it rewrote the ticket, the memory entry, and the insight so all three records agreed.

One finding stayed open on purpose. The scheduled job's virtual account carries broad privileges on a domain controller. The AI recorded that as an open insight for a separate decision instead of quietly changing it.

A side note: add a user and push it to Entra now

A separate chat asked to add a user to a group and make the change visible in Entra ID right away. The AI verified the user and group with read-only queries, presented the plan, and waited for explicit confirmation. It then added the member, triggered a delta sync on the sync server, and polled until the cycle finished. Finally it used the identity tools to confirm the membership and the last-sync timestamp in the cloud. When you asked to roll it back later, the rollback followed the same plan, confirm, execute, verify sequence.

TIP

A completed sync cycle doesn't prove the change arrived. Always verify the object in Entra ID itself, including the tenant's last directory sync time, before you tell anyone it's done.

Reusable knowledge

Most of what came out of this investigation applies to any tiered AD with automation in it.

Tiering and JEA

Keep per-server local-admin groups in a Tier-1 OU and keep delegation groups and service accounts in Tier-0. Delegate to groups, not individual accounts. Get-PSSessionConfiguration lists JEA endpoints, and role capabilities live in .psrc files. A virtual RunAs account is a temporary local administrator, which on a domain controller means domain-admin-equivalent. JEA transcripts give you per-run evidence when a job's own output doesn't.

Directory events and sync

Group events are logged on the domain controller that processed the change, so query every DC. Event 4727 and 4730 record creation and deletion of a security-enabled global group, and 4731 and 4734 do the same for a domain local group. For an Entra Connect delta sync, run Start-ADSyncSyncCycle -PolicyType Delta, poll until the cycle finishes, and then verify in the cloud.

Permissions and attributes

Clear accidental-deletion protection with the generic Set-ADObject -ProtectedFromAccidentalDeletion $false. An attribute that belongs to no property set needs its own ACE on the attribute's schemaIDGUID, scoped to the object class. A user's sAMAccountName is limited to 20 characters, even though its CN can be longer. A filter on operatingSystem misses every object where that attribute is empty, which includes some Linux domain joins.

Where you stay in control

The work spanned four sessions over about six weeks, each from half an hour to three hours, in place of several hours of reading logs, module source, and ACLs by hand. Every session followed the same rules. The AI read first. Before every write, whether a membership change, a delete, an ACL entry, or a new account, it showed a plan, waited for explicit confirmation, and verified the result. It trusted stderr over output that only looked like success, cleaned up after a failed create, and recorded the risk it didn't fix instead of fixing it silently. Tool annotations and roles explain how read-only and state-changing tools are kept apart.

Next steps

Check what your domain controller agents can run in Agent tools, and see which cloud identity and platform data the AI can verify against in Microsoft identity tools. To carry findings and baselines across sessions, read Insights and Memory.