Active Directory remains the core of digital identity in the majority of enterprise infrastructures, and for this very reason it is also one of the primary targets of any advanced cyber attack. Compromising AD, in most cases, means gaining full control of the environment.
The security of Active Directory is not achieved through a single product or an isolated configuration, but through a set of coherent architectural decisions, primarily based on privilege reduction, role separation, and the protection of the most sensitive credentials.
In this article, we analyze some of the fundamental best practices to concretely improve the security posture of a modern Active Directory domain.
Enterprise Admin and Schema Admin: less is more
The Enterprise Admins and Schema Admins groups represent the highest level of privilege within an Active Directory forest. For this reason, they should be treated as exceptional roles, not as day-to-day operational tools. Best practices dictate that:
- No permanent accounts should be members of Enterprise Admins
- Schema Admins should be populated only temporarily, exclusively during schema modification activities (for example, product upgrades that require it)
Under normal conditions, these groups should be empty. Role assignment should occur:
- for a limited period of time
- using dedicated accounts
- preferably through controlled processes (change management, approvals, auditing)
Reducing the exposure of these privileges significantly lowers the impact of a potential credential compromise.
The Tier 0 – Tier 1 – Tier 2 model
The Domain Admins group is required for domain administration, but it is also one of the primary targets in privilege escalation and lateral movement attacks. One of the most important rules is the following: a Domain Admin account must never be used to access client devices.
The correct approach is the Tier Model:
- Tier 0: Domain Controllers, AD, PKI, identity systems
- Tier 1: application and infrastructure servers
- Tier 2: clients and user workstations
Domain Admin accounts belong to Tier 0 and, at most, should operate against Tier 1 systems. They must instead be explicitly blocked:
- from interactive logon on client devices
- from usage on non-dedicated administrative workstations
This isolation reduces the risk that malware present on a user endpoint can intercept high-privilege credentials.
Client management: dedicated accounts and strict separation
Client management (Tier 2) should be performed using dedicated accounts, specifically designed for this purpose. The key characteristics of these accounts are:
- Administrative permissions limited to client devices only
- No access rights to servers or Domain Controllers
- No membership in privileged domain groups
This separation is often underestimated, but it is critical, as client devices are inherently more exposed, commonly used for high-risk activities such as web browsing and email, and represent the primary initial compromise vector in most security incidents.
Limiting the scope of client management accounts prevents a local compromise from escalating into an infrastructure-wide incident.
In practice, however, this approach can be operationally inconvenient for day-to-day management. For this reason, achieving at least a partial separation toward a “Tier 2–1” model represents an excellent starting point and helps mitigate security risks.
LAPS: secure management of local administrator passwords
The management of local administrator account passwords has historically been one of the weakest points in Windows environments. Reusing the same password across multiple systems, often for operational convenience, exposes the infrastructure to highly effective attack techniques such as credential dumping and pass-the-hash, allowing attackers to move quickly from one system to another.
Local Administrator Password Solution (LAPS) was designed to eliminate this issue at its root, introducing a model in which each machine has a unique local password, automatically generated, periodically rotated, and accessible only to authorized subjects. As a result, even if a single endpoint is compromised, the attacker cannot reuse that credential to propagate within the domain.
From an architectural perspective, LAPS enables:
- generation of complex, non-reusable passwords
- automated password rotation based on defined policies
- elimination of the need to manually know or distribute local credentials
- a significant reduction in lateral movement risk
Traditionally, the local administrator password is stored in Active Directory, within protected attributes of the computer object, with ACLs that allow access only to specific groups or roles. This approach is inherently secure, provided permissions are correctly configured and access is properly audited.
In more modern scenarios, however, LAPS can also be integrated with Microsoft Entra, enabling password storage and management directly within the cloud identity service. This model is particularly useful in:
- Hybrid environments
- Cloud-native environments
- Microsoft Entra joined devices or systems managed through Intune
Integration with Entra enables the application of advanced access controls, such as Conditional Access and centralized auditing, further improving the governance of local credentials and aligning endpoint management with cloud-native security strategies.
The KRBTGT key: the invisible pillar of Kerberos
The password of the KRBTGT account is one of the most critical and sensitive elements of an Active Directory domain. It is the key used by the Kerberos service to sign and encrypt Ticket Granting Tickets (TGTs), which allow users to authenticate and access domain resources.
For this reason, a compromise of the KRBTGT password represents one of the worst possible scenarios: an attacker in possession of this key can generate Golden Tickets, impersonate any identity — including Domain Admins and Enterprise Admins — and obtain persistent, extremely difficult-to-detect access to the entire infrastructure.
Microsoft has long recommended regular rotation of the KRBTGT password, while stricter security guidelines, such as STIG, suggest a maximum interval of 180 days. In high-criticality environments, however, rotation should be evaluated not only on a time-based schedule, but also in response to security events.
An often-overlooked aspect is that any privileged account that had the ability to generate Golden Tickets, even temporarily, represents a risk as long as the KRBTGT password remains unchanged. If a highly privileged user leaves the organization or is disabled, but previously operated in a trusted context, tickets generated during that period may still be valid.
In such scenarios, failing to rotate the KRBTGT password may allow an attacker to:
- maintain persistent access to the domain
- bypass standard authentication controls
- operate undetected even after official credentials have been revoked
For this reason, an advanced best practice is to reset the KRBTGT password whenever an account with critical privileges is decommissioned or compromised, rather than relying solely on periodic rotation.
The rotation of the KRBTGT password must be performed carefully. The correct procedure requires two distinct resets, separated by sufficient time to allow replication to complete across all Domain Controllers.
The double reset is essential to fully invalidate any previously issued Kerberos tickets. However, a common and potentially disruptive mistake must be avoided: performing two consecutive resets in rapid succession, before replication has completed.
A double reset performed too quickly can result in:
- invalidation of still-legitimate tickets
- service and server access disruptions
- authentication issues for Kerberos-dependent applications
The procedure must therefore be planned, monitored, and documented, taking into account infrastructure replication timing and application dependencies.
Proper management of the KRBTGT password is not merely a hardening measure, but a true post-compromise containment mechanism. In the event of an incident, it is one of the most effective tools for restoring trust in the domain and disrupting persistent access invisible to traditional controls.
Conclusions
Securing Active Directory first and foremost means reducing privileges, not increasing them. Every unnecessary permission represents an additional attack surface. Active Directory remains a solid and reliable technology today, but only when administered with discipline, awareness, and a modern security mindset.
Limiting critical roles, clearly separating operational scopes, protecting local credentials, and properly managing key components such as KRBTGT are not optional activities: they are prerequisites for a resilient domain.
#DBS