How many enterprise admins on a Windows network is too many?

I’m often asked how many enterprise admins — the most privileged users on a Windows network — a company should have. The answer is straightforward enough: the bare minimum. Doling out that type of power willy-nilly is a great way to expose your systems to attacks. In fact, the No. 1 way to minimize overall security risk is to minimize the number of enterprise admins you have and how often they need to logon. 

The specific number depends on the operational needs and business strategies of each environment, but as a best practice, two or three is probably a good amount. At some companies, I’ve seen anywhere from several dozen to over a hundred, which is far too many. Many organizations simply add every administrator and help desk technician to the enterprise admins group to make it easy for them to fix and configure the computers they need to administer. These employees use their enterprise admin accounts to manage the network, as well as to pick up email and surf the Web. Hackers love that.

Not only should enterprise admin rights be handed out with care, they should be used with discretion. Such accounts should only be used for tasks that span multiple Active Directory domains, and for activities that require that sort of elevated membership, as many network configuration items do. Enterprise admins should not be logged on for surfing the Web, picking up email, or any other task that doesn’t require enterprise admin abilities. 

In most cases, admins can be instead added to the Domain Admins group — which, coincidentally, needs to be protected nearly as much as Enterprise Admins. Alternatively, you can use Active Directory delegation (for more details, see Microsoft’s site). Need to manage all the users in a forest? Use the Active Directory delegation. Need to have full control over every file, folder, and registry key on a server? Again, try Active Directory delegation. I’m hard-pressed to find scenarios where delegation doesn’t work better than assigning dozens of users into the enterprise admins group.

There is a downside to Active Directory delegation: It’s difficult to audit. Delegation creates granular security permissions that are difficult to collect across the enterprise unless you run auditing tools on every forest-joined computer. That’s a big problem, but I prefer it over granting a user full control over every asset and object in a forest by default. 

Half the battle Minimizing the number of highly privileged admin accounts takes you halfway toward decreasing security risk, but it’s not the only thing that matters. Among other recommendations, all admin user accounts should have long passwords, 15 characters or more. This disables the easy-to-break password hashes (e.g. LANMan) and prevents password guessing. Passwords should be changed on a regular basis; every 90 days is a good period of time, although I’m willing to go even longer with 15-character passwords — so 180 days isn’t out of the question. Your audits might flag a lengthier setting.

Passwords of shared accounts should also be changed anytime a member separates employment or changes job duties. Many companies are now requiring two-factor authentication (such as key fobs, smartcards, biometric) for admins. It’s a good practice, although it can be expensive to enable for admins only.

I’m also a big fan of creating dedicated admin workstations for domain or enterprise admins. Elevated users should avoid logging onto regular workstations to troubleshoot problems, if possible. You never know what malware (such as a keystroke logger) may be present. One logon could compromise your network in a big way. Having dedicated admin workstations, which are kept superclean and used only for administrative tasks, is a good way to protect sensitive logon credentials. Some companies require that users RDP from “dirty workstations” to clean admin virtual images as a half-way step, but that still doesn’t remove the threat of a local key logger.

If an elevated user has to log on to a nondedicated workstation or server, the admin should reboot the computer after completing their task (if at all possible), to remove the elevated credential from memory. If not, someone using pass-the-hash tools could obtain the hashes and re-use them to again elevate access.

I’m also an advocate of third-party software that helps companies manage elevated accounts. I often run into Cyber-Ark’s privilege identity manager solutions. It’s pretty cool stuff and perfect for managing elevated accounts. Admin accounts can be locked into a digital vault, then protected by granular policies that enforce rules and checkout procedures in order for an elevated account to be used. One of my favorite features is the one-time-use passwords, where the password is changed for each user and occasion. You can also easily enable auditing of who used what accounts when.

In Windows Vista and later, you can create special audit events anytime someone belonging to a predefined group logons. See KB947223 for more details. In a nutshell, you define one or more groups (using their SIDs) into a local registry key (HKLMSystemCurrentControlSetControlLsaAuditSpecialGroups); thereafter, Windows will generate a 4964 event ID message when someone belonging to the defined group logs on. This is a great way for pulling out useful information instead of just sifting through every regular logon event.

No matter how you do it, you should probably perform periodic audits to see who is a member of your elevated admin groups. It isn’t typical to see the number of members creeping up as time goes on, as “temporary” admins get left and made permanent. You should strive to minimize the number of admin accounts and secure those that are needed.