Case studies

Research paper · Atlantic Technological University Mayo · April 2026

Implementation of a Least Privilege Model in a Simulated SME Environment

Designing and evaluating a hybrid least-privilege access architecture with Active Directory, Microsoft Entra ID, RBAC and Just-In-Time privilege elevation: meaningful Zero Trust-aligned security without a full architectural overhaul.

JIT admin access, approved and time-boxed

  • Cybersecurity
  • Zero Trust
  • Identity & Access

01. Overview

Small and medium enterprises are increasingly targeted by cyberattacks that exploit excessive user and administrative privileges. While Zero Trust Architecture (ZTA) has emerged as an effective security model to address these risks, its full implementation often requires resources, expertise, and organisational maturity that exceed the capabilities of many small organisations.

Least Privilege Access is widely recognised as a foundational element of Zero Trust — ensuring that users, devices, and services are granted only the minimum access necessary to perform their functions. Poor privilege management, including standing administrative access and privilege creep, significantly increases an organisation's attack surface.

Aim

To design, implement, and evaluate a risk-based Least Privilege Access model as a foundational control within the context of Zero Trust Architecture for a small enterprise environment — demonstrating that meaningful security improvements are achievable without full architectural transformation.

Project Objectives

  • Examine Least Privilege Access as a foundational Zero Trust control
  • Identify risks arising from excessive privileges in SME environments
  • Design and implement a risk-based Least Privilege model in a simulated environment
  • Evaluate its effectiveness in reducing cybersecurity risk
  • Critically reflect on feasibility and limitations for small enterprises

Architecture Overview

Hybrid Least Privilege Identity Architecture diagram
Fig. 1 — Hybrid Least Privilege Identity Architecture. On-premises Active Directory serves as the authoritative identity source, managing Organisational Units, Security Groups, RBAC assignments, and AGDLP file permissions. Identities are synchronised to Microsoft Entra ID via hybrid provisioning agents, extending governance into the cloud through Administrative Role assignments, Privileged Identity Management (PIM) with Just-In-Time privilege elevation, and Conditional Access policies enforcing MFA. Both planes converge on the Zero Trust principles of Verify Explicitly, Use Least Privilege, Assume Breach, and Monitor & Audit.

02. Literature Review

This review examines two key sources: Syed (2025) Zero Trust Principles and the Evolution of Privilege Access Management Architectures, and Lund et al. (2024) Zero Trust Cybersecurity: Procedures and Considerations in Context.

Key Findings from the Literature

Syed (2025) explores how Zero Trust principles have transformed Privileged Access Management from static, perimeter-dependent controls to adaptive, identity-centric architectures. Traditional security models inadequately address contemporary threats — including credential compromise, cloud-based attacks, and insider misuse — due to implicit trust in authenticated internal users. The paper highlights innovations such as passwordless authentication, just-in-time (JIT) privilege provisioning, and session-based access control as strategies to reduce standing privileged access and limit lateral movement.

Lund et al. (2024) conceptualise Zero Trust primarily as a set of procedural and governance principles rather than a purely technical architecture. Anchored in "never trust, always verify," the paper discusses MFA, dynamic authorisation, network segmentation, and the adoption of an "assume breach" mindset. The principle of least privilege is emphasised through RBAC, contextual access decisions, and segmentation strategies.

Synthesis

Both sources confirm that identity is the new security perimeter and least privilege is the highest-impact entry point for Zero Trust adoption — deployable in resource-constrained environments using existing cloud-native platforms without significant infrastructure cost.

Critical Gaps Identified

A significant gap in both sources is the lack of explicit guidance for phased implementation and evaluation of least-privilege controls in simulated small-enterprise environments. Neither work directly addresses the incremental deployment of identity-centric controls using cloud-native identity platforms — which is precisely what this project addresses.

03. Lab Environment Design

