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 (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 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
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
tdRegProv")
