Active Directory (AD) is used for authentication and authorization across a network. By definition, it is a system that needs to be protected and managed with security at the forefront. We often hear about AD domain administrators holding the keys to the kingdom. While this is absolutely true, several other groups also hold privileges and need to be protected as much as, if not more than, domain administrators. The two groups this article focuses on are Enterprise Admins and Schema Admins.
The first domain in an AD forest is unique from all other domains in that forest. There are two groups in this first domain that we must be aware of: Enterprise Admins and Schema Admins. If you create a child domain or tree domain in the forest, those domains will not get their own Enterprise Admins group or Schema Admins group.
Enterprise Admins
Partner with Microsoft experts you can trust
If it’s time to take that first step toward leveling up your organization’s security, get in touch with Ravenswood to start the conversation.
Enterprise Admins is a built-in group that by default has administrative access to all domains in a forest. Enterprise Admins is a member of the Administrators group in all domains in a forest. There are very few tasks that require the use of an Enterprise Admin account. The tasks that require this level of access are forest-wide and are executed very rarely over the life of an AD forest.
When Enterprise Admin privileges are required, it is typically because something in the AD forest’s Configuration partition must be changed. This partition gets replicated to all domain controllers (DCs) in a forest but can only be edited with Enterprise Admin access. In a forest called andyland.com, the configuration container is CN=Configuration,DC=andyland,DC=com.
The screenshot below shows the effective access for Domain Admins on the Configuration container. Note that the object owner is the Enterprise Admins group. The Domain Admins group is denied access to all permissions for this container.
Figure 1 – The effective access for Domain Admins on the Configuration container
Some specific tasks do require Enterprise Admin access. A few of the most common tasks include the following:
- Adding either a child domain or tree domain to an existing forest
- Software that requires updates to the Configuration partition of an AD forest, such as Exchange Server
- AD forest recovery
- “Break glass” scenario for child domains in the forest
The Enterprise Admins Group Should Be Empty
The Enterprise Admins group is in the root domain of a forest. Domain Admins in this domain have full control of the root domain. Therefore, root Domain Admins can add and remove users from the Enterprise Admins group. As noted previously, valid reasons to use an Enterprise Admin account occur very rarely. A Domain Admin in the forest root can always elevate anyone, including themselves, to Enterprise Admin if necessary.
A side benefit of having an empty Enterprise Admins group is that it adds just enough friction to ensure that enterprise-wide changes requiring Enterprise Admin rights are done purposefully and methodically.
Schema Admins
The AD schema contains formal definitions of every object class that can be created in an AD forest, as well as their attributes. As an example, two of the most common classes in an AD schema are user objects and computer objects. The schema can be found under the Configuration container. In a forest called andyland.com, you can find the schema partition at CN=Schema,CN=Configuration,DC=andyland,DC=com.
There are very few instances when it is required to change or extend the schema. Typical examples of extending the schema include updating AD to a new version of Windows or installing Exchange, which adds numerous attributes to user objects. Additionally, sometimes third-party vendors will require schema extensions for their application to work with AD.
Other than editing the schema, there is one other procedure that requires Schema Admins group membership. You need to be a Schema Admin when you are transferring or seizing the Schema Flexible Single-Master Operation (FSMO) role. The Schema FSMO role is the DC in the forest with a writable copy of the schema.
Below, you can see that I am in the Enterprise Admins group but I still do not have access to transfer the Schema FSMO role.
PS C:\> netdom query fsmo
Schema master Andy-DC2.andyland.com
Domain naming master Andy-DC1.andyland.com
PDC Andy-DC1.andyland.com
RID pool manager Andy-DC1.andyland.com
Infrastructure master Andy-DC1.andyland.com
The command completed successfully.
PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity andy-dc1 -OperationMasterRole Schema
Move Operation Master Role
Do you want to move role 'SchemaMaster' to server 'Andy-DC1.andyland.com' ?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): Y
Move-ADDirectoryServerOperationMasterRole : Access is denied
At line:1 char:1
+ Move-ADDirectoryServerOperationMasterRole -Identity andy-dc1 -Operati ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (andy-dc1:ADDirectoryServer) [Move-ADDirector...ationMasterRole], ADExcept
ion
+ FullyQualifiedErrorId : ActiveDirectoryServer:0,Microsoft.ActiveDirectory.Management.Commands.MoveADDirectorySer
verOperationMasterRole If I add myself to the Schema Admins group, I can successfully transfer or seize the Schema FSMO role if I need to.
PS C:\> get-aduser andy -Properties memberOf | select-object -ExpandProperty memberOf CN=Domain Admins,CN=Users,DC=andyland,DC=com CN=Schema Admins,CN=Users,DC=andyland,DC=com PS C:\> Move-ADDirectoryServerOperationMasterRole -Identity andy-dc1 -OperationMasterRole schema Move Operation Master Role Do you want to move role 'SchemaMaster' to server 'Andy-DC1.andyland.com' ? [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): Y PS C:\>
Just like the Enterprise Admins group, there is very rarely a need to use Schema Admin privileges. This group should be empty as well. Schema changes should always be done with testing, preparation, and a solid understanding of why the changes need to be made.
Keeping your Enterprise Secure
Understanding the roles and functions of all the highly privileged groups in AD is essential to maintaining a secure authentication and authorization platform in your enterprise. Keeping track of all these groups and the different rights associated with them can be confusing and hard to maintain. Ravenswood Technology can help! Contact our team to get started.
