Chapter #1 - AdminSDholder: the guardian
When a 25‑year‑old Active Directory mechanism still shapes modern security and identity
Versione italiana disponibile qui → [IT]
December 15th, 1999.
The world is living through a strange mix of excitement and tension.
In Italian cinemas, The Green Mile is on screen. In the United States, people debate Fight Club and are shocked by the ending of The Sixth Sense.
On the radio, “Move Your Body” by Eiffel 65 plays nonstop, while “Mambo No. 5” by Lou Bega echoes across Europe.
But deep inside the IT world, attention is focused elsewhere.
Sixteen days remain before the turn of the millennium. The IT industry is holding its breath for the Millennium Bug, fearing that systems written decades earlier may fail when the date flips to January 1st, 2000.
In this climate of uncertainty, Microsoft releases Windows 2000 RTM, an operating system that breaks with the past and makes everything before it feel suddenly outdated, thanks to the introduction of Active Directory.
And the guardian is already there: AdminSDHolder is a native component, designed as an internal line of defense for the directory’s most critical mechanisms. It cannot be stopped or disabled. It can only be understood.
What It Is and How It Works
AdminSDHolder refers to one of the most important — and most forgotten — protection mechanisms in Active Directory.
Its goal is simple: to protect the most privileged accounts and groups in the domain, preventing incorrect permissions or overly permissive delegations from compromising them, either accidentally or intentionally.
In simple terms: to avoid locking yourself out of your own house — or letting someone else do it for you.
To achieve this, Active Directory adopts a rigid and intentionally non‑negotiable approach, documented in Microsoft’s official guidance on protected accounts and groups.
Within every Active Directory domain, there is a special object called AdminSDHolder, located in the System container.
This object is not a user or a group. It is a branch of Active Directory that contains a security template.
More precisely, its security descriptor (ACL) defines the standard permissions that must be enforced on all objects considered critical.
In other words:
AdminSDHolder is the template
the objects to be protected are the targets to which the template is applied
Whenever Active Directory detects a discrepancy between the template and a target object, it intervenes to restore the correct state. But how?
The entire mechanism is driven by an internal “engine” called SDProp (Security Descriptor Propagator).
SDProp is triggered on the Domain Controller holding the PDCE (Primary Domain Controller Emulator) role. It does not act in real time; instead, it performs a control cycle with a default interval of 60 minutes, which can be customized via a registry key.
During this cycle, it works like a guardian: if it finds something out of place, it brings it back to the expected state.
But which objects need to be protected?
The determining factor is membership in built‑in groups that hold a minimum level of privilege within the Active Directory environment. Here is the complete list:
Account Operators
Administrator
Administrators
Backup Operators
Domain Admins
Domain Controllers
Enterprise Admins
Enterprise Key Admins
Key Admins
Krbtgt
Print Operators
Read‑only Domain Controllers
Replicator
Schema Admins
Server Operators
All of these groups and their respective members are subject to the AdminSDHolder template.
Note:
By “members” we mean both direct membership and indirect membership through group nesting, which can sometimes make it difficult to identify which objects fall within scope.
This explains one of the most frustrating behaviors for those unfamiliar with the mechanism:
“I set permissions on the objects, everything works… and an hour later they’re gone.”
But how is the template actually applied?
In an intentionally aggressive way: Active Directory assumes that no standard delegation should ever have control over these objects.
When an object falls within scope, three fundamental things happen:
1. Permission inheritance is disabled
The object stops inheriting ACLs from its parent OU.
This means that delegations configured at the OU level no longer apply.
2. AdminSDHolder permissions are applied
The object’s ACL is aligned with the template, regardless of where the object is located in the directory structure.
3. The adminCount attribute is set
The
adminCountattribute is set to 1, indicating that the object is (or has been) protected.This attribute, however, is not automatically reset when the object is removed from privileged groups, often leading to confusion and paradoxical situations.
The last thing to remember is that this mechanism cannot be disabled.
Its dynamics must be clearly understood in order to properly design IT processes that interact with Active Directory — especially those that rely on specific ACLs.
What Can Go Wrong
Now that we understand how the mechanism works, we get to what I personally find the most interesting part: seeing what can go wrong when these mechanisms are not fully understood.
To do that, I found it effective to bring in real‑world cases taken directly from the field.
Real Case #1 – The Group You Don’t Expect
We are in the middle of a complex migration project in a classic hybrid environment: Active Directory + Entra ID.
There is:
a source AD domain with source users
a target AD domain with target users
Entra Connect configured to work with both domains and synchronize everything to Entra ID
Only the source users are currently synchronized.
The goal is as clear as it is ambitious: detach the source users and attach the target users, without any impact on the cloud.
For those who have never been involved in a project like this, I’ll restate my point of view: migrating resources in a modern hybrid environment is a balancing act.
Every single aspect must be aligned with absolute precision — otherwise, failure is almost guaranteed.
As soon as the migration procedure is prepared, the first problems emerge: more than half of the users show inconsistent attributes between on‑premises and cloud.
At a quick glance, Entra Connect reports recurring errors: permission-issue.
First check: the permissions of the Entra Connect service account, as suggested by this official article.
Nothing unusual at first glance.
Digging deeper, however, a curious detail emerges: all the users affected by the issue have one thing in common: from a certain point onward, new users are being created with an “unexplained” membership > Print Operators.
That detail changes everything: Print Operators is one of the protected groups in Active Directory.
Becoming a member automatically places the object within the AdminSDHolder scope, with inheritance disabled, permissions rewritten by SDProp, and ACLs that no longer follow the OU structure.
A mechanism designed 25 years ago was blocking the correct data flow to the cloud.
The solution turned out to be anything but straightforward:
review of provisioning mechanisms
removal of incorrect group memberships
restoration of correct permissions on hundreds of user accounts
realignment with the cloud
In short, a significant effort across multiple fronts — one that could have been avoided from the start with a bit more awareness in the design of provisioning flows.
In this case, poor AdminSDHolder was not blocking the migration at all.
It was simply doing its job, protecting accounts that should never have been treated as privileged in the first place.
Real Case #2 – When Security Meets Legacy
Another customer, another hybrid environment: Active Directory + Entra ID, with Entra Connect properly configured.
This time, however, the context is different: a stable environment, with no migration in progress.
A User Maintenance solution is introduced, with two clearly defined goals:
notify users of upcoming password expiration, allowing them to change it from Entra ID using password writeback to Active Directory
automatically disable user accounts for which no activity is detected, either on‑premises or in the cloud, for a given period of time
All of this is implemented in strict compliance with the Principle of Least Privilege (POLP).
A Service Principal is created for Entra ID and a GMSA for Active Directory.
Only the strictly necessary permissions are assigned to the service accounts (POLP).
The solution is configured, tested, and put into production.
Everything is designed and implemented according to modern security standards, and at first, everything appears to be working correctly.
After a short time, however, the first problems begin to surface:
some users are unable to change their passwords
others cannot be automatically disabled
At this point, the analysis focuses where experience has taught us to look:
permissions on the affected accounts, AdminSDHolder, and SDProp.
What emerges is a situation that is less rare than one might expect.
There are users who previously belonged to protected groups, but were later removed from them, leaving behind an inconsistent configuration: objects that are no longer privileged, yet still have adminCount = 1, permission inheritance disabled, and the AdminSDHolder template applied.
In this specific case, the root cause was identified in the use of dynamic assignments to privileged groups, based on Just‑In‑Time Administration, still fully compliant with POLP.
A correct choice from a security standpoint — but one that failed to account for the persistent effects of AdminSDHolder on the affected objects.
On paper, the solution might have seemed simple: clean things up and move on.
In reality, it turned out to be more complex than expected due to additional implications.
The first issue was that, to allow the User Maintenance solution to function correctly, it became necessary to assign permissions directly on the AdminSDHolder template to the service account.
This was required to enable the manipulation of objects that had become “stuck” in a permissions limbo.
Once again, a small detail completely changes the scenario.
This has a significant impact from a security perspective: the system running the solution effectively becomes a critical asset, which must be treated as Tier 0 according to the AD Tier Model, with all the associated implications in terms of hardening, access control, and segregation.
For these aspects, I refer you to the excellent article by my friend Stefano Nieri.
Finally, it is important to realize that even all of this is not sufficient on its own to fully resolve the issue: objects stuck in this limbo are still excluded from subsequent SDProp cycles.
This allows them to “bypass” the new permission set that would otherwise enable the solution to work correctly.
The only way to resolve the situation is an ad‑hoc cleanup, aimed at bringing the environment back to a stable state.
After reviewing the entire setup:
a password reset in the cloud is correctly propagated to Active Directory
a user who has not accessed either the cloud or on‑premises for a long time can be properly disabled
Once again, this is not a case of incorrect configuration.
It is the result of the interaction between legacy mechanisms and modern security requirements, whose design — if treated lightly — can lead to misleading results.
Hybrid environments, therefore, with today’s required security standards, are intrinsically more complex than cloud‑only environments.
In this case as well, greater awareness during the design phase would have made it possible to set things up correctly from the start, avoiding costly corrective actions later on.
Lessons learned from the Guardian
AdminSDHolder is a perfect example of how a “gear” that has been running under the hood for more than twenty years can be forgotten: it requires no maintenance, generates no alerts, and makes no noise.
And yet, the result of its work is always present — even, and especially, in modern cloud‑oriented environments.
The first lesson the guardian teaches us is simple, but often underestimated:
ignoring a mechanism does not make it harmless.
AdminSDHolder continues to do exactly what it was designed to do, enforcing security rules meant to protect the foundations of Active Directory — even when, on top of those foundations, we build automation, cloud integrations, and “modern” processes.
The second lesson is that doing things correctly is not always enough if there is no awareness of what happens underneath.
In the cases we’ve seen, there were no improvised configurations or neglected environments.
There were planned migrations, least‑privilege principles, Just‑In‑Time administration, and solutions designed according to current security standards.
And yet, without understanding the persistent effects of AdminSDHolder, even correct choices produced unexpected results.
The guardian also teaches us that legacy in systems is not always visible, but sooner or later, it comes back to collect its due.
Users who once belonged to privileged groups, attributes like adminCount that were never reset, broken permission inheritance — these are elements that can remain latent for years, until a new project, a new integration, or a new security requirement suddenly brings them to light.
When that happens, the problem does not manifest as a clear error, but as a “strange” behavior that is difficult to interpret, hard to diagnose, and often far more expensive to fix than expected.
Finally, there is a broader design lesson: in hybrid environments, complexity is not an exception — it is the norm.
Cloud and on‑premises are not separate worlds, but parts of the same system.
Rules from the past continue to influence the present, and designing modern solutions without knowing them simply means pushing problems further down the road.
It is precisely from this awareness that Legacy Things was born.
AdminSDHolder is not an isolated case, but only the first of many “old gears” that continue to operate beneath the surface of today’s infrastructures.
In the next chapters, we will explore other legacy mechanisms — other design choices from the past that still shape how we build, protect, and evolve our systems today.
And to you, who made it all the way to the end of this first chapter, I ask:
which hidden mechanisms would you like to see brought into the light next?