5 thoughts on “The case against using Microsoft’s Local Administrator Password Solution (LAPS)”

  1. This is a well written article, but I feel it skips over one fundamentally important point: that you are relying on having permission to read the ms-Mcs-AdmPwd property. Microsoft dedicate an entire section of their Operations Guide to finding users with Extended rights and removing them, and adding specific users/groups to have access to this property. As with anything in technology, properly configured (and this is not in any way an onerous task) LAPS is perfectly secure, and when it is then your script would be useless to anyone not on the approved list.

    If anyone is further concerned, it’s easy enough to lock down access to the LAPS properties to a single, secure service account and then make use of a third party interface (look up OVERLAPS for example) which implements a more easily managed and granular permissions system and produces easily audited logs.

  2. This is weird. There once was a GPO setting to define the Local Admin password. Later, this GPO setting was disabled because the password was stored unencrypted in the GPO. I guess LAPS was introduced as a replacement for this GPO setting. So you would expect the password to be stored encrypted…
    Now there’s a difference between a GPO and AD object, where the GPO is readable by anyone, and AD not so. But still, the Golden Rule is IMHO to NEVER store password unencrypted.

    1. As somebody already pointed out, if an attacker has Domain Admin… that’s game over. That said, it’s possible to set an expiration on LAPS. For instance, I set the expiration on LAPS for 8 hours in my org. I set an even less expiration time for servers… something like every couple of hours. I figure an 8 hour workday is enough time for a Helpdesk tech to use the local admin account on workstations for the day. After 8 hours, the LAPS password rotates. If the Helpdesk needs to pick up with a user the next day, he/she can just lookup the new LAPS password. No biggie. Also, another person mentioned protecting the readability of the LAPS password extended attribute. If you don’t end up using something like OVERLAPS, then just issue Helpdesk a username-a or username.adm account, limit which systems that account can be used on in Active Directory (example server/jumpbox specifically designed for Helpdesk to perform admin functions) and then set ACL to permit that account (or drop account into group) read rights to the attrib while denying everything else except for Domain Admins. Another person mentioned GPO storing local admin password in plaintext. I get it, but even though LAPS stores the password in plaintext the added advantage for LAPS over GPO is that even though you could keep generating random passwords for local admins on machines in an org, the randomly generated password would apply to all machines in the org, unless you end up creating 10’s if not 100’s of GPOs to set various random password across the org. LAPS creates unique, random passwords for every object and thus no password can be used on more than a single machine at a time.

  3. LAPS passwords are stored in Active Directory (AD) and protected by ACL, so only eligible or privileged users (domain admins) can read the password.

  4. I understand your point but I think the bigger concern would be a domain admin account has been compromised. Once that has happened all the bad things are already bad.

    I guess it’s kind of like saying no point in backing things up because if someone gets access to the backup system they can just delete the backups.

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top