Event details
Hello, thanks for this and answering our questions!
I’m the primary Intune administrator for a healthcare non‑profit operating on a GCC tenant. We are currently transitioning our devices from AD/Entra hybrid‑joined to Entra‑joined. We are a remote‑first organization with very few users working onsite.
Today, our prior hybrid‑joined devices (connected to a domain through VPN) authenticate using RSA and our more recent Entra-joined devices use the Windows Hello for Business passwordless experience with Intune, as we are working toward moving to adopting the Cloud Kerberos Trust model.
Our challenge is administrative access and account management during this transition. Specifically:
• We still need to manage hybrid‑joined accounts via AD DS.
• We need to audit administrative escalations on devices, typically for single installations of software vs. full-blown Intune deployment or running Command Prompt/PowerShell as admin.
Because the Windows Hello for Business passwordless experience is enabled on our Entra‑joined devices, our IT users cannot sign in with a domain admin account to administrate anything. As an example, this prevents us from running say, Active Directory Users & Computers with elevated privileges as AD DS can't be used without logging in as an account with domain admin rights, which seems to make AD DS administration from Entra-joined devices impossible at this time.
Is there a supported way to enable these administrative tools locally or administrator credentials for other than just the local admin, while still using Windows Hello for Business passwordless authentication? At the moment, our current workaround for AD DS is to log into an on‑premises VM for AD DS management and we've just been using the local admin password for standard escalations for now, which is not ideal.
Thank you for the guidance!
- Jason_Sandys
Microsoft
Hi TLyon-TMF,
Using the SSO functionality built into Windows, as long as the user account is a hybrid account, then authentication to the on-prem domain will just work seamlessly as it uses the on-prem identity of the hybrid account. This is detailed at How SSO to on-premises resources works on Microsoft Entra joined devices - Microsoft Entra ID | Microsoft Learn and Debunking the myth: Cloud-native Windows devices and access to on-premises resources | Microsoft Community Hub.
Of course, you really shouldn't be logging in to a device with an account that has domain admin permissions. Thus, the better path here is to use runas with the /netonly switch and specify the on-prem account with appropriate permissions to launch dsa.msc or whatever tools you need. It's been a while since I tried this, but it does work (from memory).
Using the jump box here is a great choice as well for a variety of reasons and has been used by orgs since well before cloud-native Windows existed.
Not sure what your last sentence about "standard escalations" means. Can you elaborate on this please? Using LAPS in many cases is actually preferred assuming you are using Windows LAPS (and not the classic LAPS) as this restricts access to a single, well-audited account that is easy to shut off if compromised and cannot be used for lateral movement.
Hi Jason,
I'll have to give this a try, will see if that works.
As for escalations, our Help Desk users normally use admin accounts to escalate for installations, command prompt, PowerShell, etc. so we normally track that via use of those accounts. LAPS seems to make this a bit more difficult to track.
runas /netonly worked!
runas /netonly /user:admincred "mmc %systemroot%\system32\dsa.msc"was the proper command.😀
- Joe_Lurie
TLyon-TMF The RSAT tools should work on Entra-joined devices as long as your user account exists in AD DS. It's the user identity that would determine if the tool can run and be logged into, not the device identity. And you can use Intune's Local Users and Groups policy to manage group membership in the local Admin group on the Intune-managed devices.
Hi Joe,
I'm not sure if I understand you fully or maybe I miscommunicated something, but if I am, that's the core issue actually. The way we are set up is that we run user accounts and then escalate to administrative accounts say for domain admin privileges. A good example would be logged in as "Joe" as the user account and using "Admin.Joe" as the domain admin account to access AD DS. The Windows Hello for Business passwordless experience blocks us off to just the local admin account for escalations.
