Introduction

In today’s ever-evolving threat landscape, managing local administrator accounts securely across a distributed device fleet is more crucial than ever. For many organizations, the days of using a shared local admin password should be gone — and for good reason.

With the new Windows LAPS experience and its seamless integration into Microsoft Intune, things just got even better. This simplifies the deployment of Windows LAPS as there is (since march) no need for scripts or CSPs configurations as this is now built in!

In this blog, we’ll take a closer look at how Intune and the "new" configuration experience with Windows LAPS work together—eliminating the need for custom scripts or manually configured CSPs. We’ll explore what’s changed and how you can get started with this powerful, streamlined solution.

Now - Let’s jump right in!

🎯 Goals

The goal of this blog post is to provide IT administrators with a clear, step-by-step guide for configuring Windows LAPS using Microsoft Intune.

By the end of this blog post, you should be able to:

  1. Understand the importance of LAPS and how it enhances endpoint security.
  2. Create and deploy a Windows LAPS policy in Intune to enforce the configuration and the user creation on organizational devices.
  3. Verify the password and the best practice approach.

⚙️ Technical Description

With the April 2023 Windows update, Microsoft introduced the modernized Windows LAPS (Local Administrator Password Solution), a built-in capability in Windows 10/11 and Windows Server 2019/2022, eliminating the need for separate LAPS installation packages. This should not be new for Endpoint / Intune Admins.

However, I still see organizations of various sizes that rely on static administrator accounts or use the built-in administrator. Let's take a quick dive into why LAPS is a must in today's security landscape:

  • Native OS Integration: Windows LAPS is built into Windows
  • Cloud and Hybrid Support:
    • Entra ID Join: Store and rotate passwords in Entra ID, visible in the device object via the Microsoft Entra admin center or Graph API.
    • Hybrid Join: Continue to support storing passwords in on-prem Active Directory if required.
💡
As always: Go Entra ID joined or prepare to sacrifice your sanity. Hybrid join is like using a flip phone in a smartphone world —technically it works, but why do that to yourself? 😅📟➡️📱
  • Microsoft Intune Integration: Configure and deploy Windows LAPS policies directly through Intune using a dedicated configuration profile. Additionally with the new experience - no custom CSP or scripts required.
  • Policy Options:
    • Password rotation frequency
    • Password complexity requirements
    • Post-expiration actions (e.g., automatic password reset)
    • Administrator account selection (built-in or custom local accounts)
  • Secure Storage: Encrypted password storage with RBAC-controlled access in both Entra ID and Active Directory.
  • Audit Logging: Password retrievals are logged in Event Viewer and optionally forwarded to SIEM solutions.
  • Recovery and Manual Rotation: Admins can trigger on-demand password rotation or recovery through the Microsoft Entra portal or PowerShell.

Requirements:

  • OS: Windows 10 20H2+ or Windows Server 2019+ (Implementing Servers is not Part of this Blog) with April 2023 update or later
💡
Today it should be anyway Windows 11 - You do have some time to upgrade but soon its october 👯
  • MDM: Microsoft Intune (MEM)
💡
The Windows LAPS automatic account management feature is only supported in Windows 11 24H2, Windows Server 2025 and later releases
  • Directory: Entra ID or Active Directory (for on-prem storage)
  • Permissions: Admins require appropriate Intune RBAC or Entra permissions to view and manage passwords

Benefits:

  • Simplified deployment with built-in OS support
  • No reliance on Group Policy or custom scripts
  • Cloud-first management via Microsoft Intune
  • Improved compliance, security, and auditability

How does it look like:

With the illustration I have tried to show how LAPS works from a simplified view. But what enables the function in the background is the Graph API:

Every configuration that is made in the Intune portal is ultimately a Graph API request, which is then answered by the Graph API if you have the apprpriate permissions to do so.

Now lets hop into the configuration for Windows LAPS.

🔧 Step 1: Entra Configuration

💡
In this blog, we are looking into configuring Windows LAPS for entra joined endpoints with the new Windows LAPS experience

Enabling Windows LAPS on Tenant level:

🔧 Step 2: Intune Configuration

Go to Endpoint Security > Account Protection in Intune to create and assign a Windows LAPS policy:

At this point, every Intune admin should be familiar with the basic LAPS deployment process.

In previous approaches, this step typically required a script or a manually configured CSP to create and prepare the local administrator account for use with LAPS.

But now, there’s a major improvement: Automatic Account Management
(This feature now eliminates the need for manual setup and simplifying the entire process)

So, now befor we proceed there are some Endpoint Security considerations you have to be clear befor proceeding with the settings above:

  • To enhance the security of the LAPS account it is deactivated by default
‼️
Friction: The managed account requires prior activation through GPO or MDM policy configuration before it becomes operational.
  • The name of the LAPS account will use a random numeric suffix
‼️
Friction: Present here too, as IT staff must be trained to avoid relying on a common, organization-wide managed account name.

Improvements and Considerations from Microsoft

Automatic account management security improvements and considerations