The implementation deployed a hybrid identity environment within a controlled home laboratory using Microsoft Windows Server and Microsoft Entra ID, reflecting the architecture adopted by organisations that combine on-premises infrastructure with cloud services.

Infrastructure Components

SystemRole
Server 2025 LAB / DC01Domain Controller — Active Directory Domain Services
FS01File Server — departmental share hosting
AADSYNC01Identity Synchronisation Server (Entra Provisioning Agent)
CLIENT01Domain Workstation — access validation testing
Microsoft Entra ID / M365 TenantCloud identity platform — RBAC, Conditional Access, PIM
Hyper-V Manager showing all four lab VMs running
Fig. 2 — Hyper-V Manager (LK-DSK). All four lab virtual machines — Server 2025 LAB (DC01), FS01, AADSYNC01, and CLIENT01 — running simultaneously on the host, confirming the full hybrid lab environment was operational during the project.

The hybrid design was deliberately chosen to reflect the reality faced by many SMEs: organisations that cannot migrate fully to the cloud but are increasingly consuming cloud services such as Microsoft 365 alongside traditional on-premises infrastructure. This mixed model introduces identity management complexity that, if unaddressed, creates privilege gaps at the boundary between environments.

Active Directory OU Structure

Organisational UnitPurpose
LAB-UsersStandard user accounts
LAB-GroupsSecurity groups used for RBAC
LAB-ServersInfrastructure servers
LAB-WorkstationsClient computers
LAB-ServiceAccountsManaged service accounts
Active Directory Users and Computers showing lab OU structure
Fig. 3 — Active Directory OU Structure. The LAB domain organisational units separating users, groups, servers, workstations, and service accounts — providing the structural foundation for scoped Group Policy and RBAC assignments.

04. RBAC & Admin Tiering

RBAC was implemented to enforce least privilege by assigning permissions to roles rather than individual users, reducing administrative complexity and the risk of excessive privilege assignment.

Three-Tier Administrative Model

TierScopeSecurity Group
Tier 0Domain Controllers & Identity InfrastructureGG-T0-DomainAdmins
Tier 1Servers & Infrastructure ServicesGG-T1-ServerAdmins
Tier 2Workstations & User EndpointsGG-T2-WorkstationAdmins
Administrative Tier Model diagram
Fig. 4 — Administrative Tier Model. Tier 0 (Domain Controllers) is restricted to Domain Admins only, with no direct access from Tier 1 or Tier 2. Tier 1 (Servers) is accessible to Domain Admins and Server Admins. Tier 2 (Workstations) is accessible to Domain Admins and Workstation Admins only — preventing credential reuse across tiers.
Security Impact

This tier separation ensures that a compromised workstation administrator account cannot be used to access servers or domain controllers — containing the blast radius of credential theft. A GPO named Tier2-Deny-Server-Logon enforces this boundary via deny logon user rights assignments.

Active Directory security groups implementing AGDLP model
Fig. 5 — Security Groups in Active Directory. Global Groups (GG-) and Domain Local Groups (DL-FS-) created in the LAB-Groups OU to implement the AGDLP permission chain. Each Domain Local Group maps directly to a specific NTFS access level on the corresponding file share.

05. Security Hardening

Workstation Security Baseline

A Group Policy Object named Workstation-Security-Baseline was linked to the LAB-Workstations OU, applying baseline security configurations to protect endpoints against credential exposure risks.

PolicyConfigurationRationale
Enable insecure guest logonsDisabledPrevents unauthenticated SMB access
LAN Manager authentication levelNTLMv2 onlyEliminates weaker legacy auth protocols
Audit logon eventsSuccess and FailureVisibility for incident detection
Workstation Security Baseline GPO settings
Fig. 6 — Workstation Security Baseline GPO. Group Policy report confirming the applied security settings: insecure guest logons disabled, NTLMv2-only authentication enforced, and logon event auditing enabled for both success and failure — hardening endpoints against credential exposure.

