Event banner
Event details
Jason_Sandys
Microsoft
MicrosoftWhy? What challenge does this solve or address for you? What's the scenario?
OK well in a Hybrid world, for example (think smaller not necessarily massive org with money and power) On-Prem servers have to be local machines and not Entra Joined. Any apps (especially legacy) might use UNC paths to shares, for example. Entra Signed in users on Entra Joined Devices cannot auth to those shares, cannot rdp or use other services with their entra credentials. If they use Hello for auth cloud works great, on-prem and legacy do not work at all. Sure there is Hello for Business, but that is a lot of overhead to set up and manage correctly especially for SMBs or orgs with just a few critical legacy systems.
Some legacy stuff, might indeed be critical and only used by 1 dept or a few people, but not "big enough" or worth the cost of moving it to the cloud or retooling it even, but it IS important still. Those legacy systems like that hamper the ability to go cloud only.
Windows Server Azure Edition works great and users can login with credentials from entra, audit logs match, great for compliance, yet this does not extend down to hybrid, complicating compliance as well.
So, since those systems are in use (maybe dev, maybe qa, maybe internal use, etc) they have to be individually managed, their LAPS controlled differently, their Malware/endpoint protection managed separately, apps installed/updated also, managed separately. see what I mean? I tried to explain it in a way that would make sense, I hope it does.
- Jason_Sandys> Entra Signed in users on Entra Joined Devices cannot auth to those shares, cannot rdp or use other services with their entra credentials. This is technically true but is not complete or accurate. The limitation of authenticating to on-prem services is specific to Entra accounts and has nothing to do with the devices being Entra joined or not -- it's also not a restriction in Entra, it's limitation imposed by the on-prem resources themselves as that's all they know about by design. But the solution here is simple and what every org has done from the beginning: use hybrid accounts, i.e., those that are synced between on-prem AD and Entra using Entra Connect. With this in place, even on Entra joined devices, the user can acquire the proper Kerberos TGT from the on-prem domain thus allowing authentication and (more importantly) SSO to the on-prem resources. No additional configuration is required for this other than having standard hybrid user accounts as noted. More details at https://learn.microsoft.com/en-us/entra/identity/devices/device-sso-to-on-premises-resources. Thus, this is not a limiter for on-prem resources than perform standard Windows authentication to the on-prem domain.
- while you are correct, problems add to it when a hybrid org acquires a new org. Now you have domain and or forest trusts to add and manage, if the acquisition were hybrid or on-prem itself. Or, heaven forbid, the acquisition is cloud only but some of those users need access to the stuff that is hybrid. Certainly, moving those systems to a cloud only model is a way to solve it but a burden. Depending on how the sync is configured, it could be a challenge for the lone admin and thus a challenge for the end users. I still see no reason why, when there is already an OS version (the Azure edition) that allows for login to windows server via entra id, one cannot be allowed to have the same feature in an on-prem edition. Since it does exist, and can be done (It's a check box when spinning up a server in azure with the proper SKU) logic says there would be a way to implement that same behavior on-prem. I guess there is some kind of MS Magic happening but only in Azure to enable that? no need to answer I appreciate all you have done. I was more after being able to manage the servers as well as other devices in Intune (single pane of glass approach).