0 (Zero) Admin Model

A Crazy Idea?
Neuron Fight Result - An Idea
Real-World Delegation Examples
What Would I Do Next
What We Can Achieve by Having a 0 Admin Model
Implementation Challenges & Considerations
Further Reading & Resources

A Crazy Idea?

0 (Zero) Admin Model in your production environment? Personally, I don't think is crazy. First thing to check when running a security audit, is the number of privileged users. Remember that a privileged user is a member of either Enterprise Admins, Domain Admins or Administrators group. The fact is that more members these groups have, the less secure is our environment. So why not to run our domain without a single user in these groups?

At this moment you must be thinking "how? Admins run many different tasks against Active Directory. No admin means that those tasks will not be complete" - well, this last statement is not true. Active Directory is extremely granular when dealing with delegations.

Key Insight: Delegation Over Permission

The fundamental principle of the 0 Admin Model is that delegation is more granular than broad admin permissions. Active Directory allows you to delegate specific tasks to specific groups on specific organizational units (OUs), giving you precise control without requiring full admin rights.

First things first: a delegation is when a privileged user grants a permission and/or right to an identity. There are some default inherited permissions, like self-password change, just to mention one. Then the idea is to delegate as much as possible, so at the end the administrators or any other built-in group are not needed in our setup. The delegations are those specific things that only an administrator can do.

Privileged users should not be more than 2 (the mighty Administrator, and one additional safeguard account) and Semi-Privileged users should not be more that 2% or 3% of the total objects of the environment. What we are suggesting in this post, is to have all minus one (the built-in Administrator, and additionally a backup administrator) users as Semi-Privileged; this means that all the tasks involving a change to AD must be previously delegated to the different users and/or groups who manage and operate the environment.

The 0 Admin Model Goal

Maintain only 2 privileged accounts (Administrator + backup) with the vast majority of operational users as semi-privileged with specific, delegated rights. This dramatically reduces the attack surface while preserving full operational capability.

Neuron Fight Result - An Idea

To begin with, the Administrator has all possible rights and permissions. From here, there are 2 possibilities:

Continue using the Administrator benefits (terrible idea!)
Have the Administrator to delegate specific tasks to separate groups.

Of course, we will go for the second option. The idea is to create a Delegation Model that will cover all the tasks that an administrator can do. By doing this, we will be able to remove all the users from the privileged groups, and assign them to specific groups with specific delegated rights.

Let's take for example the user management team. They are responsible to create new users objects for onboarding personnel, maintain those objects and decommission accordingly when no longer needed. Of course admins can do this task. And Account Operators can also - well, yes, but as mentioned earlier, admins have to much power just to use them for this purpose; account operators could do the job, but there are 2 small issues to consider:

This group is a protected group (without going into details, AD manages security of this group and all its members, so any security setting might not work as you wish it would)
By default, this group can also manage semi-privileged accounts, something that goes against the proposal itself. Only admins should have this right. Even better, a specific purpose delegated group that can only manage the Semi-Privileged accounts.

So, the idea is to create a new group, let's call it User Managers. This group will have the right to create/manage/delete users on a specific container or Organizational Unit (OU). The Admin will delegate this right to the User Managers group. The members of this group will be the user management team. By doing this, we can remove all the members of this team from the Admins and Account Operators groups.

In this scenario, the Admin will delegate the right to create/manage/delete users on specific container or Organizational Unit. By doing this, we can stop using the Built-In Account Operators group. Even more, we could delegate to 2 separated groups, so one group could manage South users, and the other one could take care for the North ones.

Now that we have a clear idea, lets try to see the big picture. I suggest to start with the most common object classes: User Class, Group Class and Computer Class.

Real-World Delegation Examples

The 0 Admin Model becomes practical when you understand specific delegation scenarios. Here are real-world examples of how to delegate common administrative tasks without requiring full admin privileges:

User Management Delegation

Scenario: Your HR team needs to manage user accounts (create, modify, disable, reset passwords) for employees in the Sales OU, but only in that container.

Solution: Create a group called Sales_User_Managers and delegate to this group the following rights on the Sales OU:

Create and delete User objects
Reset user passwords
Modify user properties (phone, email, title, manager, etc.)
Unlock user accounts
Modify group memberships (for non-privileged groups only)

Benefit: Your Sales HR representatives can fully manage their user lifecycle without ever touching privileged groups or gaining domain admin rights. Audit logs clearly show who made what changes.

Group Management Delegation

Scenario: Different departments need to manage their own distribution lists and security groups for resource access, but shouldn't create privileged groups.

Solution: Create department-specific groups like Finance_Group_Managers, IT_Group_Managers, etc., and delegate the right to:

Create and delete groups within their department OU
Modify group membership
Change group properties (description, email, etc.)