Like any user account, Windows local accounts represent a potential vulnerability vector for attackers. This threat is present for Windows LAPS-managed accounts as well, although mitigated to a huge extent by the highly complex passwords generated (and regularly rotated) by Windows LAPS. Automatic account management offers two improvements which can further mitigate threats when more assurance is desired for high-threat environments.

  • First, maintaining the managed account in a disabled state completely eliminates any chance that the account can be the target of a password spray or similar attack. Keeping the managed account in a disabled state does however introduce friction: the managed account must be enabled (via GPO or MDM policy manipulation) before the account can be used.
  • Second, maintaining a unique managed account name per device (via account name randomization) makes an attacker's job harder. Instead of knowing in advance which account to attack on all devices, the attacker must somehow find out the name of the account on a given target device. There's more friction here as well since IT staff must be trained to not rely on knowing a common, organization-wide managed account name.

IT admins deploying Windows LAPS in security critical environment should consider these features. Whether the friction introduced by adopting these features is acceptable depends on how often the Windows LAPS-managed accounts need to be used, plus the security requirements of a given IT environment.

Source: https://learn.microsoft.com/en-us/windows-server/identity/laps/laps-concepts-account-management-modes#automatic-account-management-security-improvements-and-considerations

🔎 Validation and Testing

Once you've heroically crafted the policy—like every good Intune Admin does—the legendary phase known as "The Waiting" begins... 🕐
But fear not! Somewhere deep in the cloud, architecture elves aka Microsofts Intune Product Team are optimizing pipelines and sprinkling performance dust. It will get faster. #DDM (Deep Dive by Rudy Ooms)

After some Minutes you should be able to verify the account in the Intune Portal:

... and after that on the device itself as well:

I intentionally switched the operating system to German to demonstrate that, regardless of the current OS language, the correct group is selected based on the SID and not dependent on the OS language.

When you check the eventviewer you can see the configuration in detail:

Operational tip: You can manually trigger a password rotation as a remote action directly from the device object in the Intune portal.

💡
It is possible to rename the Administrator Account in the Endpoint Security Policy (created through automatic account management) to a new name - in my testing it does take more time to take effect than the initial configuration itself - but it worked

Migrate to Automatic Account Management

Microsoft recommends that customers prefer automatic account management mode at all times, except for those (rare) situations that require unique configuration of the target management account. It is further recommended that automatic account management mode be configured to create\target a custom account, and that the built-in Administrator account be left unused and maintained in a disabled state.

While the new Windows LAPS experience in Intune offers improved functionality, migrating from an existing setup using scripts or custom CSPs isn't as straightforward as it might seem. If the local administrator account was previously created manually or through custom methods, the new policy with the automatic accoung management won’t take control of that account — even if you assign the same name. In this case, the LAPS policy simply won't apply.

To fully switch to the new experience, you’ll need to either remove the existing local admin account from all devices before applying the new policy or wait for a natural client lifecycle event (e.g., a reimage or redeployment). Only then can the new Automatic Account Management feature create and manage the local admin account as intended.

Sure - Technically, it’s also possible to manage some devices using the manually created script or CSP configuration and others with the new Automatic Account Management feature. However, I don’t recommend this migration path. Since you can’t apply a suffix to differentiate accounts, you’ll end up with multiple local administrator accounts on each device — the old one and the new one — leading to confusion and potential security issues.

If you need a script to delete the local Admin, there you go:

Script-DeleteLocalAdmin

#Define the username to delete

$userToDelete = "USERNAME_of_Admin_to_delete_HERE"

#Define log directory and file path

$logDir = "$env:LOCALAPPDATA\Temp"
$logFile = "$logDir\Script-DeleteLocalAdmin.log"

#Ensure the log directory exists

if (!(Test-Path -Path $logDir)) {
New-Item -Path $logDir -ItemType Directory -Force | Out-Null
}

#Function to write to log

function Write-Log {
param (
[string]$Message,
[string]$Level = "INFO"
)
$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
"$timestamp [$Level] $Message" | Out-File -FilePath $logFile -Append -Encoding UTF8
}

#Check if the user exists

if (Get-LocalUser -Name $userToDelete -ErrorAction SilentlyContinue) {
try {
Remove-LocalUser -Name $userToDelete -Confirm:$false
Write-Host "User '$userToDelete' has been deleted successfully." -ForegroundColor Green
Write-Log "User '$userToDelete' has been deleted successfully."
} catch {
Write-Host "Failed to delete user '$userToDelete'. Error: $" -ForegroundColor Red
Write-Log "Failed to delete user '$userToDelete'. Error: $" "ERROR"
}
} else {
Write-Host "User '$userToDelete' does not exist." -ForegroundColor Yellow
Write-Log "User '$userToDelete' does not exist." "WARNING"
}

📝 Summary

Let’s recap what we covered in this post:

  • Endpoint Security Setting for configuring Windows LAPS using the new experience (Without Scritpt or CSPs)
  • Verifying the functionality of LAPS

As someone who works closely with modern endpoint management and endpoint security, I’m excited to see how Microsoft continues to evolve and simplify essential features like Windows LAPS. The deeper integration into Intune not only saves time but also strengthens security and compliance across the board. If you haven’t already explored the new LAPS capabilities, now is the perfect time to take advantage of these improvements and make your Windows device management more secure and efficient.

Thanks for reading — feel free to share your thoughts or experiences in the comments!

⚠️ Disclaimer

The configurations shared in this post reflect my personal approach to solving this specific challenge. Every environment is unique, so adapt these solutions to fit your needs.

Happy configuring! 😊

The link has been copied!