Overview of Microsoft LAPS (Local Administrator Password Solution)

*After you’ve downloaded and deployed LAPS, the team at Recast Software created a nifty dashboard for you to monitor your LAPS “health” – bringing visibility to overlooked security necessities. This is included in the Enterprise version of the Right Click Tools.

I really like the LAPS dashboard because, since I’m already in the ConfigMgr console every day, it keeps LAPS visible and at the front of our team’s minds. I find this highly useful. It only takes a few seconds to pull it up, check my stats, and move on. If I find an anomaly, I can start looking into it. Learn more about the LAPS Dashboard.

Overview of Microsoft LAPS

“The Local Administrator Password Solution (LAPS) provides management of local account passwords of domain joined computers. Passwords are stored in Active Directory (AD) and protected by ACL, so only eligible users can read it or request its reset.” – Microsoft

Basically, LAPS reduces the risk of having a default (backdoor perhaps) local administrator and default password on your machines by having each machine use a different complex password for the account. Before LAPS, most organizations had a generic local admin e.g., ORG_LocalAdmin, with the same password on each machine e.g., ORG_P@ssword. Problem with that is, if a machine was compromised, the malware/hacker could move laterally among all your machines gathering more and more data to deepen the security breach. With LAPS implemented, you remove that attack vector, so if one machine is compromised, the ability to move laterally to another machine is greatly reduced.

There are quite a few guides out there, and the Microsoft Docs are pretty good too. I didn’t do extensive searching before creating this post, so note that some of this information may be redundant from what you’d find online.

What’s Covered

In this walk-through, I’ll cover how to:

  • Download LAPS
  • Create Source Folders
  • Create End Point Installer Application
  • Deploy LAPS Application to End Points
  • Manually Install LAPS Admin Client
  • Infrastructure Setup
    • Extend AD Schema (from Domain Controller)
  • Setup LAPS AD Groups and Permissions
  • Verify Permissions and Read / Reset Access
  • Basic Enable Group Policy
  • Perform tests to confirm that permissions are working.

What’s Not Covered in My Overview of Microsoft LAPS

  • The “Why’s” behind each step. Much of the details and reasons why you must perform these steps are already well documented in the Microsoft “LAPS_OperationGuide” which is part of the download, and quite honestly, that’s what I’m using as I create this walk through, so I suggest you look over that before you even start.
  • Every deployment scenario. This is a generic and SIMPLE lab. While much of this is the same for any environment, each environment is different and each organization is setup differently. LAPS setup will probably require multiple team involvement (AD / CM / Deployments / GPO).

What to Consider

Things to consider beforehand:

  • Active Directory structure (OUs with workstations).
  • Who will have Rights to READ the LAPS Password?
  • Who will have Rights to RESET the LAPS Password?

‍Download LAPS

Client Deployment:

Download LAPS Client and Docs from Microsoft:  https://www.microsoft.com/en-us/download/details.aspx?id=46899.

Client deployment LAPS

Source Folders

I downloaded all the files into a “LAPS” directory. Then I created a new folder to move the MSI files into.

LAPS Installer

End Point Installer Application

In the ConfigMgr console, I am now going to create a new application. Point it to the x64 version of the MSI.

Specify settings for this application

Once you choose the MSI, click on the Open button and then you can click on Next. The information needed for the application will be pulled from the MSI.

Application information

After you click on the Next button, you’ll come to General Information. I added “Microsoft” as the publisher and changed /q to /qn.

At this point, just click on the Next button. I recommend leaving the defaults until the download completes and then you can click Close.

The Local Administrator Password Solution application is now in your console. Only a couple tweaks are needed. In the Properties of the application, click on the Deployment Types tab. Choose the Deployment and click Edit. Go into Requirements and add the x64 for versions of Windows in your environment.

Deploying the LAPS Application

LAPS properties

At this point, we have the app, so let’s get it deployed to the workstations. Since you already added the logic into the app, you can safely deploy it to your workstations.

NOTE: This is where knowing your environment is crucial, so make sure you deploy the app to the appropriate collection. Perhaps you have a business reason to not deploy it to all workstations. Just use best practices for deployments (maintenance windows, etc.).

The remainder of this example will be generic.

Fill in software and collection fields
Specify settings to control how this software is deployed

I left the settings for Scheduling, User Experience and Alerts all set to the defaults (see the screenshot below).

Confirm the settings for this new deployment

Infrastructure Setup

Admin Client / LAPS Management Client

Now that the client is deployed, let’s get the infrastructure setup. First, you should switch over to a client test machine, or your typical admin workstation. I’m going to get the LAPS client installed along with the Management Tools. Once you kick off the installer (double-click on the MSI) click through the first couple screens to get to the Custom Setup screen. Once here, enable all the options.

LAPS custom setup

Next, go ahead and install it. You’ll need to grab some of the items it installs and then copy them back out to your source server for easy access.

Go to C:\Windows\PolicyDefinitions. Here you will grab the AdmPwd.admx file, and the AdmPwd.adml file from the en-US subfolder. I created a folder called GPO_ADMX in my source location to copy them to (see, “New…,” in the screenshot below).

Source location

