If you are auditing Active Directory (AD) the most important “big miss” I see from auditors is neglecting some of the less-than-common administrator level accounts within AD.

In general, there are two types of accounts that I focus on when I audit AD.

1. Accounts and groups with explicit Administrator privileges, and
2. Accounts and groups with inherited Administrative privileges.

Accounts and Groups with Explicit Administrative Privileges

Dependent upon the Windows version you are working with the list of Admin accounts may vary. So you should  be sure to include the appropriate request in you information request list (PBC or IRL). Here is the list of accounts within Active Director with explicit Administrator privileges that you should be concerned.

Windows 2000 <SP4 Windows 2000 SP4 –Windows Server 2003 Windows Server 2003 SP1+ Windows Server 2008 –Windows Server 2012
Administrators Account Operators Account Operators Account Operators
Administrator Administrator Administrator
Administrators Administrators Administrators
Domain Admins Backup Operators Backup Operators Backup Operators
Cert Publishers
Domain Admins Domain Admins Domain Admins
Enterprise Admins Domain Controllers Domain Controllers Domain Controllers
Enterprise Admins Enterprise Admins Enterprise Admins
Krbtgt Krbtgt Krbtgt
Print Operators Print Operators Print Operators
Read-only Domain Controllers
Replicator Replicator Replicator
Schema Admins Schema Admins Schema Admins

AUDIT NOTE: Some accounts, like “Print Operators”, do not sound like an Admin account, but shouldn’t be missed. That is why it is important to understand the system and the version you are auditing.

Accounts and Groups With Inherited Administrative Access

Typicially, when you request a list of Administrative accounts you not only have to scrutinize what users may have access to the built-in Administrative accounts (listed above), but also those users, groups, and system accounts that may exist within an Administrative group.

AUDIT NOTE: Unfortunately, getting detail at this level usually requires follow-up audit requests because the Administrator rarely provides this detail to the auditor by instinct.

In the example below you would need not only the “Administrator” account, but also the “NY Group” group membership and the “Manhattan Group” memberships (totaling 9 users with Admin access). This same exercise must be performed for every Administrator-level account in Active Directory.

Note: This isn't actually what AD looks like. Usually lists are exported to excel or via screenshot.

Note: This isn’t actually what AD looks like. Usually lists are exported to excel or via screenshot.

Is Access Appropriate?

Once you have identified all users and accounts with Administrative access the next thing to do is determine if that level of access is appropriate. Here are a few questions you should ask:

1. Is the employee currently employed with the Company?
2. Does the employee’s job function require Admin access?
3. Does Management agree that the user should have Admin access?
4. Does the user have any conflicting roles or levels of access? (Development, Executive Leadership, or Money Management Roles would typically be inappropriate)

The answers to these questions should help you gain reasonable assurance as to the appropriateness of each user’s access.

User Access Considerations

It is also important to consider if the client you are auditing has integrated Active Directory to control access to applications and systems across the business (i.e., Accounting and Business Systems).

If so, then when you evaluate user access across each system you will have to consider inherited access (the screenshot above) for each application. It is possible that entire groups or portions of the company has inadvertently been given system access to perform critical functions. If you fail to dive deeper into each group and the group’s membership that error will go unresolved and could cost your client dearly.

Are we missing anything? Let us know in the comments.