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 65

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.

Tyler Sherman 130 Reputation points

2023-04-25T01:58:06.8133333+00:00

I am having this exact same issue with my VMSS VMs. I have the System-Assigned Managed Identity enabled and the microsoft.AADLogin-Windows Extension is installed successfully. My VM appears in my Azure AD Tenant under Devices. "dsregcmd /status" shows AzureAdJoined: Yes All my Azure networking rules and local VM firewalls are configured to allow Azure AD traffic both in and out. RBAC roles for Virtual Machine Login Administrator are assigned to my user account Nothing seems to work no matter what I do. In my case, my VMSS is sitting behind a Load Balancer, but the networking part is clearly working fine, since I'm able to RDP in with the local admin creds just fine. One thing I did find interesting is that when I run a curl request to grab my access token with the following CURL command: curl -H Metadata:true "http://169.254.169.254/metadata/identity/oauth2/token?resource=urn:ms-drs:enterpriseregistration.windows.net&api-version=2018-02-01" , then decode it with [http://calebb.net/], I can see the OID actually matches an "Enterprise Application" in my Azure Tenant, rather than the Object Identifier of the VM in Azure AD. If I had to wager a guess, there's an issue on Microsoft's back end that's causing the modern auth process to check against the wrong OID.
Limitless Technology 44,681 Reputation points

2023-04-26T11:44:44.6366667+00:00

Hello there, To enable Azure AD authentication for your Windows VMs in Azure, you need to ensure your VMs network configuration permits outbound access to the following endpoints over TCP port 443: If you are creating a new VM in Azure and you want to log in using Azure AD credentials, you must enable the Login with Azure AD option. There are two ways to enable Azure AD login for a VM in Azure: You can enable in Azure Portal while creating a VM. You can also use the Azure Cloud Shell experience when creating a Windows VM or on an existing Windows VM. Hope this resolves your Query !! --If the reply is helpful, please Upvote and Accept it as an answer--
Tyler Sherman 130 Reputation points

2023-04-26T15:17:33.9233333+00:00

That is not helpful. We've followed Microsoft's official documentation precisely (See document here: https://learn.microsoft.com/en-us/azure/active-directory/devices/howto-vm-sign-in-azure-ad-windows). Everything you mentioned is already detailed in this article. Furthermore, I have Network Security Group Outbound rules for TCP 443 Any/Any configured as well as matching rules on the VM's Windows Firewall. The VM appears in my Azure AD Tenant under Devices. The "AADLoginForWindows" extension is installed and shows Status: Provisioning succeeded. Our issue with target identifier errors persists.
Cicero Junior 0 Reputation points

2023-04-28T01:15:25.6533333+00:00

Me too, same issue; followed the documentation and I'm receiving the same error.
Gunnar 0 Reputation points

2023-05-02T22:18:40.39+00:00

I am also running in this same issue. Currently working with a VM that has no public IP using a auto detected FQDN with a private DNS zone and private DNS resolver and tunned into with an Azure P2S VPN. The VPN I can authenticate to without issue but attempting to use my same login with the VM results in the same error OP is getting.
IWSIT admin 65 Reputation points

2023-05-05T00:40:03.8566667+00:00

This resolved the issue. Thanks!
vipullag-MSFT 26,471 Reputation points

2023-05-05T03:19:25.7466667+00:00

Hello IWSIT admin

Thanks for confirming that the solution provided by elexpander help solve your issue.

Please 'Accept as answer', so that it can help others in the community looking for help on similar topics.
vipullag-MSFT 26,471 Reputation points

2023-05-10T05:10:04.2066667+00:00

Hello IWSIT admin

We noticed your feedback that the above answer was not helpful.

Thank you for taking time to share feedback.
As you have mentioned in your recent comment "This resolved the issue." request you to take a resurvey.

Looking forward to your reply. Much appreciate your feedback!
Mika Mattila 0 Reputation points

2023-05-31T06:08:36.7+00:00

I wonder if anyone got this working with just private IP addresses for the VMs? I've only got it working by adding the VM's IP to etc/hosts, which is really not a very convenient way.
Piotr Karpala 0 Reputation points Microsoft Employee

2024-04-21T02:50:01.9833333+00:00

I followed all the posts in this thread an renamed my VM by adding the domain part.

The error for "not finding in domain" went away, but I'm getting this weird thing - CAA2003 OAuth2 Authorization code was already redeemed.

IMHO - this looks like a bug in mstsc.
I reinstalled it with the latest version but that didn't help
Chris Peyton 21 Reputation points

2024-05-27T04:48:16.5666667+00:00

Hi, I found an answer to my problem with this. Same Error - CAA20002 / AADSTS293004.

The server name you are logging into needs to be the same in its DNS suffix. For example, you're logging into server01.location.cloudapps.azure.com in the RDC, but the server name is set to server01 only.

In my case, the server was not on a domain, and I had to add the DNS suffix to the server name by going to Advanced system properties, Computer Name, Change, More, and add the primary DNS suffix there.

One restart later, and I'm on.

I hope this helps you.
Iain McEwen 5 Reputation points

2024-08-12T16:31:12.2233333+00:00
@Chris Peyton add DNS suffix solved it for me - makes sense and is simplest answer around !
François Dufour 0 Reputation points

2024-10-17T17:26:31.6333333+00:00

For all of those still encountering this issue, i had the same problem using Bastion. I had to rename the HOSTNAME of the machine the same as the VM name in azure for it to work. It seems azure to trying to log you in the machine using the VM name and can't find it.

7 answers

John Brander 0 Reputation points

2024-04-08T11:31:52.2966667+00:00

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 'contoso.com'
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.
Please sign in to rate this answer.
Chad Gross 0 Reputation points

2024-06-14T04:56:13.3866667+00:00

Where did you set the domain in the UI? I'm also working with a Server 2022 Azure Edition VM, the registry keys are not working for me.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Andrew McNaughton 0 Reputation points

2025-03-30T18:04:48.08+00:00

This post comes up a lot when people encounter this error in scenarios involving Entra joined RDP Session Hosts.

If you have enabled/permitted access to the host via an Entra group, and not as individual user accounts**, you need to disable NLA (Network Level Authentication) on the host to avoid this error.**

NLA is a legacy approach that doesn't make as much sense on an Entra joined device. The credentials are protected by HTTPS/TLS when authentication takes place. Just like using a browser. So, there will be no interception. These devices won't ever accept on-premises AD credentials for RDP. Only local accounts could be vulnerable and they should be disallowed for RDP.

It's possible all this faffing about with DNS suffixes is playing a role in supporting NLA in believing the two ends of the connection are on the same trusted network. NLA doesn't seem aligned with Zero Trust principles.

You may also need to make sure that PKU2U isn't blocked by policy. This should only be blocked in on-premises-only environments. Hybrid and Entra joined systems should not have this blocked.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

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

7 answers

Your answer