Unable to Login with Entra Credentials After Server Migration from VMware to Azure

Question

Cannot Login with Azure AD Credentials on Entra ID-Joined Windows Server 2019

Note: This post was compiled with AI assistance to organize extensive troubleshooting information.

Primary Question

Why can't I log in with Azure AD credentials on a properly Entra ID-joined Windows Server 2019 VM?

Despite successful device join, all services running, credential provider displaying correctly, and proper RBAC assignments, authentication with Azure AD credentials consistently fails. Authentication either falls back to NTLM (user not found) or reaches Azure AD but fails with MFA/credential errors.

---

Environment

• OS: Windows Server 2019 Datacenter
• Build: 10.0.17763.7922 (fully patched, October 2025 cumulative update)
• Cloud: Azure (Government Community Cloud tenant)
• Extension: AADLoginForWindows v2.2.0.0
• Connection Methods Tested: Direct RDP, Azure Portal RDP, Azure Bastion
• Migration: Migrated from on-premises VMware to Azure

---

Configuration Status

✅ Working/Configured Correctly

Device Join:

• dsregcmd /status shows AzureAdJoined: YES
  • TenantName properly populated after fresh join
    • MDM URLs configured
      • Device certificate issued with 10-year validity
        • Device visible in Entra ID → Devices
        RBAC:

        - "Virtual Machine Administrator Login" role assigned to user at VM scope
        
           - Assignment verified in Access control (IAM)
        
           **Authentication Services:**
        
           ```typescript
           TokenBroker (Web Account Manager): Running, Automatic
        

wlidsvc (Microsoft Account Sign-in): Running, Manual
dmwappushservice (Device Management): Running, Manual RuntimeBroker processes: Multiple instances running ```

                 **Credential Provider:**
                 
                    - Cloud Experience Credential Provider (GUID: C5D7540A-CD51-453B-B22B-05305BA03F07) installed
                    
                       - Displays at Windows login screen
                       
                          - "Other user" option shows user's email address correctly
                          
                          **Local Administrators:**
                          
                             - User account added: `AzureAD\[username]`
                             
                                - Verified with `net localgroup "Administrators"`
                                
                                **Network:**
                                
                                   - VM can reach login.microsoftonline.com (confirmed via auth attempts)
                                   
                                      - NLA disabled for troubleshooting
                                      
                                         - Firewall allows RDP
                                         

❌ Not Working

1. Authentication consistently fails - Cannot log in with Azure AD credentials
2. Inconsistent authentication routing - Sometimes reaches Azure AD, sometimes uses NTLM
3. Azure Bastion uses NTLM instead of Azure AD authentication
4. Primary Refresh Token never establishes - AzureAdPrt: NO persists
5. Account Domain blank in NTLM authentication attempts

---

Problem Description

Observed Behavior

When attempting to log in with Azure AD credentials:

1. Login screen displays correctly with user's email address
2. User enters password
3. Authentication fails with generic error

Two Different Authentication Patterns Observed

Pattern 1: Azure AD Authentication Attempted (Initial Tests)

AAD Operational Log shows:

Event 1081: OAuth response error: interaction_required
Error: AADSTS50076 - MFA required for access

Event 1081: OAuth response error: invalid_grant  
Error: AADSTS50126 - Invalid username or password

Pattern 2: NTLM Fallback (Bastion and Most Recent Tests)

Security Event Log shows:

Event ID: 4625 (Logon Failure)
Account Name: ******@domain.com
Account Domain: [BLANK]
Status: 0xC000006D (Logon failure)
Sub Status: 0xC0000064 (User name does not exist)
Authentication Package: NTLM
Logon Process: NtLmSsp

AAD Operational Log: No events during these attempts - Azure AD is not contacted

Critical Finding: Azure Bastion Uses NTLM

When connecting via Azure Bastion (which should natively support Azure AD authentication):

• Security logs show NTLM authentication attempt
• Account Domain field is blank
• Error: 0xC0000064 (user not found)
• No events in AAD Operational log
• Source shows Bastion workstation name

This is particularly concerning as Bastion is specifically designed for Azure AD authentication and should never fall back to NTLM.

---

Troubleshooting Performed

Fresh Device Join Attempt

After initial failures, performed complete rejoin:

1. Unjoined device: dsregcmd /leave
2. Uninstalled extension via Azure Portal
3. Restarted VM
4. Configured services:

Set-Service -Name "TokenBroker" -StartupType AutomaticStart-Service -Name "TokenBroker"Start-Service -Name "wlidsvc"Set-Service -Name "dmwappushservice" -StartupType ManualStart-Service -Name "dmwappushservice"

1. Reinstalled AADLoginForWindows extension
2. Verified successful join

Result: Join successful with improved configuration (TenantName populated, MDM URLs configured), but authentication issue persists.

Device Registration Logs Confirm Successful Join

User Device Registration logs show:

