Microsoft Local Administrator Password Solution (LAPS)

[Arthur]

This is Microsoft's solution to the issue of using a common local account with an identical password on every computer in a domain. It's based on AdmPwd.

 

Website / Download (Direct Links: x64, x86) / Documentation (Datasheet, Operations Guide, Technical Specification, KB3062591)

 

Microsoft is now offering the Local Administrator Password Solution (LAPS). This provides a solution to the issue of using a common local account with an identical password on every computer in a domain. LAPS resolves this issue by setting a different, random password for the common local administrator account on every computer in the domain. Domain administrators who use this solution can determine which users, such as helpdesk administrators, are authorized to read passwords.

 

For environments in which users are required to log on to computers without domain credentials, password management can become a complex issue. Such environments greatly increase the risk of a Pass-the-Hash (PtH) credential replay attack. The Local Administrator Password Solution (LAPS) provides a solution to this issue of using a common local account with an identical password on every computer in a domain. LAPS resolves this issue by setting a different, random password for the common local administrator account on every computer in the domain. Domain administrators using the solution can determine which users, such as helpdesk administrators, are authorized to read passwords.

 

LAPS simplifies password management while helping customers implement recommended defenses against cyberattacks. In particular, the solution mitigates the risk of lateral escalation that results when customers use the same administrative local account and password combination on their computers. LAPS stores the password for each computer’s local administrator account in Active Directory, secured in a confidential attribute in the computer’s corresponding Active Directory object. The computer is allowed to update its own password data in Active Directory, and domain administrators can grant read access to authorized users or groups, such as workstation helpdesk administrators.

 

Use LAPS to automatically manage local administrator passwords on domain joined computers so that passwords are unique on each managed computer, randomly generated, and securely stored in Active Directory infrastructure. The solution is built on Active Directory infrastructure and does not require other supporting technologies. LAPS uses a Group Policy client-side extension (CSE) that you install on managed computers to perform all management tasks. The solution’s management tools provide easy configuration and administration.

 

How does LAPS work?

The core of the LAPS solution is a GPO client-side extension (CSE) that performs the following tasks and can enforce the following actions during a GPO update:

 

• Checks whether the password of the local Administrator account has expired.
  
• Generates a new password when the old password is either expired or is required to be changed prior to expiration.
  
• Validates the new password against the password policy.
  
• Reports the password to Active Directory, storing it with a confidential attribute with the computer account in Active Directory.
  
• Reports the next expiration time for the password to Active Directory, storing it with an attribute with the computer account in Active Directory.
  
• Changes the password of the Administrator account.
  

The password then can be read from Active Directory by users who are allowed to do so. Eligible users can request a password change for a computer.

 

What are the features of LAPS?

LAPS includes the following features:

 

• Security that provides the ability to:
   
  
  • Randomly generate passwords that are automatically changed on managed machines.
    
  • Effectively mitigate PtH attacks.
    
  • Enforced password protection during transport via encryption using the Kerberos version 5 protocol.
    
  • Use access control lists (ACLs) to protect passwords in Active Directory and easily implement a detailed security model.
    

   

  [*]Manageability that provides the ability to:

   

  • Configure password parameters, including age, complexity, and length.
    
  • Force password reset on a per-machine basis.
    
  • Use a security model that is integrated with ACLs in Active Directory.
    
  • Use any Active Directory management tool of choice; custom tools, such as Windows PowerShell, are provided.
    
  • Protect against computer account deletion.
    
  • Easily implement the solution with a minimal footprint.
    

 

Requirements

 

• Active Directory:
  
  • Windows 2003 SP1 and above
    

   

  [*]Managed machines:

  • Windows Vista with current SP or above; x86 or x64
    
  • Windows 2003 with current SP and above; x86 or x64 (Itanium not supported)
    

   

  [*]Management tools:

  • .NET Framework 4.0
    
  • PowerShell 2.0 or above
    

Edited May 3, 2015 by Arthur

[Arthur]

Local Administrator Password Solution (LAPS) Implementation Hints « Ask Premier Field Engineering (PFE) Platforms

 

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.)