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.
Having the delegation model in place can give the needed granularity to easily adapt to future changes in the business. All delegations are just some Access Control Lists (ACL), assigned to Security Groups where the “Key” user is member of. By following manufacturer best practices, delegation is done to groups and not to users. This give us the ability to grant or revoke any delegated right by just adding or removing the user from the corresponding group.
Technically speaking, what is the Delegation Model?
The Delegation Model is defined by several hundred System ACL, organized in such way that the required roles can be mapped to this implementation. This is done by using a kind of “Match Pair” of Domain Local Groups and Global/Universal groups. Each member of this pair will grant certain functionality:
- The Principal will be a Domain Local Group used to grant rights and/or permissions.
- Global/Universal Group will only have users and/or Global/Universal groups as members
The System ACL will have the “principal” Domain Local Group on the ACE (Access Control Entry), defining the Access Rule (AR) to the object.
The delegation model strategy is as follows (on image Figure 2 – SACL strategy from left to right):
- Define the required AR on the object’s SACL (many AR can be defined to achieve desired results)
- Define the “Principal” Domain Local Group on the Access Control Entry
- Add Global/Universal group (matching pair) as member of the Domain Local group
- If required, add Global Groups to other Global Groups. Universal Groups should only have Global Groups as members (no users)
- Add the user to a Global Group
 |
| 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.
There are several key factors influencing how this model is built up. To start with is the simplicity; the simpler the model, the easier is to maintain and operate. On the introduction section of this document, I did reference the 10 Immutable Laws of Security Administration and its second law says “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.
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.
The idea behind the scene is to separate the main Active Directory ® operational tasks or formal/un-formal roles and organize them in a simple and secure way. This will grant the ability to control the delegation points as well as the needed security configuration of the environment. Of course, the idea is to have security all over the environment, but there are some areas which must have higher security than others, and beside this, we have to start from one point, so is better if we take care of the most sensible part of it.
As already explained before, there can be as many areas as the IT business requires, but as few as possible in order to maintain simplicity. Remember: the simpler the better. Thereof the simplest design, 3 areas are to be build.
The areas
The levels explained before (Admin, Sites & Servers) can be considered as the IT Business representation of the model. Those are, in general, how the operation and maintenance of the environment will be configured. Now, on this section, we will introduce the main 3 areas where all the objects will be located and mapped to the previous description.
We will organize everything (unless there is a well justified, documented and approved reason to have an extra area) organized into 3 OU sub-trees, better referred to as AREAS or TIERS. Each of these areas has its own characteristics based on the objects contained and the function those objects develop. Each of the three below described sections will be discussed an analyzed in more detail latter in this document.
| Name | Description |
| Administration
(Also referred as Tier0 or Red Area) |
This is the main, and most important Area within the model. The model itself is “stored” in this OU subtree, but not exclusively; any permission, setting or configuration which is not specifically assigned to an area, it will automatically be considered as part of this one. This area contains all Administrative accounts, all the groups with specific granted rights, all privileged users/Groups/Workstations, etc.
The Administration area (or whatever name is used instead) is the engine of the delegation model. For this reason, the security implemented here is different from any other area. Same way the monitoring of such content must be implemented in accordance of this function. Any change on this area, from the creation of a new user, to a change on the delegated rights, is owned and authorized by the Infrastructure Architectural Team of the environment.
|
| Servers
(Also referred as Tier 1 or Green Area) |
This area is designed to host the servers. As each server provides different services a sub-division of those is implemented. For example, database servers provide specific services and have different access requirements than the web services; but all of those have practically the same needs when talking of operation and monitoring. So, a combination of global operation/administration and the sub-category of the server will provide the security and accessibility required.
|
| Sites
(Also referred as Tier 2 or Blue Area) |
This area is where all users, workstations, laptops and groups will reside. All day to day objects will be created and maintained in this area. Although some of the required objects are not site specific, those still belong to this area; A transversal “site” might be created in order to accommodate such requirement.
The area will be created evenly for all and each site, creating a flexible and robust delegation. As each site will have a standard set of delegations based on groups, these delegations can be granted and revoked on the fly, just by changing the corresponding group membership.
|
| Table 6 – Description of the 3 Main Areas | |
By setting up these Areas or Tiers, we are effectively implementing a “Credential Partitioning” scheme. This comes among some basic principles that must be implemented and strictly respected. Credentials from one area cannot be exposed by, for example, log on a different tier. This can be achieved by assigning exclusive “Privileged Access Workstations” with a set of configurations and restrictions.