Also, copy the AdmPwd.PS folder from the PowerShell modules: C:\Windows\System32\WindowsPowerShell\v1.0\Modules

You’ll need all these files later.

Copy folder from PowerShell Modules

Extend AD Schema (from Domain Controller)

Now, the following steps you can (and should) do from your workstation, but to make sure I had a connection and rights, I did it from my actual domain controller (DC). You’d typically do this from an admin machine with proper credentials. Your DC should be running Windows Server CORE and it should not even have a desktop experience. You typically never want to actually log onto a DC. But this is a lab, and I’m just making a demo.

Modify the AD Schema

On the domain controller (DC), copy the AdmPwd.PS folder you uploaded to your source into the local module repository on your DC. Next, launch the admin PowerShell console. In the image below, you can see how I tried to Import-Module before I had copied the files onto the DC. After the copy, the command runs correctly.

Modify the AD Schema

Next, run the command: Update-AdmPwdADSchema

Run the command

In my lab, you can see it successfully added two attributes and modified one class.

LAPS AD Groups and Permissions

Hopefully you considered a few things before starting this journey, like which OU the workstations are in that you want to apply LAPS group policy to, and who do you want to have permissions. In my lab, it’s pretty easy. I have one “Master OU” setup for workstations, and all other workstations fall into sub-OUs of that master OU.

Target workstations OU

At this point, it’s nice to check and see who has rights to view that info in AD. In your PowerShell console, type: Find-AdmPwdExtendedrights -identity <OU Name> | Format-Table

See who has rights to view info in AD

As you can see, the rights in my lab are pretty clean, and I’m ok with these folks having rights to LAPS.

Now, in AD, let’s setup “Read” and “Reset” groups. This will grant these groups access to LAPS. In the screenshot below, you’ll see that I’ve created two groups: LAPS Read Only and LAPS Reset PWD.

Setup a Read & Reset Group

Now we need to grant machines the ability to update their own passwords. I’m going to grant access to the “SELF built-in account” for all machines in the Workstation OU: (Workstations) Set-AdmPwdComputerSelfPermission -OrgUnit <OU Name>

Grant Machines the ability to update it's own password

Next, we need to grant users rights to look up that information. This is where those groups we just created come in. We’re going to give the “LAPS Read Only” group rights to read LAPS passwords: Set-AdmPwdReadPasswordPermission -OrgUnit <OU Name> -AllowedPrincipals <FQDN Group Name>

We’re going to give the  “LAPS Reset PWD” group rights to reset LAPS passwords: Set-AdmPwdReadPasswordPermission -OrgUnit <OU Name> -AllowedPrincipals <FQDN Group Name>

Verify Permissions

I’m also going to confirm this worked by using the Find… command (see the screenshot below).

Find Command

Now, back in AD, you can nest the groups you want in your LAPS Security Groups to have access.

Nest the groups in your LAPS Security Groups

For my lab, I have Service Desk Tier 1 and 2 with read only rights, and Tier 3 can reset.

Enable Group Policy

You’ll need to copy the ADMX and ADML files you copied to your source folder into your Group Policy Central Store, which can be located here: \\FQDN\SYSVOL\FQDN\policies

Group Policy

Now you can launch Group Policy and create your LAPS policy. In this demo, I’m going to create a new simple policy, but you can always add it into one that already exists. The new GPO is set to the defaults, except I disabled User Policies. I did this because my new policy is all machine based, so there is no point in having it look for user policies.

Launch Group Policy and create your LAPS Policy

I used basic settings to make this work with my lab. In my lab, I have a local admin account on the computer, besides the disabled default, which is named “MyLocalAdmin.” This is the account I want LAPS to manage.

Local admin account example

That’s it. Now it’s time to confirm you get the results you want.

Confirm Permissions

‍These are the permission tests I will perform:

  • Standard End Users (should have No Rights).
  • Service Desk Tier 1 and Tier 2 (should have Read access).
  • Service Desk Tier 3 (should have Read and Reset access).

Test 1: Standard User

Test 1: Standard User

Test 2: Tier 1 and Tier 2 Service Desk

Test 2: Tier 1 Service Desk

Test 3: Tier 3 Service Desk

Test 3: Tier 3 Service Desk

What did I learn from this test? Reset permissions do not include Read. Unless you have a need for a group to be able to reset this password, and not read it, I’d nest the LAPS Reset PWD group inside of the LAPS Read Only group.

LAPS Read Only Group

Test again.

LAPS Read Only Group test

Now, I get the desired results. Tier 3 Service Desk can both Read and Reset the LAPS password.

Conclusion – Overview of Microsoft LAPS

I hope you found this LAPS overview useful, and hopefully it provided additional information not found in other online guides. The main reason for writing this blog post, is to prepare the groundwork for Part 2, configuring Recast Management Server User / Groups to view the LAPS Compliance Dashboard in the ConfigMgr console.

-By Gary Blok

See how Right Click Tools are changing the way systems are managed.

Immediately boost productivity with our limited, free to use, Community Edition.

Get started with Right Click Tools today:

Share this:

Support

  • This field is for validation purposes and should be left unchanged.

Contact

  • This field is for validation purposes and should be left unchanged.
en_USEnglish