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

IWSIT admin 50 Reputation points

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.

Azure Virtual Machines
Azure Virtual Machines
An Azure service that is used to provision Windows and Linux virtual machines.
7,408 questions
Azure Virtual Desktop
Azure Virtual Desktop
A Microsoft desktop and app virtualization service that runs on Azure. Previously known as Windows Virtual Desktop.
1,419 questions
Remote Desktop
Remote Desktop
A Microsoft app that connects remotely to computers and to virtual apps and desktops.
4,340 questions
Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
20,182 questions
{count} votes

5 answers

Sort by: Most helpful
  1. Tyler Sherman 95 Reputation points

    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., "") 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 "" with your public-facing domain: Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters -Name 'Domain' -Value ''

    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.

    17 people found this answer helpful.

  2. eLeX 26 Reputation points

    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 azurecomputername

    5 people found this answer helpful.

  3. Olle Johansson 0 Reputation points

    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 (

    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.

  4. Kenneth Benjamin 0 Reputation points

    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
    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:
    0 comments No comments

  5. John Brander 0 Reputation points

    Hey, since had quite a bit of struggle with this one as well, I just wanted to clarify something I found in another post about the issue. The powershell command
    Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters -Name 'Domain' -Value ''
    seems not to work in my case. Setting the same value in the Windows UI did the trick, and now everything is fine with me. I was running Windows Server 2022 Azure Edition Hotpatch.