Local Administrator Password Solution (LAPS) Implementation Hints and Security Nerd Commentary (including mini threat model)

First published on TechNet on Dec 28, 2015

Local Administrator Password Solution (LAPS) Implementation Hints and Security Nerd Commentary (including mini threat model)

Hi, Jessica Payne from Microsoft Enterprise Cybersecurity Group's Global Incident Response and Recovery team guest starring on the Platforms PFE blog today.

Credential theft is a major problem in the security landscape today. Matching local administrator passwords in an environment often contribute to that problem and are a popular target for bad guys. Far more than zero days or malware, credentials are what allow attackers to be successful in your network. I think this is best summed up by John Lambert from Microsoft Threat Intelligence Center.

"Adversaries need credentials more than malware. Deny them by avoiding the sins of Windows credential administration. pic.twitter.com/vQMasZWOwA"

— John Lambert (@JohnLaTwC) April 12, 2015

Randomizing the local administrator password has always been part of Microsoft guidance such as the Pass the Hash Whitepaper, however outside of solutions provided via a Premier offering we didn't have a supported Microsoft way to do this.

On May 1st 2015, Microsoft released LAPS. LAPS stands for Local Administrator Password Solution, and it exists to address the problem of having a common administrator password in an environment. LAPS is a fully supported Microsoft product that is available for free! (Or "at no additional charge" as some of my colleagues would want me to say.) I've done a Taste of Premier episode on the technology, but wanted to do this post for the people who prefer blog posts as well.

LAPS is designed to run in a least privilege model. No need to put a service account into the domain admins to manage passwords, the password resets are done in the context of the computer/system. There's no additional server to install - the passwords are stored in Active Directory. This has led to some interesting discussion on the Internet, with some saying "that makes AD a clear target." Active Directory has always been a clear target for attackers, and has always held "keys to the kingdom" that would allow an attacker to take complete control of an infrastructure. That's why we really want you to be aware of what the threats look like and how to configure and administer AD in a secure manner (Best Practices for Securing Active Directory, The Pass the Hash Whitepapers  and my talk on Securing Lateral Account Movement are good references for that.) By storing the passwords in AD, we're piggybacking on the controls you already should have in place to protect against Pass the Hash, Domain Admin level compromise, the Golden Ticket post exploitation technique, etc.   LAPS, just like many other security controls, should be seen as part of a holistic solution. Just taking care of local administrator passwords is a great step and a massive reduction in overall attack surface, but without the other mitigating controls in an environment it's absolutely true that attackers will still be able to gain a foothold and compromise your entire network. Randomizing local passwords is just a step in a security strategy, but it's a necessary step which is now easy and free with LAPS.

Installation

Installing LAPS is actually really straightforward. The guide included in the download has a great walk through, and I ran through a demo install (as well as discussion on implementation strategies) in my Taste of Premier video on LAPS.

Gotchas/Weird Stuff/Implementation Lessons Learned about LAPS :

• Your biggest challenges are going to be developing a delegation model and a workflow for using the passwords. If your OU structure isn't laid out based on policy boundaries, or if you don't already have well defined Role Based Access this can will be a challenge. Your workflow for accessing the passwords will dictate a lot of how you design the access. Are you planning on using the passwords ever? Are you just trying to stop Lateral Movement, so you see it just being a break glass account and using DART disks instead? If you do have people access them, that should decrease your password expiration time - make the credential viable for less time. You may even use an orchestration engine to front the password checkouts, which has access to the ms-MCS-admpwdexpirationtime attribute to make sure it resets right after use.
  
  
  
