I was thinking of starting a new category in my blog called “You don’t need Domain Admin”.
I will use this to gather info about delegation from Active Directory out to the client in different cases and needs.
I personally think delegation of roles and responsibility is an important part of securing the infrastructure. If everybody had access to everything or has the ability to gain access to everything on himself, well then the security is gone.
I will start with something that I see almost everywhere and it can never be justified when you start talking about it. One of the first thing I look at when I’m in a new AD environment is the high-privileged group memberships. There is always so many users and service account members I always fall of the chair, and when I get up and ask about it I always get the same answers.
– They said they need it.
– It doesn’t work otherwise.
– It was the easiest way.
That’s not good answers.
First of all, all objects in Active Directory is securable, you can basically delegate everything in different levels adjusted to your environment. Likewise you can also delegate rights to the servers, clients and services.
This is not an easy quest but it is really important and has to been done. And to get started I want to go thru a few high privileged groups and try to explain the purpose, how and when to use them.
- Built-In Administrators
- Domain Admins
- Enterprise Admins
Members of these groups is considered as high-privileged accounts. The important thing to know is that there is a difference between privileged and delegated permissions. If you want to know more about the difference I have another short post about it: http://secureidentity.se/admin-privileges/
If you read up on Microsoft TechNet about default groups at: http://technet.microsoft.com/en-us/library/cc756898(v=ws.10).aspx you see the difference of these groups and their access levels.
built-in Administrators:
| Administrators | Members of this group have full control of all domain controllers in the domain. By default, the Domain Admins and Enterprise Admins groups are members of the Administrators group. The Administrator account is also a default member. Because this group has full control in the domain, add users with caution. | Access this computer from the network; Adjust memory quotas for a process; Back up files and directories; Bypass traverse checking; Change the system time; Create a pagefile; Debug programs; Enable computer and user accounts to be trusted for delegation; Force a shutdown from a remote system; Increase scheduling priority; Load and unload device drivers; Allow log on locally; Manage auditing and security log; Modify firmware environment values; Profile single process; Profile system performance; Remove computer from docking station; Restore files and directories; Shut down the system; Take ownership of files or other objects. |
As stated from the TechNet diagram the default members is Domain Admins (DA), Enterprise Admins (EA) and the Built-In Administrator.
If we talk about the Administrator for a second I want to point out that this is an account that almost never should be used. It’s an account that gets created in every domain by default and you use it to set up the initial structure when you build your new forest root domain. When it’s no longer needed you should disable it and only use it in a disaster and recovery scenario.
Since the DA and EA is nested in the Built-in Administrators group I don’t see any reasons for having other users as members in this group.
Domain Admins:
| Domain Admins | Members of this group have full control of the domain. By default, this group is a member of the Administrators group on all domain controllers, all domain workstations, and all domain member servers at the time they are joined to the domain. By default, the Administrator account is a member of this group. Because the group has full control in the domain, add users with caution. | Access this computer from the network; Adjust memory quotas for a process; Back up files and directories; Bypass traverse checking; Change the system time; Create a pagefile; Debug programs; Enable computer and user accounts to be trusted for delegation; Force a shutdown from a remote system; Increase scheduling priority; Load and unload device drivers; Allow log on locally; Manage auditing and security log; Modify firmware environment values; Profile single process; Profile system performance; Remove computer from docking station; Restore files and directories; Shut down the system; Take ownership of files or other objects. |
The Domain Admins group is a very powerful group and is a great target for malicious users, in fact obviously all groups covered here is a high target, and one reason is that they are, from a security perspective, considered equal.
A Domain Admins group exists in every domain, it is member of the Built-in Administrators group on DCs and all member servers and clients in its domain. If a malicious user would get in hold of an account with DA privileges the whole domain is compromised, and even the Forest is in jeopardy.
So, when to use it?
In the daily operations no one should be a member of this group. Basically everything for the daily operations can be delegated and should be, after the principle of Least Privilege.
To keep it at a minimum leave the default membership with the Administrator account disabled and only add users to the DA group when needed for domain wide configuration of your AD domain e.g. promote/demote a DC, move domain wide FSMO roles, raising Domain Functional Level and domain services troubleshooting.
Enterprise Admins:
| Enterprise Admins (only appears in the forest root domain) | Members of this group have full control of all domains in the forest. By default, this group is a member of the Administrators group on all domain controllers in the forest. By default, the Administrator account is a member of this group. Because this group has full control of the forest, add users with caution. | Access this computer from the network; Adjust memory quotas for a process; Back up files and directories; Bypass traverse checking; Change the system time; Create a pagefile; Debug programs; Enable computer and user accounts to be trusted for delegation; Force shutdown from a remote system; Increase scheduling priority; Load and unload device drivers; Allow log on locally; Manage auditing and security log; Modify firmware environment values; Profile single process; Profile system performance; Remove computer from docking station; Restore files and directories; Shut down the system; Take ownership of files or other objects. |
As you can see the Enterprise Admins exists only in the Root Forest Domain but is member of any domains Built-in Administrators group in the entire forest. Members of this group controls the whole forest.
This group should only be used when doing forest wide configuration e.g. create/remove a new domain, forest trusts, raising Forest Functional Level and managing forest trusts. And last for deep dive troubleshooting.
It’s very rarely users would need membership of this group, leave it default empty with default Administrator account, and only add members when necessary.
Thoughts and questions:
One big problem today is that many accounts is members of high-privileged groups for the simple reason that they believe they need it all the time, or they are just lazy and use the easiest way to give out permissions. The easiest way is not always the best way, and in this case it’s so far away from being the best way.
Do you really think it’s good that your 1st line support guys have DA access just to be able to update info on user objects or modify a few group memberships?
Is it really good to install applications and services running on a service account that is DA? If the application has a vulnerability and gets hacked the hacker now owns the whole domain or worse the entire forest.
And the worst I have seen, does a computer really need to be DA? It will be quite a fun challenge to protect that computer is all I have to say.
Since members of any of these mentioned groups has the privilege to add themselves to one of the other groups, all of these should be considered equal and treated/protected with the same highest classification.
If a user gains access to the Administrators or DA groups in the root domain, they can add themselves to the EA group and now has access to the complete forest. There are also attacks that can be done by compromising a child domains DA accounts and work themselves up to the forest root. This apply on malicious outsiders and the rouge Admin in your company. Remember the outermost security boundary of administration is the AD Forest.
The delegation part of it:
As you may be noticed I mentioned that the groups should be empty when not in use, and disable the Administrator account. Maybe sounds weird but it is manageable.
By delegating a group the possibility to add members to the admin groups you don’t need to have members in the high-privileged groups all the time. You could still do a privilege escalation attack, but this is just the start of securing your AD environment.
By doing this way you also enforces the Least Privilege principle and also protects your admins for configuration errors. If you don’t have default has access to something, then you can’t (almost) break it.
In a good delegation model you have two sets of delegation. The Service Management and the Data Management.
Service Management:
The service management users is the ones that maintain the services and availability of Active Directory, plan and upgrade the domain/forest.
These users can be divided in different levels of responsibility and a subset of these admins should have the ability to add or remove membership of the high-privileged groups when absolutely needed.
Data Management:
The data management users is responsible for the data stored in the AD domain. They create and maintain the delegation model of OU structure, provision and manage groups and accounts. And services/application data stored in AD.
These users can be divided in to many different departments with their own responsibilities of applications and application data stored in AD, or servers in the domain.
They never need Built-In Administrators, DA or EA privileges.
This isn’t an easy task, and you can start with minimizing the number of admins and remove all the service accounts. It has been done over and over in large Active Directory environments to keep the membership to maximum of 3-10 admin users so it isn’t impossible.
The goal should be to leave the high-privileged groups ideally empty.
Until next time:
And to end this post I want to quit with a few things:
Whenever someone asks for administrator access, ask yourself (hand him) do he really need this?
If a software vendor requires administrator account for their service/application to work, ask them why they don’t applies the principle of Least Privilege when they’re developing the software. It’s a fundamental part of IT security. And should be a requirement when buying new software.
How many things do you know about that really need Administrator rights everywhere in your AD Forest?
Is the laziness worth the impact of a compromised domain/forest? I promise you will need to work hard when it happens.
And at last, there is absolutely no need for a single user to always be member of all the admin groups at the same time for some kind of weird redundancy.