Unable to access windows VM created in azure portal which is also a domain controller

Hello @Philip,

Based on your description, I can see that you’ve already verified most of the prerequisite requirements. However, I suggest checking the following additional points:

• Per-user MFA: Ensure that the user is not enabled or enforced in per-user MFA settings.
• Conditional Access Policies: If there is a Conditional Access policy requiring MFA, please make sure to exclude the "Microsoft Azure Windows Virtual Machine Sign-in" app (App ID: 372140e0-b3b7-4226-8ef9-d57986796201) from the targeted cloud apps.

Also, make sure you meet this condition:

Remote connections to VMs that are joined to Microsoft Entra ID are only allowed from Windows 10 or later PCs that are either Microsoft Entra registered (minimum build 20H1), Entra joined, or Entra hybrid joined to the same directory as the VM.

For reference, see this Microsoft Learn article: Sign in to a Windows virtual machine in Azure by using Microsoft Entra ID.

If MFA isn’t enabled through per-user MFA or conditional access policy and still unable to login into VM.

Try to check if Security Defaults were enabled in your tenant. While Security Defaults typically do not affect non-admin users signing into a VM, they do require Global Administrators to complete MFA. If your account has the Global Administrator role assigned, MFA is still being enforced due to Security Defaults. As per design we can’t login into the Azure VM with Microsoft Entra ID user if the MFA is being applied on VM login.

To work around this, create a new Global Administrator account and a backup admin account, then remove the Global Administrator role from your main account. This allows you to sign in to the VM without being prompted for MFA.

If you are still unable to sign in to the VM using Entra ID credentials, please share your email address and availability for a call over private message, and I’d be happy to assist you further.

Follow these steps to regain access and restore domain functionality.

1. Verify the VM is running and booting correctly

• In the Azure portal, confirm the VM is in a Running state.
• Open Boot diagnostics for the VM and check the screenshot/logs for Windows boot errors or blue screens. If the OS is not booting, resolve that first (for example by using an Azure recovery/repair method) before focusing on sign‑in.

2. Fix RDP connectivity to the domain controller VM If RDP to the DC itself fails:

• Check the VM’s NIC and subnet NSG rules to ensure inbound TCP 3389 is allowed and no higher‑priority deny rules block it.
• If still not reachable, use an alternate remote tool such as Azure Serial Console or other remote troubleshooting tool for Azure VMs to sign in with the local Administrator account.
• Once on the VM, verify:
  • Windows Firewall allows RDP.
  • Remote Desktop Services are running.
  • “Allow remote connections to this computer” is enabled and the account used is allowed RDP.
  • If RDP configuration or listener is corrupted, repair it as described in the Azure VM RDP troubleshooting guidance (reset RDP config, recreate listener, or redeploy as needed).

3. Check domain secure channel from the domain‑joined VM Since another domain‑joined VM cannot log on with domain credentials but works with local admin, the secure channel to the domain controller is likely broken.

On that domain‑joined VM (using local admin):

1. Identify the domain controller it is using:
   • Run in CMD:

          set | find /i "LOGONSERVER"
     

2. Test connectivity to the DC:
   • Use PowerShell Test-Connection to the DC’s FQDN. If there is no connectivity, troubleshoot the network path (NSGs, routing, firewalls). Network Watcher diagnostics can help.
3. Test the secure channel:
   • In PowerShell:

          Test-ComputerSecureChannel -Verbose
     

   • If it reports unhealthy, attempt repair:

          Test-ComputerSecureChannel -Repair
     

4. If repair fails, reset the machine account password:
   • On the domain‑joined VM, run:

          Reset-ComputerMachinePassword
     

   • Then reboot and try logging on with a domain account again.

If the DC VM itself has a broken secure channel to the domain (in a multi‑DC environment), run the same Test-ComputerSecureChannel and -Repair steps on the DC against another healthy DC.

4. Consider domain join hardening if rejoining is needed If a VM must be rejoined to the domain and the computer account already exists, ensure the account used to join has the Group Policy setting Domain controller: Allow computer account re-use during domain join applied, and that all domain controllers and member computers have Windows updates released on or after March 14, 2023, per KB5020276 - Netjoin: Domain join hardening changes.
5. If the DC VM remains inaccessible If, after fixing NSG/firewall/RDP and using Serial Console or other remote tools, the DC is still not recoverable, typical next steps are:

• Restore the DC from a backup/snapshot if available, or
• Build a new domain controller VM in Azure, join it to the existing domain (if any DC is still healthy), transfer FSMO roles as needed, and then decommission the broken DC.

Because this VM is both a domain controller and integrated with Entra ID/AAD, avoid simply deleting and recreating it without planning for AD and Entra synchronization impact.

References:

• Troubleshoot a failed trust relationship in an Azure Windows VM
• Troubleshoot session host virtual machine configuration