Case Study: Strengthening Enterprise Identity Security Through Tiered Admin Separation
At a glance
- Client type: Large New Zealand manufacturing enterprise
- Problem: Broad Domain Admin usage across routine operational workloads.
- Finding: Tier 0 and Tier 1 activities were not adequately separated.
- Outcome: Privileged credential exposure paths reduced and operational access redesigned safely.
- Related service: Security and identity / Tiered administration model
Overview
A large New Zealand manufacturing enterprise had a common but serious identity security problem: privileged access had expanded over time.
Domain Administrator access had gradually been assigned to senior engineers and operational teams for convenience. In many cases, the access was not only used for identity-critical systems such as domain controllers, federation services, certificate authorities, and core directory infrastructure. It was also being used to manage regular servers, web applications, application VMs, patching tasks, and general operational support.
This created unnecessary exposure.
Highly privileged credentials were being used across systems that did not require that level of access. If any of those lower-tier systems were compromised, there was a risk that privileged credentials could be harvested and used to move toward identity-critical infrastructure.
CloudQbit helped design and implement a tiered administrative model separating identity-critical administration from standard server operations.
The result was a significant security hardening uplift, reduced privileged credential exposure, clearer operational separation, and a stronger identity security model aligned with practices used by critical national organisations.
The Challenge
The organisation had a growing number of Domain Administrators. Over time, privileged access had been granted to engineers and operational teams to make day-to-day work easier.
The issue was not that the teams were careless. They had operational responsibilities and needed to manage systems quickly. The problem was that Domain Administrator access had become the default answer for too many activities.
Domain Administrator credentials were being used for tasks such as:
| Activity | Risk |
|---|---|
| Managing domain controllers and identity systems | Appropriate only for tightly controlled Tier 0 access |
| Managing federation and certificate authority services | Requires strong privileged access control |
| Patching regular servers | Does not usually require Domain Admin rights |
| Fixing application server issues | Should use lower-tier admin access |
| Managing web applications and standard VMs | Creates unnecessary identity risk |
| General operational troubleshooting | Increases credential exposure surface |
The organisation also relied on shared administrative access patterns, including use of a common jump box for operational administration. This created additional concern because credentials, scripts, cached sessions, and administrative artefacts could potentially be exposed in one shared location.
The core risk was simple:
Why This Was a Problem
In Active Directory environments, Domain Administrator access is one of the highest-risk privilege levels.
If Domain Admin credentials are exposed, an attacker may be able to compromise the entire directory environment and gain control over identity, authentication, policy, and critical infrastructure.
This is why privileged access must be separated by administrative tier.
A Domain Admin account should not be used to manage regular servers, application VMs, or lower-trust systems. Those systems are often accessed by more teams, have more software installed, are patched at different cadences, and may be exposed to different operational risks.
When a highly privileged account logs on to a lower-tier server, it can create a credential exposure path. Cached credentials, tokens, administrative tools, scripts, or session artefacts may create opportunities for credential theft or lateral movement.
In this case, analysis showed thousands of potential exposure paths where privileged credentials could potentially be harvested from non-identity systems if the environment were compromised.
The organisation needed to reduce those paths without slowing down operational teams.
Investigation Approach
CloudQbit reviewed the existing administrative model, privileged group membership, server roles, operational access patterns, and how engineers performed day-to-day support.
The review focused on answering several key questions:
| Question | Why it mattered |
|---|---|
| Who has Domain Administrator access? | Identify privileged access sprawl |
| Why do they need that access? | Separate genuine identity administration from convenience access |
| Which systems are identity-critical? | Define Tier 0 scope |
| Which systems are standard operational workloads? | Define Tier 1 scope |
| How are administrators connecting? | Identify jump box and credential exposure risks |
| Are the same accounts used across tiers? | Detect cross-tier credential contamination |
| Can operations continue without Domain Admin access everywhere? | Ensure the model is practical, not theoretical |
The key finding was that many users did not need Domain Administrator access for most of their daily work. They needed reliable administrative access to the systems they supported, but not full control over the identity plane.
Root Cause
The root cause was privilege creep.
Over time, Domain Administrator access had become a convenient way to solve operational access issues. As more senior engineers and support teams needed to manage more systems, high privilege was granted broadly rather than separated by role, system criticality, and administrative tier.
The main issues were:
| Issue | Impact |
|---|---|
| Broad Domain Admin membership | Increased risk of identity compromise |
| Same accounts used across different system tiers | Higher chance of credential exposure |
| Domain Admins used on regular servers | Created unnecessary credential harvesting paths |
| Shared jump box model | Increased concentration of administrative risk |
| Lack of Tier 0 / Tier 1 separation | Identity systems and standard workloads were not isolated operationally |
| Limited privileged access education | Teams did not always know which account to use for which task |
| Convenience-based access model | Access was granted for ease of support rather than least privilege |
The organisation did not just need access cleanup. It needed a new privileged access operating model.
Solution Approach
CloudQbit proposed and helped implement a tiered administrative model separating identity-critical administration from standard operational administration.
The model introduced clear separation between:
| Tier | Purpose |
|---|---|
| Tier 0 | Identity-critical systems such as domain controllers, core directory services, federation services, certificate authority, and privileged identity infrastructure |
| Tier 1 | Standard server administration, application servers, service VMs, patching, and operational workloads |
The operating model gave engineers the access they needed without exposing Domain Administrator credentials across the wider server estate.
Operational teams received separate administrative accounts for different purposes:
| Account type | Usage |
|---|---|
| Tier 0 admin account | Used only for identity-critical systems from hardened Tier 0 administrative access points |
| Tier 1 admin account | Used for standard servers, application VMs, patching, and operational support |
| Standard user account | Used for email, browsing, productivity tools, and normal daily work |
This ensured that highly privileged identity credentials were no longer used for routine administration of non-identity systems.
Key Controls Implemented
The implementation combined technical controls, process changes, and team education.
| Area | Action |
|---|---|
| Tier model design | Defined Tier 0 and Tier 1 administrative boundaries |
| Privileged access review | Reviewed and reduced unnecessary Domain Administrator membership |
| Account separation | Introduced separate admin accounts for identity-critical and standard server administration |
| Hardened access paths | Restricted Tier 0 administration to protected administrative systems |
| Jump box redesign | Reduced reliance on a single shared administrative access point |
| Server classification | Identified identity-critical systems and separated them from regular workloads |
| Credential hygiene | Prevented highly privileged credentials from being used on lower-tier systems |
| Password process improvement | Implemented password reset processes and credential hygiene policies |
| Team training | Educated engineers on account separation, password separation, and correct account usage |
| Operational enablement | Ensured teams retained access needed to manage their systems without Domain Admin rights |
| Governance | Established clearer rules for privileged access assignment and review |
The goal was not to remove operational capability. The goal was to provide the right access at the right tier.
Business and Security Outcome
The implementation delivered a significant identity security uplift.
Domain Administrator access was restricted to users and systems that genuinely required Tier 0 administrative capability. Operational teams retained the access they needed to manage standard servers and services, but no longer had to use Domain Admin credentials for routine work.
The outcome included:
| Area | Outcome |
|---|---|
| Privileged access reduction | Domain Admin access limited to identity-critical administration |
| Credential exposure reduction | Highly privileged credentials no longer used broadly across regular servers |
| Tier separation | Tier 0 and Tier 1 administration clearly separated |
| Operational continuity | Teams retained appropriate access to manage supported systems |
| Security maturity | Stronger privileged access model aligned to enterprise security practice |
| Team awareness | Engineers trained on separate accounts, passwords, and correct account usage |
| Risk reduction | Thousands of potential credential exposure paths reduced |
| Audit recognition | Security uplift recognised as a significant hardening improvement during external review |
| Repeatable method | Approach later applied across multiple organisations |
The value was not only technical. The work improved how the organisation thought about privileged access.
The Mindset Shift
The previous model treated Domain Administrator access as a practical solution to operational access issues.
The improved model treated Domain Administrator access as a highly sensitive identity-control function that must be protected, separated, and used only where required.
| Old mindset | Better mindset |
|---|---|
| “Senior engineers need Domain Admin to get things done.” | “Senior engineers need the right access for the systems they manage.” |
| “One admin account is simpler.” | “Separate admin accounts reduce credential exposure.” |
| “Domain Admin can be used for patching and troubleshooting.” | “Routine server support should not expose identity-critical credentials.” |
| “A shared jump box is convenient.” | “Privileged access paths must be separated and hardened.” |
| “Access issues are solved by granting more privilege.” | “Access should be role-based, tiered, and reviewed.” |
| “Security controls slow operations down.” | “Good security design enables safe operations.” |
This mindset shift was essential. Without it, the environment would eventually drift back toward privilege creep.
Why This Matters
Identity is one of the highest-value targets in any enterprise environment.
If attackers obtain Domain Administrator credentials, the impact can be severe. They may gain control over authentication, group policy, privileged groups, servers, and critical business systems.
Many organisations still carry legacy administrative models where Domain Admin access has grown over time. This often happens for understandable reasons: operational pressure, urgent troubleshooting, historical access requests, or lack of a practical alternative.
But broad Domain Admin usage creates unnecessary risk.
A mature privileged access review should ask:
- Who has Domain Administrator access?
- Why do they need it?
- Are Domain Admin accounts used on regular servers?
- Are separate accounts used for different administrative tiers?
- Are Tier 0 systems clearly identified?
- Are Tier 0 admin paths hardened?
- Do operational teams have enough access without over-privilege?
- Are credentials separated with different passwords?
- Are shared jump boxes creating credential exposure risk?
- Are privileged access rules documented and reviewed?
These questions help organisations reduce risk without stopping teams from doing their work.
CloudQbit Capability Developed
Through this and similar engagements, CloudQbit developed a practical approach to tiered administration and privileged access separation.
The approach includes:
- Reviewing Domain Administrator membership
- Identifying Tier 0 identity-critical assets
- Separating Tier 0 and Tier 1 administrative access
- Designing separate admin account models
- Hardening privileged access paths
- Reducing cross-tier credential exposure
- Improving password reset and credential hygiene processes
- Training engineering and operational teams
- Supporting operational access without unnecessary Domain Admin rights
- Documenting governance rules for ongoing privileged access management
This practice has been repeated across multiple organisations and recognised during external security review as a meaningful improvement to identity security posture.
Conclusion
This case study demonstrates how tiered administration can significantly reduce identity risk while preserving operational capability.
A large New Zealand enterprise had accumulated broad Domain Administrator access across senior engineers and operational teams. Those privileges were being used not only for identity-critical systems, but also for regular servers, web applications, patching, and day-to-day support.
CloudQbit helped design and implement a Tier 0 and Tier 1 administrative separation model. Identity-critical systems were managed only with dedicated Tier 0 accounts from hardened access points, while standard servers and applications were managed with separate Tier 1 administrative accounts.
This reduced unnecessary privileged credential exposure, limited Domain Administrator usage, improved operational discipline, and reduced thousands of potential paths where highly privileged credentials could be exposed.
The lesson is simple:
This is the type of practical security and identity improvement CloudQbit focuses on: reducing real risk, enabling safe operations, and helping organisations protect their most critical systems.