Enable Azure AD Authentication on Azure VMs | Lensix

TL;DR

This check flags Azure VMs that rely only on local accounts and SSH keys instead of Azure AD (Microsoft Entra ID) authentication. Without it, you lose centralized identity, MFA, and conditional access on your servers. Fix it by installing the AADLoginForLinux or AADLoginForWindows extension and assigning the right RBAC login roles.

Most teams spend a lot of effort securing the front door of their cloud accounts with MFA and conditional access, then leave the back door wide open: the VMs themselves still use shared local credentials and long-lived SSH keys. The VM Azure AD Authentication Disabled check looks for exactly that gap. It tells you which of your Azure virtual machines are missing Azure AD (now Microsoft Entra ID) login, which means access is governed by something other than your central identity provider.

What this check detects

The check inspects each Azure VM and verifies whether the Azure AD login extension is installed and the VM is configured to authenticate users against Microsoft Entra ID. Specifically, it looks for:

The AADSSHLoginForLinux (or legacy AADLoginForLinux) extension on Linux VMs.
The AADLoginForWindows extension on Windows VMs.
A system-assigned managed identity on the VM, which the extension depends on.

If none of these are present, the VM is treated as relying on local authentication only, and the check fails.

Note: Azure AD authentication for VMs is not the same as joining a VM to a domain. The extension lets users sign in with their Entra ID credentials over SSH or RDP, and it routes authorization through Azure RBAC instead of local group membership. Domain join (AADDS or Active Directory) is a separate mechanism.

Why it matters

When a VM uses only local accounts and SSH keys, that VM lives outside your identity perimeter. The consequences show up in a few concrete ways.

Credentials are scattered and hard to revoke

SSH private keys get copied to laptops, pasted into CI pipelines, and shared in chat threads. When an engineer leaves the company, you can disable their Entra ID account in seconds, but you have no easy way to know which VMs still trust their key. With Azure AD authentication, removing the user from the tenant removes their access to every enrolled VM at once.

No MFA, no conditional access

Local SSH and RDP logins bypass all the protective controls you have built around Entra ID. There is no multi-factor prompt, no check on device compliance, no block on logins from unexpected countries. An attacker who phishes or finds a leaked key gets straight in.

Warning: Applying conditional access policies (such as requiring MFA) to VM login can lock out automated jobs that sign in interactively. Test policies against a pilot group and use service principals or managed identities for automation instead of human accounts.

Weak audit trail

Local logins are recorded in the VM's own logs, which are easy to tamper with and rarely centralized. Azure AD sign-ins flow into Entra ID sign-in logs, so you get a tenant-wide record of who accessed what, when, and from where. That matters for incident response and for compliance frameworks like SOC 2 and ISO 27001 that expect centralized access logging.

Attack scenario

A common breach pattern: an attacker obtains an SSH key from a compromised developer machine or a misconfigured public bucket. With local-only auth, that key works until someone manually rotates it. With Azure AD login, the same key is useless because authentication runs through Entra ID, and any conditional access policy would have blocked the attempt anyway.

How to fix it

Remediation has two parts: install the login extension on the VM, then grant users an RBAC role that permits login. Skipping the second step is a common mistake. The extension alone does not grant anyone access.

Step 1: Enable Azure AD login on a Linux VM

az vm extension set \
  --publisher Microsoft.Azure.ActiveDirectory \
  --name AADSSHLoginForLinux \
  --resource-group my-rg \
  --vm-name my-linux-vm

This automatically enables a system-assigned managed identity if one is not already present.

Step 2: Enable Azure AD login on a Windows VM

az vm extension set \
  --publisher Microsoft.Azure.ActiveDirectory \
  --name AADLoginForWindows \
  --resource-group my-rg \
  --vm-name my-windows-vm

Step 3: Assign login roles

There are two built-in roles:

Virtual Machine User Login — sign in as a standard user.
Virtual Machine Administrator Login — sign in with admin or sudo rights.

