Ok, once we have a little taste of the “sweet Delegation Model” and its tween brother “Tier Model“, you will be having many questions. And questioning is what we need in order to start building a proper Delegation Model with Tiers for Active Directory ®.
Questions raised on the AD Delegation model.
No. Once a user becomes member of a high privileged group, there is no technical restriction; he can create/change/delete any other administrator. This is the problem with big AD implementations which did not consider a proper Delegation model (or a 3rd party tool which might provide this functionality).
Yes. Active Directory is extremely granular when referred to delegations. We can delegate the task to manage a full partition, certain kind of objects within a given partition, attribute sets for an object or even specific attributes.
A split-delegation is when 2 different teams have similar rights within the same object. This is very common and is recommended to split loads within teams. A very common scenario is: the user provisioning team is in charge to create and delete users, but is the Service Desk team in charge to reset passwords and unblock user accounts, and the Human Resources team who will maintain certain attributes for the user, as it might be the Employee number and type or the organizational description.
In this example, we can see the importance of the “To who do I need to delegate?” and “What it has to be delegated?” questions
Well, this is a very generic and difficult question to answer, or at least it is without having several more following it. We need to identify any person who is making a change within Active Directory, excluding of course typical standard changes as “Changing my own password”.
In smaller scenarios a simple division within operations (reboot a computer, backup and restore data, reset and unblock user, etc,) and administration (create users, groups, access rights, etc.) might be sufficient, but for larger organizations there might be several teams for each area: one group is in charge of granting and revoking access, a different team manages the user provisioning, several teams take care of desktops and laptops, others are responsible for the servers, which are not the same of the infrastructure supporting these, etc.
Here is the Business who will dictate who is responsible of any assigned task, if the task is feasible. In other words, we should be able to identify the persons, or group of persons, who are assigned to run a task against the directory.
Same as the previous question, quite hard to individually response. The simplest, easiest and worst case is to assign Administrator rights, so we will completely ignore it as is not even an option. What we must identify, is what specific action has to be done on the directory, and if it matches with the “To who do I need to delegate?” question, then we already identify a role, which is followed by a delegation.
Following the user provisioning idea, this team oversees creating and deleting users within the directory, so a delegation will be done for the identified team granting the right to ONLY create users.
Security topics around the model
Not really. The model focuses on many “very old, but STILL valid” concepts, which help us to protect our directory. For example, having unpatched systems will render into vulnerable systems, and the only solution is to patch them, reducing the risk thus increasing security.
But when a more advanced thread is ahead, the solutions get more complex. The main concept here is: if you cannot access it, then you cannot tramper with it. The model is restricting highly targeted identities (nice cookie for hackers), minimizing their exposure. The model can be somehow modified and adapted, but there is no other “efficient” alternative to the concept.
Because Active Directory is exposed, and don’t misunderstand this. It is exposed to persons, applications, services and networks, so there is a real risk to get it compromised. There are hundreds of details to take into account in order to objectively evaluate the risk, but the risk is there, and the best thing to do is to manage the risk.
In the old times, just by having an antivirus was enough (Huuh!) to be protected. No internet available. Networks where pretty small, or even inexistent. As the devices where expensive, granting access to anyone was not so easy, so physical security was kind of present.
Today, we have an extreme connectivity, with at least 1 antivirus, anti-Trojans, worms, rootkits, spam… we have access control list for disks, groups, shares, mailboxes… we have many web applications and services, which use any kind of authentication and authorization… databases… social networks… BYOD… AND we have to manage it, assuring the integrity and security of all these. We cannot afford the risk of exposing all this information, or even worst compromising it.
We care about firewalls… networks… IDS… personal FW… antivirus… Authentication… Authorization… so: Why we are not protecting one of the most valuable and critical assets?
This model will not be the “ultimate” security for AD, but will help mitigate credential theft techniques.
Questions raised based on the Tier Model
Any security improvement is welcome, but no single security measurement will help us to protect all our environment; for example, a firewall facing internet indeed will help protecting our network, but will not help us too much on Trojans or worms.
The Tier Model does help us on implementing a set of tiers or buffer zones, and with a set of rules and guides, we can restrict and isolate some of our assets. But here we are missing reducing the overall permissions and rights a user might have, even if this user is within a given restricted tier. Here is where the twin brother comes to play: the Delegation Model can help reduce the those mentioned permissions and rights.
Even more, by implementing both models is not sufficient. We have to be prepared to monitor security, and to properly react on any given event. This demonstrates the need to have several tools (monitoring, analysis, alerting, etc.) working embedded into the models.
Delegation Model vs. Tier Model comparison
|Lest Privileged Access|
|Clean Source Principle|
|Configuration over Convention|
|Segregation of Duties|
|Segregation of Assets|
|Reduce Privileged Accounts|
|Protect from Credential Theft|
|Logical Perimetral Network|