Note: For this post I am operating under the assumption that you have a basic understanding of what Active Directory is and why a company uses it. If you do not have that basic understanding try these articles in Wikipedia or Microsoft.
Why do we care about administrators?
An Administrator in Active Directory, if inappropriate, presents almost unlimited risk to a company’s I.T. Environment because an Administrator has almost unlimited control of the company’s system. For example, an Administrator may have access to:
– Manipulate system configurations (password parameters, backup schedules, shutdown systems etc.),
– Control user access,
– Create user accounts, and
– Potentially control the flow of data on your network.
How to Audit Administrative Access to Active Directory
The trick to appropriately auditing administrative access in Active Directory is understanding what groups in Active Directory grant a user Administrative privileges. In general, you should inquire with the Network Administrator to gain an understanding of which groups grant a user Administrator level privileges, but here is the process:
1. Inquire with the Network Administrator to understand which network(s)/domain(s) are included in the scope of your audit and as to all groups that grant users Administrator level privileges. It is possible that depending upon the application or locations you are auditing that only part of the company’s network may be included in scope. (For example, if you are only auditing one application and that application is only relevant to New York – then that may reduce your audit scope if New York is segregated to its own domain.)
2. Ensure that your request includes all known default groups (see below) in Active Directory that grant Administrative access.
3. Once you receive the listing of Administrators verify that the accounts belong to individuals (aren’t sub-groups), that the individuals are currently employed with the company, appropriate based on job duties, and that there are no segregation of duties violations. If the account is a system or generic account inquire as to its purpose and validity.
Common Default Administrator Level Accounts
|Group or Account Name||Default Location||Description|
|Enterprise Admins||Users container||This group is automatically added to the Administrators group in every domain in the forest, providing complete access to the configuration of all domain controllers.|
|Schema Admins||Users container||This group has full administrative access to the Active Directory schema.|
|Administrators||Builtin container||This group has complete control over all domain controllers and all directory content stored in the domain, and it can change the membership of all administrative groups in the domain. It is the most powerful service administrative group.|
|Domain Admins||Users container||This group is automatically added to the corresponding Administrators group in every domain in the forest. It has complete control over all domain controllers and all directory content stored in the domain and it can modify the membership of all administrative accounts in the domain.|
|Server Operators||Builtin container||By default, this built-in group has no members. It can perform maintenance tasks, such as backup and restore, on domain controllers.|
|Account Operators||Builtin container||By default, this built-in group has no members. It can create and manage users and groups in the domain, but it cannot manage service administrator accounts. As a best practice, do not add members to this group, and do not use it for any delegated administration.|
|Backup Operators||Builtin container||By default, this built-in group has no members. It can perform backup and restore operations on domain controllers.|
Be Cognizant of Service Accounts
When auditing administrative users in Active Directory, also be aware of Service Accounts and inquire about their function within the organization.
Service accounts are used to run background processes on systems (also called a daemon account in Linux) and often times have administrative privileges.
These accounts are potentially risky because they:
- Often time have passwords set to never expire.
- The passwords are often known by many users.
Control risks associated with service accounts by:
- Suggesting that service account passwords be rotated (not feasible in some cases)
- Verifying that local login is not permitted for service accounts.
- Verifying that access to service account passwords is restricted to only personnel who require the information.
In a future post, we’ll explore how to properly manage service accounts using the SetSPN feature in Windows Server.