Auditing Commonly Missed Administrative Accounts in Active Directory

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.

5 thoughts on “Auditing Commonly Missed Administrative Accounts in Active Directory

  • quick question: i understand that best practice dictates to disable the default Administrator account and have the client create individual Admin accounts for the administrators for accountability. but sometimes the client says it’s not possible as they need to have the default Administrator account active for processes. is that rationale valid?

    • I think they might be referring to the Local Admin accounts on each system. In that case, I have seen applications before that will require this. I feel like it is poor app design to require it but it happens…

      As for a default Admin account in the Windows Active Directory, no there is no rationale. If the client needs an Admin Account for active processes, they should research how to set up Service Accounts to perform that task for them.

      Of course, I have also seen poorly developed in-house apps that will want to require a logged on account to act as the admin account, but in my experience these are exceptions to the rule and the risk could usually be mitigated easily enough.

      • thanks for the clarification, shane. nope, it’s for AD. i usually encounter this observation and i’ve always been consistent about recommending to disable the default Admin account and create individual accounts for administrators and then we go back to their rationale about using it for system processes. but you were right, a service account should be the appropriate ID to be used for those, not the default Admin account as that will pose more risks.

        thanks for all these IT audit tips, shane! it’s really a very good site to keep us informed and make sure that we’re doing the right thing in our audits. kudos!

    • @L

      I agree with Shane’s comment, but I wanted to offer a couple of other thoughts around mitigation if renaming the admin account is not feasible for some reason.

      1. They can add an automated monitoring control (i.e., Email alerts anytime anyone logs into the admin account or any time an action is performed with the admin account outside of normal functions).
      2. They can add a control to periodically review for last login to ensure that the admin account is not being used by humans.
      3. They can make login to the Admin account a firecall only account (meaning anytime needs access to the account they have to request the username and password which is stored in a secure file with management).

      Overall – it is much easier and reduces a lot of risk just to disable the account and disallow usage of generic admin accounts.

  • other user groups i check are account operators, group policy creators, and server operators. although you’re right, these don’t seem like as significant as administrators, domain admins, enterprise admins, etc. but should still be checked,

Leave a Reply