I recently implemented the relatively newly available MS LAPS solution. The implementation itself was surprisingly simple for such an effective and powerful offensive security solution. Microsoft documentation on this piece is also very good compared with any standards available.
Implementing the solution sets a unique local administrator password on selected computer accounts in Active Directory and stores the password in a protected attribute on the object itself.
This is done by updating the Forest Schema with two new attributes for computer accounts called
ms-Mcs-AdmPwd – This stores the password in clear text
ms-Mcs-AdmPwdExpirationTime – This stores the date and time when to reset the password next .
A new ADMX file (AdmPwd.admx) need to be copied to the central ADMX file store, it enables you to configure new GPO settings to configure the password complexity settings, password length, age and what local administrators account to configure. You don’t have to specify that name of the built in account even if you have renamed it for obscurity reasons as it will use the default SID-500
A Group Policy Client Side Extension (GPO CSE) is required on all client computer accounts that are to be configured for LAPS.
Following on from that you will need to use the ADSI editor and edit the properties of the OU or OUs that hold targeted computer accounts and select the Advanced and remove the ‘All Extended rights’ for Security principals that should not have rights to see the passwords. This is required because ‘All Extended Rights’ permission gives also permission to read confidential attributes.
Next is to give the computer accounts rights to edit this new attributes themselves. Give the SELF built-in account rights to edit this attribute. This is required so as the machine could update password and expiration time stamp of own managed local Administrator password.
Then give CONTROL_ACCESS permission on ms-Mcs-AdmPwd attribute of computer accounts to the group(s) that shall be allowed to read password of a managed local Administrator account on managed computers. Groups that are allowed are usually IT Helpdesk group and of course the Domain Admins group.
Write permission has to be added for ms-Mcs-AdmPwdExpirationTime attribute of computer accounts to the same groups that are to be allowed to force password reset for managed local Administrator account on managed computers. These are normally the same groups as above.
All the required components to do this come in a single MSI package, either x86 or x64 dependent on your architecture. Full install of it comes with the Group Policy Client Side Extension that all clients that are to be configured require, a Fat UI Client for admins and IT Helpdesk staff, Power Shell module and also the Group Policy Administrative template to upload to your central GPO store.
My implementation was to create an SCCM Application for the GPO CSE and roll it out in predefined stages as a required application. A separate SCCM Application rolled out the full package with the Fat UI client and the PowerShell module to all workstations in our IT Workstations AD group. Once all clients had the GPO CSE installed I proceeded with the rest of the implementation.
The Forest Schema is updated with a single line PowerShell command using the PowerShell module provided. The operation needs a Schema Admin to undertake.
Once you have the PowerShell module installed you update the Scheme with this single command
Afterwards you should double check manually in the ADSI editor if any groups could have been previously given ‘All Extended rights’ on the OUs you are going to target. In my case there where none.
The delegation of the computer account itself and rights to AD group to read the new attributes are also achievable with PowerShell and the provided module.
Set-AdmPwdComputerSelfPermission -OrgUnit “OU=Client Machines,DC=Contoso,DC=Local”
The above command gives the built in SELF object within the OU rights to update its new attributes, repeated this for each OU needed and any Sub-OU if you have removed inheritance in your OU structure.
Set-AdmPwdReadPasswordPermission -OrgUnit “OU=Client Machines,DC=Contoso,DC=Local”-AllowedPrincipals “Domain Admins”
The above command gives the Domain Admins AD group rights to read the new attribute therefore to see the password assigned to the local administrators account. Repeat this to any AD groups that you have delegated some AD rights to such as IT Helpdesk.
Set-AdmPwdResetPasswordPermission -OrgUnit “OU=Client Machines,DC=Contoso,DC=Local”-AllowedPrincipals “Domain Admins”
The above command give the Domains AD group rights to change the ms-Mcs-AdmPwdExpirationTime attribute effect to change the next password reset time.
Now I configured the GPO and linked it to the OUs I wanted to target.
I use a SIEM solution for auditing purposes and when a password is read an event ID is created in the Security Log of the Domain Controller.
To enable auditing for the new Schema attributes I ran
Set-AdmPwdAuditing –OrgUnit: “OU=Client Machines,DC=Contoso,DC=Local” -AuditedPrincipals: Domain Admins
Repeat this command for any OUs that have and AD accounts that read the attribute.
When a password is successfully read, a 4662 event is logged in the Security log of the Domain Controller.
The new Fat UI client is created to query a computer from AD and only return the password and next reset time. This is very handy for IT Helpdesk users who may not be comfortable with either PowerShell or using the attribute editor of a computer object in AD. Remember only user with the rights to view and or edited these attributes can see them not matter what method they use. The client can also be used to change the next time the password will automatically change. Handy in case the IT Helpdesk would have to give a remote laptop user who forgot his password the local admin password to get that important file that’s located on its hard drive.
There are other ways to view the password such as the attribute editor of the computer account or PowerShell query which could be handy if a mass export was needed. The LAPS client is by far the friendliest to use
$computername = IcemansPC
Get-ADComputer $computername -Properties ms-Mcs-AdmPwd | select name, ms-Mcs-AdmPwd
Password is protected by ACL
Protected in transit by LAPS tools
Password is not replicated to RODC and is not revealed in audit logs on a DC (you can edit the Filtered Attribute Set and replicate the attributes to RODCs if it is needed in your scenario)
MS full guide and MSI package is included here: