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 ressources on machines that are joined to Entra ID Domain Services without entering his username and password.
The authentication fails with incorrect username and password (event id 200) message and the Security-Kerberos eventlog reports that it was not able to contact a domain controller for the AzureAd Domain (so he is not using the Domain name of the target domain).
However has someone already tried this and is there something I am overlooking or is that something that simply can not work.
Thank you very much in advance for any ideas.
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
JohannesHi, 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
