- Managing shared mailboxes in Office 365 with PowerShell - Thu, May 5 2016
- Managing shared mailboxes in Office 365 with the GUI - Wed, May 4 2016
- Installing and configuring the Enhanced Mitigation Experience Toolkit (EMET) - Wed, Mar 16 2016
Does the Microsoft Local Administrator Password Solution (LAPS) require an agent? I really don’t want to install yet another agent on my computers. (Special thanks to reader Mike for this question.)
No, LAPS does not require an agent. For LAPS to function on workstations and servers, a Group Policy Client Side Extension (CSE) will need to be installed. The Group Policy CSE is not an agent. Typically, an agent is a service that runs at system startup and continues to run in the background to provide telemetry or some other data back to a central system such as System Center Configuration Manager, Operations Manager, or an antivirus monitoring platform. The CSE only runs at Group Policy refresh cycles.
Local Administrator Password Solution Setup - Manual install of Group Policy CSE
Can I use LAPS without installing the Active Directory schema changes?
No, you cannot use LAPS without installing the AD schema changes. The schema update adds the ms-Mcs-AdmPwd and ms-Mcs-AdmPwdExpirationTime attributes that LAPS requires.
Does LAPS require an additional infrastructure such as additional application servers or SQL?
No. LAPS requires two additions to your AD schema. LAPS also requires that an additional Group Policy Client Side Extension (CSE) be installed on all of the managed computers. You will not need to run an additional application server or SQL server to use LAPS.
Is storing the Administrator password in AD in plain text secure?
The ms-Mcs-AdmPwd attribute in AD is a confidential attribute protected by an Access Control List (ACL). Only users with permissions to view this attribute can view the password (that is, Domain Admins and anyone else they’ve delegated access to). Keeping the same local Administrator password across large groups of systems is a much bigger security risk.
If the passwords are stored in AD, can’t anyone with AD access view them?
No, only users with adequate permissions can view the stored passwords. You can use the Find-AdmPwdExtendedRights PowerShell cmdlet to view which groups and users can view the stored passwords. You can use the Set-AdmPwdReadPasswordPermission PowerShell cmdlet to give groups and/or users access to view the passwords.
Find-AdmPwdExtendedRights output example
Can I require two-factor authentication (2FA) to view the passwords LAPS has stored in AD?
Access to the ms-Mcs-AdmPwd attribute is controlled with a user’s regular AD credentials. You would need to implement 2FA for all user logons that have access to that data in AD. You won’t be able to require 2FA for just accessing that attribute without implementing some kind of custom solution.
What happens if an admin’s account is compromised? Wouldn’t the compromised account have access to the stored passwords?
If a user with adequate rights to view the ms-Mcs-AdmPwd attribute is compromised, that account could be used to pull all of the local Administrator passwords from your domain (or subset of computers if the user account can only view Administrator passwords for specific OUs in the domain). Typically, this kind of account would already have had enough rights to reset the password remotely on any of those computers or wreak other havoc with the delegated privileged access.
The upside of having LAPS in place is that you can now force a password reset on all systems that could have a compromised Admin password and then see in AD if they’ve updated.
Can LAPS manage the password of the local Administrator account and a custom local administrator account with a different name at the same time?
You can manage either the default Administrator account (including if the account has been renamed) or a secondary local Administrator account that you’ve created, but not both.
What happens if the computer loses its connection/trust with Active Directory? Will LAPS change the local Administrator password on the computer, but fail to update it in AD? If this happens, I won’t know the local Administrator password. (Special thanks to reader Ken D. for this question.)
The password that is stored in AD is the computer’s current password—even if the password should have expired. In this situation, the computer’s Group Policy Client Side Extension (running in the Local SYSTEM context) would be unable to check the expiration date stored in AD. When that happens, the password change process would stop. You would need to re-establish the computer’s AD trust before the local Administrator password changes again.
Can LAPS manage the local Administrator passwords on non–domain-joined machines?
No. Computers must be domain-joined to be managed by LAPS.
Can LAPS change the stored password for a service if it is using the local Administrator account?
No. LAPS will only update the local Administrator password. It will not update the service to use the new password.
Aren’t there more elaborate solutions that can do more than just randomize the local Administrator password? What if I need to rotate passwords for service accounts or do something more advanced?
Microsoft LAPS is designed to randomize passwords of the local Administrator (or a custom Administrator account) for domain-joined systems without the need to implement additional infrastructure. This gives organizations a way to randomize those local passwords to prevent large numbers of computers from being vulnerable to Pass-the-Hash attacks or from being compromised if that password becomes known. Yes, much more elaborate solutions exist if you’re willing to pay for them and take the effort to implement additional infrastructure.
What if my question isn’t listed here?
Feel free to ask your question in the comments section below!
Read the latest IT news and community updates!
Join our IT community and read articles without ads!
Do you want to write for 4sysops? We are looking for new authors.
All of our computers have the local administrator account and a local administrator administrator named IT. Can LAPS do both the administrator account and the IT account or do I need to go through the process of deleting one.
This is addressed in question #8 in the article.
Is there auditing / logging available with LAPS? Is there a local log on the client, or an event ID I can use to audit password changes, etc?
LAPS logs to the Application Event Log with the Source AdmPwd. By default, LAPS only logs errors, but you can modify that in the Registry in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{D76B9641-3288-4f75-942D-087DE603E3EA}\ExtensionDebugLevel . 0 (the default) is errors only, 1 logs errors and warnings, and 2 is verbose logging.
Kyle, thanks for answering the question about logging / auditing. What about any logging available on domain controllers when the AD attribute is changed? We would like a central way to show when passwords were changed for Security audits.
Thanks!
I’m not seeing anything in the documentation about that. You’d need to enable some additional auditing in AD to do that.
The LAPS documentation mentions the way to audit is to enable auditing on the DCs and parse for event 4662 with the specific LAPS schema GUID for the attribute ms-mcs-AdmPwd, the GUID is placed into the parameters value of the event log. This approach doesn’t work – SCOM monitoring in our environment (several thousand users) revealed that the schema GUID was populated on 4662 events for events not related to machine passwords and LAPS.
Sometimes I want to get a big stick and hit the Ms developers over the head, surely they could have easily coded a different event ID to allow machine password access to be audited?
I presented this solution to my co-workers but their main concern was the schema changes to AD. For no reason at all they were not interested due to the schema changes. Any argument against this stance?
Your alternative is to be vulnerable to pass-the-hash attacks because you’re not randomizing local Administrator accounts. It’s kind of hard for me to argue against a stance that doesn’t have a justification.
1) how quickly after expiration does a new password get generated and sent to AD?
2) Prior to Microsoft making changes to GPO managed local admin passwords, we had a GPO in place. What is the easiest way to remove those GPO settings from all the workstations?
LAPS updates when the Group Policy CSE runs during a Group Policy refresh. You can run it manually, kick it off from a management station if you have network access, kick it off from a script from a tool like SCCM, or just wait for the refresh to happen.
Just remove the GPO (or the setting in the GPO) and you should be good to go.
We just configured LAPS and it seemed to work fine but when Group Policy updates the LAPS password no longer works, we have the retention set for 42 days. If we reset it then run gpupate it will work until Group Policy runs again. I moved a single server into a test OU with no other GPO’s being applied and it still does not work properly. Any ideas of what we may have missed here? Thanks, Joe.
There are three possibilities I can think of: a Group Policy processing issue, another policy applying that is changing the password, or someone is changing it manually. First, make sure that you don’t have an old Group Policy Preference or script that is changing the password. I would check the local Event Logs to see when the password is being changed too; you may have an employee that is changing it. Second, the time that you set isn’t an expiration in the sense that the password will expire. That time tells the LAPS CSE that it needs to change the password on the local system. The process that the CSE uses shouldn’t change the password on the local system if it can’t update it in AD. Also, if you’re moving a test system to another OU and it still isn’t working, did you make sure that the LAPS policy was still applying? LAPS doesn’t work without the Group Policy configuration in place.
Unfortunately LAPS does not deliver one critical functionality. Consider this. After LAPS is deployed passwords and expiration dates are published in AD. A user with local admin rights resets the local administrator’s password manually. This is not detected by LAPS on the next group policy refresh interval. Because of that, LAPS does not return local administrator’s password to the value published in the AD. This leaves incorrect password value in the AD which authorized admins cannot use. They can reset password from dsa.msc console, but only if the computer is still joined to the domain. If not, tough luck and they must turn to other tools. Because of that LAPS is useless.
If you’ve got employees using their Admin rights to remove computers from AD or the local Administrator password without permission, that’s a problem that should be solved through HR… not with technology. Assuming they have a business need to change the local Administrator password, the best way to handle that situation would be to make sure their machine gets a policy that changes the local Administrator password more regularly.
Kyle, I cannot agree that this is not technology problem. We had a technology tat continously updated password according to policy on regular refresh intervals. This is now gone. What LAPS should do is simply read ms-Mcs-AdmPwd attribute and apply it’s value to local password on a regular group policy interval. Simple as that. Now as it is, the solution is useless. It took me a couple of days implementing and testing. From the beginning I was under impression that LAPS would at least keep the essential functionality that existed with Group Policy Preferences, ie resetting password to default value at GP intervals. After all this is how restricted groups GP works as well. I was very dissapointed to discover it is not the case. I feel I need to bring this news to other colleagues and save them a day or two of work. By the way I did deploy LAPS at the customer, but I am now waiting for their decision if they want to keep it.
If a user is doing something on a computer that he/she shouldn’t be doing, that is typically a policy issue in the organizations where I’ve worked/consulted. The employee violating that policy would be dealt with through an HR process. That said, we’ll just have to agree to disagree on the issue. If you do have an environment where IT is being asked to implement a control because employees are constantly changing the local Administrator password, LAPS may not be the right product for you or you may need to set the threshold for expiration to a much lower number.
LAPS is a Group Policy Client Side Extension… not a server-side product. The CSE checks in to see if the date in AD is expired. If the date has passed, it updates the local Administrator password on the client and in AD. The server can’t/won’t reach out to the client to update the password because it is simply a repository for the password and date. If you would like the CSE to have the ability to re-apply the password to the client until the expiration, I would encourage you to submit that as an enhancement request to Microsoft on Connect. LAPS is intended as a way for organizations to mitigate Pass-the-Hash attacks by randomizing passwords on client systems. If you need something more robust that can re-apply passwords, update service accounts, report on end users changing passwords, etc., you may want to look into a 3rd party product that has more advanced features.
If your workstation is joined to Domain A can you use the LAPS UI to retrieve local passwords in Domain B ?
The passwords are stored in AD as an attribute. As long as the account you’re using has appropriate permissions to view the attribute, you should be able to view it.
Domain A and Domain B have a 2 way trust by the way
For some Reason since my workstation is another Domain when I run the LAPS UI it just says Computer not Found when the server is in the other Domain
It sounds like the GUI tool is probably trying to perform the lookup in your computer’s domain. You could try adding the domain suffix for the computer you’re looking for, but I’m guessing that may not work either. It may be necessary for you to run the LAPS GUI from a jump box that is on the domain of the computer you need to manage. If you’re just trying to view the password, you can do that in ADUC.
I know…I know…I know… that the purpose of this great tool is to manage and randomize Local admin passwords. With that said my org. (aka upper mgmt) is adamant about not randomizing the pwd for the local admin acct (something about being too complex for our workstation admins). Can I still use this tool?
That’s the whole point of the product. You’ll probably want to look into a 3rd party solution for your organization’s requirements.
I have performed the above steps and able to find the new password for my test machine (local admin) but that password does’t work ..still old password is active..it’s been more than 2 days i am trying to find solution..can any expert help me to solve this issue.
Ravindra, This really isn’t much information for me to work from. Do you have any other outside system (like Group Policy Preferences) that could be changing the local Administrator password? Have you checked the Event Logs to see what actions LAPS has performed or if something is changing the password of the Administrator account?
Hello Ravindra,
were you able to solve this issue?
I have one question. If we are resetting the local administrator manually in a LAPS enabled environment, what will happen.? Will LAPS change the password on next gpupdate or will it wait until the password expiry date..?
No, LAPS will wait until the expiration to update the password again. It will not re-apply the password that is stored in AD.
Kyle, for those worried about their “trusted” staff manually changing the password and LAPS not recording it, could they set expiration to 1 day and reduce the time frame the password and its LAPS entry be put of sync? Also, could you enable auditing on the attribute to log reads and know who looked at a computers password? Thanks for the LAPS walk through. We were thinking of deploying LAPS-E (the encrypted version) but MS pulled it. Still going to implement something. Might just randomize on boot or scheduled task and not care about the password (very rare use) as we are licensed for DART and can just reset it if needed. Thanks again.
And I should have kept reading to FAQ page 2… nice. Yes, thanks again.
Nice writeup, thanks!
I have been installing laps for a while now but I am seeing that the password is not actually being set on the machine. I see it changing in AD and i can see the events that the password has been changed but the password never actually changes. Has anyone else had this issue?
I would enable the logging for LAPS on the client and set it to Verbose to see what is going on at the client. The second part of the FAQ has the Registry key to do this. I would also check your other Group Policy, SCCM, or any other system that can push configuration out to your clients. If you have an old Group Policy Preference or script that is pushing the password down to the local Administrator account, that would overwrite the work LAPS is doing.
i have the same issue. have you come up with solution? were you able to solve the issue?
Ren – Did you follow the instructions I gave the previous person? Did you enable logging on the client to see what it is doing?
The adm template is not showing in the domain policy when I want to create the policy, it would however show the LAPS template in the local group policy. Any issues as to why this is happening? I did it twice in my test environment and it worked,
If it worked in your test environment, it sounds like your Test and Production environments either aren’t identical or you might have done something differently the second time in Production. Do you have the Group Policy Central Store in Prod and not in Test? Did you copy the files on to the same management station where you’re trying to create the policy?
I had to manually copy the admx and adml files to my group policy central store in my production environment, something which i didn’t had to do in my test environment since they automatically appeared in the GP. passwords are being showed in AD and when i used the LAPS gui tool but for some reason the password is not being changed on the machine. any ideas? I have reset two times and the reset does happens but it just does not changed the initial local admin password i initially had before LAPS.
It sounds like your Test environment doesn’t have the Group Policy Central Store enabled then. If it did, you would have had to copy the ADMX/ADML files over.
First off, make sure you’re running the GUI tool with Admin rights (Right-click, Run as Administrator) just to be sure that isn’t it. Otherwise, I’d enable Verbose logging on the client and see what the client is doing.
also can this password password solution be applied to servers without any issues??
Yes, it can be applied to servers. Whether you’ll have any issues is dependent on if you’re using the local Administrator account on your servers. If you are, you’ll need to switch to an AD-based service account or have a strategy for updating the password in your service.
So, My workstation admin needs to hop from workstation to workstation without being able to log into ADUC to find the local admin password for the next workstation that he needs to work on. Can i run a report to query AD and dump the current passwords into a text file so they are available to him for when he needs them? I am thinking put them in a password manager or something similar. Is there a better way to accomplish this
Yes! Check out Part 2 of the FAQ. You can use the Get-AdmPwdPassword PowerShell cmdlet to pull lists of passwords for machines.
Honestly, you’re probably better off giving your workstation admin a dedicated account that has admin rights on the machines. He/she could then jump machine to machine with one account. In the event a machine wasn’t on the domain, then you could have a way for him/her to get to the local Administrator passwords. A password manager should be fine… just keep in mind that the passwords will expire and change. You’ll want to make sure you’re regularly updating your saved copy and keeping the date with it so the tech knows if it has expired.
We have implemented LAPS in our organization. We have around 2000 computers. However recently we had faced one issue that we deleted a machine from domain and created a computer account with same name. After we needed to obtain the password of the old computer. But old computer was not available in active directory recycle bin. How we can over come this issue..?
The easiest way would be to use a tool like DaRT to boot the system and reset the local Administrator password.
Hi Kyle. Thank you for this FAQ. I did want to elaborate further on one of the questions.
What happens if the computer loses its connection/trust with Active Directory? Will LAPS change the local Administrator password on the computer, but fail to update it in AD? If this happens, I won’t know the local Administrator password. (Special thanks to reader Ken D. for this question.)
I am in a situation where a remote PC has lost its trust relationship with AD. LAPS is providing a password, that is still within the expiration date, but it is not working. I do not have any cached credentials for another user account with local admin rights on this remote machine. This has happened 3 times in the past 4 weeks in my environment and I am fairly certain no one is changing the password locally. Do you know what might be going on here?
I don’t, but you may want to enable Verbose logging on the computer (addressed in this article) and see if you can get some clues there.
Hi Kyle,
I have succesfully tested the Local Admin Password Soln on my test env. The only thing iam not able to come across online is a command to revoke access provided to a group.
for these commands below , is there a revoke/remove switch as well ? e.g. – if i want to remove Domain Admins to read password or if i want to remove a particular OU of computers from SelfPermission that i may have already granted ?
1. Set-AdmPwdReadPasswordPermission
2. Set-AdmPwdComputerSelfPermission
Thanks
Domain Admins can undo anything that you’re doing. It would be a waste of time to try and deny access to anyone in the Domain Admins group since they can just give themselves access again.