Server Security Baseline

A Server-Security-Baseline GPO was linked to the LAB-Servers OU. Using Restricted Groups policy, local Administrators group membership on all servers was centrally locked to only LAB\Domain Admins and LAB\GG-T1-ServerAdmins.

Group Policy Restricted Groups configuration locking server local admins
Fig. 7 — Server Security Baseline — Restricted Groups. The Server-Security-Baseline GPO configured via Restricted Groups policy, locking the local Administrators group on all servers to LAB\Domain Admins and LAB\GG-T1-ServerAdmins only — preventing unauthorised privilege escalation from lower-tier accounts.

Microsoft LAPS

Microsoft LAPS was deployed to eliminate shared local administrator passwords across workstations. LAPS automatically generates unique, periodically rotated passwords per workstation and stores them securely in Active Directory, retrievable only by authorised administrators.

SettingValue
Password Length14 characters
Password ComplexityLetters, numbers, special characters
Password RotationEvery 7 days
Backup LocationActive Directory
PowerShell
Get-LapsADPassword CLIENT01

06. File Server Access Control

Least privilege was demonstrated through controlled access to three departmental file shares hosted on FS01 (Finance, IT, and Public), ensuring users could only access data required for their role.

AGDLP Permission Model

AGDLP Chain
User Account → Global Group → Domain Local Group → NTFS Permissions

Example:
finance.user → GG-Finance-Users → DL-FS-Finance-RW → Modify (NTFS)

NTFS Permission Assignments

ShareGroupAccess Level
FinanceDL-FS-Finance-RWModify
FinanceDL-FS-Finance-RORead and Execute
ITDL-FS-IT-RWModify
PublicDL-FS-Public-RORead and Execute
NTFS Advanced Security Settings for IT share
Fig. 8 — NTFS Permissions — IT Share. Advanced Security Settings on the IT share confirming DL-FS-IT-RW (LAB\DL-FS-IT-RW) is the only non-system group with Modify access — all other principals are restricted to system accounts and the owner.
Key Insight

A finance user who cannot enumerate the IT share cannot identify targets for lateral movement or data exfiltration. Least privilege combined with Access-Based Enumeration functions as both an access control and a reconnaissance countermeasure.

Access-Based Enumeration enabled on File Server shares
Fig. 9 — Access-Based Enumeration (ABE). ABE enabled on the FS01 file server shares via File and Storage Services. With ABE active, users only see folders they have permissions to access — folders they cannot read are hidden entirely, eliminating passive reconnaissance paths.

Validation Results

  • finance.user — accessed Finance share only; IT and Public folders not visible
  • it.user — accessed IT share only; Finance folder not visible
  • public.user — restricted to Public share only
User account group membership properties for public, IT, and finance users
Fig. 10 — User Group Memberships. Active Directory properties confirming role-based group assignments: public.user is a member of GG-Public-Users only; it.user is a member of GG-IT-Users only; finance.user is a member of GG-Finance-Users only — each scoped to the minimum access required for their role.

07. Hybrid Identity Integration

To extend identity management capabilities to the cloud, the on-premises Active Directory environment was integrated with Microsoft Entra ID using Microsoft Entra provisioning agents installed on AADSYNC01.

Without hybrid identity, organisations managing both environments risk operating two disconnected identity planes — one governed by Active Directory policies, and one ungoverned in the cloud. This fragmentation creates conditions where least privilege applied on-premises is not carried through to cloud resource access, undermining the model at the boundary.

Architecture Decision

By synchronising identities through Entra provisioning agents, the project established a single authoritative identity source spanning both environments — ensuring role-based controls defined in Active Directory are consistently reflected in cloud identity governance.

08. Microsoft Entra Security Controls

Following hybrid synchronisation, Microsoft Entra ID extended the on-premises governance model into the cloud via RBAC, Privileged Identity Management, and Conditional Access.

