Forum Discussion
Cloud only Entra ID Domain Services and Seamless SSO from Entra ID Joined machines
Hello I am currently implementing Entra ID Domain Services with one customer (he has no on-premises active directory). We now face the issue that an Entra ID joined client is not able to access r...
Hi, Hauke.
Both the "server" and the client need to be joined to the domain contained within Domain Services. It can't just be one or the other, or - as you've found - Kerberos will not work.
From a session perspective, both ends behave as though they are "traditional" domain-joined machines, so if one is not (and simply belonging to Entra ID is not enough) then Kerberos is not going to work.
Cheers,
Lain
Hello Lain,
if I read the documentation correctly, this only applies to Entra ID Domain Services. If a local AD is used via Entra Connect or Cloud Sync, then an Entra ID Joined device can directly access the corresponding shares/resources. Of course, only if there is a “direct” line of sight.
Is this correct?
Thanks
Johannes
if I read the documentation correctly, this only applies to Entra ID Domain Services. If a local AD is used via Entra Connect or Cloud Sync, then an Entra ID Joined device can directly access the corresponding shares/resources. Of course, only if there is a “direct” line of sight.
Is this correct?
Thanks
Johannes
Hi, Johannes.
Not universally, correct, no.
It sounds like the original poster is providing services that are running on virtual machines that are domain-joined to the Entra ID Directory Services domain, which means they are "traditional" services (as distinct from modern).
Traditional services will be expecting Active Directory authentication using Active Directory security principals, which you cannot get from a resource outside of the domain itself. This is particularly true for computer authentication (which is common in both Kerberos and NTLMv2 scenarios).
However, there are some replacement technologies that can indeed span Entra ID DS and Entra ID. One example can be found in Azure Files, which may be a suitable alternative to a traditional Windows Server-based file server:
But when you're dealing with "legacy" (I'm not a fan of the sales-driven marketing behind "legacy" vs. "modern" terminology) applications and services that you might be trying to lift-and-shift using an IaaS approach, not everything has a direct or even suitable replacement, bringing you back to requiring in-domain authentication between the client and server.
Cheers,
Lain
- +1 - you cannot leveage Cloud Kerberos Trust functionality in a setup where servers are joined to Entra Domain Services, and clients are joined to Entra ID.
Customer will need to look at optimizing authentication from clients to server, to support Oauth 2.0 (often a large development task by vendor of the application)In fact, the Cloud Kerberos Trust should be coming pre-configured on the Entra ID Domain Services, or it should be possible to enable it. The Entra ID Domain Services are quite useless like this.
It is totally possible with an old on-Premises Active Directory, and it is a very common scenario these days.
