Managed Passwords for Local Administrator Accounts
What is Microsoft LAPS?
Microsoft Local Administrator Password Solution (LAPS) is a password manager that utilizes Active Directory to manage and rotate passwords for local Administrator accounts across all of your Windows endpoints. LAPS is a great mitigation tool against lateral movement and privilege escalation, by forcing all local Administrator accounts to have unique, complex passwords, so an attacker compromising one local Administrator account can’t move laterally to other endpoints and accounts that may share that same password. A benefit, compared to other password managers, is that LAPS does not require additional computers, or application servers, to manage these passwords. The management of these passwords is done entirely through Active Directory components. You can read more on Microsoft LAPS here, and download it here.
Setting up Microsoft LAPS
Setting up LAPS in your environment requires a couple steps, and Microsoft does a good job outlining all of those steps in their LAPS_OperationsGuide.docx which is included in the download. I’ll walk through at a high level what some of these steps are. The installation of LAPS on an endpoint results in a few optional components being laid down.
- Fat client UI
- PowerShell module
- Group Policy templates
- AdmPwd GPO Extension
Management consoles need one or more of the above features to be installed to manage LAPS, whereas all the endpoints to be governed by LAPS only need the AdmPwd GPO Extension. Microsoft offers a few ways to push the AdmPwd GPO Extension to your endpoints inside the Operations Guide.
The next step in the process is to extend your Active Directory schema to accommodate LAPS. Microsoft provides a PowerShell module that will aid in this process. There are two computer attributes added to your schema, ‘ms-Mcs-AdmPwd’ and ‘ms-Mcs-AdmPwdExpirationTime’. The ‘ms-Mcs-AdmPwd’ attribute stores the local Administrators password for the computer object in clear text, scary, I know, but I’ll expand on this later. The ‘ms-Mcs-AdmPwdExpirationTime’ attribute stores the time until the password expires.
Once the schema is extended, you can push out through Group Policy the configuration of LAPS to all your member servers. There is a new Group Policy template you have access to configure once this is installed.
The ‘Password Settings’ GPO setting allows you to configure the password complexity for the passwords for these local administrator accounts, including the length and age.
The ‘Enable local admin password management’ GPO setting controls if the endpoints governed by the GPO are being managed by LAPS. These are the only two settings I configured for my testing, but there are two other settings that allow you to control some other things. One of them allows you to control non-default local administrator accounts passwords (local accounts not named ‘Administrator’) and the other allows you to enforce the password expiration time set in the ‘Password Settings’ policy to ensure that no password expiration exceeds the ‘Password Age (Days)’ setting.
Ensuring LAPS is Secure
After you’ve extended your AD schema, the next step is going to be ensuring that the permissions to these new attributes are correctly applied. This is one of the most important steps in the process, as you only want to grant access to the ‘ms-McsAdmPwd’ attribute to objects that need it. Microsoft provides plenty of PowerShell scripts to check who has access to the attribute currently, and to apply new permissions to these attributes where needed. At a high level, there a few categories that you’ll want to consider when trying to understand your permissions. The first one you’ll want to be aware of, is removing the existing ‘All extended rights’ permission from users and groups on computer objects that shouldn’t be able to view the password of the local Administrator accounts (remember it’s stored in clear-text in an attribute). The next permission to be aware of, is the computer object or ‘SELF’ principal requiring the capability to write the ‘ms-Mcs-AdmPwdExpirationTime’ and ‘ms-Mcs-AdmPwd’ attributes so it can update the passwords and expiration times when a password expires. The ACE for ‘SELF’ is required on all the computer objects governed by LAPS. The last permission to be knowledgeable of would be to grant access to users and groups that are allowed to reset passwords on these local administrators to the attributes on these computer objects. Locking these attributes down via permissions isn’t the only way you can stay on top of your LAPS implementation. Monitoring LDAP traffic against the two LAPS attributes is another way to stay ahead of any attackers querying this information when misconfigured permissions allow. StealthDEFEND for Active Directory is a tool that can provide real-time alerting after creating a policy to monitor LDAP traffic against these attributes.
Attached below is a script that should assist in the review of currently applied permissions to understand who has access to these attributes today.
Seeing LAPS In Action
There are a few ways to get the current local Administrator password through LAPS, but the easiest way is the GUI.
Entering a computer name that you want to query the local Administrator password for returns you with the plaintext password as well as the expiration date. You also have the capability to update the expiration date in this client. You can also query this information using PowerShell.
To Review Microsoft Local Administrator Password Solution (LAPS)
Microsoft LAPS is a powerful solution to manage the local Administrator passwords across all of your endpoints. When implemented correctly, it is an effective way to prevent some potential lateral movement or privilege escalation within your environment. Unfortunately, when it is not implemented correctly, it can create a very large opening to attackers. Understanding Active Directory permissions is a critical component of securing your environment, and the addition of LAPS attributes only makes that more complex to understand and secure. I’ve provided a script below that can assist in identifying MOST of the permissions applied directly or through inheritance that would grant access to these extended attributes. Another effective way to help understand your Active Directory permissions would be to take a look at StealthAUDIT Active Directory Permissions Analyzer. This feature of StealthAUDIT can help you understand who has access to some of the most important objects within Active Directory, including the LAPS attributes. I created two custom reports within StealthAUDIT that identify generic permissions to computer objects (Full Control, Write All Properties, Read All Properties, etc.) and specific permissions to the LAPS attributes.
Learn more about StealthAUDIT Active Directory Permissions Analyzer here.
Kevin Joyce is a Senior Technical Product Manager at Stealthbits – now part of Netwrix. He is responsible for building and delivering on the roadmap of Stealthbits products and solutions.
Kevin is passionate about cyber-security and holds a Bachelor of Science degree in Digital Forensics from Bloomsburg University of Pennsylvania.
Related Posts
- Cutting down the Red Forest
- Active Directory Permissions – Hiding in the Shadows
- Understanding Delegated Permissions in Active Directory
- What Active Directory Groups Am I In?
- Adding a Linux Host to an Active Directory Domain
- How to Join Linux Hosts to Active Directory Using realmd & SSSD
- Back to “The Basics” Blog Series – Part 2: Active Directory
- What Is Kerberos?
- Ready for Microsoft’s LDAP Changes? What You Need to Know
- Microsoft LDAP Channel Binding and Signing Patch
Hi i was curious to know, my organization want to implement LAPS, but not sure what would be the impact, have you seen any impact when implementing LAPS?
Hey Alex! I focused more on the security side of LAPS and not the impact it may have on your Active Directory environment from an operational perspective. There is some research out there that does offer information around this. I’ve provided a link to one blog from Microsoft below. Hope this helps answer some questions you may have!
https://blogs.msdn.microsoft.com/laps/2016/08/08/laps-and-ad-sizing-considerations/
Can LAPS help me with local admins which their user name is not “Administrator”?
I have an organization that I manage with domain, but through the time many users made themselves local admins on computers.
Can LAPS can change all those local users’ passwords randomly ?
Hey Eden, yes, LAPS has a Group Policy setting that allows you to specify the names of accounts that aren’t ‘Administrator’. You would just need to configure this policy during the implementation of the solution.
Hi, thank you for the great information. I have 1 question about LAPS.
Can LAPS manage local admin for a user with a specific device? Meaning, users can only have local admin to their machine and not to the rest of device within the network.
Thanks for the question! LAPS manages the passwords for local administrator accounts, it does not limit access or control who has local administrator privileges on devices or across the network.
installing laps in DC can lockout dc password ?
Hey Optimus,
Thanks for the response. Based on my research installing LAPS on a DC will change the [DOMAIN]\Administrator account password. This is because Domain Controllers do not have local administrator accounts. It is suggested not to install LAPS on Domain Controllers, but only end points where these local admin accounts exist.
Domain Controllers SAM files, which control the local user administration are only used during a recovery where Active Directory is not accessible on the machine. The password it would change, in theory, would be the Directory Service Restore Mode Administrator password.
Hi Kevin.
Do you know what happens if a server with LAPS is restored to a point of time where the password was changed a few times?
is it possible to lookup passwords from a specific date in the past?
Thanks for the question! I don’t think you’re able to get a password from a specific date in time. I believe you’d want to force the password to be reset using the UI client or PowerShell, and then query the new updated password.
Something like this:
Reset-AdmPwdPassword -ComputerName [RestoredComputer]
You’ll need to wait for group policy to refresh on that computer before the PW is updated, but you should be able to kick that off in the Group Policy Management snap-in.
If a memberserver is restored and its local admin acount password has changed between the backup and the restore, it is most likely the computer account password has also been changed. Hence:
– no local admin password to access the local machine to re-connect it to ad
– no domain-access to the local machine due to lost of access between ad and the local machine.
The only solution here is to reset the local admin password using an alternate boot system. Bad luck if you have secured the boot meganism to not be able to boot from any other device than the os device.
Hi,
Thanks for the information. What happens if the server being managed by LAPS loses it’s connection to the AD domain? How would you log into it? The only reason we even have a local admin enabled is in case domain login stops working
Thanks for the question! In this case the password should be stored in the AD attribute for the computer object, you can query it to retrieve the current password using the LAPS UI or PowerShell cmdlets. Then you should be able to use it to login as the local admin even though the computer is not able to connect to the domain for whatever reason.
If the LAPS fat client isn’t installed on a DC, then where *is it* installed?
The client UI is going to be installed on whatever server you installed the LAPS tool onto.
The laps fat client is not needed to have the passwords reset and stored in ad. The laps fat client is most likely only needed to get the password and optionally forcefully reset it.
Hi!
What happens if we restore a backup of a server that i older than the maximum age configured for the LAPS clients?
The password has changed since the backup was taken, and we will then have no local Administrator to log on to the server an rejoin it to the domain..?
Is there any possibility to store some kind of password history. Maybe 2 or 3 passwords back in time.
Thanks!
Regards
Fredrik
Thanks for the comment. I did a little digging into this, and it seems some folks are exporting the LAPS password on a regular basis and storing it in a secure manner to handle this situation. I think that potentially raises a security concern, and I wouldn’t advise going down that path. Something I thought of when looking into this, is that you could modify your AD schema to include a few more LAPS related attributes, and script something that would take the current LAPS password and populate it in one of the newly created attributes and continuing that process as time goes on storing X passwords, where X is the number attributes you decided to create. Treating these new attributes in a secure manner, similar to the native LAPS attributes would be necessary here, but at least it’s not exporting the passwords and storing them on a file system somewhere.
Unfortunately for end-users, it seems Microsoft may have not accommodated for this scenario, and a custom solution would need to be created in the instance this is a frequent process in an organization.
Hi Kevin,
my company is considering implenting LAPS.
The only issue for us is that it’s not possible to find the local admin password without having to connect to AD.
For example: if im logged into the laptop as user with no internet connection, i can’t login to our AD environment and check the current local admin password.
Is there a workaround for this?
Thank you
Hey Bob, unfortunately, you need connectivity to an Active Directory domain controller to query the current password for a LAPS managed machine. I’m a little confused about the situation you posed though. If you’re already logged into the laptop, what do you need to query the password for? How LAPS works is the password is changed every X days (configured in the LAPS policy). If for whatever reason the laptop/PC isn’t connected at the time of the rotation, it will change in AD, but it wont be updated on the endpoint until it is reconnected to the network and can communicate with the Domain Controller. This means that if you know the current password (presumably you do because you were able to login), the password should remain the same for that machine until it is reconnected to the network/Active Directory environment, at which point it should rotate. Once it rotates, as long as you’re still connected to the network, you should be able to query the password again.
Hopefully that helps, if not feel free to clarify where I may have been confused and I’ll try to assist further.
Thank you very much, it worked here.
Hi Kevin,
Do you know if/when LAPS will support LDAPS (LDAP over SSL) as Microsoft plans to put LDAP to rest in 2021?
Thanks for the question! Unfortunately I was unable to find anything from Microsoft regarding supporting LDAPS for the LAPS tool/command line.
Where can I find version history and life cycle dates for LAPS?
Unfortunately, I am unable to find a Microsoft page or document outlining the version history and life cycle for LAPS. I did come across the following things that may help you, but you may ultimately need to reach out Microsoft to get more details:
Original security advisory for LAPS – File Version – 6.0 23-6-2015
Latest updated version of LAPS – File Version – 6.2 10-6-2020
Microsoft Support Product Lifecycle Search – LAPS is not present
Thank you! Very helpful.
Hello,
Does LAPS work when a client computer is authenticating against an RODC and RODC has connectivity to RWDC.
The client computer itself doesnt have direct connectivity to RWDC.
Thanks
Thanks for the comment! I unfortunately have not tested that scenario myself in my lab, I only used a RWDC. I did do some digging and found that when a RODC is at play, you need to update the Filtered Attribute Set (FAS) to include the LAPS attributes in the schema to be replicated. I found this guide that explains how that can be done. I hope this helps, and sorry for not having an answer to your specific question! If possible, I would suggest testing that scenario in a Dev/QA type environment before deploying to production.
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754794(v=ws.10)
Hello,
How much time it will take to generate new password for the first time when we deploy laps?
Once you configure and enable LAPS, it should update the password(s). Then, the new passwords will be determined based on the configured value for the password age in the group policy settings.
Using the Microsoft LAPS client and group policy, is it possible to control more than one administrator account on the machine? So let’s say we had admin, dave, bob, and john on different computers throughout the company as local admins. Could you administer all those different names with the policies?
Hi,
I’ve successfully tested the Microsoft DaRT tool to reset the local admin password in a lab environment (both physical and VM), which should mitigate the problems highlighted above.
This might seem to open a security hole in LAPS, but remember, you need physical (or virtual physical) access to the server to run DaRT. And as some security guy who i can’t remember the name of said, “once your adversary has physical access to the system, it’s game over”.
If you want other accounts with automatic chaniging passwords, have a look at service-accounts, Managed Service Accounts and Group Managed Service Accounts. The latest iteration does a fair job in frequently changing the password and keep the password updated in member-servers for the services and jobs running on that account.
Is it possible to limit certain users to have access to just computers within a sub-OU?
For example, user “sub-OU-admin” has rights within a sub-OU to be able to administer computer objects and user objects, but no special rights outside of that sub-OU. Can we give user “sub-OU-admin” LAPS access to computers within just that sub-OU without giving him access to all computers in AD?
This is definitely possible with Active Directory permissions and inheritance. You’d need to provide the sub-OU-admin access at the OU level to be able to read/write the two attributes related to LAPS on descending computer objects.