az role assignment create \
  --role "Virtual Machine Administrator Login" \
  --assignee [email protected] \
  --scope /subscriptions//resourceGroups/my-rg/providers/Microsoft.Compute/virtualMachines/my-linux-vm

Tip: Scope role assignments to a resource group rather than individual VMs so new machines in that group inherit access automatically. Even better, assign roles to Entra ID groups rather than individual users so onboarding and offboarding stays a single operation.

Step 4: Sign in

Once enrolled, users authenticate through the Azure CLI rather than passing a key directly:

# Install the SSH extension once
az extension add --name ssh

# Connect using Azure AD credentials
az ssh vm --resource-group my-rg --name my-linux-vm

Terraform example

For teams managing VMs as code, add the extension and identity in your module:

resource "azurerm_linux_virtual_machine" "this" {
  name                = "my-linux-vm"
  resource_group_name = azurerm_resource_group.this.name
  location            = azurerm_resource_group.this.location
  size                = "Standard_B2s"
  admin_username      = "azureuser"

  identity {
    type = "SystemAssigned"
  }

  # ... os_disk, network_interface_ids, source_image_reference ...
}

resource "azurerm_virtual_machine_extension" "aad_login" {
  name                       = "AADSSHLoginForLinux"
  virtual_machine_id         = azurerm_linux_virtual_machine.this.id
  publisher                  = "Microsoft.Azure.ActiveDirectory"
  type                       = "AADSSHLoginForLinux"
  type_handler_version       = "1.0"
  auto_upgrade_minor_version = true
}

resource "azurerm_role_assignment" "vm_login" {
  scope                = azurerm_linux_virtual_machine.this.id
  role_definition_name = "Virtual Machine Administrator Login"
  principal_id         = azuread_group.vm_admins.object_id
}

Warning: Enabling the extension does not disable existing local accounts or SSH keys. Until you remove or restrict them, both paths work. Plan a cutover where you confirm Azure AD login works, then rotate out the local credentials.

How to prevent it from recurring

Fixing VMs one at a time does not scale. Bake the requirement into your platform so new machines arrive configured correctly.

Azure Policy

Microsoft ships a built-in policy that audits or deploys the extension automatically. Assign the "[Preview]: Configure Linux machines to use Azure AD authentication" initiative (and its Windows counterpart) with a DeployIfNotExists effect so any non-compliant VM gets remediated.

az policy assignment create \
  --name "require-aad-vm-login" \
  --display-name "Require Azure AD login on VMs" \
  --policy "" \
  --scope /subscriptions/ \
  --location eastus \
  --mi-system-assigned

CI/CD gate

If you deploy infrastructure through pipelines, run a policy-as-code check before apply. With Checkov, for example, you can write a custom check that fails any azurerm_linux_virtual_machine without an attached AAD login extension. Wire it into the pull request stage so non-compliant VMs never reach production.

Tip: Pair the policy with Lensix continuous monitoring so you catch VMs that drift out of compliance after deployment, for example a machine restored from an old snapshot or created manually during an incident.

Best practices

Assign roles to groups, not people. It keeps offboarding to a single action and avoids orphaned grants.
Use just-in-time access. Combine VM login roles with Privileged Identity Management so admin access is granted temporarily and is logged on activation.
Layer conditional access. Require MFA and compliant devices for VM sign-in, but exempt automation identities so jobs do not break.
Restrict the network too. Azure AD login secures identity, not reachability. Keep VMs behind Azure Bastion or a private network and avoid public SSH and RDP ports.
Remove local accounts after cutover. The whole point is collapsed to nothing if local keys keep working in parallel.
Centralize sign-in logs. Route Entra ID sign-in logs to Log Analytics or your SIEM so VM access is part of your overall audit trail.

Azure AD authentication turns your VMs from isolated islands of credentials into part of your managed identity perimeter. It is one of the higher-leverage compute controls you can apply, because it makes MFA, conditional access, centralized logging, and instant revocation work on the servers themselves, not just the control plane.

VM Azure AD Authentication Disabled: Why It Matters and How to Fix It