• LAPS only randomizes one local account password. By default, it randomizes the built-in admin account and discovers it by well-known SID. A different local account can be specified via GPO, but bear in mind it is discovered by name. So if I'm Bad Guy Bob using an Elevation of Privilege in win32k.sys or Steve the Rogue Admin, having access even temporarily + rename account = permanent access. Account discovery and management is static in a lot of password products, not just LAPS, so it also means someone with access could create another local account and add it to admins and have permanent access - this is actually something we've seen real bad guys do.  Local accounts are tricky things to manage, which is why we created the Local Account principle. The strategy I suggest to my customers is to have 1 (one) local administrator account - the built-in one. The built-in 500 SID account is always there, always an admin and always something you can re-enable if you know what you're doing. Embrace that it's there, that LAPS will always find it and manage it. Which leads to …
  
  
  
• Make LAPS part of your larger Credential Theft Mitigation strategy. Implement the steps in the Pass the Hash whitepaper, use Restricted Groups to be authoritative on who is an admin, deny Local Accounts access over the network and come up with a secure way to manage machines, such as RestrictedAdmin RDP with a non-admin account and elevation/RunAs locally with the LAPS managed password.
  
  
  
• Monitor for the use and creation of local accounts. These are Indicators of Compromise and the successful logon of the local administrator account is a far more accurate metric of danger than auditing access to the password in many organizations.
  
  
  
• Monitor for Lateral Movement on the whole in your environment. Stopping Lateral Account Movement from stolen credentials via Credential Hygiene and preventing the attacker wandering unfettered around your network is the #1 thing that would have made the Incident Responses I’ve been to this year less of an Incident. Even if you are using another password management product, Credential Theft Mitigation and stopping Lateral Account Movement are critical tasks for your environment. I'm doing a whole series on tracking Lateral Movement on the blog, so please feel free to follow along.
  
  
  
• Since ms-MCS-adminpwd only stores one password some customers have expressed concerns for what this means for a system restored from backup. The supported scenario there would be to reset the password with a supported tool such as DART. (DART is really cool btw, you can have it access BitLocker recover keys and build all sorts of interesting actions into it. DART is a fully supported Microsoft product and a great "known good publisher" alternative to going out and downloading a hacking tool if you need to reset a password.)
  
  
  
• There's a GPO setting for "do not allow Password Expiration Time longer than defined by policy." I consider that to be a non-optional option, as enabling this option means if someone sets the password expiration to be 300 days, LAPS will say "I think you meant 30 days."
  
  
  
• Native LAPS auditing is …not optimal. The password is stored in as an AD attribute, which means access is tracked via AD Attribute logging, Event ID 4662. The bad part about that is it can get really noisy, for instance if someone who has access to the password opens attribute editor it's going to show as a password read even if they didn't mean to. Kurt Falde's made great improvements to the auditing via Windows Event Forwarding and PowerBI on his blog.
  
  
  
• Access to the password is granted via the "Control Access" right on the attribute. Control Access is an "Extended Right" in Active Directory, which means if a user has been granted the "All Extended Rights" permission they'll be able to see passwords even if you didn't give them permission. LAPS includes the Find-AdmPwdExtendedrights cmdlet to track down who has those permissions.
  
  
  
• It's really straightforward to migrate from the unsupported AdmPwd solution or the SLAM scripts that LAPS has replaced, most people have no issues with it. If you have an issue moving from the supported SLAM scripts to LAPS, open a Premier case and we'll help you out.
  
  
  
