LAPS for Azure Arc is the new shining star, after for years, IT teams relied on the classic, legacy Microsoft LAPS tool. Microsoft then integrated Windows LAPS directly into the operating system core, modernizing the architecture. Now, the landscape expands further with the introduction of LAPS for Azure Arc. This evolution shifts password management from localized configuration policies up to a cloud-backed governance control plane.

Introduction

Securing local administrator credentials remains a critical baseline defensive measure for any enterprise. Leaving identical, static local passwords across a fleet of servers provides an open invitation for lateral movement and privilege escalation during a security breach.

For years, IT teams relied on the classic, legacy Microsoft LAPS tool. Microsoft then integrated Windows LAPS directly into the operating system core, modernizing the architecture. Now, the landscape expands further with the introduction of LAPS for Azure Arc. As Thomas Maurer recently highlighted in his deep dive with the Azure Edge Security product team, this evolution fundamentally shifts local credential security up to the Azure Policy control plane, moving password management from localized configuration policies to a cloud-backed governance framework.

This guide evaluates all three variations, details their underlying architectural differences, and provides an objective roadmap to help you choose the right approach for modern enterprise environments.

From Legacy to Hybrid Control Planes

Legacy LAPS

The original Microsoft Local Administrator Password Solution released over a decade ago. It relies entirely on a client-side MSI extension installed on every target machine. It requires a schema extension to Active Directory, storing passwords initially only in a clear-text attribute protected only by Active Directory Access Control Lists (ACLs). Group Policy Objects (GPOs) trigger password processing during client refresh cycles.

Windows LAPS

The native, built-in reincarnation of the tool introduced in modern Windows and Windows Server versions. It requires no separate client installation or software deployment. It natively supports encryption for Active Directory storage, integrates with Microsoft Entra ID for cloud-only or hybrid environments.

More details can be found in my original article here.

LAPS for Azure Arc

The cloud-managed evolution powered by Azure Policy and the OSConfig Machine Configuration extension. Instead of pushing local GPOs or relying on heavy mobile device management (MDM) tools, it uses declarative Azure Policy definitions to audit and configure local admin protection across Azure VMs and Arc-enabled physical or virtual infrastructure outside of Azure.

This finally also provides a way to onboard non domain joined Windows servers to LAPS in Entra ID.

My key facts:

• LAPS for Azure Arc enabled machines
• LAPS gets Cloud Native
• No GPOs for non domain joined server
• New Azure Policy for LAPS
• Password Rotation & Backup
• Support for Windows Server 2019 bis 2025

Read all about LAPS for Azure Arc (preview) here https://aka.ms/LAPS4ARC

Architectural Comparison

Understanding how each solution handles password orchestration, enforcement triggers, and storage locations highlights the clear technical progression toward hybrid management.

Direct Feature Comparison Matrix (AI generated)

The table below maps the major technical boundaries across all three generations of the Local Administrator Password Solution.

Step-by-Step Implementation Pathways

Transitioning to modern LAPS solutions requires understanding the mechanics of deployment. The following overview details how to implement both the local OS-native approach and the modern cloud-driven framework.

Setting Up Windows LAPS

Step 1: Update the Active Directory Schema using the Update-LAPSADSchema PowerShell cmdlet to add the modern secure password attributes and image rollback detection variables.

Step 2: Configure permissions using Set-LapsADComputerSelfPermission so computer objects can write their own rotated credentials to the directory securely.

Step 3: Author a Group Policy Object or Intune configuration profile to define password complexity rules, length criteria, and desired post-authentication actions.

Step 4: Link the policy to your target Organizational Units (OUs) to initiate automated local administrator credential rotation across the fleet.

Deploying LAPS for Azure Arc

Step 1: Ensure target machines are onboarded to Azure Arc with the Connected Machine Agent running and the Machine Configuration extension enabled.

Step 2: Import the custom LAPS policy definition JSON from the official Microsoft OSConfig repository into your Azure Policy authoring environment. (Preview only)

Step 3: Assign the policy at your chosen target scope, such as an enterprise hybrid-infrastructure resource group.

Step 4: Configure the policy parameters. Choose between Audit-only mode to detect local configuration drift, or Audit-and-configure mode to actively enforce and configure LAPS behaviors down to the host OS.

Important: If you deploy LAPS for Azure Arc on non-domain-joined servers located outside of Azure, you must configure the password backup directory target parameter to point to Microsoft Entra ID. Directing isolated non-domain servers to attempt an Active Directory backup will cause a total configuration failure, leaving local administrative passwords unrotated and unmanaged.

Tips & Tricks: When configuring modern Windows LAPS or Azure Arc policies, take advantage of the post-authentication action parameter. Setting this value to automatically rotate the password, terminate active user sessions, or trigger a reboot eight hours after a credential is read ensures that if an engineer uses the local administrator account for emergency maintenance, the access window closes completely and automatically without manual intervention.

My Recommendations

Do not spend time troubleshooting or patching the original Legacy LAPS MSI extensions. The old product belongs in the history books. It lacks the attribute encryption and modern posture-checking controls required to defend against sophisticated modern credential harvesting methodologies.

For pure on-premises, domain-centric infrastructure where cloud connectivity is restricted, migrate your legacy configurations directly to Windows LAPS with encrypted Active Directory storage. Ensure you run the latest schema updates to prevent torn states caused by virtual machine snapshot rollbacks.

For distributed architectures, branch locations, and enterprise hybrid fleets, utilize LAPS for Azure Arc. Managing identity and access configurations across hundreds of distinct locations through legacy GPOs or isolated Intune profiles creates operational blind spots.

When your IT Security and IT Architecture teams realize they can drop domain dependencies and enforce a secure identity posture across edge nodes, cloud environments, and isolated workgroup servers using a single control plane, the efficiency gains become immediately obvious.

Conclusion

Securing the local admin footprint has evolved from an unencrypted Group Policy hack into a primary architecture control plane component. Upgrading from Legacy LAPS to native Windows LAPS or implementing the declarative governance of LAPS for Azure Arc ensures your infrastructure remains protected against lateral movement. Evaluate your current connectivity boundaries, sunset legacy clients, and lean heavily on policy-driven automation to enforce your security baselines.

Classic Windows LAPS is configured machine by machine using Intune, Group Policy, or local CSP. While this approach works fine for isolated environments, it introduces unnecessary operational overhead when managing distributed enterprise infrastructure. Every single machine requires individual configuration delivery, tracking, and local troubleshooting.

LAPS for Azure Arc lifts that orchestration straight up to the centralized control plane. Instead of pushing scattered local profiles, you leverage Azure Policy combined with Machine Configuration. This allows you to audit and enforce the exact same operational settings through a single policy assignment across Azure VMs and Arc-enabled servers anywhere, whether they live on-prem, at the edge, or inside other clouds.

If you have any questions please don’t hesitate to reach out to me on LinkedIn, Bluesky or check my newly created Adaptive Cloud community on Reddit.

LinkedIn: https://www.linkedin.com/in/andreas-hartig/

Bluesky: https://bsky.app/profile/hartiga.de

Adaptive Cloud community on Reddit: https://www.reddit.com/r/AdaptiveCloud/

My YouTube Channel: https://www.youtube.com/@hartiga