I have Windows Server VMs in Azure with the AADLoginForWindows extension, so interactive administrators can sign in over RDP with Entra ID. I also need Ansible and CI/CD pipelines to authenticate to the VMs and run commands over WinRM or SSH. I expected to use an Entra app registration or service principal, similar to the service-principal-based SSH workflow available for Linux VMs, but Windows does not appear to support that scenario. The remaining options seem to be using the original local administrator, creating and managing additional local accounts, or switching to Azure VM Run Command. The first two create scaling and security problems, while Run Command would require redesigning automation that currently assumes an established remote session. Is there a supported way to use Entra-based application credentials for Windows VM access?
3 Answers
We ran into the same limitation and wrapped VM Run Command in a small internal script that presents an interface similar to SSH. That allowed us to keep most of our existing Ansible pipeline structure while Azure handled the actual command execution. It is not as clean as native WinRM access, but it avoided creating and rotating lots of local accounts.
Unfortunately, AADLoginForWindows mainly enables interactive Entra sign-in through RDP. It does not provide service-principal authentication for WinRM or SSH on Windows in the same way it does for Linux. The supported alternatives are local or domain accounts, or authenticating to Azure and using VM Run Command instead.
Yes, Run Command is the remote execution approach I was referring to. It works technically, but it does not fit our existing automation model without substantial changes.
Your understanding is correct: the Windows login extension supports interactive user access, but service principals cannot currently authenticate to Windows VMs over WinRM or SSH in the same way they can on Linux. Other patterns include using a managed identity for scripts initiated inside the VM, a dedicated Entra user account for automation, or joining the VM to AD DS or Entra Domain Services and using a domain service account. Each option has trade-offs, and none provides the simple Linux-style service-principal push model.
That sounds like the kind of compatibility layer we may need. Keeping the current playbooks mostly intact would make Run Command more practical.