Entra Domain Services: the last step in retiring on-prem AD

Workstations have moved to Entra ID and Intune, email and files are in the cloud. And yet two old domain controllers are still running in the data centre, because “there is still that one system”. For that one system the organisation maintains servers, backups, patching and often VPN connections too.

I run into this constantly, and few people know there is a tool for exactly this gap, one that handles the last dependencies without any domain controllers of your own. It is Entra Domain Services, and in my view it is one of Microsoft’s least known services relative to how much it can simplify an environment.

What Entra Domain Services is and what it is not

Entra Domain Services (Entra DS, formerly Azure AD Domain Services) is an Azure service that provides traditional Active Directory Domain Services features from the cloud: Windows domain join, sign-in with AD credentials, an LDAP directory, Kerberos and NTLM authentication and Group Policy. In practice Microsoft deploys and maintains two domain controllers in the Azure region you choose. You never see them as servers and never sign in to them; you simply use the domain.

The most important thing to understand from the start: Entra DS is a separate domain of its own, not an extension of your existing on-prem AD. Users, groups and password hashes synchronise into it one way from Entra ID. If the environment has on-prem AD, the chain is AD DS → Entra ID → Entra DS. Nothing is written back.

Being separate also means limitations that are worth knowing before you plan anything:

• You do not get Domain Admin or Enterprise Admin rights. Management happens through the restricted AAD DC Administrators group and a separate management server or workstation with the RSAT tools installed.
• The AD schema cannot be extended. If an application requires schema changes, this is not the tool.
• Objects synchronised from Entra ID cannot be modified on the Entra DS side. LDAP write works only for objects created in the domain itself.
• Trusts are limited: forest trusts only, no external trusts, and only on the Enterprise or Premium tier.
• AD Certificate Services cannot be deployed in the domain at all, because an Enterprise CA requires Enterprise Admin rights and changes to the directory. The same applies to other AD add-on roles that need similar rights.
• Certificate and smart card authentication do not work. The user must have a password whose hash synchronises.

If these limitations are not a problem, the service is truly hands-off. Microsoft handles patching, replication, backups and high availability.

Four situations where Entra DS solved the problem

These are from environments I have worked in. The details are generalised.

Server access in a pure cloud environment. The organisation had no on-prem AD at all, but a growing number of servers in Azure for developers. Access and account lifecycle were managed server by server with local accounts, which does not scale. Entra DS was deployed, the servers were joined to the new domain and access, such as RDP, was granted through groups. When a developer leaves, the account is removed from Entra ID and with it from every server.

The last AD-dependent servers and the AD shutdown. This is the most common case. Workstations were already purely Entra joined and managed with Intune, and AD was to be shut down. A handful of servers still depended on the domain and could not be retired yet. The solution: deploy Entra DS, synchronise passwords from on-prem through Entra ID, set up a VPN between Azure and the data centre, move the servers to the new domain one at a time and test. When the last server had been moved, the old AD was shut down. This is exactly the situation where Entra DS is a replacement: not for the whole of AD from day one, but for its final phase.

A new application required LDAPS. A pure cloud environment that decided to adopt software which authenticates users only over LDAP. Without Entra DS the options would have been building a domain controller in Azure or changing the application. Entra DS was deployed, LDAPS was enabled with a certificate and the application’s public IP was allowed through. The deployment took an afternoon.

A large legacy system, but only a few users. A broad environment with a lot of history and a large on-prem AD infrastructure, with a security modernisation under way at the same time. One expensive old system required LDAP, but only a handful of people used it. It could have been connected directly to on-prem AD, but that would have meant opening network paths to the domain controllers and making changes in the AD environment. Instead, Entra DS was deployed, only a small scoped group of accounts was synchronised into it and LDAP was upgraded to LDAPS at the same time. The result: a narrow, isolated AD only for those who really need it, no changes to the old environment, and a service that practically runs itself.

The common denominator in all of them: a concrete, named dependency that could not be removed right away. Not “we might need it someday”.

When not to use Entra DS

The three mistakes I see most often:

Buying it just in case. If you cannot name the application or server that needs Kerberos, NTLM, LDAP or domain join, you do not need Entra DS. It costs money every month whether it is used or not. Entra ID and Intune handle a modern workstation environment without a domain.

Assuming it is an extension of the current AD. It is not. It is a separate domain, and the old AD’s Group Policy objects, OU structure and schema extensions do not carry over. If the expectation is “the same AD, but in the cloud”, the right option is a domain controller in an Azure virtual machine, along with all the maintenance you wanted to get rid of.

Using it as an excuse not to modernise, or the reverse. One legacy application easily becomes the reason to keep the whole of AD alive. The right use of Entra DS is precisely that an old LDAP or Kerberos application no longer blocks modernising the rest of the infrastructure. The application can stay, AD cannot. If the application can later be replaced with a SAML or OIDC integration, that is worth doing too, but it is not a precondition for getting started.

What to know before deployment

The deployment itself is wizard-driven and takes under an hour, but a few decisions have to be made right the first time, because they cannot be corrected afterwards. The exact limitations and SKU tiers are in Microsoft’s documentation.

• The domain name cannot be changed. Choose a name you own and that is routable on the internet (for example ads.company.com). That does not make the service public, but it avoids name conflicts later.
• A virtual network of its own in Azure. Entra DS lives in a vNet, and the network cannot be changed afterwards any more than the domain name can. If on-prem servers need to join the domain, you need a VPN or ExpressRoute. Remember DNS too: machines joining the domain must be able to find the Entra DS domain controllers.
• Password hashes and the initial synchronisation. Kerberos and NTLM need password hashes that Entra ID does not store by default in the format Entra DS requires. If users synchronise from on-prem AD, Password Hash Synchronization must be enabled and a full synchronisation is forced with a PowerShell script. Cloud-only users appear in Entra DS only after they have changed their password once so that the hashes are generated. This surprises almost everyone, so plan the message to users in advance. The initial synchronisation can take hours, so start testing only once the Domain Services Health view shows synchronisation as complete. After that, in my experience, changes have shown up without any noticeable delay.
• SKU tier. Standard, Enterprise and Premium differ in recommended object count, authentication volume, backup frequency and number of trusts. The tier can be changed later. For a small or mid-sized environment Standard is enough, unless you need a forest trust to on-prem AD during the transition.
• LDAPS. If the application uses LDAPS, you need a certificate. If the connection comes from the internet, a public IP is opened for Entra DS and access is restricted to source addresses.
• Price. Billing is hourly per replica set, and the exact prices are on the Azure pricing page. On the Standard tier the order of magnitude is a bit over a hundred euros per month. That is cheap compared with maintaining two domain controllers, but not free, so do not leave it running unused.

Checklist

• Name the dependencies. List the applications and servers that really need Kerberos, NTLM, LDAP or domain join. If the list is empty, you do not need Entra DS.
• Check whether the dependency can be replaced. SAML or OIDC is better than LDAP if the application supports it. If it does not, that is no reason to postpone other modernisation.
• Choose the domain name carefully. It cannot be changed.
• Plan the password change and the communication. Cloud-only users have to change their password once; synchronised users need PHS enabled.
• Scope the synchronised users. If only a handful need the service, synchronise only them. Smaller attack surface, clearer environment.
• Set a target for switching the service off. Write down which application is the reason Entra DS exists. When it has been replaced, switch off Entra DS too.

Entra DS is not a destination but a means. It makes possible a transition in which on-prem AD is retired in a controlled way while the journey towards a fully cloud-based environment continues. Once you know that a tool like this exists, there is one obstacle less on the road to simpler IT.