Search

LAPS Leaks Local Admin Passwords

Updated: Jun 30

On a previous blog (here), LAPS (Local Administrator Password Solution) was installed. LAPS manages and updates the local Administrator passwords on clients and member servers, controlled via GPO.


Only Domain Admins have default permission to view the local administrator password for clients and member servers. Access to view the passwords by non-Domain Admins is via delegation, here lies the problem. Access to the local administrator passwords may be delegated unintentionally.


This could lead to a serious security breach, leaking all local admin accounts passwords for all computer objects to those that shouldn't have access.


This article will demonstrate a typical delegation for adding a computer object to an OU and how to tweak the delegation to prevent access to the ms-Mcs-AdmPwd attribute.


#Prep Work

There is some prep-work, LAPS is required to be installed and configured, follow the above link. At least 1 non-domain joined client, preferably 2 eg Windows 10 or 11 Enterprise.


A test account, mine's named TestAdmin, with no privileges or delegations and an OU named 'Workstation Test'.


Ideally, I'll be using AD Groups and not adding TestAdmin directly to the OU, it's easy for demonstration purposes.


#Delgation of Account

Open Active Directory Users and Computers or type dsa.msc in the run command.


With a Domain Admin account right-click on 'Workstation Test' OU, Properties, Security Tab and then Advanced.


Click Add and select the TestAdmin as the principal.


Select, Applies to: This Object and all Descendant Objects

In the Permission window below select:


Create Computer Objects

Delete Computer Objects

Apply the change.


This is a 2 step process, repeat this time selecting.


Applies to: Descendant Computer Objects


Select Full Control in the Permissions window.


#Test Delegation

Log on to a domain workstation with RSAT installed and open Active Directory Users and Computers.


Test by pre-creating a Computer object, right-click on the OU and select New > Computer, and type the hostname of the client to be added.


Log on to a non-domain joined Windows client as the administrator and add to the domain using the TestAdmin credentials, reboot.


Then wait for the LAPS policy to apply.......I've set a policy to update daily.

#View the LAPS Password

As the TestAdmin, from within AD Users and Computers go to View and select Advanced.


Right-click properties on the client, select the Attribute tab


Scroll down and locate 'ms-Mcs-AdmPwd', that the Administrator password for that client.

#The Fix....

To prevent TestAdmin from reading the ms-Mcs-AdmPwd attribute value, a slight amendment to the delegation is required.


As the Domain Admin right-click on 'Workstation Test' OU, Properties, Security Tab and then Advanced.


Select the TestAdmin entry, it should say 'Full Control'.


Remove 'All Extended Rights', 'Change Password' and 'Reset Password' and apply the change.

As TestAdmin open AD Users and open the Computer attributes.


ms-Mcs-AdmPwd is no longer visible.

#Did I Just Break Something......

Test the change by adding a computer object to the OU and adding a client to the domain.

Introducing computers to the domain is functional... No harm no foul.

#Final Thoughts

Removing the Extended Rights and Password permissions prevents the delegated account from reading the local administrator password from ms-Mcs-AdmPwd AD attribute without causing any noticeable problems.


Watch for any future delegations ensuring the permissions aren't restored by accident.


Enjoy and hope this was insightful.



11 views0 comments