Entra-joined AVD/hybrid user cannot use RunAs as secondary hybrid user

Question

Entra-joined AVD/hybrid user cannot use RunAs as secondary hybrid user

SteveAitch-7485 20

Hello everyone,

A normal AVD personal 1:1 desktop user needs to use the native Windows 11 RunAs to run SQL Management Studio as another "SQL admin" user. This functionality is required in order to use the built in Windows Authentication method to run SSMS as the user account who launched the SSMS process.

Both user accounts are hybrid with on-prem AD synched to Entra and the AVD is Entra-joined and confirmed AD aware.

Suffice to say the symptom is the same no matter the username syntax -> the username or password is incorrect

domain.local\sqladmin

[email protected]

******@company.com

AzureAD******@company.com

I have reviewed the AVD Security Logs and can see an ID#4625 failed Secondary logon attempt. The Domain Controller also records a successful Kerberos TGT request ID#4768 at the same time. This suggests the Kerberos token is issued but the AVD can't use it for some reason, perhaps because the AVD needs a domain computer account to utilise it. I'm not sure.

Fundamentally I'm looking to get this functionality working in order to successfully complete a AVD POC and migrate away from on-premise Citrix XenDesktop. Any ideas?

Many thanks!

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hi @SteveAitch-7485

I don't think the successful 4768 on the domain controller proves that the Entra-joined AVD VM needs an AD computer account for this scenario. Microsoft Entra-joined devices can authenticate synchronized hybrid users to on-premises AD resources using Kerberos/NTLM even though the device itself isn't domain-joined.

Check these two things before changing the AVD join model.

First, check the username format. Microsoft specifically documents that applications authenticating users from an Entra-joined Windows device should use either the implicit UPN or the NT4 syntax with the AD DNS/FQDN domain, for example:

[email protected]

domain.local\sqladmin

A legacy NetBIOS form such as DOMAIN\sqladmin can fail on an Entra-joined device even when the account and password are correct.

From your examples, it looks like you've already tested the FQDN forms, so the next useful test is to separate secondary interactive logon from network authentication to SQL Server.

Try:

runas /user:[email protected] cmd.exe

and note whether Windows successfully creates the secondary process.

Then compare that with:

runas /netonly /user:domain.local\sqladmin "C:\Path\To\Ssms.exe"

/netonly is particularly relevant to your use case because the objective is for SSMS to access a remote SQL Server using the alternate AD credentials rather than necessarily creating a full local Windows logon for that AD identity.

Also, run the following from the normal hybrid user's AVD session:

dsregcmd /status
klist

In dsregcmd /status, confirm:

AzureAdJoined : YES

DomainJoined : NO

and inspect the SSO State, particularly whether OnPremTgt is available. OnPremTgt: YES, indicating that a Cloud Kerberos ticket for accessing on-premises resources is present for the signed-in user.

Also confirm that the session host has line of sight to the AD domain controllers, including DNS/DC discovery. Entra-joined AVD session hosts need connectivity to AD DS to access on-premises resources.

One other configuration point to check: if you're using Microsoft Entra SSO with Entra-joined AVD session hosts and still need access to on-premises resources, create a Kerberos server object for this scenario.

Therefore, avoid converting the AVD host to hybrid/domain join solely because RunAs currently fails. Entra-joined AVD with hybrid identities and access to on-premises resources is a supported architecture.

If runas /user: still produces 4625 while the DC simultaneously records a successful 4768, could you post the 4625 Status, SubStatus, and Logon Type, plus the account/domain fields from that event? Those values should tell us much more precisely whether Windows is rejecting the secondary local logon after the domain credentials have already been validated.

References:

SSO to on-premises resources from Microsoft Entra-joined devices

Microsoft Entra-joined AVD session hosts

Configure SSO for Azure Virtual Desktop

Troubleshoot device state with dsregcmd

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.

SteveAitch-7485 20 Reputation points

2026-09-25T10:36:28.5433333+00:00

Hi Allan Solomon Mejia,

Many thanks for your thorough reply, it was very useful to run through everything that should be in place in order for this functionality to work on the AVD platform. And to have it confirmed it would be fully supported.

Suffice to say we had already covered every aspect of what you suggested.

But the key missing piece of the puzzle which isn't explicitly declared by MS docs but (as is often the case) "implied", is that the secondary hybrid user account MUST also be a member of the Virtual Machine User Logon RBAC role for the AVD virtual machine object it is running on.

Otherwise it seems to me the on-prem kerberos token is not validated for use by the Entra authentication process and simply drops it.

To be clear on the distinction though, the secondary user needs Virtual Machine User Logon RBAC role for the AVD virtual machine object it is running on, not AVD Host Pool/Application Group rights.

Thanks again for your help.

Steve