How to fix ""the target identifier in the request was not found in the tenant" when logging to AzureVM with AAD web credentials

Question

New Azure VM joined to AzureAD. Followed-default setup. When logging into the AzureVM using web access over rdp client, we get prompted for web interactive login and once authentication completes we receive the error: "the target identifier "" in the request was not found in the tenant"* "*" is the FQDN domain of the VM needed for web access over rdp. How do we resolve this? It seems that the VM's FQDN is not being recognized over web session. No issue accessing with local user login with FQDN.

Answer 1

After weeks of troubleshooting, I found a solution for this issue. Below are my steps to resolve the issue.

1. Add an A-Record on my company domain registrar's DNS, such that the Azure VM's name is a sub-domain of our public-facing domain. In our case, the record name reads as "[VM's hostname].[my company's domain name]". The record value is the Azure VM's public IP (or load balancer's public IP if using an Azure LB).
2. (Optional, depends on if you use hybrid Azure AD like we do) Log into our on-prem/local DNS host and add a forward lookup zone for the new sub-domain added in step 1 and create an A-Record there that points to the Azure VM's public IP.
3. Log into the Azure VM using local admin credentials, then set the system-wide "Primary DNS Suffix" to equal the public-facing domain (I.E., "contoso.com") and reboot the server. Below are three different ways to make this change happen:
   1. Navigate to Advanced System Settings/System Properties > Computer Name tab > click the "Change" button to rename the computer > Click "More..." under the existing computer name > type in your public-facing domain and click OK > Save and reboot.
   2. On the Azure VM, open the Registry Editor and navigate to this path: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters > Adjust value for "NV Domain" to your public-facing domain > Save and reboot.
   3. On the Azure VM, open an elevated Powershell session and run this command (be sure to replace "contoso.com" with your public-facing domain: Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters -Name 'Domain' -Value 'contoso.com'

After completing the above steps, I am now able to RDP into the VM using the "Use a web account to sign in to the remote computer" option checked in mstsc.exe. For the Computer Name, I simply type the, "sub-domain.public domain name" hostname we created with DNS records earlier.

I'm shocked that none of this is included anywhere in Microsoft's documentation.

Answer 2

IP address or computer DNS name will not work.

The computer name in mstsc needs to exactly match the computer name in Azure AD.

There are 2 ways to workaround this:

• You add a DNS record to your corporate domain.
• You add an entry to your hosts file: c:\windows\system32\drivers\etc\hosts

azure.computer.ip.address azurecomputername

Answer 3

I was having this issue when connecting from remote network (home office) to a AzureAD joined Windows 11 Pro VM using a AzureAD joined Windows 11 Enterprise laptop (joined to a different Azure tenant). The VM is hosted in the public MS Azure cloud "North Europe (Zone 1)".

For me the solution required these steps:

1. Turn on the Azure RBAC as documented here if not already on. In my case this was off.
2. Configure the Azure role "Virtual Machine User Login" for the user. Note: as a security measure assign the minimum rights needed.
3. Add an entry ip-address hostname (with the same hostname as in the Azure VM Computer Name) in the HOSTS file which makes possible connecting with the hostname, not FQDN.
4. Turn on the Advanced -> Use web account option (equivalent to the enablerdsaadauth:i:1 property in the RDP file).
5. Add the targetisaadjoined:i:1 property in the RDP file.
6. Connect to the Remote Desktop using the username "AzureAD\user@domain" in the RDP client.
7. In the M365 login popup window choose "sign in with a different account" and enter the credentials "user@domain" (without "AzureAD" in the beginning).

Answer 4

Settings up a custom DNS record or manually editing you hosts file can not be the expected solution to this problem? Its not even documented in the documentation (https://learn.microsoft.com/en-us/azure/active-directory/devices/howto-vm-sign-in-azure-ad-windows).

I did however find a viable solution using Basition that seems to work. Bastion should anyhow be a more secure and reliable solutions.

1. Setup Bastion on the vnet using Standard tier and enable Native client support.
2. Setup a vm using the guide above and make sure its connected to the bastion vnet.
3. Connect using az network bastion rdp as follows:

az login
az account set --subscription <my subscription name>

az network bastion rdp --name "<bastion name>" --resource-group "<resource group>" --target-resource-id "/subscriptions/<subscription id>/resourceGroups/<resource group>/providers/Microsoft.Compute/virtualMachines/<vm name>" --enable-mfa

The last option: enable-mfa is important if you want the web based login window that enables MFA.

But I can not believe this is the only answer. I really think it should work out of the box somehow, even without Bastion or changing DNS record in external system.

Answer 5

We're having this issue going VM to VM inside the same vNet (AVD to another VM). What worked for me (in Azure Government) was:

1. Only connect via hostname, not FQDN, e.g. myvm, not myvm.internal.cloudapp.net
2. Turn off the Advanced -> Use web account option (this removes the enablerdsaadauth:i:1 property. This property is in preview. It doesn't appear to work in Azure Gov, I suspect because it gets a JWT that is for the commercial cloud, not Azure Gov. If someone can test this in commercial cloud, that would be good.
3. Edit the RDP file with a text editor and add the targetisaadjoined:i:1 property.
4. User credentials work with either user@domain.tld or AzureAD\user@domain.tld but I suggest using the 1st one since that's the only format that works with enablerdsaadauth.
5. Reference: https://learn.microsoft.com/en-us/azure/virtual-desktop/rdp-properties