AD Delegation Model with Tiers
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. EguibarIT 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.
Best practices for tiered delegation in Active Directory.
The delegation model is based on the concept of tiers. Each tier represents a level of responsibility and access within the Active Directory environment. The tiers are designed to separate duties and minimize the risk of privilege escalation. The most common tiers are:
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.
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 configured, 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".
This does not mean that the delegated units cannot be managed from the root domain, but the delegation model must be applied within each domain. This provides a more granular control of the delegated units, and a better segregation of duties.
For example, if the organization has a domain for each geographical location, then each domain must have its own delegation model, with its own set of policies and procedures to manage the delegated units.
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 are 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.
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 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
There are many models out there, but most of them are not flexible enough to adapt to the different needs of the companies. Some of them are too complex to implement and maintain. Others are too simple and do not provide enough security. The model we are proposing is based on best practices and is flexible enough to adapt to the different needs of the companies.
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.
Another key factor is the least privileged access. The model must provide the minimum rights to perform the tasks, but without jeopardizing the functionality. This is a very delicate balance, and it is not always easy to achieve. But once achieved, it provides a high level of security and efficiency.
Additional considerations
There are other considerations that must be taken into account when designing the model. For example, the model must be flexible enough to adapt to the changing needs of the organization. It must be able to accommodate new roles and responsibilities as they arise. It must be able to scale up or down as needed. The model must be able to integrate with other systems and processes within the organization. It must be able to support the organization's overall security strategy.
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.