Automate Changing The Local Administrator Password
Autor: Ivo barros | Publicado: 2016-05-18T06:16:00-07:00



   
  
  











 




   
      
  
 
 
 




 
  

   
    
    
 

  
How To Automate Changing The Local Administrator Password
Fonte: https://blogs.technet.microsoft.com/askpfeplat/2014/05/18/how-to-automate-changing-the-local-administrator-password/

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&nbsp;(more
 info found at the link)&nbsp; 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)&nbsp;delivery (we typically call it POP-SLAM). This course is an advanced course for implementing mitigation lateral movement mitigations from Microsoft’s Pass the HashWhitepaper.
 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 
&nbsp;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 


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  -AllowedPrincipals 


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  -AllowedPrincipals 


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 \AdmPwd.Setup.x64.msi /quiet or msiexec /i \AdmPwd.Setup.x86.msi


Just change the  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 




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 




You can also reset the password using PowerShell.


Reset-AdmPwdPassword -ComputerName  -WhenEffective 




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