If you haven’t already, you should familiarize yourself with the term LAPS. It may be one of the most underrated tools from Microsoft for on-premises environments. LAPS stands for Local Administrator Password Solution. In a nutshell, LAPS is a solution which can do the following:

  1. Regularly update and reset the local admin password for administrator accounts.
  2. Provide a managed way to retrieve the admin password when the IT team needs it.

LAPS is deployed in many of my enterprise clients. But the classic version has an issue. It is based on on-premises technologies, like Windows Active Directory, which makes it hard to use in a modern workspace especially when Windows endpoint is a cloud-managed solution as there is no Windows Active Directory for those endpoints, and the classic version of LAPS does not work in this situation. To address the problem, Microsoft recently released a revamped version of LAPS that can store the local admin password in Entra ID to work with cloud-managed endpoints. Let’s get into the details about deploying LAPS and how to leverage this solution to further enhance the security of Windows endpoints.

The Requirements

To use Windows LAPS (the name of the new LAPS), instead of having to install agents on Windows endpoints, a supported version of Windows is needed, which is listed below:

  • Windows 10 or 11 with Apr 2023 update.
  • Windows Server 2019 or 2022 with Apr 2023 update.

For those familiar with the classic version of LAPS (called Microsoft LAPS), you may expect the need to install agents. This is not the case for Windows LAPS as Microsoft bundles the needed components in Windows and exposes it via a configuration service provider (CSP). CSP is a component available in Windows 10 or 11 that provides a standardized way for us to customize the Windows. This replaces the need for using registry files, for example, during Windows deployment to apply settings to Windows endpoints. Intune is one of the primary tools that leverages CSP to customize Windows configurations. Hence, we can control Windows LAPS via an Intune policy. Of course, if needed, you can still configure the setting via GPO, but in this article, we focus on using Intune to deploy the setting.

One point to note is that if you have systems running older versions of Windows, like Windows Server 2016, and want to use LAPS to manage local administrator passwords, you have no choice but to deploy Microsoft LAPS.

If you plan to store the local administrator password in Entra ID, make sure you check if the tenant enabled support for Windows LAPS. The setting is found in the device settings blade of the Entra admin center as shown in Figure 1.

Deploy Cloud-Based Windows LAPS to Windows Endpoints
Figure 1: Entra ID Device Settings page to Enable LAPS

Configure Windows LAPS with Intune

The first step is to deploy a policy that only works when Windows is patched with the Apr 2023 or later update, and creating a Dynamic Device security group that targets the devices running the required Windows version or later is the best choice. Building a membership rule to match devices based on the Windows version is a bit tricky, so we need to use a regular expression.

Deploy Cloud-Based Windows LAPS to Windows Endpoints
Figure 2: Sample Dynamic Group Membership Rules include Windows with a specific version

Here’s an example of a membership rule:

(device.deviceOSType -eq “Windows”) and (device.deviceOwnership -eq “Company”) and (device.deviceOSVersion -match “^10.0.22000.(1817|19[0-9][0-9]|[2-9][0-9][0-9][0-9])”) or (device.deviceOSVersion -match “^10.0.22621.(1555|1[6-9][0-9][0-9]|[2-9][0-9][0-9][0-9])”)

The membership rule will match all Windows devices where the version is 10.0.22000.1817 or above (Windows 11 21H2) and 10.0.22621.1555 or above (Windows 11 22H2). I opt to use regex (the -match condition) because it is easier to match multiple versions at once, but you can use other ways, like manually populating some value to an extensionAttribute at device level (like extensionAttribute1) and creating a membership rule that only includes devices with that flag or explicitly specifying the version. But the focus here is to make sure a group includes all Windows devices that are supported by Windows LAPS. Once Entra ID populates the group membership with the devices, we can use the group in an Intune policy to target only supported devices.

Next, we create an account protection policy in the Intune admin center as shown in Figure 3.

Deploy Cloud-Based Windows LAPS to Windows Endpoints
Figure 3: Creating Windows LAPS policy in Intune Admin Center

