The AD Delegation Model (also known as Role Based Access Control, or simply RBAC) is the implementation of: Least Privileged Access, Segregation of Duties and “0 (zero) Admin“. By identifying the tasks that execute against Active Directory, we can categorize and organize in a set of functional groups, or roles. Those roles can be dynamically assigned to the Semi-Privileged accounts. This reduces the exposed rights by having what needs, and does provides an easy but effective auditing of rights. The model does helps reduce the running costs by increasing efficiency. Additionally increases the overall security of the directory, adhering to industry best practices.

The goal is to determine the effective performance of computer management. Designing a directory that supports an efficient and simple organic functionality of the company. Anyone can “transfer” the organigram of the company to AD, but often, will not provide any extra management benefit. Even worse, it may complicate it. Not to talk about security or segregation of duties and assets. Eguibar Information Technology S.L. can design the Active Directory based on the actual needs of the company focusing on computer management model. This benefits of the processes necessary for the daily management,  being more efficient, reducing maintenance costs and providing a high degree of security.

Design Principles

Based on the AD (Active Directory) Forest design, being the forest the security boundary, and a single domain model within the forest, the delegations (based on the Delegation Model) done via groups within the domains, each to its corresponding container or Organizational Unit (OU), as shown in Figure 1 – Forest Security Boundary.

Figure 1 – Forest Security Boundary

Either if the model is regional, functional or hybrid, the delegation technic behind scenes remains: smaller containers (ej. Sites or Servers grouped by types). Those objects do have the same standard configuration to be evenly administered. To keep these objects secured and monitored, those objects (better known as privileged/semi-privileged accounts and/or groups) will be in a separated container.

Multi-Domain design

Although we are referencing a single domain model, the concept applies as well to a multi-domain forest: Each domain configuration must be evenly, as described with the split of administration objects. In other words, what is relative to administer smaller delegated units, must remain within the domain; all the rest (privileged user and accounts) will be managed from the so called “root domain”.

Although is possible and recommended to have a delegation model in a multi-domain environment, we are focusing on a single-domain, single-forest design; after the model definition, architected and all requisites committed, it can extend as needed by the IT business.

Even more, if the delegation structures created within the forest, it does not mean using all them. For example, if the organization implements a central user provisioning system, then the local administrator should not have the right to provision users. But the model is ready to provide such functionality in case of any further change.

Having a uniform implementation, changes (organizational changes, which are more common) are more granular and support the company strategy. Going back to the previous example, the user provisioning system can manage AD users, but if by any chance, there is a specific exceptional requirement where the site should manage users manually, then the model does support it, without changing permissions or modifying existing setup.

Figure 2 – Forest Breakdown of Rights

Model based on Best Practices.

The model intention is to operate with the least privileged access, understanding the least privilege as a set of rights and permissions necessary to complete the given tasks, while remaining fully functional. To establish this model, a logical structure has to be implemented by using privileged access, but once this is complete, only semi-privileged access will be used according to the person’s role.

On Figure 2 – Forest Breakdown of Rights we can appreciate the breakdown of the rights. Starting from the user identity, passing through the corresponding OU, where the object resides, and the semi-privileged access are granting, and getting down to the most privileged access.

The last three levels should remain empty due the security implications that might exist on a day-to-day usage of those privileges. The proposed model should grant all needed rights without jeopardizing the environment security. The “least privileged” technique is well appreciated within Active Directory, but is not exclusive to it. Member servers, workstations, laptops, applications, data repositories, just to name some, should implement this kind of access. More on this topic at Implementing Least-Privilege Administrative Models.

Other Models

Microsoft does provides a so called “Tiering Model”, which is a very good approach. There is a little problem with it: is an “All or Nothing” model. In other words, this model has Domain Admins as tier 0 administrators. All the rest of the users are standard users.

The model we are suggesting it does considers a full range of “Semi-Privileged” users, with different roles defined on each of the “areas or tiers”.

We have to consider several key factors that influence the way this model is build up. To start with: simplicity; the simpler the model, the easier is to maintain and operate. The 10 Immutable Laws of Security Administration mention on its second law “Security only works if the secure way also happens to be the easy way”. So, having a complex, difficult to manage environment will not necessarily provides security. Even worst, it might expose breaches instead. Following the same path, daily operations of a complex environment are more expensive and most time inefficient.

Additional considerations

All this talking is very nice, but we just hit an administration paradigm: How secure is the simplest? Or how simple is the high secure environment? Well, this is quite hard to answer in a simple sentence. There are many ways to measure and estimate the daily operation (unfortunately out of the scope of this document). But once we have this value, we can determine the efforts to maintain it secure and running.