Domain Admins – Best Practice and Tracking Down Their Misuse and Proliferation

The Domain Admins Group

Members of this group have full control of the domain. By default, this group is a member of the Administrators group on all domain controllers, all domain workstations, and all domain member servers at the time they are joined to the domain. By default, the Administrator account is a member of this group. Because the group has full control in the domain, add users with caution.

Default Groups: Active Directory, Microsoft Docs

Misuse and Proliferation

The power of a domain administrator account (“domain admin”, or occasionally “da”, for short) makes it incredibly tempting to use for various administration purposes where you need to guarantee that the account used has sufficient privileges. I’ve seen domain admin accounts used for running Windows Services, scheduled tasks, I have even seen one hardcoded into a .NET app deployed to clients (yeah, really don’t do this, you know who you are!). This is universally and unequivocally a bad idea for reasons innumerable, just some of which are listed below.

It goes against “Least Privilege” best practices

For any task, account, group membership, login, absolutely anything on your network, you should only release the minimum amount of permissions needed to carry out that task. This is the principal of Least Privilege, and it helps to tighten the security of your network and prevent permission creep.

It leaves password hashes everywhere

Windows provides authentication throughout the network by passing around hashes of the account password, rather than the password itself. These hashes are stored locally in the Windows SAM file and can be copied and cracked by someone with sufficient skill. If a domain admin or similarly high-privileged account gets compromised, you are, for lack of a better term, screwed. At this point you would have two options available:

1. Take the domain offline, change every password (including the krbtgt twice to block the attacker from issuing valid Kerberos tickets) and then bring it back online;
2. Scrap the whole domain and rebuild it from scratch.

It makes tracking the use (and misuse) of the Domain Admin account harder

Monitoring when domain admin credentials are used on your network becomes much more difficult because the logs will be filled with garbage from its over-use.

What to Check For

The three principal places to check for domain admin accounts being used where they shouldn’t are: Scheduled Tasks, Windows Services and interactive logins.

Scheduled Tasks

Check the Windows Task Scheduler for any schedules which have been configured to run as a domain admin account.

Scheduled tasks are vulnerable to a number of attacks, the simplest being redirecting or replacing the intended executable/script to something else which can allow an attacker to run arbitrary code as the user account setup in the scheduled task. In the case of a domain admin account this is very bad.

Windows Services

It may be tempting to configure a custom or third party Windows Service to run as a domain admin if it needs to interact with network resources. However, this is vulnerable to the same attacks as scheduled tasks, so this should be avoided at all costs.

Interactive Logins

When interacting with remote computers, it can be tempting to use a domain admin account to gain administrator access over it for a “quick fix”. However, this will leave traces of the account on the target computer, not least of which will be its hashed password which can be hacked.

Free Command Line Scan Tool (dascan.exe)

I’ve chucked together a quick and dirty scan tool to help you identify possible misuse cases of a Domain Admin account which you can download for free from the link below.

If I get a chance and demand is high enough I’ll tidy up the source and publish it for anyone to download and modify as they see fit.

What does it do?

It enumerates the Domain Admins group for user accounts, and it will check either the local or a remote computer for the three problem areas above. If found, it will display the details of the vulnerability and return a relevant exit code.

What doesn’t it do?

It won’t make any changes to the target computer or fix any discovered vulnerabilities. Once they’ve been identified, it’s up to you to fix them.

How do I use it?

Run the command with a “/?” or “–help” parameter for full details on what parameters to supply the tool and how to interpret its bitwise encoded return data. This information is copied and pasted below for quick reference.

Usage: dascan.exe [/c <hostname>]
 
Command Line Parameters:
 /c or --computer        - The hostname to scan (defaults to localhost)
 /ru or --remoteuser     - Username to connect with
 /rp or --remotepassword - User account password
 /to or --timeout        - Maximum amount of time to wait for the scheduled task scan
 
Optional Domain Admin Lookup Options:
 /dc or --domain         - Name of the domain controller to connect to
 /du or --domainuser     - Username to query the domain controller
 /dp or --domainpassword - Password for the domain query account

 /nosched                - Disable Schedule Task scan
 /noserv                 - Disable Windows Service scan
 /noprof                 - Disable Profile check

Additional Parameters:
 /p or --pause           - Require a keypress before closing
 /v or --verbose         - Output additional data

Return Code Information (Bitwise code with following possible bits set):
 0 - No domain admin account usage found
 1 - An error occurred
 2 - One or more scheduled tasks with domain admin accounts were found
 4 - One or more Windows services with domain admin accounts were found
 8 - One or more profiles for domain admin accounts exist

Licence and Disclaimer

This utility is released under the CC BY-NC-ND 3.0 (Attribution-NonCommercial-NoDerivs) licence Creative Commons License. Meaning that it can be copied and redistributed at will as long as appropriate credit is given, and it is not sold.

This utility is designed as a quick scan tool to aid in quickly identifying the potential misuse of one or more domain admin accounts, it may not return accurate results under some circumstances and should always be used in conjunction with other security best practices. Int64 Software Ltd does not make any guarantees for the accuracy of any results produced.

Download

You can download “dascan” from the link below.

Download dascan105.zip (22kb)

Mitigation

Use Managed Service Accounts for Scheduled Tasks and Services

When deploying scheduled tasks or custom/third party services to devices, it is recommended that you create a unique Managed Service Accounts (see Managed Service Accounts: Understanding, Implementing, Best Practices, and Troubleshooting) for each one to compartmentalise and limit potential attack vectors.

Managed Service Accounts are a sort of hybrid computer and user account, but inherit mainly from computer accounts, so they will automatically update their passwords on the same scheduled as a computer account (30 days by default). They are also incapable on interactive logins.

Prevent Interactive Login (except where strictly needed)

Domain Admin accounts should be blocked from interactive logins in Group Policy except where that behaviour is strictly required – this should be incredibly rare.

There are solid arguments for removing all Domain Admin (and Enterprise Admin) accounts and only adding accounts back into the groups for the odd occasion that they are required (e.g. disaster recovery). But that’s an Enterprise Security Policy decision which you’ll have to discuss internally.

As is the case with the Enterprise Admins group, membership in Domain Admins groups should be required only in build or disaster-recovery scenarios. There should be no day-to-day user accounts in the DA group with the exception of the local Administrator account for the domain…

Implementing Least Privilege Administrative Models, Microsoft

Limit the Number of Domain Admin Accounts and Who Has Access to Them

Ideally, as stated previously, this should be limited to zero accounts except for the default Administrator.

When contemplating the need for a Domain Admin account, consider the follow:

• Why is it needed?
• Can the same thing be achieved with a non-domain admin account?
• Are you avoiding best practice for the sake of ease?
• Who is going to be responsible for monitoring the account usage and decommissioning it when it is no longer required?

Remember that generic accounts for interactive device usage are poor practice as they essentially anonymise the actions of the person using said account. If two or more people have access to a single account then they each have plausible deniability for any wrong-doing (either deliberate or accidental) that occurs from that account.

Conclusion

Domain Admin accounts are incredibly powerful, and as a result can be very tempting to use when you just need to quickly fix that thing, or query that device, or update that setting; but remember that they only exist for a few specific, well defined tasks to do with (surprise) domain administration.

Any good Enterprise Security Policy should have clear delineation of services and duties which require elevated network credentials, and as a result carefully crafted groups, accounts and Group Policies can be crafted with just a little effort which provide that required access and nothing else.

Have you got any horror stories about the misuse of domain admin accounts or similar? I’d love to hear about them, you can tweet them to me or email me at mestacey@int64software.com.