Unlocking Windows LAPS: How to Safeguard Local Passwords with Administrative Units

Windows LAPS (Local Administrator Password Solution) has recently become generally available, introducing a robust and intriguing design built on multiple DLLs and functions.

Numerous resources exist that detail how to enable and utilize this feature. In this blog post, we will explore a crucial aspect of Windows LAPS – how to delegate access to the passwords, now securely stored within Entra.

Why delegation matters ?

In large organization, you don’t want admins having access to EVERY local administrators passwords. Managing local administrator passwords for numerous machines is a daunting task. While Windows LAPS provides a solution, it’s vital to control who has access to these sensitive credentials.

The answer lies in leveraging Administrative Units, a powerful feature that allows you to fine-tune access control.

You can scope the access and we’ll see how !

Create the role

First, create the role on Entra. You can either chose a builtin one or create your own custom role.

Here are the builtin roles having access to the local passwords content and/or metada :

You need the following permission to have access to the password content : microsoft.directory/deviceLocalCredentials/password/read

With this permission, you can create a custom role that focuses exclusively on local password access. This means you’ll have more control without the complexity of additional permissions found in native roles. I’ll use a custom role !

Entra portal > Identity > Roles & Admins > New Custom role > Pick the permission for password access and/or metada

_{I don’t use a PIM role for this usecase but you can of course chose to do so if you have the licences to leverage PIM.}

Here is my custom role created :

My Administrative Unit

Start by setting up Administrative Units (AUs) to manage permissions. The structure of your AUs should align with your organization’s specific needs. Consider factors like Business Units (BUs), geographic regions, use cases, or entities when structuring your AUs.

Use Case Example: In our use case, we’re restricting access to local passwords exclusively for devices in the HR department.

During the AU creation process, link the custom role you created earlier to the Administrative Unit. This step ensures that the permissions you defined are applied to the appropriate AUs.

You can also assign the custom role scoped on the AU later on. Pick admin directly or an admin group.

Assign your devices to the admin unit

To populate your admin units, you can use powershell, dynamic queries or adding the devices manually.

Using powershell, you use something like :

Where adminunitsid is the id of your admin unit and groupid is the id of the group containing your devices. Feel free to adapt the script to handle errors or logs !

If you’re part of the preview you can leverage dynamic queries to handle the admin unit membership.

Now your devices are « members » of the admin units :

Great !

Check with a Global Admin first

To make sure there is indeed a local password stored on Entra, i check with my global admin account if there is such a password.

I test two different devices : DESKTOP-78205VK and TOMMACHADO554D

Local password can be retrieved for both of these devices.

Using a different account : Admin0

Admin0 is a administrator having intune permissions. Its scope should be only devices belonging to user0 such as TOMMACHADO554D.

Though, somehow, he sees a device out of its scope, a device belonging to user8 : DESKTOP-78205VK :

Let’s see what happens if i try to access to the local password of both of these devices.

TOMMACHADO554D should work fine, as it is under my scope/administrative units :

Great !

Now what about DESKTOP-78205VK ? This device is not under my scope/admin unit :

Can’t get the local password ! Which is great, i should not have access to this device password.

Conclusion

Leveraging Administrative Units in Entra offers an effective approach to precisely control permissions. By harmonizing your custom roles with tailored scopes and integrating Privileged Identity Management (PIM), you establish a robust and adaptable system for managing access.

If you’re keen on diving deeper into understanding the intricacies of Windows LAPS behavior, i recommend exploring the insightful blog post by Sherlock Ooms. His expertise and informative posts make for an enriching reading experience. Enjoy your exploration!

Et voilà !