Auditing Administrators in Active Directory

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.

Control Statement
Administrative access to the network (Active Directory) is limited to appropriate individuals based on job duty and current employment.

 

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.

Risk Statement
Unauthorized administrator access to the network (Active Directory) presents the risk of:
– Inappropriate configuration changes resulting in system downtime or security breach and
– Inappropriate user access changes or account creation.

 

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.

PBC Request
1. A system generated listing of all users with administrative level access in Active Directory including Domain Admins, Enterprise Admins, Administrators, and any other administrative level groups or sub-groups not specifically mentioned.

 

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.

 

2 thoughts on “Auditing Administrators in Active Directory

  • hey christian and shane! got here through mack’s referral in his own IT audit blog. thanks for all these IT audit insights. i’ve already subscribed to your blog and looking forward to more interesting takes on IT audit risks and controls.

    now, two questions:

    1. do we actually still need to ensure that super user/administrative user activity is monitored/reviewed or is it sufficient if we have already validated that the super user/admin access is only restricted to authorized personnel only?

    2. for service accounts, how do you exactly verify that access to the password is only restricted to authorized personnel? i can only think of inquiry and, definitely, that is a weak form of evidence that needs to be corroborated with other test procedures.

    looking forward to your response.

    thanks,
    L

    • Hi L,

      Thanks for the comment and to answer your questions:

      1. It is considered best practices that a company log activity performed by an administrator. There are tools such as IBM Tivoli Monitoring that can keep such logs; however, it is typically not a requirement that these logs are reviewed (that is usually a very large administrative burden). These logs are usually just for tracing activity back to the origin when necessary.

      2. When you think about service accounts there are a few things to consider.
      – Not all service accounts can be logged into. Find out which are strictly service accounts and which can be accessed. (There is a difference between service account and shared generic account.)
      – For those service accounts that can be logged into is that number reasonable and do they serve a purpose? If not, that could be a finding.
      – It is best practices that a company keep a log of all approved services accounts and the individuals who have access to those accounts. You can use password libraries that keep the login credentials to these accounts safe by dynamically changing the credentials on a periodic basis and tracks who is accessing those credentials.

      Beyond that it is mostly an inquiry control, but you should use your judgment as an IT professional to determine if what you are seeing is an issue or not. At a minimum you should recommend, if they aren’t already doing so, that they utilize some of the best practices outlined above.

Leave a Reply