Local Administrator Password Solution (LAPS) is now official

This solution is now officially distributed by Microsoft!

"Microsoft is offering the Local Administrator Password Solution (LAPS) that provides a solution to the issue of using a common local account with an identical password on every computer in a domain. LAPS resolves this issue by setting a different, random password for the common local administrator account on every computer in the domain. Domain administrators using the solution can determine which users, such as helpdesk administrators, are authorized to read passwords."



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: 

  • AdmPwd.ps 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: http://www.microsoft.com/en-us/download/details.aspx?id=17718

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"/>

Reference: http://tfl09.blogspot.cz/2010/08/using-newer-versions-of-net-with.html

4. Update schema

PS C:> Import-module AdmPwd.ps
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:  http://support.microsoft.com/kb/922836

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:

OCSP response unauthorized or unsuccessful

Windows OCSP client requires that the OCSP responder URL is populated in the AIA extension. If it is not included, Windows will not form the OCSP request properly and the validation will fail with Certutil status of "Unsuccessful". The same certificate was successfully validated by a Cisco ASA OCSP client. 

According to the RFC2560 Apendix A.1.1:

{url} may be derived from the value of AuthorityInfoAccess or
   other local configuration of the OCSP client.

This does not seem to be the case in Microsoft's implementation. 

OCSP responder address is specified in the Authority Information Access (AIA) extension. In Windows CA, this is configured in the properties of the CA on the"Extensions" tab.

 Once configured all newly issued certificates will include the OCSP responder address.

Without the OCSP extension validation using certutil fails.

According to RFC2560, an OCSP request must specify hashing algorithm, issuer name hash, issuer key hash and serial number of the certificate to be validated. 

Extract from RFC2560:

CertID          ::=     SEQUENCE {
  hashAlgorithm       AlgorithmIdentifier,
  issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
  issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
  serialNumber        CertificateSerialNumber }

issuerNameHash is the hash of the Issuer's distinguished name. The hash shall be calculated over the DER encoding of the issuer's name field in the certificate being checked. IsuerKeyHash is the hash of the Issuer's public key. The hash shall be calculated over the value(excluding tag and length) of the subject public key field in the issuer's certificate. The hash algorithm used for both these hashes, is identified in hashAlgorithm. serialNumber is the serial number of the certificate for which status is being requested.
If the AIA extension doesn't specify the OCSP URL Windows client does not include issuer's key hash in the request. 

In this case the responder returns an error of "unauthorized" and the validation fails. 

Extract from RFC2560:

2.3 Exception Cases

In case of errors, the OCSP Responder may return an error message. These messages are not signed. Errors can be of the following types:

   -- malformedRequest
   -- internalError
   -- tryLater
   -- sigRequired
   -- unauthorized
The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server.

x.509 Certificates - Critical vs non-critical extensions

Extensions are used to associate additional information with the user or the key. 

Each certificate extension has three attributes - extnID, critical, extnValue

extnID - Extension ID - an OID that specifies the format and definitions of the extension
critical - Critical flag - Boolean value
extnValue - Extension value 

Criticality flag specifies whether the information in an extension is important. If an application doesn't recognize the extension marked as critical, the certificate cannot be accepted. If an extension is not marked as critical (critical value False) it can be ignored by an application.

In Windows, critical extensions are marked with a yellow exclamation mark, 

View certificate extensions using OpenSSL:

# openssl x509 -inform pem -in cert.pem -text -noout

(output abbreviated)

        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Subject Key Identifier:

Extract from RFC  "Internet X.509 Public Key Infrastructure - Certificate and CRL Profile" 


4.1  Basic Certificate Fields

   The X.509 v3 certificate basic syntax is as follows.  For signature
   calculation, the certificate is encoded using the ASN.1 distinguished
   encoding rules (DER) [X.208].  ASN.1 DER encoding is a tag, length,
   value encoding system for each element.

 Each extension includes an OID and an ASN.1 structure.  When an
   extension appears in a certificate, the OID appears as the field
   extnID and the corresponding ASN.1 encoded structure is the value of
   the octet string extnValue

  Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING  }

4.2  Standard Certificate Extensions

   The extensions defined for X.509 v3 certificates provide methods for
   associating additional attributes with users or public keys and for
   managing the certification hierarchy.  The X.509 v3 certificate
   format also allows communities to define private extensions to carry
   information unique to those communities.  Each extension in a
   certificate may be designated as critical or non-critical.  A
   certificate using system MUST reject the certificate if it encounters
   a critical extension it does not recognize; however, a non-critical
   extension may be ignored if it is not recognized.

Windows CRL caching

By default, both downloaded CRLs and OCSP responses are cached by a Windows client. If a
time-valid version of the CRL or OCSP response exists in the cache, the client will use the
cached version rather than downloading an updated CRL or submitting a new OCSP request. 

Caching related configuration is defined in the following registry hive:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config

A binary value of: 


defines when cache will be cleared. 

Force the cache to be cleared:

c:\> certutil –setreg chain\ChainCacheResyncFiletime @now

Force the cache to clear in 1 hour:

c:\> certutil –setreg chain\ChainCacheResyncFiletime @now+0:1

View current cache life time config:

c:\> certutil –getreg chain\ChainCacheResyncFiletime