Constraint: Use filtering to ensure they cannot modify groups with "Admin", "Privileged", or "Executive" in the name.

Benefit: Department managers maintain their access control autonomously while preventing accidental or malicious modification of sensitive groups.

Computer Management Delegation

Scenario: Your IT support team needs to manage computers in the Workstations OU (join to domain, reset computer accounts, manage BitLocker), but shouldn't have admin rights on those computers.

Solution: Create a group called Workstation_Admins and delegate:

Create, delete, and modify Computer objects in the Workstations OU
Reset computer accounts
Modify computer properties (description, location, etc.)

Benefit: Support staff can provision new machines, troubleshoot domain join issues, and manage computer lifecycle without needing local admin access to individual machines.

Password Reset Delegation (Limited Scope)

Scenario: Your help desk needs to reset user passwords without seeing them or modifying any other user properties.

Solution: Create a group called HelpDesk_Password_Reset and delegate only the "Reset Password" right on specific user OUs (e.g., Sales Users OU, Finance Users OU).

Constraint: Explicitly exclude privileged users and semi-privileged user OUs from this delegation.

Benefit: Help desk staff can resolve password lockouts for end users without the ability to make any other changes or see sensitive user configurations.

Organizational Unit (OU) Delegation

Scenario: You want to allow specific teams to manage the structure and policies within their OU hierarchy without being able to modify other OUs.

Solution: Create a group called Sales_OU_Managers and delegate:

Create and delete OUs within the Sales OU
Link and unlink Group Policy Objects (GPOs) to OUs they manage
Modify OU properties

Scope Limitation: This delegation applies only to their specific OU tree, preventing cross-team impact.

Benefit: Each business unit maintains its own organizational structure and policies autonomously while remaining isolated from other departments.

Delegation Pattern

Notice the pattern: Create specific groups → Grant granular rights → Scope to specific OUs or object types → Exclude sensitive objects. This approach scales across your entire organization while maintaining security boundaries.

What Would I Do Next

Some months ago, I blog on "Segregation of Duties", which mainly deals on splitting and separating permissions and rights. To avoid using all the power an Administrator has, we have to create specific-tasks delegations. Is going to be a very challenging process just to remove the users from the Admin group; instead we have to provide the "Least Privileged Access" to the user so she can complete its tasks, and afterwards remove it from the Privileged group.

Critical Implementation Step

Removing users from the Admin group is the final step, not the first. Before removing any privileged user, ensure all their operational tasks have been delegated to appropriate groups and thoroughly tested. Premature removal can cause operational disruption.

Certainly, there are some specific tasks that cannot fit into the delegation. Those can be promoting or demoting a Domain Controller, or creating a new domain DFS namespace, to name some. But this does not mean that the user should be part of a Privileged group. A process should be developed and implemented so whoever needs the access, first gets authorization, and then granting temporary rights to perform specific task. This can be accomplish by providing the credentials of the second Admin account (the lifesaver account) and automatically reset the password after predefined elapsed time. Other approach would be to use a PIM solution (Privileged Identity Management).

Exception Handling: When Temporary Privilege Is Needed

Not all tasks can be delegated. Tasks like Domain Controller promotion, forest recovery, or schema modifications require full admin rights. For these exceptions, implement a Just-In-Time (JIT) access model: require authorization, grant temporary rights with automatic credential reset, and audit all actions. This maintains security while preserving operational flexibility.

0 Admin Model

Our Delegation Model design is flexible enough to accommodate all these technics, increasing the overall security of Active Directory. This is how we end up with a 0 Admin Model.

What We Can Achieve by Having a 0 Admin Model

The 0 Admin Model delivers profound security and operational benefits far beyond simply reducing the number of admin accounts. Let's explore the multi-layered advantages:

Attack Surface Reduction: Credential Exposure Prevention

By having a 0 Admin model, we avoid exposing Privileged credentials into our environment. This makes it significantly more difficult for Pass-the-Hash and Pass-the-Ticket attacks to succeed. Although this technique will not completely eliminate such attacks, it makes obtaining privileged credentials exponentially harder. Simply put: credentials that are never used are never exposed to attackers.

Threat Mitigation: Lateral Movement

Without 0 Admin Model: An attacker compromising a standard user account has a clear path to escalate to admin through compromised admin accounts used daily.
With 0 Admin Model: An attacker compromises only the specific delegated permissions for that compromised account. Moving laterally to other departments or critical systems requires additional breaches across segregated delegation groups.

Risk Mitigation: Human Error Prevention

We avoid the risk of having a privileged user doing something that can compromise the security of the environment. By having a Delegation Model, we ensure that users only have the permissions they need to perform their tasks, reducing the risk of accidental or malicious changes to critical systems. An administrator with full power might accidentally delete a critical OU or modify a Domain Controller policy. With delegated rights scoped to specific OUs, that cannot happen.

