Managing The Local Administrator Password - Part 3 - The Implementation

In this post I outline a step by step guide on implementing the solution. This post builds on the previous one.

This is mostly a condensed version of the author’s documentation with addition of some items that either I found unclear or were not covered by the author. 

In any case you should read the full documentation found here:

WARNING: The solution requires schema extension and this should never be taken lightly so do test properly and proceed at your own risk. 

The steps described in this section can be carried out on a Domain Controller or a management workstation. 

1. Install the CSE including the “Management Tools”

This installs: 

  • PowerShell module 
  • GPO templates (AdmPwd.admx and .adml) 

Note: I tested this on a domain with a local GPO store. If you are using a Central Store you should check if the templates have been copied. 

The following to steps are required for Windows 2008 and 7. Windows 2012 comes with .Net4 installed and enabled.

A) Download and install .Net4:

B) Configure PowerShell to load .Net4: 

Create a file named  “PowerShell.exe.config” in “\windows\system32\WindowsPowerShell\v1.0\” with the following content:

<?xml version="1.0"?>
    <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v4.0.30319"/>
        <supportedRuntime version="v2.0.50727"/>


4. Update schema

PS C:> Import-module
PS C:> Update-AdmPwdSchema 

5. Remove “All Extended Rights” permission

This permission is not granted by default, you should however ensure it has not been granted manually as this would give access to the stored passwords.  

  • Use ADSIEDIT.msc to and connect to the “Default Naming Context”
  • Right-click the OU that will contain computer objects you want to manage,
  • Go to “Permissions” tab and click “Advanced”. 

You should also ensure that permission inheritance is enabled on sub-OUs.

6. Add Write permission to ms-MCS-AdmPwdExpirationTime and ms-MCS-AdmPwd attributes to SELF

PS C:> Set-AdmPwdComputerSelfPermission -OrgUnit

7. Add CONTROL_ACCESS permission to ms-MCS-AdmPwd attribute

In this step we grant permission to retrieve passwords from AD. See the previous post for more details. Firstly you need to create a group which you will use to grant access to retrieve passwords.

PS C:> Set-AdmPwdReadPasswordPermission -OrgUnit -AllowedPrincipals

8. Add Write permission to ms-MCS-AdmPwdExpirationTime attribute

In this step we grant permission to force password reset . 

PS C:> Set-AdmPwdResetPasswordPermission -OrgUnit -AllowedPrincipals

9. Create a GPO that will be used to enable password management

The GPO needs to be linked to the OU containing accounts of the computers you want to manager. You don’t configure any settings in the GPO. The magic happens in the next step. 

10. Register the CSE with the GPO

PS C:>  Register-AdmPwdWithGPO -GpoIdentity:

The cmdlet accepts displayName, GUID or DN.

This is all configuration that's required server side.

Now we need to deploy the CSE to computers we want to manage, and configure password requirements (see the previous post for and the documentation for details). 

Managing The Local Administrator Password - Part 2 - The Solution

Jiri Formacek, a Microsoft Services consultant (based on his LinkedIn profile), has published an excellent local admin password management solution. 

The solution uses Group Policy Client Side Extension (CSE) to set random and unique per computer local administrator password that is changed at a user controlled interval (30 days by default). The password is then stored in a confidential Active Directory (AD) attribute. Permission to retrieve the password is controlled using a security group.

The solution is described in the documentation so I won’t be repeating what’s there. I’ll go over the main points and some stuff that’s not covered in the official documentation.  I recommend reading the documentation.

The solution can be downloaded here:

The documentation can be found here:

Implementation requires AD schema extension in order to create two new attributes and add them to the computer object class.  

The two attributes are:

  • ms-MCS-AdmPwd – stores the password 
  • ms-MCS-AdmPwdExpirationTime – stores the expiration time, password change can be forced by setting the value to “0”

The attributes are marked as confidential so the authenticated users group cannot read the values.
More on confidential attributes here:

Access to the attributes is controlled, with a security group. I used two separate groups. One group with read access to the ms-MCS-AdmPwd attribute for retrieving the passwords and the second one with write permission to the ms-MCS-AdmPwdExpirationTime attribute allowing for forcing the reset. In most cases it would be the same group performing both, however I prefer to have an option of separating the tasks. Permission can be granted per OU so you can further subdivide the access. For example based on geographical location.

The passwords can be retrieved using “AD Users and Computers” and ADSIEDIT consoles. Also, the author provided a GUI tool that can be used to easily retrieve admin passwords. The tool is installed along with the management tools.

The Client Side Extension (CSE) is a DLL file that needs to be deployed to and registered on managed computers. A convenient MSI file is provided. It can be deployed using your standard package management tools such as SCCM, Altiris or Group Policy.

The management tools (Group Policy Template, PowerShell scripts, and the GUI tool) are installed using the same MSI. Only the CSE needs to be installed on the managed computers.

The CSE is configured using the provided GPO template. 

 The documentation states that the default password length is 15 characters, in fact it is 12. We definitely want to use at least 15 characters long password as this prevents Windows from storing passwords using insecure LM Hash. More on LanManager here: 

There are two settings in the template:

The CSE has an event log provider that logs to the Application Log. This is detailed in the documentation. I found it useful to set the logging level to the highest during testing.

Summarizing, I find this solution to meet all requirements. I have tested it on a 2012 AD with Win 7 clients and 2012 member servers as well as 2008R2 AD with Win7 and XP clients. I think this is an excellent solution.

A potential concern one may have is that the passwords are stored in clear text in AD directory partition. However, an attacker would have to obtain a copy of the AD database and extract the passwords offline. 

Managing The Local Administrator Password - Part 1 - The Issue

Local administrator password has always been a cause of a headache for security professionals. There hasn’t been a good and free way to manage the password on a large scale and most organizations ended up using the same password on all desktops or even servers. This introduces a number of vulnerabilities, such as:

  • All IT Staff know the password
  • The password is never changed
  • The password inevitably becomes known to the users and various 3rd parties
  • Machines are exposed to pass-the-hash attacks 

If an attacker, a malware or an evil insider gains access to a single machine currently logged on under the local admin account they will be able to access all machines by executing a script or using built-in management tools. Moreover, compromise of a single machine will allow an attacker to grab a password hash and use it to access other computers.

The local administrator password can be managed using Group Policy Preferences as detailed in the following article: 

While this satisfies most compliance requirements (they generally only require that passwords are changed at a set interval), this still leaves all computers with a single password. Furthermore, Group Policy Preferences store encrypted passwords in the SYSVOL folder and the encryption key is published on MSDN:

Clear text passwords can be retrieved from Group Policy Preferences using a PowerShell script as detailed in the article below:

Summarizing, GPO Preference is not a good solution.

As to other solutions, there is one from SANS. I haven’t explored it but it does look comprehensive: