Active Directory N-TIERS Model - Privileged Access Management Implementation

In our previous article, we demonstrated how the N-tier model significantly enhances the security of information systems by limiting attackers’ lateral movements. However, we concluded that the inherent increase of user accounts number required by this model makes it challenging to implement: to reduce movement between tiers, the model recommends using accounts specifically dedicated to each tier.
That said, the model is not impossible to implement. In this article, we will explore a viable solution to address this challenge.

Changing the Authentication Model

The N-tier architecture leads to the proliferation of privileged accounts (administrative and service accounts) and a potential loss of control over the policies applied to them. This is why we propose an authentication model where the use of personal accounts is replaced by generic accounts. The segmentation policy for generic accounts is arbitrary. One fundamental rule must be followed: a generic account must not grant access to resources in two different tiers. The strictest model would enforce the use of a dedicated generic account for each server, meaning an account can only connect to one server, on which it has specific rights. A server, however, may have multiple generic access accounts (a one-server-to-many-accounts relationship).

Privileged Access Management (PAM)

The use of generic accounts represents a paradigm shift that is complex to implement. This likely raises strong reactions among readers, and for good reason: how can the principle of “accountability of actions” be ensured in this model? That is why a Privileged Access Management (PAM) solution appears to be a suitable approach. Such solution provide centralized management and oversight of privileged accounts across the various resources of the information system, as well as user access to these accounts. With PAM, we ensure that only authorized users can access privileged accounts according to defined policies. Additionally, PAM ensures compliance with the principle of accountability by accurately tracing and recording actions performed through these accounts. Many such solutions are available on the market, including those we deploy and manage at WELAN: CyberArk, Wallix, and Teleport. In this model, the management of generic administrative accounts (password creations and rotations, rights, etc.) is no longer handled by administrators but by the PAM solution. Users wishing to connect to resources authenticate to the PAM using their personal accounts, which then grants them access to the appropriate generic accounts based on their assigned rights. It is also essential to enable multi-factor authentication (MFA) on the PAM to ensure segregation between the use of personal and administrative accounts.

This total control allows us to define an account management architecture that aligns with our N-tier policy. Indeed, the scope of account connections is no longer dependent on users, who are also relieved of the burden of managing multiple accounts. Without the limitation of managing numerous accounts, it becomes possible to achieve a level of tier granularity that minimizes the risks of lateral movement within the information system.

The integration of a new server into this model would follow these steps:

1 : Add a new server to the information system. 2 : Reference the server in Active Directory and apply local configurations. 3 : Create generic accounts restricted to the server. 4 : Register the server and its generic accounts in the PAM.

Once all these elements are in place, implementing the N-tier model becomes possible, resulting in a significant increase in the security level of the information system.

Standardization and Automation

Implementing this architecture requires creating accounts for all servers in the information system. For specific architecture, usage, or account availability considerations, it may be necessary to create multiple generic accounts with the same rights on the same server. Indeed, sharing generic accounts can lead to information leaks. For example, when a user leaves sensitive data (such as credentials) in a session opened with a generic account, this information may inadvertently become accessible to another user reusing the same account. To mitigate this risk, dedicated generic accounts limited to specific teams can be created. Creating these accounts, integrating them into the PAM, and managing them daily represents a significant operational workload. To minimize this workload, ensure responsiveness, and maintain service availability, it is necessary to automate recurring tasks related to this model (e.g., creating generic accounts, registering them in the PAM, delegating rights). Automation also involves formalizing naming conventions and standardizing system objects (accounts, groups, organizational units, server names, etc.) to ensure consistent and efficient management.

Delegation of Rights

In an extended information system that would apply this architecture, managing the lifecycle of administrator rights for each user can become complex. To simplify this management, we recommend using an Identity Access Management (IAM) solution and provisioning rights through roles defined within it. This also implies automating the association process between servers and the roles that require access to them.

Limitations

As sais before, this architecture addresses administrative accounts. However, service accounts remain a challenge in the implementation of this model. These accounts may need to connect to multiple servers, creating cross-tier connections. While mechanisms such as Managed Service Accounts facilitate managing these accounts, their integration into the N-tier model is not improved as a result.

In a future article, we will explore how to technically implement tiers in the Active Directory.