Enhanced Compliance & Audit Trails

We implement a set of technical roles which grant specific delegated rights to our semi-privileged users, giving us granular control and enhanced auditing capabilities. Unlike broad admin permissions where "anything is possible," delegated roles create clear audit trails:

Who made the change (captured in AD audit logs)
What they changed (specific object type and property)
When it happened (timestamp)
Why they could do it (delegated role assignment)

This level of accountability is essential for compliance frameworks like SOC 2, ISO 27001, and HIPAA.

Least Privilege Access Implementation

We reinforce the Delegation Model by implementing a Least Privileged Access role strategy that helps us to "isolate" the semi-privileged credentials and ensures minimal permission grants. This foundational security principle dramatically reduces both the blast radius of compromises and the likelihood of security violations.

Segregation of Duties (SoD) Enforcement

A natural consequence of the 0 Admin Model is automatic segregation of duties. You cannot have true segregation if everyone with domain access has full admin rights. With delegated roles, conflicting duties can be assigned to different groups:

User Managers cannot approve password resets
Password Reset staff cannot modify user properties
Group Managers cannot modify security group memberships
Account creators cannot approve account creations (if using approval workflows)

Operational Autonomy & Scalability

Each business unit gains autonomy within its scope without impacting others. The Sales department can manage its users and groups without involvement from IT admins. Finance can manage its resources independently. This decentralization reduces bottlenecks and improves agility as your organization scales.

Security Culture Transformation

By design, the 0 Admin Model forces conversations about "what does this user actually need to do their job?" Rather than granting broad permissions and hoping for the best, your organization becomes intentional about access control. This mindset shift extends beyond AD to all systems and is a hallmark of security-mature organizations.

Cumulative Security Benefit

The 0 Admin Model creates defense in depth. Even if an attacker compromises a delegated user account, they cannot access resources outside that delegation scope. Multiple layers of access controls must be bypassed to cause significant harm, making sustained attacks far more difficult and detectable.

Implementation Challenges & Considerations

While the 0 Admin Model offers compelling security benefits, implementation requires careful planning and organizational alignment. Here are the key challenges to anticipate:

Initial Effort & Time Investment

Building a comprehensive delegation model is not a weekend project. You must:

Map all administrative tasks across your organization
Design delegation groups and scope for each task
Test delegations in a lab or test environment thoroughly
Phase rollout carefully to minimize operational disruption
Train users on their new delegated roles and limitations

For a mid-sized organization (1,000-5,000 users), expect 2-6 months of design and testing before production rollout.

Organizational Resistance

People accustomed to "having admin access" often resist restrictions, even when the restrictions are justified. Common objections:

"I need admin access 'just in case'" → Require them to articulate the specific use case and create a delegation or JIT process for it
"This will slow us down" → Demonstrate that delegated access often speeds up self-service operations
"We trust our admins" → Explain this is not about trust; it's about limiting blast radius and enforcing segregation of duties

Executive sponsorship and clear communication of security benefits are essential.

Documentation & Ongoing Maintenance

A delegation model must be documented and kept current. As your organization evolves:

New departments or roles emerge requiring new delegations
Staff changes mean users join/leave delegation groups
Unused delegations should be cleaned up to prevent privilege creep
Audit logs must be regularly reviewed for anomalies

Without a process and owner for this maintenance, delegations can become inconsistent or outdated.

Exceptions & Edge Cases

Real-world environments are messy. You will encounter:

Third-party applications that expect admin-equivalent permissions in AD
Legacy systems that don't work well with scoped delegations
Emergency scenarios where you need quick admin access (mitigation: use break-glass procedures)
Contractors or consultants needing temporary broad access

Plan for these exceptions with clear policies and approval workflows.

Testing & Validation Complexity

Delegations must be thoroughly tested:

Does this delegated group actually have the permissions they need? (Positive test)
Can they NOT do things they shouldn't? (Negative test)
Does their access work on all domain controllers? (replication)
Do delegations work through your management tools (e.g., Active Directory Users & Computers, PowerShell modules)?

Incomplete testing can lead to a false sense of security or operational failures.

Tool & Process Alignment

Your identity and access management tools must support delegated role-based access control. Consider:

Does your ticketing system enforce approval workflows for privileged tasks?
Does your PAM/PIM solution support delegated roles (or just admins)?
Can your SIEM/audit system track delegated access separately from admin access?
Do your change management processes account for delegated vs. privileged changes?

Start Small, Prove Value, Scale

Don't try to implement a full 0 Admin Model across your entire organization at once. Start with a pilot: select one department (e.g., Sales) or one object class (e.g., User Management), implement delegation, measure results, and iterate. Early wins build organizational confidence and smooth the path to enterprise-wide rollout.