First published on TechNet on Jul 16, 2012
In my role as a transactional PFE, I have the privilege of visiting 40-50 customers per year. Often I’m called in to perform an Assessment of the Active Directory Infrastructure . Without a doubt, one of the biggest challenges most customers face is managing the membership of the privileged groups in their domain. The challenge manifests itself in a couple of ways, but for simplicity let me call out two dimensions of the problem:
1. Privileged groups in the domain have too many members.
2. Some of these privileged accounts are loosely managed, and have passwords that are never/rarely changed.
Before we proceed, let me specify what I mean, when I say “Privileged Groups”. These are built-in groups in Active Directory that have been granted various levels of rights in the domain, from full administrative rights (Enterprise Admins, Domain Admins, Administrators, Schema Admins) to more limited, but still significant, rights (Account Operators, Server Operators, DNSAdmins). Fellow Microsoftie Laura Robinson has a nice blog that details these groups and explains some of their privileges.
Laura further makes the case that these groups should be empty. From a security perspective, her argument is absolutely sound. Unfortunately, I’m an infrastructure dude, so I worry about all the bad things that might happen and how having some of those built-in privileges might help you fix those bad things. So I’m not willing to argue for no members in your (built-in) privileged groups. However, I think we can all agree that having less (privileged accounts) is more (better).
So how many are too many? In our AD risk assessment we flag any privileged group with 20+ members. That’s somewhat arbitrary, but you have to set some goals. I would argue for almost any organization, you should aspire to less than 10 members in each of the most privileged groups (Enterprise Admins, Domain Admins and Administrators). Some of those other groups like (Account Operators, Server Operators, Backup Operators, Print Operators) should probably be empty (see the delegation argument, below).
The challenge is how do you get there from here? If you’re like one of the roughly 75% of customers I visit where these groups have 20-500 members, you probably didn’t design an Active Directory where these group memberships are bloated. And the key word here is design . Unless you have a design for your privileged groups, you will likely always have pressure (political and technical) to unnecessarily add users to these groups. Every administrator in IT wants a domain admin account, so they’re not bothered with access problems. Services are so much easier to deploy when you can simply add the service account to the Domain Admins group. (Hence the large number of privileged service accounts with passwords that never change). This continuous pressure leads you to a place where trying to remove accounts from privileged groups is like playing whack-a-mole. You take some out, and even more come back.
So how do you design your AD for membership in privileged groups? Technically, it’s not that hard. Put your nose into our Best Practices for Delegating Active Directory Administration whitepaper. After you’ve blown through those 500+ pages, don’t forget the appendices. Simply put, you must design your AD (with your own privileged groups), so that you can give every person exactly the rights they should have without dropping them into one of the built-in groups and giving them too many rights.
If you do this, you will find that the most privileged built-in groups (Enterprise Admins, Domain Admins, Administrators) can contain a few number of accounts, and some of the other built-in groups (Backup Operators, Server Operators, etc) can be emptied.
Sounds easy, but it does take some time for study, design and testing. It also takes some time to get the political backing to get the resources and allow for eventual implementation. If that’s a battle you’re not ready to fight, start small by exposing the magnitude of the problem. You may even be able take some small steps in the right direction.
Step 1: Expose the Problem
Below is a PowerShell script which will enumerate the membership of the built-in privileged groups. This includes expanding nested groups to get down to all the individual members. The script also handles duplicates so only unique members are listed – for example, an account that is directly a member of a group and indirectly a member through a nested group. Run the script and it will:
Report On-Screen:
- The group that is being scanned
- The number of unique members (both direct and nested) in the group
- Members with old (greater than 365) passwords
Dump to an output file (AllPrivUsers.csv):
- Information on each unique user in each privileged group such as password age and enabled/disabled.
- Note, users that are members of multiple privileged groups will appear multiple times in the spreadsheet – once for each privileged group of which they are a member.
Note on the Script: Like all my PowerShell scripts, this PowerShell script does not use the Active Directory module that is built-in to 2008 R2. I know the AD module is cool, and lets you write your code much more succinctly. If you’re really clever you might even be able to replace my script with a one-line command. However, the AD module doesn’t help you if you don’t have the AD web services (built-in to 2008 R2 DCs) in your environment. Since many of my customers still use 2003 DCs, I try to write my code for compatibility. My apologies to those of you who are leveraging the goodness of 2008 R2 DCs. For those of you who don’t, contact me and we (PFE and Microsoft Premier Support) can get you on the upgrade fast track.
Step 2: Use the Information to Drive Action
So now what? If you’re concerned or disappointed by the number of users in privileged groups, drive towards designing a delegation model that will help you reduce the membership of users in the built-in privileged groups. If you’re concerned about password ages, you might want to change the passwords on privileged accounts.
What if the privileged accounts are service accounts? While granting a service account the privilege of a non-expiring password is perfectly fine, that does not absolve you from ever changing the password. Aren’t you the least bit concerned that every administrator who’s worked with your Active Directory in the past decade (whether they still work with you or not) knows the password to a privileged account. While you may not be able to prevent a service account from entering a privileged group, you should at least require the owner of that service to change the password periodically. If they can’t, or won’t, you probably shouldn’t be granting them administrative privileges.
Another tool to keep in your belt is managed service accounts. These were introduced in Windows Sever 2008 R2, and should mature even further in Windows 2012. One of the features of managed service accounts is automatic password changes that require no administrative intervention and no service outage.
In all honesty, I hope being able to access/generate this information will give the issue the necessary exposure, and drive you to action. If nothing else, you’ve got another PowerShell script that you can add to your collection, or potentially scavenge some code for your own purposes.
Until next time….
Doug Symalla
Update 8 April 2013. The script on this blog has been updated.
Disclaimer
The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.