Add policies: Deploy the Microsoft Entra login extensions to Azure VMs

[simon-vedder]

What this adds

Two DeployIfNotExists policies that install the Microsoft Entra login extensions, so users can sign in to Azure virtual machines with their Microsoft Entra credentials — over SSH on Linux, over RDP on Windows — with access governed by Azure RBAC and Conditional Access, and no SSH keys or local accounts to manage.

Path	Extension	Effect
policyDefinitions/Compute/configure-windows-virtual-machines-to-use-microsoft-entra-login	AADLoginForWindows	DeployIfNotExists
policyDefinitions/Compute/configure-linux-virtual-machines-to-use-microsoft-entra-login	AADSSHLoginForLinux	DeployIfNotExists

There are built-in policies that harden an Entra-enabled machine (357cbd2d-… and cd22fc48-…, disable local users), but none that deploy the extensions that enable Entra login in the first place — the same gap the repo already fills for Log Analytics, Qualys, IaaSAntimalware and other extensions.

Design notes

• Both policies match only virtual machines that already have a system-assigned managed identity, because the extension cannot install without one (exit code 22 on Linux, terminal error 1007 / DSREG_E_MSI_TENANTID_UNAVAILABLE on Windows). As with any extension-deploy policy, the prerequisite is left to the assignment: pair these with a policy that provides the identity — for example Microsoft's built-ins 3cf2ab00-13f1-4d0c-8971-2ac904541a7e and 497dff13-db2a-4c0f-8603-28fa3b331ab6 — assigned and remediated first.
• Image filtering follows the documented support matrix, switchable per OS with matchAllWindowsImages / matchAllLinuxImages for custom and golden images. Windows Server Core is excluded (no Desktop Experience). Rocky and AlmaLinux each ship under two marketplace publisher names; both are in the default supportedImagePublishers.
• evaluationDelay: AfterProvisioningSuccess so newly created virtual machines are picked up without a manual compliance scan.

Testing

Validated in a live subscription against a lab covering the match and no-match cases. The extensions were assigned alongside the two built-in identity policies above — the same way you would combine them in practice.

Case	Expected	Result
Windows Server 2022 Datacenter	extension installed, AzureAdJoined : YES	pass
Windows Server 2022 Datacenter Core	no extension (excluded)	pass
Windows 11 24H2	extension installed, AzureAdJoined : YES	pass
Ubuntu 24.04	AADSSHLoginForLinux installed	pass
Ubuntu 24.04 with a user-assigned identity	extension installed, user-assigned identity preserved	pass
CentOS (publisher outside the supported list)	no extension (excluded)	pass

Both interactive sign-in paths were confirmed end-to-end on a policy-configured VM:

• Linux: az ssh vm lands on a shell as the Microsoft Entra user, no SSH key placed on the machine.
• Windows: RDP with Entra web sign-in (enablerdsaadauth + targetisaadjoined) reaches the desktop as the Microsoft Entra user, including an MFA prompt satisfied through the browser flow.

A note on the compliance signal

Like any DeployIfNotExists policy, the Windows policy reports a virtual machine compliant once the extension reports provisioningState: Succeeded. AADLoginForWindows can report Succeeded while the Entra join itself failed (for example error_hostname_duplicate from a leftover device object) — a property of the extension, identical under a manual install, not something a policy can detect. Where the join state matters, verify out of band with dsregcmd /status. The Linux extension does not create a device object and surfaces failures as a failed provisioning state. Flagging it for transparency.

References

• Sign in to a Linux VM using Microsoft Entra ID and OpenSSH
• Sign in to a Windows VM using Microsoft Entra ID

[simon-vedder]

@microsoft-github-policy-service agree