The policy doesn’t contain many settings, but here are the key ones:

  1. Backup Directory –controls where the auto-generated password is stored. Supported directories are Entra ID and on-premises Active Directory. Note that you cannot have Windows LAPS backup the password to both directories, meaning you can only backup to either Entra ID or to Active Directory, not both.
  2. Password Age Days –controls when passwords will get reset by Windows LAPS. The number specified in the policy dictates the interval between password resets.
  3. Administrator Account Name –specifies the name for the local administrator account managed by Windows LAPS. If you do not want to change the name of the account or want to manage a built-in administrator account, you can leave this blank.

Other settings are self-explanatory so I’m not going to go into them in any depth here. Figure 4 illustrates an example of the policy that I use for many clients.

Deploy Cloud-Based Windows LAPS to Windows Endpoints
Figure 4: Windows LAPS Intune Policy Example

After completing the policy, Intune must deploy the policy to the target devices. This process can take several hours. If you want to make sure the policy is applied to a PC, the best way is to login to that PC and check the Windows event log (at Application and Service Log > Microsoft > Windows > LAPS). The event log will give some clues on whether the LAPS policy deployed successfully or what’s wrong when LAPS does not work (like no local administrator password found in Entra ID Admin Center or Intune Admin Center). One example of such error is shown in Figure 5.

Deploy Cloud-Based Windows LAPS to Windows Endpoints
Figure 5: Windows LAPS policy deployment error

Windows LAPS Operations

Two actions must be performed after enabling Windows LAPS: retrieval of the local administrator password for the endpoint or manually resetting the password after use. To do these tasks, you must wait until the policy is deployed to the target device and the first password is uploaded to Entra ID. Then locate the device in the Intune Admin Center and choose the Local Administrator Password link on the device details page. This will give you access to the local administrator account password as shown in Figure 6.

Deploy Cloud-Based Windows LAPS to Windows Endpoints
Figure 6: Retrieve Local Administrator Account Password from Intune Admin Center

Another operation we can do is manually triggering the update of the local administrator account password. The process is called Rotate Local Admin Password. You have access to the action from the device page in Intune Admin Center as show in Figure 7.

Deploy Cloud-Based Windows LAPS to Windows Endpoints
Figure 7: Triggering the process to rotate local administrator account password

To perform the two tasks, use an account assigned either the Global Admin or Cloud Device Admin role.

With Windows LAPS capable of sending local administrator account passwords to Entra ID and managed by Intune-based policies, I encourage you to include this deployment in Intune deployment projects. Windows LAPS helps to protect the Windows endpoint in the tenant from security risks associated with the default local administrator account as stated here. But pay attention to see if any applications use that account (should not but it happens) before deploying LAPS to every device.  

About the Author

James Yip

James Yip is Managing Director at Eventus based in Asia. He spent 20 years in Microsoft technologies. As part of this job, he plays the role of architect and technology lead in projects he involves. He and his team design and implementation services for local and worldwide clients on desktop deployment and management solutions, for example Microsoft Azure, .NET, Microsoft 365. James is a Microsoft Certified Trainer for almost 20 years and he enjoys teaching courses related to Microsoft technologies. He enjoys travel between countries and enjoy foods whenever he goes. Follow him on Twitter.

Comments

  1. Lukas

    This requires the local admin account already present, right? So it can’t really be used on its own but combined with a script to create a local account, which I found a hit and miss in the past.
    It puzzles me why MS does not include creation of an admin account in the new solution.

  2. Michiel

    In your article and every other article on other blogs I read this instruction about how to configure Laps. But to my understanding it doesn’t end there. You also need to enable the Laps on the device (via a policy) and enable the administrator account (via a policy). I combined these two in one device configuratie policy. Unless missing something, those are not done by the other policy from your article? And then when you have enabled Laps, how do you sign into the device? Maybe that’s beyond the scope of Laps, but I got it working by signing in as “Device name\administrator” and the password given by Laps.

    1. James Yip

      Usually, when I RDP to that device, I use .\administrator or like what you used device\administrator.

  3. JB

    Great article,

    We don’t use old LAPS but interested in this new version, and like the agentless feature.

    thanks

    1. James Yip

      It is agentless. That’s the best part of the new Windows LAPS

Leave a Reply