Event 389: Automatic Azure SecureVM Join Succeeded
Event 105: The complete join response operation was successful  
Event 111: The registration status has been successfully flushed to disk
         Join type: 12 (DEVICE_AUTO_MSI)
Event 106: The post join tasks for the AAD Authentication Package completed successfully

Extension Behavior

Extension consistently reports in logs:

Device is already secure joined. Exiting Enable action

This occurs even after complete unjoin/uninstall, suggesting extension detects join state before completing full configuration.

---

Current dsregcmd /status Output

Device State:
  AzureAdJoined: YES
  EnterpriseJoined: NO
  DomainJoined: NO

Tenant Details:
  TenantName: [Populated after fresh join]
  TenantId: [Valid GUID]
  Idp: login.windows.net
  
MDM Configuration:
  MdmUrl: https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc
  MdmTouUrl: https://portal.manage.microsoft.com/TermsofUse.aspx
  MdmComplianceUrl: https://portal.manage.microsoft.com/?portalAction=Compliance

SSO State:
  AzureAdPrt: NO
  AzureAdPrtAuthority: [empty]

Ngc Prerequisite Check:
  IsDeviceJoined: YES
  IsUserAzureAD: NO
  PolicyEnabled: NO
  PostLogonEnabled: YES
  DeviceEligible: YES
  SessionIsNotRemote: NO

---

Diagnostic Commands Used

Check Authentication Services

Get-Service -Name "TokenBroker", "wlidsvc", "dmwappushservice"
Get-Process | Where-Object {$_.ProcessName -like "*broker*"}

Check Credential Providers

Get-ChildItem "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers" | ForEach-Object {
    [PSCustomObject]@{
        GUID = $_.PSChildName
        Name = (Get-ItemProperty $_.PSPath).'(default)'
    }
}

Check Authentication Failures

# AAD Operational Log
Get-WinEvent -LogName "Microsoft-Windows-AAD/Operational" -MaxEvents 30

# Security Log - Authentication Failures  
Get-WinEvent -LogName Security | Where-Object {$_.Id -eq 4625}

# Device Registration
Get-WinEvent -LogName "Microsoft-Windows-User Device Registration/Admin" -MaxEvents 50

Verify Device Join

dsregcmd /status
dsregcmd /RefreshPrt  # Attempted, no effect

---

---

What We've Ruled Out

• ❌ OS version - Fully patched to latest cumulative update (17763.7922)
• ❌ Missing services - TokenBroker, wlidsvc, dmwappushservice all running
• ❌ Credential provider - Cloud Experience Credential Provider installed and displays
• ❌ RBAC permissions - VM Administrator Login role properly assigned
• ❌ Device join - Join successful with complete configuration
• ❌ Network connectivity - VM can reach login.microsoftonline.com
• ❌ Extension installation - Extension status shows "Provisioning succeeded"
• ❌ Local permissions - User added to Administrators group

---

Comparison: What Should Happen vs. What Happens

Expected Behavior

1. User enters Azure AD credentials at login
2. Cloud Experience Credential Provider routes authentication to Azure AD
3. Azure AD authenticates user (may prompt for MFA if required)
4. User successfully logs in
5. Primary Refresh Token established

Actual Behavior (NTLM Fallback)

1. User enters Azure AD credentials at login
2. Authentication falls back to local NTLM
3. Account Domain field is blank (not recognized as Azure AD account)
4. System looks for user as local account
5. Fails with "user name does not exist" (0xC0000064)
6. No PRT established

Actual Behavior (Azure AD Attempted)

1. User enters Azure AD credentials at login
2. Authentication request sent to Azure AD
3. Azure AD responds with MFA required or invalid credentials
4. Login fails
5. No PRT established

---

Similar Issues Found

Searched for similar issues but found no exact matches with:

• Successful Entra ID join
• All services running
• Credential provider displaying
• Yet authentication consistently failing
• Especially with Azure Bastion falling back to NTLM

---

Workaround Currently Using

Accessing VM via local administrator account until Azure AD authentication can be resolved. This works but doesn't meet security requirements for centralized identity management and MFA enforcement.

---

What I Need Help With

Primary Issue: I cannot log in with Azure AD credentials despite everything being configured correctly according to Microsoft documentation.

Specific Help Needed:

Has anyone successfully enabled Azure AD login on Windows Server 2019? If so, are there steps beyond the standard documentation?

Is there a known issue with authentication routing on Server 2019 that causes the behavior I'm seeing?

Why would Azure Bastion fall back to NTLM for an Entra ID-joined VM?

What diagnostic information can I gather to understand why the credential provider isn't routing authentication to Azure AD consistently?

Current Blocker: This prevents us from using centralized identity management and MFA for our Azure VMs, which is a security requirement.

---

Additional Context

• Migration Source: This VM was migrated from on-premises VMware infrastructure to Azure
• Windows licensing successfully converted from on-premises KMS to Azure licensing
• System Assigned Managed Identity configured and working
• All other Azure integrations working correctly
• Only Azure AD user authentication failing

Thank you for any assistance!