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.