Entra RBAC Role Assignments

RolePurposeAssignment Type
Global AdministratorTenant configuration & identity managementEligible (JIT)
User AdministratorUser lifecycle & group managementEligible (JIT)
Security ReaderSecurity monitoring & log reviewActive (permanent)

Just-In-Time Privilege Elevation (PIM)

Privileged roles are assigned as eligible rather than permanently active, requiring administrators to activate them through the PIM interface with operational justification and a service desk ticket reference. Activated roles expire after one hour with a full audit record generated per activation.

PIM Activation — Audit Record Example
RoleUser Administrator
ResourceSME-ZeroTrust-Lab
StartMarch 15, 2026 11:59 UTC
EndMarch 15, 2026 12:59 UTC
JustificationResetting the password for User-X
Ticket systemConnectWise
Ticket number#3334444
PIM Just-In-Time activation request and completion status
Fig. 11 — PIM Just-In-Time Activation. Left: activation request for the User Administrator role with a 1-hour duration, ConnectWise ticket reference, and operational justification. Right: activation status confirming all three stages completed successfully — the role is now active and will expire automatically after the defined window.

Conditional Access — MFA for Privileged Roles

Conditional Access was configured to require MFA for all privileged administrative accounts, ensuring elevated roles are protected by explicit identity verification beyond passwords alone.

Conditional Access policy requiring MFA for privileged roles
Fig. 12 — Conditional Access Policy — CA-Require-MFA-For-Privileged-Roles. The policy targets all users assigned privileged roles, requires multi-factor authentication as the grant control, and applies to all cloud resources — ensuring no privileged action can be performed on password alone.

09. Findings & Conclusion

This project successfully designed, implemented, and evaluated a hybrid least privilege architecture within a simulated SME environment, demonstrating that least privilege functions as a practical and high-impact Zero Trust control even under resource constraints.

Key Outcomes

  • Persistent admin privileges eliminated — replaced with role-based assignments and JIT elevation via PIM
  • Shared local admin passwords replaced — unique, rotating credentials per workstation via LAPS
  • Unrestricted file share visibility eliminated — strictly scoped NTFS access with ABE removing reconnaissance paths
  • Tier isolation enforced — GPO boundaries prevent lower-tier credentials from accessing higher-value systems
  • Unified identity plane — hybrid Entra ID sync eliminates the privilege gap at the environment boundary

Limitations

The implementation assumes consistent identity governance and disciplined role management. Operational pressures may lead to privilege creep over time. The project is a controlled simulation and does not incorporate endpoint detection, device compliance policies, or network-level segmentation.

Conclusion

Meaningful Zero Trust-aligned security improvements are achievable without full architectural transformation. By combining RBAC, administrative tiering, LAPS, hybrid identity synchronisation, cloud role governance, and JIT privilege elevation, the implementation significantly reduced unnecessary access rights. Least privilege is a realistic and measurable first step for small enterprises strengthening their cybersecurity posture.

References

  • Center for Internet Security. (2023). CIS Microsoft Windows Server 2022 benchmark.
  • Joint Task Force. (2020). Security and privacy controls for information systems and organizations. NIST SP 800-53r5.
  • Lund, B. D., et al. (2024). Zero trust cybersecurity: Procedures and considerations in context. Encyclopedia, 4(4), 99.
  • Microsoft. (2022). Enterprise access model. Microsoft Learn.
  • Microsoft. (2023). Windows LAPS overview. Microsoft Learn.
  • Microsoft. (2024). What is Microsoft Entra Privileged Identity Management? Microsoft Learn.
  • National Cyber Security Centre. (2022). Introduction to identity and access management. NCSC.
  • Rose, S., et al. (2020). Zero trust architecture. NIST SP 800-207.
  • Syed, S. (2025). Zero trust principles and the evolution of privilege access management architectures. Journal of Computer Science and Technology Studies, 7(7), 866–873.