First published on TechNet on May 18, 2014
Hello again, Tom Ausburne with another post we think you’ll enjoy. With all of the security breaches we keep reading about on the Internet these days, I keep getting asked how to make servers and workstations less vulnerable to attack. The list of things you can do are extensive and more than I could ever cover in a single blog post.
Today I decided to focus on one that is simple to implement, changing the local administrator’s password on a regular basis. If you only have one computer then this is an easy thing to do. But what about when you have thousands of servers and tens of thousands of workstations? Now we need a little bit of automation to keep things moving along smoothly.
The first thing that might come to mind is to use Group Policy Preferences . Because of the security concerns with storing passwords in Group Policy Preferences, Microsoft just released a security patch, MS14-025: Vulnerability in Group Policy Preferences could allow elevation of privilege , that removes this functionality. Once you apply this patch, this is no longer a usable option. Since some of you may be doing this already, I'll talk about this in a little detail and explain why we removed this.
1. Start the Group Policy snap-in.
2. Expand Computer Configuration
3. Expand Preferences
4. Click Control Panel
5. Right-click Local Users and Groups
6. From the menu select New - Local User .
7. Select Update as the action
8. Type Administrator into the User name text box
9. Type the new password into the Password text box, confirming the password in Confirm Password text box.
10. Press OK .
That was pretty simple right. It is, but it is not all that secure. You see the stored password is obfuscated. That’s is a fancy way of saying that the password is converted to an unreadable format. Unreadable doesn’t mean secure however. And all machines that get this policy will have the same password. The other problem with this solution is that although the password is encrypted using AES 256, the private key for the encryption is located on MSDN.
The passwords are stored in the XML file that Group Policy Preferences uses to store its data. When you set this up you are even warned about this:
Let’s take a look at that file. You can see that while the information shown below in yellow isn’t the password I used (which was Password1), it is still readable by any authenticated user as they all have read access to Sysvol.
Let’s take this a step further. Using a simple PowerShell script (more info found at the link) that utilizes the encryption key that was easily available on MSDN, I was able to get the password with a few keystrokes.
I’m not sure I could ever in good conscious recommend this to anyone who is serious about security. Once this password is discovered I am opening myself up to a Pass-the-Hash (PtH) attack. So what else can you do?
If you are a Microsoft Premier customer you have the option to get a Proactive Operations Program – Securing Lateral Account Movement (SLAM) delivery (we typically call it POP-SLAM ). This course is an advanced course for implementing mitigation lateral movement mitigations from Microsoft’s Pass the Hash Whitepaper. It covers an overview of Pass-the-Hash (PtH) and ways to mitigate it, understanding the breadth of related credential theft risks, risks of using shared passwords, the enforcement of local account restrictions, randomized local Administrator account passwords, recovery procedures for privileged account passwords as well as real world capabilities that you can implement into your environment to compartmentalize and defend against lateral traversal attacks using built in Administrative credentials. (Updated 11-4-14 to reflect new name and add clarity).
Note: If you are a Microsoft Premier customer and would like more information on this delivery, please contact your Technical Account manager. If you aren’t a Microsoft Premier customer, contact us and we can get you talking to the right people .
I know what many of you are saying. I’m too small to be a Microsoft Premier customer but I still want to be do something to protect myself. What can I do? Glad you asked. One of our Microsoft Consulting Services (MCS) engineers wrote a solution to this problem that anyone can download and implement with ease. It works with Windows 2003 SP1/XP and above so as long as you have an Active Directory environment you should be good to go. You do have to be running domain controllers that are running Windows Server 2003 SP1 or a later because this solution uses confidential attributes which were introduced in 2003 SP1. This feature does not depend on whether a domain or a forest functional level is enabled.
So if you want to follow along with my installation instructions, you might want to go ahead and download the files. You will need the Installers and Documentation files.
Solution for management of built-in Administrator account's password via GPO
http://code.msdn.microsoft.com/Solution-for-management-of-ae44e789
While you are downloading these let’s talk about what this solution is designed to do:
• Password must be unique and random on each computer
• Password must not be guessable from name of workstation, MAC addresses, etc.
• There must be a way for eligible people (IT support staff) to easily know the password when necessary
• Password management solution must scale to support thousands of computers
• Password management solution must be easily deployable and manageable
• Password management mechanism must be resistant against tampering with
• Password management solution must support renaming of built-in Administrator account
• Password management solution must offer the mechanism for bulk password change when necessary
• Solution must be able to correctly handle the situation when computer is disconnected from corporate network, i.e. not to change the password when it is not possible to report it to the password repository
• Solution must support OS Windows XP/2003 and above
• Solution must support x86 and amd64 hardware platforms
There is a lot more that this solution can do but those are the highlights. The documentation provided with the solution is very detailed and can answer most any question you might have. The developer of the solution is also very responsive if your questions aren’t answered either here or on the Q/A section of the solutions page. What I wanted to do in this blog is to show you just how easy this is to install and configure.
Here is my little Disclaimer: You should test all of this out in a lab first as the first step requires that you modify the Active Directory Schema which as you probably know is non-reversible. As you are also aware, Microsoft no longer supports XP. If you continue to use Windows XP now that support has ended, your computer will still work but it might become more vulnerable to security risks and viruses. If you are reading this article on how to help increase security I'm assuming you are either already off of XP or well on your way. If you aren't, what are you waiting on!
As in the previous articles I am going to assume you know how to set up a basic Active Directory domain with servers and clients and won’t be covering that. So let’s get started.
Installation Procedures
Much of this work involves modifying the Schema, Group Policies and Organization Units (OU) so I am doing all of this work on my Domain Controller. I’m using Windows Server 2012 R2 and Windows 8.1 on the client so that’s where the screenshots are taken from.
The first thing to do is to extract the files from the Installers.zip to a folder. There will be two files, AdmPwd.Setup.x64.msi and AdmPwd.Setup.x86.msi. Copy these files to a working directory. Double click on the appropriate file to get started.
Click Next.
For this first machine you should enable all the installation choices. You will use these same files later to install the Client Side Extensions (CSE) on all the computers and the PowerShell module and/or Fat client on the management computers.
Click Next .
Click Install .
Modifying the Schema
The Schema needs to be updated to add two new attributes:
ms-MCS-AdmPwd – Stores the password in clear text
ms-MCS-AdmPwdExpirationTime – Stores the time to reset the password
I can already hear the wheels turning on the clear text part. When the password is changed the communication is encrypted with Kerberos encryption. We will cover restricting its viewing it in Active Directory in a just a minute.
** Just to make sure you didn’t just skim over the first part to get to the “meat” of the article, let me just say one more time that you should be testing this in a LAB environment first**
Okay, back to the good stuff. To update the Schema you first need to import the PowerShell module. Open up an Administrative PowerShell window and use this command:
Import-module AdmPwd.PS
Now you can update the Schema with this command:
Update-AdmPwdADSchema
Delegation of permissions on computer accounts
The next step is to remove all extended rights/permissions from users and groups that are not allowed to read the value of attribute ms-MCS-AdmPwd. This is required because the All Extended rights/permissions permission also gives permission to read confidential attributes. If you want to do this for all computers you will need to repeat the next steps on each OU that contains those computers. You do not need to do this on subcontainers of already processed OUs.
1. Open ADSIEdit
2. Right Click on the OU that contains the computer accounts that you are installing this solution on and select Properties .
3. Click the Security tab
4. Click Advanced
5. Select the Group(s) or User(s) that you don’t want to be able to read the password and then click Edit .
6. Uncheck All extended rights
Important: This will remove ALL extended rights, not only CONTROL_ACCESS right, so be sure that all roles will retain all necessary permissions required for their regular work.
Next we need to add the Write permission on ms-MCS-AdmPwdExpirationTime and ms-MCS-AdmPwd attributes of all computer accounts to the SELF built-in account. This is required so the machine can update the password and expiration timestamp of its own built-in Administrator password. We can use PowerShell to do this.
Set-AdmPwdComputerSelfPermission -OrgUnit <name of the OU to delegate permissions>
In my case the OU name was Servers. Repeat this for any additional OUs that contain computer accounts you want this solution to apply to.
Now add the CONTROL_ACCESS permission on ms-MCS-AdmPwd attribute of the computer accounts to group(s) or user(s) that will be allowed to read the stored password of the built-in Administrator account on managed computers.
Set-AdmPwdReadPasswordPermission -OrgUnit <name of the OU to delegate permissions> -AllowedPrincipals <users or groups>
Use the same –OrgUnit name(s) as in the previous command.
Note: You can use multiple groups and users in the same command separated by comma.
Ex: Set-AdmPwdReadPasswordPermission -OrgUnit Servers -AllowedPrincipals domain2\Administrator,domain2\HelpDesk,domain2\Group3
Lastly we need to add the Write permission on ms-MCS-AdmPwdExpirationTime attribute of computer accounts to group(s) or user(s) that will be allowed to force password resets for the built-in Administrator account on managed computers.
Set-AdmPwdResetPasswordPermission -OrgUnit <name of the OU to delegate permissions> -AllowedPrincipals <users or groups>
Again, use the same –OrgUnit name(s) as in the previous commands. You can still use multiple groups and users in the same command separated by comma.
Registration of CSE with chosen Group Policy Object
What makes all of this work is a Group Policy client side extension that runs on each server whenever Group Policy is refreshed. We need to register it with a PowerShell command.
Register-AdmPwdWithGPO -GpoIdentity: "General Server GPO"
The –GPOIdentity can be either the displayName, GUID or distinguishedName. My example uses the displayName.
If you are wondering what this command does, it adds its client side extension value to the gPCMachineExtensionNames attribute for the Group Policy you selected. I my policy it looked like this:
Before:
[{C6DC5466-785A-11D2-84D0-00C04FB169F7}{942A8E4F-A261-11D1-A760-00C04FB9603F}]
After:
[{C6DC5466-785A-11D2-84D0-00C04FB169F7}{942A8E4F-A261-11D1-A760-00C04FB9603F}][{D76B9641-3288-4f75-942D-087DE603E3EA}{D76B9641-3288-4f75-942D-087DE603E3EA}]
Run the client install on the local servers
The final step in the setup process is to run the client install on the local computers. These are the same install files, AdmPwd.Setup.x64.msi and AdmPwd.Setup.x86.msi, that we used earlier. I chose to do mine using the Software Installation feature of Group Policy but you can do this any way you like. If you just want to test this quickly a manual install like we did in the beginning works just fine. On the client you don’t need to choose any additional options.
Once this is installed you can see it in Programs and Features.
If you want to script this you can use this command line to do a silent install:
msiexec /i <file location>\AdmPwd.Setup.x64.msi /quiet or msiexec /i <file location>\AdmPwd.Setup.x86.msi
Just change the <file location> to a local or network path. Example: msiexec /i \\dc3\share\AdmPwd.Setup.x64.msi /quiet
I’m sure there are other ways but this should get you started.
Changing the Basic Configuration
By default this solution uses a password with password complexity, 12 characters and changes the password every 30 days. If you decide you want to change that just modify the settings as seen below.
Choose the settings that fits your needs.
So what does this look like?
Once everything is configured, and Group Policy has refreshed on the clients, you can look at the properties of the computer object and see the new settings.
The password is stored in plain text. The Expiration date is a little more complex. Active Directory stores date/time values as the number of 100-nanosecond intervals that have elapsed since the 0 hour on January 1, 1601 till the date/time that is being stored. The time is always stored in Greenwich Mean Time (GMT) in the Active Directory. If you want to convert it yourself try this command:
w32tm /ntte <number you want to convert>
I know you don’t want everybody poking around in Active Directory so wouldn’t it be nice if there was a graphical interface available. Well there is. When you install the program on a computer where you want the ability to easily retrieve the password just select the Fat client UI option.
The program you want to run is C:\Program Files\AdmPwd\ AdmPwd.UI.exe . It will be in the menu and looks like this:
When you launch the interface all you have to do is enter the client name and click Search .
If you want to manually reset the password just click the Set button. When a Group Policy refresh runs it will be updated.
If you don’t want to deal with a GUI you can also get the password using PowerShell. All the same security you set still applies. You still need the rights to read this attribute!
Get-AdmPwdPassword -ComputerName <computername>
You can also reset the password using PowerShell.
Reset-AdmPwdPassword -ComputerName <computername> -WhenEffective <date time>
Just in case you are wondering, let’s see what happens when a user who hasn’t been granted rights to see the local Administrators password tries to access it. If they were to gain access to the GUI interface the password won’t be displayed.
Likewise if they run Active Directory Users and Computers (ADUC) and try to view the password it will show as Not set.
Compare that screenshot with someone who has been granted rights to view the password.
Now you can see why earlier we removed the extended rights and granted only certain individuals and groups the rights to see this. It doesn’t take a lot of effort for someone to browse through Active Directory and see most any information. If you don’t restrict who can see this then why are you bothering to implement this in the first place?
Final Thoughts
As I mentioned earlier, security is at the top of many people’s list these days and sometimes the implementation of solutions can be costly and/or time consuming. I wanted to show that there are still things that can be done quickly and easily to lessen the impact of security threats. Speaking of that, don’t forget about the Premier offering I talked about towards the beginning. It covers a wider range of security issues. If you want someone onsite to help you with this and a whole lot more, tell your TAM you want SLAM . You can send them a link to this post if you want. If you aren’t a Premier customer and want to find out all the benefits of being one just let us know.
So your mission, should you decide to accept it, is to quickly and easily increase security in your environment by changing your local administrator passwords and make them unique on every machine. This password will self-destruct in 3…2…1….
Tom Ausburne