Active Directory N-TIERS Model - Introduction to the N-TIERS Model

After presenting the 3-Tier model and its limitations in the article Active Directory N-TIERS Model - State of Active Directory Infrastructures, today we introduce another Active Directory architecture model: the N-Tiers model.

The N-TIERS Model: A Theoretical Model?

In our previous article, we saw that the 3-Tier model does not sufficiently limit the impact of vulnerability exploitation by an attacker. Indeed, the attacker remains able to move within the silo they compromised, which can significantly affect the information system.

To address this, we propose an advanced tiering model: the N-Tiers model. This model is not intended to replace the 3-Tier model but rather to add a supplementary layer of security.

The principle of this model is to apply an additional level of segmentation within each tier. Technically, the definition of tier is achieved through Authentication Policies and Authentication Policy Silos. This feature, introduced in Active Directory with Windows Server 2012 R2, allows the creation of containers—authentication policy silos—where user, machine, or service accounts can be assigned. Authentication policies can then be applied to these silos, affecting all accounts contained within them. These policies allow for the restriction of the areas of the domain where these accounts can authenticate.
More specifically, authentication policies help control, among other things:

1. The lifespan of the account’s TGT (defined as non-renewable).
2. The criteria device accounts must meet to connect with a password or certificate.
3. The criteria user and device accounts must meet to authenticate to services running under the account.

These policies are applied during TGS and TGT exchanges and thus require the use of the Kerberos protocol for account authentication. This also means that they can only be applied to domain accounts, not local accounts.

When implementing authentication policies, it is recommended to also use the “Protected Users” security group. This security group is designed to protect accounts from credential theft. It enables non-configurable protections on devices to prevent credential caching during member authentication. Furthermore, membership in this group forces authentication via Kerberos, and NTLM authentication is no longer allowed.

Once this mechanism is understood, it is essential to define the tiering logic that will determine the criteria for each account’s assignment to a silo. The segmentation policy applied will greatly depend on the organization’s context and its information system. For instance, silos can be defined by application, application environment (prod, dev, test, QA, etc.), external exposure level (i.e., DMZ), geographic location, security level, or sensitivity.

A good practice is to maintain consistency between the network segmentation strategy and the Active Directory siloing strategy. However, the goal is not to achieve an exact correspondence between the two, as the various levels of network segmentation cannot be replicated in AD, but rather to respect the same logic between the two architectures.

This consideration also highlights the need for a governance instance that connects the network teams with the Active Directory teams. Indeed, organizational bottlenecks due to lack of communication between these teams are common. Such issues could present significant obstacles to the implementation of the N-Tiers model.

Implementing Authentication Policies alone is not enough to establish the siloing model and consider Active Directory as secure. Appropriate GPOs must also be applied to each silo. In an N-Tiers model, no GPO other than the default one should be applied at the domain level. These GPOs must be configured independently for each silo to meet the security needs of each zone.

By implementing these features, we can ensure that each account’s access is restricted solely to its designated usage area. For example, a developer will only have access to the information system elements related to development, while the accounting department will only be able to connect within its designated zone. This minimizes the permeability between the different zones of the system by applying the principle of least privilege as much as possible. This logic has significant consequences for the system’s security level, as it implies that the compromise of an account will only affect the restricted zone (silo) it has access to, and an attacker will not be able to exploit residual privileges assigned to the account. Intra-Tier movements, which were still possible under the 3-Tier architecture, are thus significantly reduced.

In our article on the 3-Tier model, we discussed the importance of understanding the various attack paths that an attacker could exploit. This consideration was already complex, but it becomes even more so in this N-Tiers model. Indeed, mastering the system’s flows must reach an extremely fine level of detail, as this will define both the silos’ perimeters and their interactions.

The Operational Limitations of the Model

That being said, the limitations of this model quickly become apparent. Strictly limiting account access rights rarely aligns with users’ actual needs. For example, in a siloing model based on application environments, a user account would be restricted to the production, test, or QA environment. However, in reality, a single developer may need access to several (or all) of these environments. This issue becomes even more evident when it comes to administrative rights. In this logic, users would see their number of accounts multiplied by the number of silos they need access to, which, depending on the siloing strategy, could quickly lead to dozens of accounts.

Given such a constraint, and without a solution to mitigate it, it would be unrealistic to expect users to maintain strong passwords and enable MFA on all of these accounts. Thus, a logic initially designed to secure the system could actually end up weakening it. It is because of this complexity in implementation and usage that Microsoft does not mention this model, and no organization has attempted to adopt it.

In our upcoming articles, we will explore potential solutions to address this limitation and make the N-Tiers model implementable. We will also cover the more technical aspects of implementing this model.