How to roll out Microsoft LAPS via GPO and why you should do it?

Local Administrator Password Solution (LAPS) is a password manager that can be used to automatically rotate the Built-in Administrator (RID-500) account on each individual workstation or server.

The great thing about LAPS is, that it doesn’t require any additional infrastructure to store passwords, and you don’t have to pay for it, because it is free. There are of course better solutions in the market with the likes of CyberArk and Thycotic to rotate the password of the RID-500 account, but not every organization can afford an expensive PAM solution.

In this blog post, we are going to explain how to roll out LAPS. But not only that, we will also explain how to use the RID-500 account for remote administration, and show why it’s actually not that bad to use it. Once we have LAPS in place.

Source: https://www.anoopcnair.com/laps-for-windows-10/

How does LAPS work?

LAPS relies on something that is called a Client-Side Extension, which is a set of .dll files that contains the settings, that have been applied to a targeted computer.

The Client-Side Extension performs multiple administrative tasks, such as checking if the Built-in Administrator password has been expired, and if it has been expired. It would rotate the password automatically and store it in a confidential AD attribute, that is only readable for users with the right permissions. The permissions can be managed via Active Directory ACLs.

What are the benefits of LAPS?

One of the benefits with deploying LAPS is, that it would mitigate attackers from moving laterally across each machine in the network by using the RID-500 account. Once the password of the RID-500 is the same on every workstation and member server, it is just a matter of time before an attacker has compromised the entire environment.

Why does this problem still exist?

A common reason why the password of the Built-in Administrator (RID-500) account is often the same is, due to the sysprep process of an OS image. Most organizations have a system image in place that has all the business software (already) installed on it, which means that if they clone an image to a machine. The end-user or the IT Admin doesn’t need to manually install each individual software again.

The problem with sysprep is, because once a system image has been cloned from a machine to another machine. The local SAM database will be cloned as well, and that database stores all the hashes of each local account. Including the RID-500 account.

How to install LAPS?

First, we need to temporary assign ourselves “Schema Admin” permission in Active Directory and then download the Microsoft LAPS solution.

  1. After we installed LAPS, we have to make a schema change. Two new attributes will be extended to the AD schema, which will be ms-MCS-AdmPwd that stores the RID-500 account password of a computer, and the second attribute is ms-Mcs-AdmPwdExpiration that contains the expiration time of a password.

In order to do this, we need to run the following commands:

Import-Module admpwd.ps
Update-AdmPwdADSchema

Result

At the sample result, we can see the two new attributes. I have already done this step, so that’s why you’ll see ”EntryAlreadyExist”, but it should say “Success” if you are installing LAPS for the first time.

2. Now we need to delegate rights on an OU that contains the workstations and member servers, where we want to have LAPS on. This allows the machine accounts that resides in those OU write to the specified attributes.

First, we are going to delegate the rights on the Workstations OU.

Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Workstations,DC=contoso,DC=com"

Result

At the sample result, we can see that the rights have been delegated on the workstations OU.

Second, we are going to delegate the rights on the Member servers OU. Don’t do this on Domain Controllers!

Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Member servers,DC=contoso,DC=com"

Result

At the sample result, we can see that the rights have been delegated on the member servers OU.

3. Now we need to delegate rights to an AD group that is allowed to reset and view the plain-text password that is generated by LAPS.

First, we will start with an AD group that contains all the Helpdesk employees. This group is only allowed to reset and view the LAPS password on the workstations, but not the member servers.

Set-AdmPwdReadPasswordPermission -OrgUnit "OU=Workstations,DC=contoso,DC=com" -AllowedPrincipals "Tier2-Helpdesk"

Result

At the sample result, we can see that Tier2-Helpdesk can now reset and view the LAPS password of all the client workstations.

Now we need to do the exact same thing for our Tier-1 admins (e.g. Server Admins), so in this case. Tier-1 admins can only reset and view the LAPS password of all the member servers, but not the workstations.

Set-AdmPwdReadPasswordPermission -OrgUnit "OU=Member servers,DC=contoso,DC=com" -AllowedPrincipals "Tier1-ServerAdmins"

Result

At the sample result, we can see that the “Tier1-ServerAdmins” group can reset and view the LAPS password of all the member servers.

4. Now we have to save the LAPS package in a read-only folder that can be accessed by all the devices.

In this example, we just created a folder on a DC and saved the LAPS packages in that folder.

Second thing we have to do is share “Read” access to the Domain Computers group.

Create a GPO to push LAPS

At the last phase, we have to create a GPO and link it to the OUs to push out LAPS. This section will explain the different steps to configure the GPO, etc.

  • Create a Group Policy Object and give it a name that you prefer.
  • In the Group Policy Management Editor, go to Computer configuration, then Policies, and then Software settings.
  • Right click on Software installation and then new
  • Select the exact network path where we saved our LAPS package.

  • Go to Computer configuration, then Administrative Templates, and then LAPS
    • Password Settings: Enabled
    • Do not allow password expiration time longer than required by policy: Enabled
    • Enable local admin password management: Enabled

    The only thing we have to do now is to link the GPO to the workstation and member servers OU.

    Verify LAPS installation

    It can take some time before the Group Policy has processed, but after it has finished. We are able to query the LAPS password of each device.

    Why it is not bad to use the RID-500 account?

    Once we have LAPS rolled out, I don’t think it’s bad to use the RID-500 account to do admin tasks. In this example, we are going to use the RID-500 account to RDP to the “APD-Device” machine. APD-Device is a regular client workstations, so users in Tier-2 can retrieve the LAPS password of it.

    1. The first thing is to verify that the AD group can retrieve the LAPS password of all the workstations that is stored in the appropriate OU.
    Find-AdmPwdExtendedRights -Identity "OU=Workstations,DC=contoso,DC=com" | Format-Table ExtendedRightHolders

    Result

    At the sample result, we can see that “Tier2-Helpdesk” can retrieve the LAPS password.

    • Retrieve LAPS password

    In order to retrieve the LAPS password, we can use the RSAT module for example and run the following command:

    Get-ADComputer -Identity "APD-Device" -Properties ms-MCS-AdmPwd

    Result

    At the sample result, we can see the LAPS password of the device.

    2. We are now going to use the RID-500 account of “APD-Device” and RDP to the machine with it.

    3. What happens when the “APD-Device” is now compromised?

    Here is an example of an attacker dumping credentials from the LSASS process memory. Testing is the RID-500 account FYI, but I just renamed it.

    We have the NT hash of the RID-500 account that resides on the “APD-Device”. Can we use that NT hash to perform a pass the hash attack and authenticate against “APD-Server”?

    The answer is no, because as we discussed earlier. LAPS randomizes the password on each workstation and member server, so here we will see that it will fail.

    Summary

    We have learnt how to roll out Microsoft LAPS via Group Policy and why it is actually not that bad to use the RID-500 account, once we have LAPS in place.

    Reference

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out /  Change )

    Google photo

    You are commenting using your Google account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )

    Connecting to %s