Microsoft Entra Domain Services - Simply Explained

Hello everyone and welcome to another episode of Microsoft Knowledge Nuggets here on M365, FM. I'm Mirko Peters. Imagine you move an old business app from a server in your office to an Azure virtual machine. The app is now in the cloud, but it still asks for a Windows domain. It wants to join that domain, look up people through LDAPI, sign users in with Kerberos and apply group policy. Most people assume Entra ID replaces every active directory job. It doesn't. Modern cloud apps can sign you in through Entra ID, but older Windows apps still expect the same kind of domain they used back in the server room. By the end of this episode, you'll see where Entra ID, active directory and Entra domain services each fit, and there's one detail that changes how you manage all of it. Identity information only travels in one direction. Why Entra ID alone cannot run every legacy app? Let's start with what Entra ID does well. It's the reception desk for your cloud services. It knows who you are, checks your sign in and decides whether you can enter Microsoft 365 Teams SharePoint or a business app in the cloud. You sign in once, then move between services without typing your password again and again, that single sign on. Entra ID can also ask for a second sign in check through multi-factor authentication. Look at the device you're using where you're signing in from and the rules your company sets around access. For a modern app, that pattern works really well. You open a browser, the app sends you to Entra ID you sign in, perhaps approve a prompt on your phone, and then Entra ID sends the app a secure sign in message behind the scenes. The app reads that message and lets you in. With this pattern, there's no need for a domain join, no old Windows server involved, and no requirement for the app to search a classic company directory. But older apps grew up in a different world. Imagine a finance app that has run on a Windows server for years where user sign in from domain joined PCs. The app looks up employee details through LDAP, which is a common way for older software to search a company directory. It may use Kerberos, and older Windows sign in method that lets systems trust each other. It may rely on group policy, the set of company rules that can control settings on Windows servers. That app doesn't know how to read a modern cloud sign in message. It expects to call out across the network and find a traditional Windows domain, and if it can't find one, the app might fail to sign users in, fail to find a service account, or simply refuse to start. You've probably seen this pattern outside of IT as well. A new power outlet doesn't help when the plug on an old machine doesn't fit. The electricity is there, but the connection is wrong. Now picture the company moving that finance app and its database into Azure Virtual Machines. The service have moved, but the old need hasn't. You could leave active directory in the office and connect Azure back to it through a VPN, a private network tunnel, so the app in Azure sends requests across that connection whenever it needs the domain. That can work, but the app now depends on the network link and the on-premises domain controller staying available, and if that connection has a problem, the cloud app may have a problem too. Another choice is to create your own domain controller virtual machines in Azure. A domain controller is the server that runs the traditional active directory domain, handling the directory, sign-ins, and other domain jobs. It also works, but now your team owns more servers. Someone needs to patch them and monitor them. You need backups, recovery plans, a plan for keeping domain controllers in sync, and you also need to protect the powerful admin accounts that control the domain. For some companies that control make sense, for others, it's extra work just to keep an older app happy. So the gap is quite narrow, but it's real. An app lives in Azure, yet it still speaks the old active directory language. What Microsoft EnterDomain Services actually is, Microsoft EnterDomain Services is a managed Windows domain that runs inside your Azure network. That's the plain English definition. The domain controllers run behind the scenes fully managed by Microsoft while your Azure virtual machines and older apps use the familiar domain services they expect. Think of your cloud setup as an office building. Enter ID is the front reception desk. It checks who you are when you sign into Microsoft 365 or another cloud app, and it applies the company rules around that sign in. EnterDomain Services sits in a locked back office room. Older systems don't need to visit that reception desk the way a modern cloud app does. They need an old style directory nearby. One that understands their language and can answer their requests. That back office room is the managed domain. Here's the thing, you don't have to build the domain controllers yourself. You don't sign into them with remote desktop. You don't decide how many to run, patch windows on them, or manage the connection between them. Microsoft takes care of all that. Your job is to connect the right Azure virtual machines and apps to the managed domain. Once they're connected, they can use familiar active directory services. A Windows VM can join the domain. The older app can use LDIP to look up people, groups, and directory details. It can use Kerberos. The sign-in method older business apps often expect when one server needs to trust another. It can also use NTLM. Another older Windows sign-in method that some apps still need. The managed domain provides DNS too, which helps systems find the right server by name rather than by a string of numbers. And it supports group policy so you can apply certain window settings to computers and users in that managed domain. That list sounds technical, I know. Picture it as a translation desk instead. Your app asks in the old Windows language, who is this user? Can this server trust that server? Where is the database? What settings should this computer use? Entra domain services understands those questions and gives the type of answer the app expects, but it doesn't create a second main list of employees. The main identity record stays in Entra ID. Users and groups from Entra ID copy into the managed domain so the older app can see and use them in the form it understands. If your company also has on-premises active directory, identities may already reach Entra ID from there before they copy into domain services. Direction matters here. Identity details flow into Entra domain services. They don't flow back out. So if a user comes from Entra ID, you manage that user an Entra ID. If the user originally comes from your on-premises active directory, you manage the user there. You don't treat domain services as the place to edit the main employee record. That keeps the managed domain from becoming a second filing cabinet with different versions of the same person. Now, there's one part that catches a lot of people during setup passwords, modern cloud sign-in and older windows sign-in don't use passwords in exactly the same way behind the scenes. For Kerberus and NTLM to work, domain services needs a protected form of password data that supports those older methods. Microsoft never keeps your password as plain text. Instead, the service needs the right protected password information before a user can sign into a domain joined VM or an older app through the managed domain. For cloud-only users, that often means the user needs to change their password after domain services is enabled. That password change creates the protected form needed for the managed domain. Until that happens, the user may sign into Microsoft 365 perfectly well but still fail when trying to use the old style domain. It can feel audit first. The user already has an account, the password already works, yet the legacy app still can't use it. The missing piece is not the user account. It's the protected password form required by those older sign-in methods. Domain services also has a clear boundary around where it works. It runs inside an Azure Virtual Network, often called a VNet. For Azure VMs, need network access to that VNet and they need to use the managed domains DNS settings so they can find it. This isn't a public directory that every device on the internet can contact. It's a private domain service for workloads connected to the right Azure network. So when an app needs old Active Directory behavior in Azure, domain services gives it a managed place to find that behavior. That brings us to the next question, where does this sit beside EntraID and your existing Active Directory domain? The names sound similar but their jobs are very different. EntraID, Active Directory and domain services. Different jobs. The names are close, so it's easy to treat these as different versions of the same product. They aren't. Each one handles a different part of your company's identity picture and once you see the job each one does, the choice becomes much clearer. EntraID handles cloud identity. When you open Microsoft 365 Teams SharePoint or a modern business app, EntraID checks your sign-in and controls what you can access. It also supports multi-factor authentication and access rules, like asking for a stronger sign-in check when you work from an unknown device. It's built for cloud services. A modern app doesn't need to sit on the same network as EntraID because it uses web-based sign-in methods. You sign in through a browser or an app, EntraID confirms who you are and the app receives proof that you're allowed in. That's the normal pattern for new cloud apps. Active Directory domain services, often shortened to Active Directory, does a different job. This is the traditional Windows domain that many companies run in their own offices, data centers, or server rooms. The company owns the domain controllers, chooses how to set them up, and manages the whole domain from top to bottom. It can control Windows PCs, support local servers, and provide the older sign-in methods that long-running business apps expect. That level of control comes with responsibility. Your IT team runs the domain, looks after the servers, and decides how the directory should work for the company. EntraDomain Services sits between those two worlds. It gives Azure workloads and managed Windows domain when they need older Active Directory behavior, but Microsoft runs the domain controller side of it. You use the domain for Azure VMs and older apps without taking on the full job of running a traditional Active Directory domain yourself. Think of it as a filing cabinet system. EntraID holds the main employee record for cloud work. That's where the company keeps the working record used for Microsoft 365 and modern cloud sign-ins. Domain Services gives older Azure apps a compatible copy of the records they need. Those apps can open the familiar type of filing cabinet and find users, groups, and sign-in details in the old format they understand. You don't need to rebuild the app just because it moved into Azure. A cloud-only company can use this setup too. Imagine a company that has never run local domain controllers. Everyone signs into Microsoft 365 through EntraID and the business starts using Azure VMs for an older Windows app. That company doesn't need to build an on-premises Active Directory domain just for that app. Instead, it can use Entra domain services for the Azure VMs that need domain behavior, while the rest of the company keeps using EntraID for normal cloud work. A hybrid company has a different starting point. It may already run Active Directory in its office with users and groups that sync into EntraID. Those people can then appear in Entra domain services for workloads that run in Azure. The flow looks like this. The company's existing Active Directory sends identity details to EntraID and EntraID provides the compatible copy to domain services. That doesn't mean domain services replaces the original on-premises domain. The office may still need its own Active Directory domain for local PCs, local servers, factory systems, or applications that remain on site. Entraid domain services only handles the Azure part where managed old-style domain behavior fits the workload. It doesn't turn EntraID into full Active Directory either. EntraID remains a cloud identity service. Domain services adds a managed domain for certain older needs, but it doesn't give you every option and every level of control you'd have when you run Active Directory yourself. So picture three separate jobs. EntraID handles modern cloud signings. Active Directory handles the Windows domain your company runs itself. The domain services handles legacy Azure workloads that still need a Windows domain without asking you to run the domain controllers. With those jobs clear, you can ask a much better question. When does domain services fit the workload and when should you choose something else? When domain services fits and when it does not. Start with the app, not the product name. If an older app uses LDAP, that's an old language for checking user names and passwords, and you're moving it to Azure, domain services can be a great fit. The app keeps using what it already understands without forcing a full rewrite. It matters when the app still works, the business needs it and rewriting the sign-in code would cost too much time or money. Another common scenario, a group of Azure virtual machines need to act like normal domain computers. Staff might need to sign into Windows with their work account, servers might need a service account, an account and app users to connect to another system like a database. You might need group policy to apply company settings to those virtual machines. In those cases, domain services gives the Azure machines the domain behavior they expect. Remote desktop services fits here too. Imagine employees connecting to shared Windows desktop or apps in Azure. Those systems often depend on a Windows domain for user sign-in and computer management. Domain services provides that domain layer without your team building domain controller virtual machines from scratch. Older apps often have more than one part. There might be a web server at the front, an app server in the middle and a database at the back. The app server needs to prove its identity before the database accepts a connection. When that trust relies on Windows service accounts, domain services keeps those connections working after the move. Here's the thing. Your team gets the older domain behavior the workload needs while Microsoft handles the domain controller work that would otherwise sit on your server list. But don't pick domain services just because you're using Azure. A new cloud app should sign in directly through Entra ID. If it supports modern sign-in methods, it sends users to Entra ID, gets back proof of the sign-in and benefits from cloud access rules and multi-factor authentication. That's the cleaner path for new software. Entra ID and services helps an app that speaks the old language. It's not a reason to teach new apps that old language. There are also hard limits you need to check first. Some apps don't just read from Active Directory, they write back into it, for example. An app might want to create or change directory entries as part of its normal work. Domain services doesn't fit when the app requires LDIP right access. The same warning applies if an app needs to change the Active Directory schema, the set of fields that define what the directory can store. The older software asks you to add its own fields before it runs. A managed domain doesn't let you change that underlying design. You should also pause if your team needs full control over the domain itself. Maybe you need direct access to domain controllers. Maybe you need domain admin rights which give very broad control. Or maybe you need a complicated directory design that you want to build and run your own way. That points toward running Active Directory yourself, either on-premises or on virtual machines in Azure. Domain services deliberately gives you less control because Microsoft runs the core domain service. So ask one plain English question before you pick a path. Does this workload need old Active Directory language or can it speak modern-entra ID? If it can use modern-entra ID, start there. If it needs old domain behavior but doesn't need you to own every part of the domain, domain services may fit very well. And if the app needs to rewrite the directory, change its schema, or give your team total domain control, it needs a different home. Choosing a managed domain means accepting a trade-off. Microsoft takes care of the domain controllers and you give up some of the control that comes with running them yourself. The managed service trade-offs you need to know. That managed approach saves work, but it also changes what your IT team can control. Microsoft runs the domain controllers, keeps them in sync, applies patches and handles availability behind the scenes. You don't need to plan where each domain controller sits or recover one after a server failure. That's why many teams choose it. But you can't remote desktop into those domain controllers and you don't get domain admin or enterprise admin rights because those would give control over the parts Microsoft manages. Instead Microsoft provides a group called EntraDomain Services Administrators. Put the people who need to manage the domain into that group, then use a management virtual machine joined to the managed domain. From that machine, you can use familiar Active Directory tools to manage what Microsoft allows. For example, you can create your own organizational units or OUs. Think of them as folders for domain objects like computers or service accounts. You can manage DNS records. You can create and apply group policy for supported settings. You can also manage the computers that join the domain, which is often the main reason the service exists. These limits are on purpose. You can't add more domain controllers, change the Active Directory schema or treat the managed domain as a place where changes flow back into EntraID. So keep user and group management in the source directory. For a cloud-only company, that source is EntraID. For a hybrid company, it's the on-premises Active Directory that syncs into EntraID. This rule prevents a mistake we see often. Someone sees a user in the managed domain and changes them there assuming it will stick. But that change won't become the company record in EntraID or on-premises Active Directory. Keep the managed domain private inside Azure networking. It should support only the workloads that need it, not become a general company directory. Limit network access, protect the management machine and give admin access only to people who need it. You're choosing a service with guardrails. Those guardrails remove some work while stopping you from changing the parts that Microsoft owns. A simple Azure migration story. Imagine a finance company running an old app on servers inside their own office. That app relies on LDIP to find employees. It uses kerbos when people sign in. And its server authenticates with a service account to reach the finance database. The company wants to move both the app and its database into Azure Virtual Machines. One option is keeping the app connected to the office domain through a VPN. But then the Azure app depends on that network connection and the local domain controllers every single day. Another option is running new domain controller virtual machines in Azure. It keeps more traffic inside Azure, but adds Windows servers. The IT team has to patch, monitor, backup and recover. The team goes a different way. They're users and groups already sync into enter ID. They enable intradomain services, connect the Azure Virtual Network and configure the Azure Virtual Machines to use the managed domain. After that, they join the app servers to that domain. The finance app keeps using LDIP, Kerbos and its service account. The domain behavior it expects now sits right next to the app in Azure. Microsoft runs the domain controllers. The company runs the app. But this doesn't mean every new project should go through domain services. If the company builds a fresh expense app next year, that app should use enter ID directly for modern cloud signing. Domain services exist for that finance app. Its older design still depends on a Windows domain. Entra domain services gives Azure workloads a managed Windows domain when Entra ID alone can't meet their older sign in needs. Start by listing Azure apps that ask for LDIP, Kerbos, NTLM, Domain Join or Group Policy, then sort each one. This is the app for Entra ID. Keep it on your existing Active Directory domain or place it behind Enter Domain Services. But watch for one limit. If the app needs LDIP right access or schema changes, domain services won't work. For the wider identity picture, continue with the Entra ID Knowledge Nugget. That's where the cloud reception desk begins.