• Learn what really happens during an Incident Response and what attackers are actually doing to get into your network. The state of security now in most IT Organizations is borderline panic and a rush to "secure all the things" and knowing what attackers do and allows you to prioritize what to fix first (Spoiler alert: Credential Hygiene, that's what you fix first.) 🙂

Plaintext password storage 

One of the discussions that frequently comes up during LAPS implementations is the fact the password is stored in plain text. Applying the proper ACLs to the attribute made this a non-issue in most environments. If you don't have access to the passwords, you can’t see them. We're securing access to the attribute (along with the entire directory) versus worrying about a case where the directory is already lost.  

There are other plaintext high value attributes in AD such as Bitlocker keys and due to the nature of secrets stored in AD loss of control of the database can lead to deeper compromise through other non-plaintext avenues. Strong ACLs and overall Credential Hygiene are the strategy to be using anyway, and applying them to LAPS is just another step. We did threat model the scenarios where plain text would be part of the attack below. Remember that LAPS is just part of the Credential Theft Mitigation strategy and LAPS attributes are just part of the very high value data you need to protect in Active Directory.

Attack strategies to take advantage of plain text password storage:

1. Acquire a copy of the NTDS.dit (Active Directory Database.) The passwords would be in plain text, meaning the attacker doesn't have to crack them. This attack vector is superfluous though, because if they have your NTDS.dit, they don't need to crack the passwords because of techniques like Pass the Hash. The machine computer account passwords are stored hashed in Active Directory just like user account passwords so the attacker could already have admin/system level access on those computers without the local administrator passwords. Additionally, the AD database contains far more powerful accounts of interest than local admin accounts - Domain Admins, high value users and the KRBTGT account for Golden Ticket creation. While the passwords are in plaintext, capture of the NTDS.dit is already game over, so the plain text doesn't add additional attack surface here in our opinion. You should already be protecting your AD against theft, so having the local admin passwords there doesn't really affect the value of AD or the need to protect it.
    
2. Steal the credentials or compromise the computer of someone with access to the passwords, access admin passwords for multiple computers in domain.  In most environments, the initial stolen credential would be someone with wide reaching admin access for all of the computer accounts they were delegated ms-MCS-admpwd attribute access to - a help desk or desktop engineer so - this isn't really increasing the attack surface in this scenario. It can actually reduce the time to detection in some ways, or at least provide better monitoring for the compromise. Without the LAPS delegation, the theft of the single desktop engineer level credentials would mean instant deep/wide privilege in the domain (CEO's computer for instance.) Abusing LAPS password delegation to gain this access means they would generate a very clear audit trail as they will have to work for each password. As the worst, this is likely a net equal. The basis of the attack is that a single account had unrestricted access to assets, but that has nothing to do with plain text storage (or which credential vault you are using since it's just stealing the identity of someone who would have access.)
    
3. To make use of the fact this is plaintext over the wire you would have to then use that stolen identity to open a tool such as LDP.exe that would send the password in plaintext over the network and then sniff the credentials. Since they already had access to the credentials, this threat vector would fall into the category of "post exploit technique" and is also superfluous. Active Directory Users and Computers, Powershell and the LAPS UI all send the password in an encrypted/obfuscated traffic channel. So if you provision the password access only to secondary admin accounts locked down to use from a known good source such as an admin workstation/jump server that is already secured with software restrictions, credential tiering and network policies as recommended this attack vector isn't likely to be the thing an attacker goes for.

 LAPS is just one part of a larger Credential Theft Mitigation and monitoring strategy, but an important one that you can implement for free. Hopefully this helps you on the way to a holistic security strategy.

Here's some links to the resources I talked about:

Pass the Hash Whitepapers:

https://microsoft.com/pth

Best Practices for Securing Active Directory:

https://aka.ms/bpsadtrd

Channel9 video on LAPS:

https://channel9.msdn.com/Blogs/Taste-of-Premier/Taste-of-Premier-How-to-tackle-Local-Admin-Password-Problems-in-the-Enterprise-with-LAPS

Blog posts on getting basic monitoring with Windows Event Forwarding in place and Tracking Lateral Movement:

https://docs.microsoft.com/en-us/archive/blogs/jepayne/monitoring-what-matters-windows-event-forwarding-for-everyone-even-if-you-already-have-a-siem

https://docs.microsoft.com/en-us/archive/blogs/jepayne/tracking-lateral-movement-part-one-special-groups-and-specific-service-accounts

Detailed LAPS auditing building upon Windows Event Forwarding:

https://docs.microsoft.com/en-us/archive/blogs/kfalde/laps-audit-reporting-via-wef-posh-and-powerbi

 -Jessica "http://aka.ms/jessica" Payne @jepayneMSFT

(With a little editorial help and moral support from John Rodriguez and Aaron Margosis)