Hello @Mahajan Hemant
Since AzureAdJoined : YES, DeviceAuthStatus : SUCCESS, and AADLoginForWindows is provisioned successfully, I wouldn't try to manually create or repair a urn:p2p_cert service principal. That isn't normally something an AVD administrator provisions manually.
I would check the AVD authentication path first:
- Confirm the user has Virtual Machine User Login or Virtual Machine Administrator Login on the session host/resource group. Owner/Contributor alone doesn't provide VM sign-in rights.
- Confirm the user/group is assigned to the AVD Desktop Application Group.
- If SSO isn't configured and the client device isn't Entra joined/registered to the same tenant, add this custom RDP property to the host pool: targetisaadjoined:i:1
Microsoft documents this specifically for connections to Entra-joined AVD session hosts.
- Check Conditional Access policies affecting Azure Virtual Desktop and the Azure Windows VM Sign-In application. A policy requiring an unsupported authentication method can cause the generic “Sign in failed” message.
- Review Event Viewer → Applications and Services Logs → Microsoft → Windows → AAD → Operational immediately after reproducing the failure.
If you're using a current AVD deployment, I'd also recommend configuring Microsoft Entra SSO, which is Microsoft's recommended authentication method for Entra-joined session hosts.
If the issue remains after confirming RBAC, application-group assignment, SSO/RDP properties and Conditional Access, please share the AAD Operational event ID/error code generated during the failed connection. That should identify which part of the authentication flow is failing.
Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.