Local Administrator Password Solution, at Ignite
Last Friday, Microsoft announced the release of the Local Administrator Password Solution, which solves the problem of having an identical local account and password on large numbers of domain-joined computers. I’ll be discussing and showing LAPS this Thursday, May 7, at the Microsoft Ignite conference, as part of a session I’m sharing with Mark Simos called Barbarians Inside the Gates: Protecting against Credential Theft and Pass the Hash Today. The session runs from 5:00pm to 6:15pm US Central time. The session code is BRK2334; [I’ll update here after I verify whether it will be broadcast live through the Ignite web site.] Jeremy Moskowitz will also discuss it during his Windows 10 Group Policy session (BRK3304), Wednesday at 9am US Central.
“Pass the hash” and other credential theft techniques have become standard operating procedure even for unsophisticated attackers once they have established control of one or more domain computers. This has made the problematic configuration of a common administrative local account with an identical password on all systems riskier than ever. Even if the account is not actively used, it can be trivially easy for an attacker with control of one computer to gain control of all other computers that have the same local account and password. The Local Administrator Password Solution (LAPS) addresses this problem with a group policy client side extension (CSE) that generates and sets a different, random password for this local account on every computer in the domain. This achieves one of the three primary recommendations in Microsoft’s whitepaper, Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques, which can be downloaded from www.microsoft.com/pth. LAPS stores the password in the computer’s corresponding Active Directory object, secured in a confidential attribute. Each computer is allowed to update its own local-account password data in Active Directory, and Domain Admins can grant “read” access to authorized groups or users, such as workstation helpdesk administrators.
More information and download links here: https://support.microsoft.com/en-us/kb/3062591
Comments
Anonymous
May 06, 2015
I have a question regarding resetting local administrator password remotely, though. Can anyone help me confirm whether using this tool will suffer the same problem as documented in KB290260? support.microsoft.com/.../290260 AFAIK, Win2003 servers also suffers this problem, because we hit this problem when working as vendor for a major bank. The e-cert we used become inaccessible after server room operator used the Computer Management MMC to set the local administrator's password, instead of using the "Change password" function in the Security Session invoked by pressing Ctrl-Alt-Del. [Aaron Margosis] Yes, those issues would apply, but this solution isn't for accounts that would have certificates, EFS-protected files, etc. It's also not for workgroup computers - they have to be domain-joined. One other clarification: the password isn't changed remotely - the computer manages and sets its own local account password.Anonymous
May 06, 2015
LOL "The e-cert we used become inaccessible after server room operator used the Computer Management MMC to set the local administrator's password, instead of using the "Change password" function in the Security Session invoked by pressing Ctrl-Alt-Del." It gives us a nice changelog horizon...Anonymous
May 07, 2015
Oh, that's pitiful. I thought I could recommend it to my ex-colleagues as they're mandated by auditing rule to change password periodically. Although the passwords are stored in envelops that requires written approval to open, the person who responsible to change the passwords still knows it because we had found no way to automate that, explicitly because of the said problem.Anonymous
May 12, 2015
The comment has been removedAnonymous
May 14, 2015
Thanks for the reply Aaron. What about after my privileged admin has logged off? Is it possible to purge the "dust bunnies" left in memory that could be used for a PtH attack if the server was compromised before a reboot or the user changed their password? [Aaron Margosis] After installing 2871997 that shouldn't be an issue. 2871997 backported improvements in 8.1/2012R2 to older versions of Windows. Prior to that, a service that kept a copy of a token or other resource belonging to an LSA session could keep the session and its contents from being released. After that update, LSA sessions are forcibly purged when the user logs off. http://blogs.technet.com/b/srd/archive/2014/06/05/an-overview-of-kb2871997.aspxAnonymous
May 18, 2015
Where can I get the setup guide/more information on the following? Got it from the LAPS_datasheet.docx.
- Extensibility: o Solution can be extended to provide additional functionality, such as: Additional encryption of password stored in AD Password history Web UI [Aaron Margosis] Through Microsoft Services. Contact your Microsoft Technical Account Manager.
Anonymous
June 05, 2015
Nice idea but does this make supporting machine twice as long? We already have over the top group policies in place by a security consultant who doesn't appear to understand he's not the lord ruler of the universe. It makes doing something that normally takes me 5 minutes, twice as long which essentially costs the business more money due to the time we take fixing things. Also I'm reading that this LAPS setup means you now have the passwords in AD in plain text instead of encrypted. Surely that's not a good thing? [Aaron Margosis] Twice as long? No. Re the "over the top group policies" - refer him to Sticking with Well-Known and Proven Solutions. See whether that helps. You are correct that the password data is not encrypted, but it is protected with strong ACLs so that they are readable only by domain admins and then to whomever the domain admins explicitly grant access. If you write down a password in big, readable block letters and then put that piece of paper in a highly secure safe, is it a problem that the password is not encrypted?Anonymous
June 05, 2015
Yes. Clear -Text is a concern for sure. Following the principle of least privilege, why should Domain Admins have the right to read the password. I have worked in large organizations where Domain Admins security group is removed from domain member servers and domain member computers. Domain Admins role is there to manage the AD infrastructure and not necessarily do any troubleshooting on member computers. That's a different role all together. Domain Admins don't automatically get permissions on Linux machines, Network appliances which is a good thing and same principle should apply on Windows domain members. We have been using SYNERGIX ADCE for managing Built-In Administrator Account Password and the software stores the password in encrypted format in Active Directory and uses unique encryption key for each computer. Domain Admins do not automatically get the right to decrypt the password. A security group is put in place that includes computer objects that are managed and also, user objects that can manage those computer admin password. Found this link you may be interested in reading .. www.synergix.com/products/active-directory-client-extensions/microsoft-laps-compared/ [Aaron Margosis] I agree with you that domain admins should not manage end user computers, etc., and I did not suggest that they should. Their role in LAPS is to designate who should have the various rights (read the password, force a password change). But don't think there's anything you can do in a Windows Active Directory environment that can lock out domain admins. In the same way that trying to restrict what a local admin can do on a particular computer, trying to enforce watertight security boundaries against domain admins is futile as well. They control security throughout the environment and can override or bypass any protections you try to put in place if they so choose. LAPS is an elegant and secure solution to the problem of common local accounts and requires minimal setup and management, requiring no additional infrastructure/application servers or databases. And it is free. I anticipate that it will get wide adoption and help stop a lot of attacks that are otherwise easy to perform (and commonly performed).Anonymous
July 02, 2015
You might want to look at AGASync.com a premium solution.Anonymous
July 16, 2015
As of the new release dated July 7th, version 6.1, the Find-AdmPwdExtendedrights feature no longer works. Any attempt, with any value, returns an error : "Find-AdmPwdExtendedrights : No such object found".Anonymous
July 28, 2015
Interesting ... www.linkedin.com/.../104959-6031814562586591234 [Aaron Margosis] Yeah, he's off by a few yards. My response is now "pending manager approval". Thanks for the pointer.Anonymous
August 31, 2015
Does a computer only generate a random password when it can talk to a domain controller or does it generate it at the interval defined in the settings regardless if it can talk to a domain controller. My concern is that a laptop will generate a new password and our Service Desk won't be able to see the new password in AD, and then employee is unable to login to their computer to connect to the network/VPN. [Aaron Margosis] It doesn't change the password of the local account until after it has set the corresponding attribute in Active Directory. Also, the information that the password needs changing is in AD, so it can't even tell that the password needs changing unless it's connected to the domain. This password expiration mechanism is not like that of normal account expiration.Anonymous
November 06, 2015
It's worth noting that although it's not officially documented or supported, LAPS does work on the 64-bit version of Windows XP. If your organization is stuck a requirement somewhere to utilize XP for some reason (e.g. IE6), one possible improvement would be to replace those remaining 32-bit XP with 64-bit XP instead, The reason it works? 64-bit XP shares the same code base as 64-bit Server 2003 (same service pack files, same patches, etc). That is not the case for 32-bit XP and 32-bit Server 2003. It's also why there is an SP3 for 32-bit XP but only SP2 for 64-bit XP. Using 64-bit XP would allow you to run LAPS and any other security-related stuff that works on 64-bit Server 2003 (including 99% of security patches - the ONLY 64-bit Server 2003 patch that I found that won't work on 64-bit XP is MS14-027 / KB2926765). Still old, still no longer patched, but a big improvement over 32-bit XP. More stable too. Again, not officially supported or documented by Microsoft, but worth noting if your organization is stuck running legacy software in some places. [Aaron Margosis] Interesting, and makes sense, technically. BUT, if you're going to go to the trouble to migrate to a different platform, with likely compatibility issues to deal with, you may as well move to a supported one, right?Anonymous
November 06, 2015
Of course... if you can move to a newer, supported platform, then you should. I only gave the scenario because there may be cases where that simply isn't an option... but 64-bit XP might turn out to be a better alternative to staying on 32-bit XP, if the software in question does indeed run on 64-bit XP after testing it (IE6 was one clear example - since Vista/Server 2008 came with IE7 standard).Anonymous
November 17, 2015
Heard Microsoft state LAPS is a tactical solution and to consider 3rd party solutions for strategic implementation. [Aaron Margosis] That's an interesting observation. I have no idea what it means, though. Any ideas?