Aug. 14, 2026
Microsoft Entra Domain Services - Simply Explained
Key Takeaways
- Microsoft Entra Domain Services provides a managed Windows domain inside an Azure virtual network, allowing legacy applications to consume traditional Active Directory capabilities without requiring you to operate your own domain controllers.
- Entra ID handles modern cloud authentication extremely well, but legacy applications often still expect traditional directory services like LDAP, Kerberos, NTLM, domain join, DNS, and Group Policy.
- Identity information flows in a one-way synchronization model from Entra ID into Entra Domain Services, meaning users and groups must continue to be managed in their authoritative source rather than directly in the managed domain.
- For Kerberos and NTLM authentication to succeed, user accounts in Entra Domain Services require protected password information, which for cloud-only users often involves performing a password change after the managed domain is enabled.
- Entra Domain Services is not suitable for applications requiring LDAP write access, Active Directory schema modifications, or direct access and Domain Admin privileges on the domain controllers.
Microsoft Entra ID is built for modern cloud identity—but what happens when an older application moves to Azure and still expects a traditional Windows domain?In this episode of Microsoft Knowledge Nuggets, Mirko Peters explains Microsoft Entra Domain Services and the specific problem it solves. We look at why moving a legacy application into Azure doesn't automatically remove its dependency on LDAP, Kerberos, NTLM, domain join, DNS, and Group Policy—and how Microsoft provides these capabilities without requiring you to operate your own domain controllers.
THE CLOUD APP THAT STILL THINKS IT LIVES IN THE SERVER ROOM
Moving an application to an Azure virtual machine doesn't necessarily make it cloud-native. Many established Windows applications were designed around Active Directory and still expect to find a traditional domain.They may require LDAP directory lookups, Kerberos authentication, Group Policy, service accounts, or domain-joined Windows servers. Entra ID handles modern cloud authentication extremely well, but it doesn't simply replace every capability of traditional Active Directory.
WHY ENTRA ID ALONE ISN'T ALWAYS ENOUGH
Entra ID is designed around modern cloud identity. It provides authentication for Microsoft 365, Teams, SharePoint, and modern applications while supporting capabilities such as single sign-on, multi-factor authentication, device-aware access, and access policies.Legacy applications often operate differently. Instead of consuming modern cloud authentication, they expect to communicate directly with a Windows domain using technologies such as LDAP and Kerberos.Organizations can keep their existing Active Directory environment connected to Azure or deploy their own domain controller VMs in Azure—but both approaches introduce infrastructure and operational responsibilities.
WHAT MICROSOFT ENTRA DOMAIN SERVICES ACTUALLY IS
Microsoft Entra Domain Services provides a managed Windows domain inside an Azure virtual network.Microsoft operates the underlying domain controllers while Azure workloads can consume traditional Active Directory capabilities. Windows VMs can join the domain, legacy applications can perform LDAP queries, and workloads can use Kerberos and NTLM authentication. DNS and supported Group Policy capabilities are also available.The key distinction is that organizations consume the domain services without managing the domain controller infrastructure themselves.
ENTRA ID, ACTIVE DIRECTORY, AND DOMAIN SERVICES
These technologies solve different identity problems.Microsoft Entra ID provides modern cloud identity and authentication.Active Directory Domain Services provides the traditional Windows domain organizations operate themselves.Microsoft Entra Domain Services provides managed traditional domain capabilities for workloads—particularly legacy workloads—running in Azure.Understanding those different roles is critical when designing an Azure identity architecture.
THE ONE-WAY IDENTITY MODEL
One of the most important architectural concepts is synchronization direction.Users and groups from Entra ID are made available inside Entra Domain Services so legacy applications can consume them. In hybrid environments, those identities may originally come from an on-premises Active Directory environment before reaching Entra ID.But identity changes don't flow back from Entra Domain Services into Entra ID.Users should therefore continue to be managed in their authoritative identity source rather than treating the managed domain as a second primary directory.
THE PASSWORD DETAIL THAT CAN SURPRISE YOU
Legacy authentication protocols require password information in forms that differ from modern cloud authentication.For Kerberos and NTLM authentication to work, Entra Domain Services needs the appropriate protected password information. For cloud-only users, this can mean changing their password after Domain Services has been enabled before they can authenticate successfully against the managed domain.A user can therefore successfully access Microsoft 365 while initially being unable to authenticate against a legacy application using the managed domain.
WHEN ENTRA DOMAIN SERVICES MAKES SENSE
Domain Services can be particularly useful when migrating applications to Azure that still depend on traditional Windows domain capabilities.Typical examples include applications requiring:
- LDAP
- Kerberos
- NTLM
- Windows domain join
- Group Policy
- Service accounts
- Domain authentication for Azure VMs
- Remote Desktop Services environments
WHEN YOU SHOULD NOT USE IT
Entra Domain Services isn't a replacement for every Active Directory deployment.It isn't appropriate when an application requires LDAP write access, Active Directory schema modifications, direct access to domain controllers, Domain Admin privileges, or a highly customized directory architecture.Those requirements can point toward operating Active Directory yourself rather than using the managed service.
THE MANAGED-SERVICE TRADE-OFF
The advantage of Entra Domain Services is reduced infrastructure management.Microsoft operates, patches, synchronizes, and maintains the underlying domain controllers. Organizations don't need to determine where those controllers run or manage their recovery.The trade-off is reduced administrative control.Administrators can't RDP directly into the domain controllers and don't receive Domain Admin or Enterprise Admin privileges. Instead, delegated administration is performed through the Entra Domain Services Administrators group and management systems joined to the domain.You can still perform tasks such as managing supported Group Policy settings, DNS records, organizational units, and domain-joined computers.
A PRACTICAL AZURE MIGRATION EXAMPLE
Imagine a finance application running on-premises that uses LDAP to find employees, Kerberos for authentication, and a Windows service account to communicate with its database.The organization wants to move the application and database into Azure.Keeping the application connected to the on-premises domain introduces dependency on the VPN and local domain controllers. Deploying new domain controllers in Azure creates additional servers that must be patched, monitored, backed up, and recovered.With Entra Domain Services, the organization can instead provide the Azure application with the traditional domain capabilities it requires while Microsoft operates the underlying domain controllers.The legacy application continues working without turning domain controller management into another Azure infrastructure responsibility.
PUT ENTRA DOMAIN SERVICES ON YOUR IDENTITY MAP
The simplest way to decide whether Entra Domain Services belongs in your architecture is to examine the applications themselves.Identify workloads requiring LDAP, Kerberos, NTLM, domain join, or Group Policy.Then determine whether each workload should:Modernize and authenticate directly through Entra ID.Remain connected to an existing Active Directory domain.Use Microsoft Entra Domain Services as a managed compatibility layer.If an application requires LDAP write access or Active Directory schema modifications, Entra Domain Services isn't the right solution.Microsoft Entra Domain Services isn't about bringing traditional Active Directory architecture to every cloud workload. It's about giving legacy Azure workloads the Windows domain services they still require—without forcing your team to operate the domain controllers themselves.
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-fm-modern-work-security-and-productivity-with-microsoft-365--6704921/support.
🚀 Want to be part of m365.fm?
Then stop just listening… and start showing up.
👉 Connect with me on LinkedIn and let’s make something happen:
- 🎙️ Be a podcast guest and share your story
- 🎧 Host your own episode (yes, seriously)
- 💡 Pitch topics the community actually wants to hear
- 🌍 Build your personal brand in the Microsoft 365 space
This isn’t just a podcast — it’s a platform for people who take action.
🔥 Most people wait. The best ones don’t.
👉 Connect with me on LinkedIn and send me a message:
"I want in"
Let’s build something awesome 👊
Frequently Asked Questions
What is Microsoft Entra Domain Services?
Microsoft Entra Domain Services is a fully managed cloud service that provides traditional Windows domain capabilities—such as domain join, LDAP, Kerberos, and NTLM authentication—inside an Azure virtual network without requiring you to deploy or manage your own domain controller virtual machines.
Why can't Entra ID alone run legacy Active Directory applications?
Entra ID is built for modern cloud identity using web-based protocols and does not support legacy protocols like LDAP, Kerberos, NTLM, or Group Policy that older Windows applications and virtual machines explicitly expect.
How do user passwords work with Entra Domain Services?
Legacy authentication protocols require a specific protected password hash format. Cloud-only users often need to change their passwords after Entra Domain Services is enabled to generate this hash so they can successfully authenticate against legacy applications.
Can I get Domain Admin rights in Entra Domain Services?
No, because Microsoft fully manages the underlying domain controller infrastructure, you do not receive Domain Admin or Enterprise Admin privileges, nor can you remote desktop directly into the domain controllers.
1
00:00:00,000 --> 00:00:04,560
Hello everyone and welcome to another episode of Microsoft Knowledge Nuggets here on M365,
2
00:00:04,560 --> 00:00:05,560
FM.
3
00:00:05,560 --> 00:00:06,560
I'm Mirko Peters.
4
00:00:06,560 --> 00:00:10,000
Imagine you move an old business app from a server in your office to an Azure virtual
5
00:00:10,000 --> 00:00:10,800
machine.
6
00:00:10,800 --> 00:00:14,000
The app is now in the cloud, but it still asks for a Windows domain.
7
00:00:14,000 --> 00:00:18,440
It wants to join that domain, look up people through LDAPI, sign users in with Kerberos
8
00:00:18,440 --> 00:00:19,880
and apply group policy.
9
00:00:19,880 --> 00:00:23,280
Most people assume Entra ID replaces every active directory job.
10
00:00:23,280 --> 00:00:24,280
It doesn't.
11
00:00:24,280 --> 00:00:28,440
Modern cloud apps can sign you in through Entra ID, but older Windows apps still expect
12
00:00:28,440 --> 00:00:31,280
the same kind of domain they used back in the server room.
13
00:00:31,280 --> 00:00:35,320
By the end of this episode, you'll see where Entra ID, active directory and Entra domain
14
00:00:35,320 --> 00:00:39,760
services each fit, and there's one detail that changes how you manage all of it.
15
00:00:39,760 --> 00:00:42,760
Identity information only travels in one direction.
16
00:00:42,760 --> 00:00:45,560
Why Entra ID alone cannot run every legacy app?
17
00:00:45,560 --> 00:00:47,640
Let's start with what Entra ID does well.
18
00:00:47,640 --> 00:00:49,800
It's the reception desk for your cloud services.
19
00:00:49,800 --> 00:00:54,200
It knows who you are, checks your sign in and decides whether you can enter Microsoft 365
20
00:00:54,200 --> 00:00:56,760
Teams SharePoint or a business app in the cloud.
21
00:00:56,760 --> 00:01:01,160
You sign in once, then move between services without typing your password again and again,
22
00:01:01,160 --> 00:01:03,120
that single sign on.
23
00:01:03,120 --> 00:01:07,000
Entra ID can also ask for a second sign in check through multi-factor authentication.
24
00:01:07,000 --> 00:01:10,680
Look at the device you're using where you're signing in from and the rules your company
25
00:01:10,680 --> 00:01:12,720
sets around access.
26
00:01:12,720 --> 00:01:14,640
For a modern app, that pattern works really well.
27
00:01:14,640 --> 00:01:18,760
You open a browser, the app sends you to Entra ID you sign in, perhaps approve a prompt
28
00:01:18,760 --> 00:01:22,680
on your phone, and then Entra ID sends the app a secure sign in message behind the
29
00:01:22,680 --> 00:01:23,680
scenes.
30
00:01:23,680 --> 00:01:25,400
The app reads that message and lets you in.
31
00:01:25,400 --> 00:01:29,120
With this pattern, there's no need for a domain join, no old Windows server involved, and
32
00:01:29,120 --> 00:01:32,600
no requirement for the app to search a classic company directory.
33
00:01:32,600 --> 00:01:34,640
But older apps grew up in a different world.
34
00:01:34,640 --> 00:01:38,400
Imagine a finance app that has run on a Windows server for years where user sign in from
35
00:01:38,400 --> 00:01:39,880
domain joined PCs.
36
00:01:39,880 --> 00:01:44,080
The app looks up employee details through LDAP, which is a common way for older software
37
00:01:44,080 --> 00:01:45,880
to search a company directory.
38
00:01:45,880 --> 00:01:50,280
It may use Kerberos, and older Windows sign in method that lets systems trust each other.
39
00:01:50,280 --> 00:01:54,600
It may rely on group policy, the set of company rules that can control settings on Windows
40
00:01:54,600 --> 00:01:55,600
servers.
41
00:01:55,600 --> 00:01:58,560
That app doesn't know how to read a modern cloud sign in message.
42
00:01:58,560 --> 00:02:02,160
It expects to call out across the network and find a traditional Windows domain, and if
43
00:02:02,160 --> 00:02:05,760
it can't find one, the app might fail to sign users in, fail to find a service account,
44
00:02:05,760 --> 00:02:07,440
or simply refuse to start.
45
00:02:07,440 --> 00:02:10,040
You've probably seen this pattern outside of IT as well.
46
00:02:10,040 --> 00:02:13,440
A new power outlet doesn't help when the plug on an old machine doesn't fit.
47
00:02:13,440 --> 00:02:15,680
The electricity is there, but the connection is wrong.
48
00:02:15,680 --> 00:02:19,960
Now picture the company moving that finance app and its database into Azure Virtual Machines.
49
00:02:19,960 --> 00:02:22,160
The service have moved, but the old need hasn't.
50
00:02:22,160 --> 00:02:26,360
You could leave active directory in the office and connect Azure back to it through a VPN,
51
00:02:26,360 --> 00:02:30,840
a private network tunnel, so the app in Azure sends requests across that connection whenever
52
00:02:30,840 --> 00:02:32,120
it needs the domain.
53
00:02:32,120 --> 00:02:35,840
That can work, but the app now depends on the network link and the on-premises domain
54
00:02:35,840 --> 00:02:39,760
controller staying available, and if that connection has a problem, the cloud app may
55
00:02:39,760 --> 00:02:41,200
have a problem too.
56
00:02:41,200 --> 00:02:44,640
Another choice is to create your own domain controller virtual machines in Azure.
57
00:02:44,640 --> 00:02:48,320
A domain controller is the server that runs the traditional active directory domain,
58
00:02:48,320 --> 00:02:50,920
handling the directory, sign-ins, and other domain jobs.
59
00:02:50,920 --> 00:02:53,760
It also works, but now your team owns more servers.
60
00:02:53,760 --> 00:02:55,320
Someone needs to patch them and monitor them.
61
00:02:55,320 --> 00:02:59,040
You need backups, recovery plans, a plan for keeping domain controllers in sync, and you
62
00:02:59,040 --> 00:03:02,560
also need to protect the powerful admin accounts that control the domain.
63
00:03:02,560 --> 00:03:06,440
For some companies that control make sense, for others, it's extra work just to keep an
64
00:03:06,440 --> 00:03:07,880
older app happy.
65
00:03:07,880 --> 00:03:09,880
So the gap is quite narrow, but it's real.
66
00:03:09,880 --> 00:03:14,160
An app lives in Azure, yet it still speaks the old active directory language.
67
00:03:14,160 --> 00:03:19,240
What Microsoft EnterDomain Services actually is, Microsoft EnterDomain Services is a managed
68
00:03:19,240 --> 00:03:21,760
Windows domain that runs inside your Azure network.
69
00:03:21,760 --> 00:03:23,280
That's the plain English definition.
70
00:03:23,280 --> 00:03:27,120
The domain controllers run behind the scenes fully managed by Microsoft while your Azure
71
00:03:27,120 --> 00:03:31,520
virtual machines and older apps use the familiar domain services they expect.
72
00:03:31,520 --> 00:03:33,680
Think of your cloud setup as an office building.
73
00:03:33,680 --> 00:03:35,600
Enter ID is the front reception desk.
74
00:03:35,600 --> 00:03:39,600
It checks who you are when you sign into Microsoft 365 or another cloud app, and it applies
75
00:03:39,600 --> 00:03:41,760
the company rules around that sign in.
76
00:03:41,760 --> 00:03:44,200
EnterDomain Services sits in a locked back office room.
77
00:03:44,200 --> 00:03:48,240
Older systems don't need to visit that reception desk the way a modern cloud app does.
78
00:03:48,240 --> 00:03:50,280
They need an old style directory nearby.
79
00:03:50,280 --> 00:03:52,880
One that understands their language and can answer their requests.
80
00:03:52,880 --> 00:03:54,920
That back office room is the managed domain.
81
00:03:54,920 --> 00:03:57,880
Here's the thing, you don't have to build the domain controllers yourself.
82
00:03:57,880 --> 00:03:59,800
You don't sign into them with remote desktop.
83
00:03:59,800 --> 00:04:03,240
You don't decide how many to run, patch windows on them, or manage the connection between
84
00:04:03,240 --> 00:04:04,240
them.
85
00:04:04,240 --> 00:04:05,240
Microsoft takes care of all that.
86
00:04:05,240 --> 00:04:09,440
Your job is to connect the right Azure virtual machines and apps to the managed domain.
87
00:04:09,440 --> 00:04:12,640
Once they're connected, they can use familiar active directory services.
88
00:04:12,640 --> 00:04:14,680
A Windows VM can join the domain.
89
00:04:14,680 --> 00:04:18,240
The older app can use LDIP to look up people, groups, and directory details.
90
00:04:18,240 --> 00:04:19,520
It can use Kerberos.
91
00:04:19,520 --> 00:04:24,040
The sign-in method older business apps often expect when one server needs to trust another.
92
00:04:24,040 --> 00:04:25,880
It can also use NTLM.
93
00:04:25,880 --> 00:04:28,720
Another older Windows sign-in method that some apps still need.
94
00:04:28,720 --> 00:04:32,920
The managed domain provides DNS too, which helps systems find the right server by name rather
95
00:04:32,920 --> 00:04:34,520
than by a string of numbers.
96
00:04:34,520 --> 00:04:38,000
And it supports group policy so you can apply certain window settings to computers and
97
00:04:38,000 --> 00:04:39,960
users in that managed domain.
98
00:04:39,960 --> 00:04:41,520
That list sounds technical, I know.
99
00:04:41,520 --> 00:04:43,680
Picture it as a translation desk instead.
100
00:04:43,680 --> 00:04:47,400
Your app asks in the old Windows language, who is this user?
101
00:04:47,400 --> 00:04:49,400
Can this server trust that server?
102
00:04:49,400 --> 00:04:50,800
Where is the database?
103
00:04:50,800 --> 00:04:52,880
What settings should this computer use?
104
00:04:52,880 --> 00:04:57,040
Entra domain services understands those questions and gives the type of answer the app expects,
105
00:04:57,040 --> 00:04:59,640
but it doesn't create a second main list of employees.
106
00:04:59,640 --> 00:05:02,280
The main identity record stays in Entra ID.
107
00:05:02,280 --> 00:05:05,840
Users and groups from Entra ID copy into the managed domain so the older app can see
108
00:05:05,840 --> 00:05:07,800
and use them in the form it understands.
109
00:05:07,800 --> 00:05:11,400
If your company also has on-premises active directory, identities may already reach Entra
110
00:05:11,400 --> 00:05:14,520
ID from there before they copy into domain services.
111
00:05:14,520 --> 00:05:15,840
Direction matters here.
112
00:05:15,840 --> 00:05:18,440
Identity details flow into Entra domain services.
113
00:05:18,440 --> 00:05:19,440
They don't flow back out.
114
00:05:19,440 --> 00:05:23,400
So if a user comes from Entra ID, you manage that user an Entra ID.
115
00:05:23,400 --> 00:05:27,760
If the user originally comes from your on-premises active directory, you manage the user there.
116
00:05:27,760 --> 00:05:32,000
You don't treat domain services as the place to edit the main employee record.
117
00:05:32,000 --> 00:05:35,560
That keeps the managed domain from becoming a second filing cabinet with different versions
118
00:05:35,560 --> 00:05:36,560
of the same person.
119
00:05:36,560 --> 00:05:40,280
Now, there's one part that catches a lot of people during setup passwords, modern cloud
120
00:05:40,280 --> 00:05:44,360
sign-in and older windows sign-in don't use passwords in exactly the same way behind
121
00:05:44,360 --> 00:05:45,360
the scenes.
122
00:05:45,360 --> 00:05:49,080
For Kerberus and NTLM to work, domain services needs a protected form of password data that
123
00:05:49,080 --> 00:05:50,840
supports those older methods.
124
00:05:50,840 --> 00:05:53,160
Microsoft never keeps your password as plain text.
125
00:05:53,160 --> 00:05:57,600
Instead, the service needs the right protected password information before a user can sign
126
00:05:57,600 --> 00:06:01,400
into a domain joined VM or an older app through the managed domain.
127
00:06:01,400 --> 00:06:05,320
For cloud-only users, that often means the user needs to change their password after
128
00:06:05,320 --> 00:06:07,120
domain services is enabled.
129
00:06:07,120 --> 00:06:10,840
That password change creates the protected form needed for the managed domain.
130
00:06:10,840 --> 00:06:15,700
Until that happens, the user may sign into Microsoft 365 perfectly well but still fail when
131
00:06:15,700 --> 00:06:17,600
trying to use the old style domain.
132
00:06:17,600 --> 00:06:18,880
It can feel audit first.
133
00:06:18,880 --> 00:06:23,200
The user already has an account, the password already works, yet the legacy app still can't
134
00:06:23,200 --> 00:06:24,200
use it.
135
00:06:24,200 --> 00:06:26,080
The missing piece is not the user account.
136
00:06:26,080 --> 00:06:29,840
It's the protected password form required by those older sign-in methods.
137
00:06:29,840 --> 00:06:32,720
Domain services also has a clear boundary around where it works.
138
00:06:32,720 --> 00:06:35,880
It runs inside an Azure Virtual Network, often called a VNet.
139
00:06:35,880 --> 00:06:39,960
For Azure VMs, need network access to that VNet and they need to use the managed domains
140
00:06:39,960 --> 00:06:41,960
DNS settings so they can find it.
141
00:06:41,960 --> 00:06:45,720
This isn't a public directory that every device on the internet can contact.
142
00:06:45,720 --> 00:06:49,640
It's a private domain service for workloads connected to the right Azure network.
143
00:06:49,640 --> 00:06:53,720
So when an app needs old Active Directory behavior in Azure, domain services gives it
144
00:06:53,720 --> 00:06:55,720
a managed place to find that behavior.
145
00:06:55,720 --> 00:06:59,560
That brings us to the next question, where does this sit beside EntraID and your existing
146
00:06:59,560 --> 00:07:01,000
Active Directory domain?
147
00:07:01,000 --> 00:07:04,320
The names sound similar but their jobs are very different.
148
00:07:04,320 --> 00:07:07,640
EntraID, Active Directory and domain services.
149
00:07:07,640 --> 00:07:08,640
Different jobs.
150
00:07:08,640 --> 00:07:12,640
The names are close, so it's easy to treat these as different versions of the same product.
151
00:07:12,640 --> 00:07:13,640
They aren't.
152
00:07:13,640 --> 00:07:16,760
Each one handles a different part of your company's identity picture and once you see
153
00:07:16,760 --> 00:07:19,800
the job each one does, the choice becomes much clearer.
154
00:07:19,800 --> 00:07:21,520
EntraID handles cloud identity.
155
00:07:21,520 --> 00:07:26,160
When you open Microsoft 365 Teams SharePoint or a modern business app, EntraID checks
156
00:07:26,160 --> 00:07:28,560
your sign-in and controls what you can access.
157
00:07:28,560 --> 00:07:32,680
It also supports multi-factor authentication and access rules, like asking for a stronger
158
00:07:32,680 --> 00:07:35,240
sign-in check when you work from an unknown device.
159
00:07:35,240 --> 00:07:36,760
It's built for cloud services.
160
00:07:36,760 --> 00:07:41,120
A modern app doesn't need to sit on the same network as EntraID because it uses web-based
161
00:07:41,120 --> 00:07:42,280
sign-in methods.
162
00:07:42,280 --> 00:07:46,480
You sign in through a browser or an app, EntraID confirms who you are and the app receives
163
00:07:46,480 --> 00:07:47,960
proof that you're allowed in.
164
00:07:47,960 --> 00:07:50,440
That's the normal pattern for new cloud apps.
165
00:07:50,440 --> 00:07:54,920
Active Directory domain services, often shortened to Active Directory, does a different job.
166
00:07:54,920 --> 00:07:58,440
This is the traditional Windows domain that many companies run in their own offices,
167
00:07:58,440 --> 00:08:00,240
data centers, or server rooms.
168
00:08:00,240 --> 00:08:04,200
The company owns the domain controllers, chooses how to set them up, and manages the whole
169
00:08:04,200 --> 00:08:05,560
domain from top to bottom.
170
00:08:05,560 --> 00:08:09,360
It can control Windows PCs, support local servers, and provide the older sign-in methods
171
00:08:09,360 --> 00:08:11,560
that long-running business apps expect.
172
00:08:11,560 --> 00:08:13,800
That level of control comes with responsibility.
173
00:08:13,800 --> 00:08:17,640
Your IT team runs the domain, looks after the servers, and decides how the directory should
174
00:08:17,640 --> 00:08:19,960
work for the company.
175
00:08:19,960 --> 00:08:22,440
EntraDomain Services sits between those two worlds.
176
00:08:22,440 --> 00:08:25,960
It gives Azure workloads and managed Windows domain when they need older Active Directory
177
00:08:25,960 --> 00:08:29,240
behavior, but Microsoft runs the domain controller side of it.
178
00:08:29,240 --> 00:08:33,440
You use the domain for Azure VMs and older apps without taking on the full job of running
179
00:08:33,440 --> 00:08:35,920
a traditional Active Directory domain yourself.
180
00:08:35,920 --> 00:08:37,720
Think of it as a filing cabinet system.
181
00:08:37,720 --> 00:08:40,880
EntraID holds the main employee record for cloud work.
182
00:08:40,880 --> 00:08:44,840
That's where the company keeps the working record used for Microsoft 365 and modern cloud
183
00:08:44,840 --> 00:08:45,840
sign-ins.
184
00:08:45,840 --> 00:08:50,080
Domain Services gives older Azure apps a compatible copy of the records they need.
185
00:08:50,080 --> 00:08:54,200
Those apps can open the familiar type of filing cabinet and find users, groups, and sign-in
186
00:08:54,200 --> 00:08:56,600
details in the old format they understand.
187
00:08:56,600 --> 00:08:59,320
You don't need to rebuild the app just because it moved into Azure.
188
00:08:59,320 --> 00:09:02,000
A cloud-only company can use this setup too.
189
00:09:02,000 --> 00:09:05,120
Imagine a company that has never run local domain controllers.
190
00:09:05,120 --> 00:09:10,040
Everyone signs into Microsoft 365 through EntraID and the business starts using Azure VMs
191
00:09:10,040 --> 00:09:11,480
for an older Windows app.
192
00:09:11,480 --> 00:09:15,840
That company doesn't need to build an on-premises Active Directory domain just for that app.
193
00:09:15,840 --> 00:09:20,200
Instead, it can use Entra domain services for the Azure VMs that need domain behavior,
194
00:09:20,200 --> 00:09:23,400
while the rest of the company keeps using EntraID for normal cloud work.
195
00:09:23,400 --> 00:09:25,600
A hybrid company has a different starting point.
196
00:09:25,600 --> 00:09:30,520
It may already run Active Directory in its office with users and groups that sync into EntraID.
197
00:09:30,520 --> 00:09:34,480
Those people can then appear in Entra domain services for workloads that run in Azure.
198
00:09:34,480 --> 00:09:35,960
The flow looks like this.
199
00:09:35,960 --> 00:09:40,840
The company's existing Active Directory sends identity details to EntraID and EntraID provides
200
00:09:40,840 --> 00:09:43,360
the compatible copy to domain services.
201
00:09:43,360 --> 00:09:47,000
That doesn't mean domain services replaces the original on-premises domain.
202
00:09:47,000 --> 00:09:51,480
The office may still need its own Active Directory domain for local PCs, local servers, factory
203
00:09:51,480 --> 00:09:54,560
systems, or applications that remain on site.
204
00:09:54,560 --> 00:09:58,560
Entraid domain services only handles the Azure part where managed old-style domain behavior
205
00:09:58,560 --> 00:09:59,560
fits the workload.
206
00:09:59,560 --> 00:10:02,360
It doesn't turn EntraID into full Active Directory either.
207
00:10:02,360 --> 00:10:04,960
EntraID remains a cloud identity service.
208
00:10:04,960 --> 00:10:09,520
Domain services adds a managed domain for certain older needs, but it doesn't give you
209
00:10:09,520 --> 00:10:14,400
every option and every level of control you'd have when you run Active Directory yourself.
210
00:10:14,400 --> 00:10:16,120
So picture three separate jobs.
211
00:10:16,120 --> 00:10:18,520
EntraID handles modern cloud signings.
212
00:10:18,520 --> 00:10:21,720
Active Directory handles the Windows domain your company runs itself.
213
00:10:21,720 --> 00:10:26,320
The domain services handles legacy Azure workloads that still need a Windows domain without asking
214
00:10:26,320 --> 00:10:27,880
you to run the domain controllers.
215
00:10:27,880 --> 00:10:30,880
With those jobs clear, you can ask a much better question.
216
00:10:30,880 --> 00:10:35,360
When does domain services fit the workload and when should you choose something else?
217
00:10:35,360 --> 00:10:38,040
When domain services fits and when it does not.
218
00:10:38,040 --> 00:10:40,000
Start with the app, not the product name.
219
00:10:40,000 --> 00:10:44,360
If an older app uses LDAP, that's an old language for checking user names and passwords,
220
00:10:44,360 --> 00:10:47,400
and you're moving it to Azure, domain services can be a great fit.
221
00:10:47,400 --> 00:10:51,160
The app keeps using what it already understands without forcing a full rewrite.
222
00:10:51,160 --> 00:10:54,560
It matters when the app still works, the business needs it and rewriting the sign-in code would
223
00:10:54,560 --> 00:10:56,480
cost too much time or money.
224
00:10:56,480 --> 00:11:00,840
Another common scenario, a group of Azure virtual machines need to act like normal domain
225
00:11:00,840 --> 00:11:01,840
computers.
226
00:11:01,840 --> 00:11:05,440
Staff might need to sign into Windows with their work account, servers might need a service
227
00:11:05,440 --> 00:11:09,760
account, an account and app users to connect to another system like a database.
228
00:11:09,760 --> 00:11:13,640
You might need group policy to apply company settings to those virtual machines.
229
00:11:13,640 --> 00:11:18,200
In those cases, domain services gives the Azure machines the domain behavior they expect.
230
00:11:18,200 --> 00:11:19,800
Remote desktop services fits here too.
231
00:11:19,800 --> 00:11:24,120
Imagine employees connecting to shared Windows desktop or apps in Azure.
232
00:11:24,120 --> 00:11:29,040
Those systems often depend on a Windows domain for user sign-in and computer management.
233
00:11:29,040 --> 00:11:32,840
Domain services provides that domain layer without your team building domain controller virtual
234
00:11:32,840 --> 00:11:34,240
machines from scratch.
235
00:11:34,240 --> 00:11:36,520
Older apps often have more than one part.
236
00:11:36,520 --> 00:11:39,840
There might be a web server at the front, an app server in the middle and a database at
237
00:11:39,840 --> 00:11:40,840
the back.
238
00:11:40,840 --> 00:11:44,920
The app server needs to prove its identity before the database accepts a connection.
239
00:11:44,920 --> 00:11:48,560
When that trust relies on Windows service accounts, domain services keeps those connections
240
00:11:48,560 --> 00:11:50,120
working after the move.
241
00:11:50,120 --> 00:11:51,120
Here's the thing.
242
00:11:51,120 --> 00:11:55,760
Your team gets the older domain behavior the workload needs while Microsoft handles the
243
00:11:55,760 --> 00:11:59,640
domain controller work that would otherwise sit on your server list.
244
00:11:59,640 --> 00:12:02,240
But don't pick domain services just because you're using Azure.
245
00:12:02,240 --> 00:12:05,120
A new cloud app should sign in directly through Entra ID.
246
00:12:05,120 --> 00:12:09,400
If it supports modern sign-in methods, it sends users to Entra ID, gets back proof of
247
00:12:09,400 --> 00:12:14,200
the sign-in and benefits from cloud access rules and multi-factor authentication.
248
00:12:14,200 --> 00:12:16,360
That's the cleaner path for new software.
249
00:12:16,360 --> 00:12:19,200
Entra ID and services helps an app that speaks the old language.
250
00:12:19,200 --> 00:12:21,640
It's not a reason to teach new apps that old language.
251
00:12:21,640 --> 00:12:24,640
There are also hard limits you need to check first.
252
00:12:24,640 --> 00:12:28,640
Some apps don't just read from Active Directory, they write back into it, for example.
253
00:12:28,640 --> 00:12:33,040
An app might want to create or change directory entries as part of its normal work.
254
00:12:33,040 --> 00:12:37,040
Domain services doesn't fit when the app requires LDIP right access.
255
00:12:37,040 --> 00:12:40,560
The same warning applies if an app needs to change the Active Directory schema, the
256
00:12:40,560 --> 00:12:43,760
set of fields that define what the directory can store.
257
00:12:43,760 --> 00:12:46,960
The older software asks you to add its own fields before it runs.
258
00:12:46,960 --> 00:12:49,840
A managed domain doesn't let you change that underlying design.
259
00:12:49,840 --> 00:12:53,400
You should also pause if your team needs full control over the domain itself.
260
00:12:53,400 --> 00:12:56,160
Maybe you need direct access to domain controllers.
261
00:12:56,160 --> 00:12:59,320
Maybe you need domain admin rights which give very broad control.
262
00:12:59,320 --> 00:13:02,680
Or maybe you need a complicated directory design that you want to build and run your own
263
00:13:02,680 --> 00:13:03,680
way.
264
00:13:03,680 --> 00:13:08,520
That points toward running Active Directory yourself, either on-premises or on virtual machines
265
00:13:08,520 --> 00:13:09,520
in Azure.
266
00:13:09,520 --> 00:13:13,120
Domain services deliberately gives you less control because Microsoft runs the core domain
267
00:13:13,120 --> 00:13:14,120
service.
268
00:13:14,120 --> 00:13:16,760
So ask one plain English question before you pick a path.
269
00:13:16,760 --> 00:13:21,320
Does this workload need old Active Directory language or can it speak modern-entra ID?
270
00:13:21,320 --> 00:13:23,240
If it can use modern-entra ID, start there.
271
00:13:23,240 --> 00:13:27,480
If it needs old domain behavior but doesn't need you to own every part of the domain, domain
272
00:13:27,480 --> 00:13:29,200
services may fit very well.
273
00:13:29,200 --> 00:13:33,320
And if the app needs to rewrite the directory, change its schema, or give your team total
274
00:13:33,320 --> 00:13:35,680
domain control, it needs a different home.
275
00:13:35,680 --> 00:13:38,280
Choosing a managed domain means accepting a trade-off.
276
00:13:38,280 --> 00:13:41,560
Microsoft takes care of the domain controllers and you give up some of the control that comes
277
00:13:41,560 --> 00:13:43,440
with running them yourself.
278
00:13:43,440 --> 00:13:45,760
The managed service trade-offs you need to know.
279
00:13:45,760 --> 00:13:50,480
That managed approach saves work, but it also changes what your IT team can control.
280
00:13:50,480 --> 00:13:53,820
Microsoft runs the domain controllers, keeps them in sync, applies patches and handles
281
00:13:53,820 --> 00:13:55,640
availability behind the scenes.
282
00:13:55,640 --> 00:14:00,120
You don't need to plan where each domain controller sits or recover one after a server failure.
283
00:14:00,120 --> 00:14:01,800
That's why many teams choose it.
284
00:14:01,800 --> 00:14:05,800
But you can't remote desktop into those domain controllers and you don't get domain admin
285
00:14:05,800 --> 00:14:09,320
or enterprise admin rights because those would give control over the parts Microsoft
286
00:14:09,320 --> 00:14:10,320
manages.
287
00:14:10,320 --> 00:14:14,520
Instead Microsoft provides a group called EntraDomain Services Administrators.
288
00:14:14,520 --> 00:14:18,200
Put the people who need to manage the domain into that group, then use a management virtual
289
00:14:18,200 --> 00:14:20,360
machine joined to the managed domain.
290
00:14:20,360 --> 00:14:24,800
From that machine, you can use familiar Active Directory tools to manage what Microsoft allows.
291
00:14:24,800 --> 00:14:28,200
For example, you can create your own organizational units or OUs.
292
00:14:28,200 --> 00:14:31,720
Think of them as folders for domain objects like computers or service accounts.
293
00:14:31,720 --> 00:14:33,120
You can manage DNS records.
294
00:14:33,120 --> 00:14:35,920
You can create and apply group policy for supported settings.
295
00:14:35,920 --> 00:14:39,360
You can also manage the computers that join the domain, which is often the main reason
296
00:14:39,360 --> 00:14:40,680
the service exists.
297
00:14:40,680 --> 00:14:41,880
These limits are on purpose.
298
00:14:41,880 --> 00:14:45,840
You can't add more domain controllers, change the Active Directory schema or treat the
299
00:14:45,840 --> 00:14:49,240
managed domain as a place where changes flow back into EntraID.
300
00:14:49,240 --> 00:14:52,240
So keep user and group management in the source directory.
301
00:14:52,240 --> 00:14:55,560
For a cloud-only company, that source is EntraID.
302
00:14:55,560 --> 00:15:00,120
For a hybrid company, it's the on-premises Active Directory that syncs into EntraID.
303
00:15:00,120 --> 00:15:02,280
This rule prevents a mistake we see often.
304
00:15:02,280 --> 00:15:06,200
Someone sees a user in the managed domain and changes them there assuming it will stick.
305
00:15:06,200 --> 00:15:11,360
But that change won't become the company record in EntraID or on-premises Active Directory.
306
00:15:11,360 --> 00:15:14,200
Keep the managed domain private inside Azure networking.
307
00:15:14,200 --> 00:15:18,520
It should support only the workloads that need it, not become a general company directory.
308
00:15:18,520 --> 00:15:22,880
Limit network access, protect the management machine and give admin access only to people
309
00:15:22,880 --> 00:15:23,880
who need it.
310
00:15:23,880 --> 00:15:25,840
You're choosing a service with guardrails.
311
00:15:25,840 --> 00:15:29,600
Those guardrails remove some work while stopping you from changing the parts that Microsoft
312
00:15:29,600 --> 00:15:31,400
owns.
313
00:15:31,400 --> 00:15:33,480
A simple Azure migration story.
314
00:15:33,480 --> 00:15:37,560
Imagine a finance company running an old app on servers inside their own office.
315
00:15:37,560 --> 00:15:39,640
That app relies on LDIP to find employees.
316
00:15:39,640 --> 00:15:41,440
It uses kerbos when people sign in.
317
00:15:41,440 --> 00:15:44,680
And its server authenticates with a service account to reach the finance database.
318
00:15:44,680 --> 00:15:49,320
The company wants to move both the app and its database into Azure Virtual Machines.
319
00:15:49,320 --> 00:15:52,880
One option is keeping the app connected to the office domain through a VPN.
320
00:15:52,880 --> 00:15:56,400
But then the Azure app depends on that network connection and the local domain controllers
321
00:15:56,400 --> 00:15:57,760
every single day.
322
00:15:57,760 --> 00:16:00,880
Another option is running new domain controller virtual machines in Azure.
323
00:16:00,880 --> 00:16:03,840
It keeps more traffic inside Azure, but adds Windows servers.
324
00:16:03,840 --> 00:16:07,000
The IT team has to patch, monitor, backup and recover.
325
00:16:07,000 --> 00:16:08,520
The team goes a different way.
326
00:16:08,520 --> 00:16:11,200
They're users and groups already sync into enter ID.
327
00:16:11,200 --> 00:16:15,880
They enable intradomain services, connect the Azure Virtual Network and configure the Azure
328
00:16:15,880 --> 00:16:18,360
Virtual Machines to use the managed domain.
329
00:16:18,360 --> 00:16:20,600
After that, they join the app servers to that domain.
330
00:16:20,600 --> 00:16:24,320
The finance app keeps using LDIP, Kerbos and its service account.
331
00:16:24,320 --> 00:16:28,160
The domain behavior it expects now sits right next to the app in Azure.
332
00:16:28,160 --> 00:16:29,440
Microsoft runs the domain controllers.
333
00:16:29,440 --> 00:16:30,560
The company runs the app.
334
00:16:30,560 --> 00:16:33,880
But this doesn't mean every new project should go through domain services.
335
00:16:33,880 --> 00:16:38,400
If the company builds a fresh expense app next year, that app should use enter ID directly
336
00:16:38,400 --> 00:16:40,240
for modern cloud signing.
337
00:16:40,240 --> 00:16:42,240
Domain services exist for that finance app.
338
00:16:42,240 --> 00:16:46,120
Its older design still depends on a Windows domain.
339
00:16:46,120 --> 00:16:50,760
Entra domain services gives Azure workloads a managed Windows domain when Entra ID alone
340
00:16:50,760 --> 00:16:52,880
can't meet their older sign in needs.
341
00:16:52,880 --> 00:16:58,040
Start by listing Azure apps that ask for LDIP, Kerbos, NTLM, Domain Join or Group Policy,
342
00:16:58,040 --> 00:16:59,360
then sort each one.
343
00:16:59,360 --> 00:17:00,920
This is the app for Entra ID.
344
00:17:00,920 --> 00:17:05,480
Keep it on your existing Active Directory domain or place it behind Enter Domain Services.
345
00:17:05,480 --> 00:17:06,600
But watch for one limit.
346
00:17:06,600 --> 00:17:11,120
If the app needs LDIP right access or schema changes, domain services won't work.
347
00:17:11,120 --> 00:17:14,440
For the wider identity picture, continue with the Entra ID Knowledge Nugget.
348
00:17:14,440 --> 00:17:16,040
That's where the cloud reception desk begins.
00:00:00,000 --> 00:00:04,560
Hello everyone and welcome to another episode of Microsoft Knowledge Nuggets here on M365,
2
00:00:04,560 --> 00:00:05,560
FM.
3
00:00:05,560 --> 00:00:06,560
I'm Mirko Peters.
4
00:00:06,560 --> 00:00:10,000
Imagine you move an old business app from a server in your office to an Azure virtual
5
00:00:10,000 --> 00:00:10,800
machine.
6
00:00:10,800 --> 00:00:14,000
The app is now in the cloud, but it still asks for a Windows domain.
7
00:00:14,000 --> 00:00:18,440
It wants to join that domain, look up people through LDAPI, sign users in with Kerberos
8
00:00:18,440 --> 00:00:19,880
and apply group policy.
9
00:00:19,880 --> 00:00:23,280
Most people assume Entra ID replaces every active directory job.
10
00:00:23,280 --> 00:00:24,280
It doesn't.
11
00:00:24,280 --> 00:00:28,440
Modern cloud apps can sign you in through Entra ID, but older Windows apps still expect
12
00:00:28,440 --> 00:00:31,280
the same kind of domain they used back in the server room.
13
00:00:31,280 --> 00:00:35,320
By the end of this episode, you'll see where Entra ID, active directory and Entra domain
14
00:00:35,320 --> 00:00:39,760
services each fit, and there's one detail that changes how you manage all of it.
15
00:00:39,760 --> 00:00:42,760
Identity information only travels in one direction.
16
00:00:42,760 --> 00:00:45,560
Why Entra ID alone cannot run every legacy app?
17
00:00:45,560 --> 00:00:47,640
Let's start with what Entra ID does well.
18
00:00:47,640 --> 00:00:49,800
It's the reception desk for your cloud services.
19
00:00:49,800 --> 00:00:54,200
It knows who you are, checks your sign in and decides whether you can enter Microsoft 365
20
00:00:54,200 --> 00:00:56,760
Teams SharePoint or a business app in the cloud.
21
00:00:56,760 --> 00:01:01,160
You sign in once, then move between services without typing your password again and again,
22
00:01:01,160 --> 00:01:03,120
that single sign on.
23
00:01:03,120 --> 00:01:07,000
Entra ID can also ask for a second sign in check through multi-factor authentication.
24
00:01:07,000 --> 00:01:10,680
Look at the device you're using where you're signing in from and the rules your company
25
00:01:10,680 --> 00:01:12,720
sets around access.
26
00:01:12,720 --> 00:01:14,640
For a modern app, that pattern works really well.
27
00:01:14,640 --> 00:01:18,760
You open a browser, the app sends you to Entra ID you sign in, perhaps approve a prompt
28
00:01:18,760 --> 00:01:22,680
on your phone, and then Entra ID sends the app a secure sign in message behind the
29
00:01:22,680 --> 00:01:23,680
scenes.
30
00:01:23,680 --> 00:01:25,400
The app reads that message and lets you in.
31
00:01:25,400 --> 00:01:29,120
With this pattern, there's no need for a domain join, no old Windows server involved, and
32
00:01:29,120 --> 00:01:32,600
no requirement for the app to search a classic company directory.
33
00:01:32,600 --> 00:01:34,640
But older apps grew up in a different world.
34
00:01:34,640 --> 00:01:38,400
Imagine a finance app that has run on a Windows server for years where user sign in from
35
00:01:38,400 --> 00:01:39,880
domain joined PCs.
36
00:01:39,880 --> 00:01:44,080
The app looks up employee details through LDAP, which is a common way for older software
37
00:01:44,080 --> 00:01:45,880
to search a company directory.
38
00:01:45,880 --> 00:01:50,280
It may use Kerberos, and older Windows sign in method that lets systems trust each other.
39
00:01:50,280 --> 00:01:54,600
It may rely on group policy, the set of company rules that can control settings on Windows
40
00:01:54,600 --> 00:01:55,600
servers.
41
00:01:55,600 --> 00:01:58,560
That app doesn't know how to read a modern cloud sign in message.
42
00:01:58,560 --> 00:02:02,160
It expects to call out across the network and find a traditional Windows domain, and if
43
00:02:02,160 --> 00:02:05,760
it can't find one, the app might fail to sign users in, fail to find a service account,
44
00:02:05,760 --> 00:02:07,440
or simply refuse to start.
45
00:02:07,440 --> 00:02:10,040
You've probably seen this pattern outside of IT as well.
46
00:02:10,040 --> 00:02:13,440
A new power outlet doesn't help when the plug on an old machine doesn't fit.
47
00:02:13,440 --> 00:02:15,680
The electricity is there, but the connection is wrong.
48
00:02:15,680 --> 00:02:19,960
Now picture the company moving that finance app and its database into Azure Virtual Machines.
49
00:02:19,960 --> 00:02:22,160
The service have moved, but the old need hasn't.
50
00:02:22,160 --> 00:02:26,360
You could leave active directory in the office and connect Azure back to it through a VPN,
51
00:02:26,360 --> 00:02:30,840
a private network tunnel, so the app in Azure sends requests across that connection whenever
52
00:02:30,840 --> 00:02:32,120
it needs the domain.
53
00:02:32,120 --> 00:02:35,840
That can work, but the app now depends on the network link and the on-premises domain
54
00:02:35,840 --> 00:02:39,760
controller staying available, and if that connection has a problem, the cloud app may
55
00:02:39,760 --> 00:02:41,200
have a problem too.
56
00:02:41,200 --> 00:02:44,640
Another choice is to create your own domain controller virtual machines in Azure.
57
00:02:44,640 --> 00:02:48,320
A domain controller is the server that runs the traditional active directory domain,
58
00:02:48,320 --> 00:02:50,920
handling the directory, sign-ins, and other domain jobs.
59
00:02:50,920 --> 00:02:53,760
It also works, but now your team owns more servers.
60
00:02:53,760 --> 00:02:55,320
Someone needs to patch them and monitor them.
61
00:02:55,320 --> 00:02:59,040
You need backups, recovery plans, a plan for keeping domain controllers in sync, and you
62
00:02:59,040 --> 00:03:02,560
also need to protect the powerful admin accounts that control the domain.
63
00:03:02,560 --> 00:03:06,440
For some companies that control make sense, for others, it's extra work just to keep an
64
00:03:06,440 --> 00:03:07,880
older app happy.
65
00:03:07,880 --> 00:03:09,880
So the gap is quite narrow, but it's real.
66
00:03:09,880 --> 00:03:14,160
An app lives in Azure, yet it still speaks the old active directory language.
67
00:03:14,160 --> 00:03:19,240
What Microsoft EnterDomain Services actually is, Microsoft EnterDomain Services is a managed
68
00:03:19,240 --> 00:03:21,760
Windows domain that runs inside your Azure network.
69
00:03:21,760 --> 00:03:23,280
That's the plain English definition.
70
00:03:23,280 --> 00:03:27,120
The domain controllers run behind the scenes fully managed by Microsoft while your Azure
71
00:03:27,120 --> 00:03:31,520
virtual machines and older apps use the familiar domain services they expect.
72
00:03:31,520 --> 00:03:33,680
Think of your cloud setup as an office building.
73
00:03:33,680 --> 00:03:35,600
Enter ID is the front reception desk.
74
00:03:35,600 --> 00:03:39,600
It checks who you are when you sign into Microsoft 365 or another cloud app, and it applies
75
00:03:39,600 --> 00:03:41,760
the company rules around that sign in.
76
00:03:41,760 --> 00:03:44,200
EnterDomain Services sits in a locked back office room.
77
00:03:44,200 --> 00:03:48,240
Older systems don't need to visit that reception desk the way a modern cloud app does.
78
00:03:48,240 --> 00:03:50,280
They need an old style directory nearby.
79
00:03:50,280 --> 00:03:52,880
One that understands their language and can answer their requests.
80
00:03:52,880 --> 00:03:54,920
That back office room is the managed domain.
81
00:03:54,920 --> 00:03:57,880
Here's the thing, you don't have to build the domain controllers yourself.
82
00:03:57,880 --> 00:03:59,800
You don't sign into them with remote desktop.
83
00:03:59,800 --> 00:04:03,240
You don't decide how many to run, patch windows on them, or manage the connection between
84
00:04:03,240 --> 00:04:04,240
them.
85
00:04:04,240 --> 00:04:05,240
Microsoft takes care of all that.
86
00:04:05,240 --> 00:04:09,440
Your job is to connect the right Azure virtual machines and apps to the managed domain.
87
00:04:09,440 --> 00:04:12,640
Once they're connected, they can use familiar active directory services.
88
00:04:12,640 --> 00:04:14,680
A Windows VM can join the domain.
89
00:04:14,680 --> 00:04:18,240
The older app can use LDIP to look up people, groups, and directory details.
90
00:04:18,240 --> 00:04:19,520
It can use Kerberos.
91
00:04:19,520 --> 00:04:24,040
The sign-in method older business apps often expect when one server needs to trust another.
92
00:04:24,040 --> 00:04:25,880
It can also use NTLM.
93
00:04:25,880 --> 00:04:28,720
Another older Windows sign-in method that some apps still need.
94
00:04:28,720 --> 00:04:32,920
The managed domain provides DNS too, which helps systems find the right server by name rather
95
00:04:32,920 --> 00:04:34,520
than by a string of numbers.
96
00:04:34,520 --> 00:04:38,000
And it supports group policy so you can apply certain window settings to computers and
97
00:04:38,000 --> 00:04:39,960
users in that managed domain.
98
00:04:39,960 --> 00:04:41,520
That list sounds technical, I know.
99
00:04:41,520 --> 00:04:43,680
Picture it as a translation desk instead.
100
00:04:43,680 --> 00:04:47,400
Your app asks in the old Windows language, who is this user?
101
00:04:47,400 --> 00:04:49,400
Can this server trust that server?
102
00:04:49,400 --> 00:04:50,800
Where is the database?
103
00:04:50,800 --> 00:04:52,880
What settings should this computer use?
104
00:04:52,880 --> 00:04:57,040
Entra domain services understands those questions and gives the type of answer the app expects,
105
00:04:57,040 --> 00:04:59,640
but it doesn't create a second main list of employees.
106
00:04:59,640 --> 00:05:02,280
The main identity record stays in Entra ID.
107
00:05:02,280 --> 00:05:05,840
Users and groups from Entra ID copy into the managed domain so the older app can see
108
00:05:05,840 --> 00:05:07,800
and use them in the form it understands.
109
00:05:07,800 --> 00:05:11,400
If your company also has on-premises active directory, identities may already reach Entra
110
00:05:11,400 --> 00:05:14,520
ID from there before they copy into domain services.
111
00:05:14,520 --> 00:05:15,840
Direction matters here.
112
00:05:15,840 --> 00:05:18,440
Identity details flow into Entra domain services.
113
00:05:18,440 --> 00:05:19,440
They don't flow back out.
114
00:05:19,440 --> 00:05:23,400
So if a user comes from Entra ID, you manage that user an Entra ID.
115
00:05:23,400 --> 00:05:27,760
If the user originally comes from your on-premises active directory, you manage the user there.
116
00:05:27,760 --> 00:05:32,000
You don't treat domain services as the place to edit the main employee record.
117
00:05:32,000 --> 00:05:35,560
That keeps the managed domain from becoming a second filing cabinet with different versions
118
00:05:35,560 --> 00:05:36,560
of the same person.
119
00:05:36,560 --> 00:05:40,280
Now, there's one part that catches a lot of people during setup passwords, modern cloud
120
00:05:40,280 --> 00:05:44,360
sign-in and older windows sign-in don't use passwords in exactly the same way behind
121
00:05:44,360 --> 00:05:45,360
the scenes.
122
00:05:45,360 --> 00:05:49,080
For Kerberus and NTLM to work, domain services needs a protected form of password data that
123
00:05:49,080 --> 00:05:50,840
supports those older methods.
124
00:05:50,840 --> 00:05:53,160
Microsoft never keeps your password as plain text.
125
00:05:53,160 --> 00:05:57,600
Instead, the service needs the right protected password information before a user can sign
126
00:05:57,600 --> 00:06:01,400
into a domain joined VM or an older app through the managed domain.
127
00:06:01,400 --> 00:06:05,320
For cloud-only users, that often means the user needs to change their password after
128
00:06:05,320 --> 00:06:07,120
domain services is enabled.
129
00:06:07,120 --> 00:06:10,840
That password change creates the protected form needed for the managed domain.
130
00:06:10,840 --> 00:06:15,700
Until that happens, the user may sign into Microsoft 365 perfectly well but still fail when
131
00:06:15,700 --> 00:06:17,600
trying to use the old style domain.
132
00:06:17,600 --> 00:06:18,880
It can feel audit first.
133
00:06:18,880 --> 00:06:23,200
The user already has an account, the password already works, yet the legacy app still can't
134
00:06:23,200 --> 00:06:24,200
use it.
135
00:06:24,200 --> 00:06:26,080
The missing piece is not the user account.
136
00:06:26,080 --> 00:06:29,840
It's the protected password form required by those older sign-in methods.
137
00:06:29,840 --> 00:06:32,720
Domain services also has a clear boundary around where it works.
138
00:06:32,720 --> 00:06:35,880
It runs inside an Azure Virtual Network, often called a VNet.
139
00:06:35,880 --> 00:06:39,960
For Azure VMs, need network access to that VNet and they need to use the managed domains
140
00:06:39,960 --> 00:06:41,960
DNS settings so they can find it.
141
00:06:41,960 --> 00:06:45,720
This isn't a public directory that every device on the internet can contact.
142
00:06:45,720 --> 00:06:49,640
It's a private domain service for workloads connected to the right Azure network.
143
00:06:49,640 --> 00:06:53,720
So when an app needs old Active Directory behavior in Azure, domain services gives it
144
00:06:53,720 --> 00:06:55,720
a managed place to find that behavior.
145
00:06:55,720 --> 00:06:59,560
That brings us to the next question, where does this sit beside EntraID and your existing
146
00:06:59,560 --> 00:07:01,000
Active Directory domain?
147
00:07:01,000 --> 00:07:04,320
The names sound similar but their jobs are very different.
148
00:07:04,320 --> 00:07:07,640
EntraID, Active Directory and domain services.
149
00:07:07,640 --> 00:07:08,640
Different jobs.
150
00:07:08,640 --> 00:07:12,640
The names are close, so it's easy to treat these as different versions of the same product.
151
00:07:12,640 --> 00:07:13,640
They aren't.
152
00:07:13,640 --> 00:07:16,760
Each one handles a different part of your company's identity picture and once you see
153
00:07:16,760 --> 00:07:19,800
the job each one does, the choice becomes much clearer.
154
00:07:19,800 --> 00:07:21,520
EntraID handles cloud identity.
155
00:07:21,520 --> 00:07:26,160
When you open Microsoft 365 Teams SharePoint or a modern business app, EntraID checks
156
00:07:26,160 --> 00:07:28,560
your sign-in and controls what you can access.
157
00:07:28,560 --> 00:07:32,680
It also supports multi-factor authentication and access rules, like asking for a stronger
158
00:07:32,680 --> 00:07:35,240
sign-in check when you work from an unknown device.
159
00:07:35,240 --> 00:07:36,760
It's built for cloud services.
160
00:07:36,760 --> 00:07:41,120
A modern app doesn't need to sit on the same network as EntraID because it uses web-based
161
00:07:41,120 --> 00:07:42,280
sign-in methods.
162
00:07:42,280 --> 00:07:46,480
You sign in through a browser or an app, EntraID confirms who you are and the app receives
163
00:07:46,480 --> 00:07:47,960
proof that you're allowed in.
164
00:07:47,960 --> 00:07:50,440
That's the normal pattern for new cloud apps.
165
00:07:50,440 --> 00:07:54,920
Active Directory domain services, often shortened to Active Directory, does a different job.
166
00:07:54,920 --> 00:07:58,440
This is the traditional Windows domain that many companies run in their own offices,
167
00:07:58,440 --> 00:08:00,240
data centers, or server rooms.
168
00:08:00,240 --> 00:08:04,200
The company owns the domain controllers, chooses how to set them up, and manages the whole
169
00:08:04,200 --> 00:08:05,560
domain from top to bottom.
170
00:08:05,560 --> 00:08:09,360
It can control Windows PCs, support local servers, and provide the older sign-in methods
171
00:08:09,360 --> 00:08:11,560
that long-running business apps expect.
172
00:08:11,560 --> 00:08:13,800
That level of control comes with responsibility.
173
00:08:13,800 --> 00:08:17,640
Your IT team runs the domain, looks after the servers, and decides how the directory should
174
00:08:17,640 --> 00:08:19,960
work for the company.
175
00:08:19,960 --> 00:08:22,440
EntraDomain Services sits between those two worlds.
176
00:08:22,440 --> 00:08:25,960
It gives Azure workloads and managed Windows domain when they need older Active Directory
177
00:08:25,960 --> 00:08:29,240
behavior, but Microsoft runs the domain controller side of it.
178
00:08:29,240 --> 00:08:33,440
You use the domain for Azure VMs and older apps without taking on the full job of running
179
00:08:33,440 --> 00:08:35,920
a traditional Active Directory domain yourself.
180
00:08:35,920 --> 00:08:37,720
Think of it as a filing cabinet system.
181
00:08:37,720 --> 00:08:40,880
EntraID holds the main employee record for cloud work.
182
00:08:40,880 --> 00:08:44,840
That's where the company keeps the working record used for Microsoft 365 and modern cloud
183
00:08:44,840 --> 00:08:45,840
sign-ins.
184
00:08:45,840 --> 00:08:50,080
Domain Services gives older Azure apps a compatible copy of the records they need.
185
00:08:50,080 --> 00:08:54,200
Those apps can open the familiar type of filing cabinet and find users, groups, and sign-in
186
00:08:54,200 --> 00:08:56,600
details in the old format they understand.
187
00:08:56,600 --> 00:08:59,320
You don't need to rebuild the app just because it moved into Azure.
188
00:08:59,320 --> 00:09:02,000
A cloud-only company can use this setup too.
189
00:09:02,000 --> 00:09:05,120
Imagine a company that has never run local domain controllers.
190
00:09:05,120 --> 00:09:10,040
Everyone signs into Microsoft 365 through EntraID and the business starts using Azure VMs
191
00:09:10,040 --> 00:09:11,480
for an older Windows app.
192
00:09:11,480 --> 00:09:15,840
That company doesn't need to build an on-premises Active Directory domain just for that app.
193
00:09:15,840 --> 00:09:20,200
Instead, it can use Entra domain services for the Azure VMs that need domain behavior,
194
00:09:20,200 --> 00:09:23,400
while the rest of the company keeps using EntraID for normal cloud work.
195
00:09:23,400 --> 00:09:25,600
A hybrid company has a different starting point.
196
00:09:25,600 --> 00:09:30,520
It may already run Active Directory in its office with users and groups that sync into EntraID.
197
00:09:30,520 --> 00:09:34,480
Those people can then appear in Entra domain services for workloads that run in Azure.
198
00:09:34,480 --> 00:09:35,960
The flow looks like this.
199
00:09:35,960 --> 00:09:40,840
The company's existing Active Directory sends identity details to EntraID and EntraID provides
200
00:09:40,840 --> 00:09:43,360
the compatible copy to domain services.
201
00:09:43,360 --> 00:09:47,000
That doesn't mean domain services replaces the original on-premises domain.
202
00:09:47,000 --> 00:09:51,480
The office may still need its own Active Directory domain for local PCs, local servers, factory
203
00:09:51,480 --> 00:09:54,560
systems, or applications that remain on site.
204
00:09:54,560 --> 00:09:58,560
Entraid domain services only handles the Azure part where managed old-style domain behavior
205
00:09:58,560 --> 00:09:59,560
fits the workload.
206
00:09:59,560 --> 00:10:02,360
It doesn't turn EntraID into full Active Directory either.
207
00:10:02,360 --> 00:10:04,960
EntraID remains a cloud identity service.
208
00:10:04,960 --> 00:10:09,520
Domain services adds a managed domain for certain older needs, but it doesn't give you
209
00:10:09,520 --> 00:10:14,400
every option and every level of control you'd have when you run Active Directory yourself.
210
00:10:14,400 --> 00:10:16,120
So picture three separate jobs.
211
00:10:16,120 --> 00:10:18,520
EntraID handles modern cloud signings.
212
00:10:18,520 --> 00:10:21,720
Active Directory handles the Windows domain your company runs itself.
213
00:10:21,720 --> 00:10:26,320
The domain services handles legacy Azure workloads that still need a Windows domain without asking
214
00:10:26,320 --> 00:10:27,880
you to run the domain controllers.
215
00:10:27,880 --> 00:10:30,880
With those jobs clear, you can ask a much better question.
216
00:10:30,880 --> 00:10:35,360
When does domain services fit the workload and when should you choose something else?
217
00:10:35,360 --> 00:10:38,040
When domain services fits and when it does not.
218
00:10:38,040 --> 00:10:40,000
Start with the app, not the product name.
219
00:10:40,000 --> 00:10:44,360
If an older app uses LDAP, that's an old language for checking user names and passwords,
220
00:10:44,360 --> 00:10:47,400
and you're moving it to Azure, domain services can be a great fit.
221
00:10:47,400 --> 00:10:51,160
The app keeps using what it already understands without forcing a full rewrite.
222
00:10:51,160 --> 00:10:54,560
It matters when the app still works, the business needs it and rewriting the sign-in code would
223
00:10:54,560 --> 00:10:56,480
cost too much time or money.
224
00:10:56,480 --> 00:11:00,840
Another common scenario, a group of Azure virtual machines need to act like normal domain
225
00:11:00,840 --> 00:11:01,840
computers.
226
00:11:01,840 --> 00:11:05,440
Staff might need to sign into Windows with their work account, servers might need a service
227
00:11:05,440 --> 00:11:09,760
account, an account and app users to connect to another system like a database.
228
00:11:09,760 --> 00:11:13,640
You might need group policy to apply company settings to those virtual machines.
229
00:11:13,640 --> 00:11:18,200
In those cases, domain services gives the Azure machines the domain behavior they expect.
230
00:11:18,200 --> 00:11:19,800
Remote desktop services fits here too.
231
00:11:19,800 --> 00:11:24,120
Imagine employees connecting to shared Windows desktop or apps in Azure.
232
00:11:24,120 --> 00:11:29,040
Those systems often depend on a Windows domain for user sign-in and computer management.
233
00:11:29,040 --> 00:11:32,840
Domain services provides that domain layer without your team building domain controller virtual
234
00:11:32,840 --> 00:11:34,240
machines from scratch.
235
00:11:34,240 --> 00:11:36,520
Older apps often have more than one part.
236
00:11:36,520 --> 00:11:39,840
There might be a web server at the front, an app server in the middle and a database at
237
00:11:39,840 --> 00:11:40,840
the back.
238
00:11:40,840 --> 00:11:44,920
The app server needs to prove its identity before the database accepts a connection.
239
00:11:44,920 --> 00:11:48,560
When that trust relies on Windows service accounts, domain services keeps those connections
240
00:11:48,560 --> 00:11:50,120
working after the move.
241
00:11:50,120 --> 00:11:51,120
Here's the thing.
242
00:11:51,120 --> 00:11:55,760
Your team gets the older domain behavior the workload needs while Microsoft handles the
243
00:11:55,760 --> 00:11:59,640
domain controller work that would otherwise sit on your server list.
244
00:11:59,640 --> 00:12:02,240
But don't pick domain services just because you're using Azure.
245
00:12:02,240 --> 00:12:05,120
A new cloud app should sign in directly through Entra ID.
246
00:12:05,120 --> 00:12:09,400
If it supports modern sign-in methods, it sends users to Entra ID, gets back proof of
247
00:12:09,400 --> 00:12:14,200
the sign-in and benefits from cloud access rules and multi-factor authentication.
248
00:12:14,200 --> 00:12:16,360
That's the cleaner path for new software.
249
00:12:16,360 --> 00:12:19,200
Entra ID and services helps an app that speaks the old language.
250
00:12:19,200 --> 00:12:21,640
It's not a reason to teach new apps that old language.
251
00:12:21,640 --> 00:12:24,640
There are also hard limits you need to check first.
252
00:12:24,640 --> 00:12:28,640
Some apps don't just read from Active Directory, they write back into it, for example.
253
00:12:28,640 --> 00:12:33,040
An app might want to create or change directory entries as part of its normal work.
254
00:12:33,040 --> 00:12:37,040
Domain services doesn't fit when the app requires LDIP right access.
255
00:12:37,040 --> 00:12:40,560
The same warning applies if an app needs to change the Active Directory schema, the
256
00:12:40,560 --> 00:12:43,760
set of fields that define what the directory can store.
257
00:12:43,760 --> 00:12:46,960
The older software asks you to add its own fields before it runs.
258
00:12:46,960 --> 00:12:49,840
A managed domain doesn't let you change that underlying design.
259
00:12:49,840 --> 00:12:53,400
You should also pause if your team needs full control over the domain itself.
260
00:12:53,400 --> 00:12:56,160
Maybe you need direct access to domain controllers.
261
00:12:56,160 --> 00:12:59,320
Maybe you need domain admin rights which give very broad control.
262
00:12:59,320 --> 00:13:02,680
Or maybe you need a complicated directory design that you want to build and run your own
263
00:13:02,680 --> 00:13:03,680
way.
264
00:13:03,680 --> 00:13:08,520
That points toward running Active Directory yourself, either on-premises or on virtual machines
265
00:13:08,520 --> 00:13:09,520
in Azure.
266
00:13:09,520 --> 00:13:13,120
Domain services deliberately gives you less control because Microsoft runs the core domain
267
00:13:13,120 --> 00:13:14,120
service.
268
00:13:14,120 --> 00:13:16,760
So ask one plain English question before you pick a path.
269
00:13:16,760 --> 00:13:21,320
Does this workload need old Active Directory language or can it speak modern-entra ID?
270
00:13:21,320 --> 00:13:23,240
If it can use modern-entra ID, start there.
271
00:13:23,240 --> 00:13:27,480
If it needs old domain behavior but doesn't need you to own every part of the domain, domain
272
00:13:27,480 --> 00:13:29,200
services may fit very well.
273
00:13:29,200 --> 00:13:33,320
And if the app needs to rewrite the directory, change its schema, or give your team total
274
00:13:33,320 --> 00:13:35,680
domain control, it needs a different home.
275
00:13:35,680 --> 00:13:38,280
Choosing a managed domain means accepting a trade-off.
276
00:13:38,280 --> 00:13:41,560
Microsoft takes care of the domain controllers and you give up some of the control that comes
277
00:13:41,560 --> 00:13:43,440
with running them yourself.
278
00:13:43,440 --> 00:13:45,760
The managed service trade-offs you need to know.
279
00:13:45,760 --> 00:13:50,480
That managed approach saves work, but it also changes what your IT team can control.
280
00:13:50,480 --> 00:13:53,820
Microsoft runs the domain controllers, keeps them in sync, applies patches and handles
281
00:13:53,820 --> 00:13:55,640
availability behind the scenes.
282
00:13:55,640 --> 00:14:00,120
You don't need to plan where each domain controller sits or recover one after a server failure.
283
00:14:00,120 --> 00:14:01,800
That's why many teams choose it.
284
00:14:01,800 --> 00:14:05,800
But you can't remote desktop into those domain controllers and you don't get domain admin
285
00:14:05,800 --> 00:14:09,320
or enterprise admin rights because those would give control over the parts Microsoft
286
00:14:09,320 --> 00:14:10,320
manages.
287
00:14:10,320 --> 00:14:14,520
Instead Microsoft provides a group called EntraDomain Services Administrators.
288
00:14:14,520 --> 00:14:18,200
Put the people who need to manage the domain into that group, then use a management virtual
289
00:14:18,200 --> 00:14:20,360
machine joined to the managed domain.
290
00:14:20,360 --> 00:14:24,800
From that machine, you can use familiar Active Directory tools to manage what Microsoft allows.
291
00:14:24,800 --> 00:14:28,200
For example, you can create your own organizational units or OUs.
292
00:14:28,200 --> 00:14:31,720
Think of them as folders for domain objects like computers or service accounts.
293
00:14:31,720 --> 00:14:33,120
You can manage DNS records.
294
00:14:33,120 --> 00:14:35,920
You can create and apply group policy for supported settings.
295
00:14:35,920 --> 00:14:39,360
You can also manage the computers that join the domain, which is often the main reason
296
00:14:39,360 --> 00:14:40,680
the service exists.
297
00:14:40,680 --> 00:14:41,880
These limits are on purpose.
298
00:14:41,880 --> 00:14:45,840
You can't add more domain controllers, change the Active Directory schema or treat the
299
00:14:45,840 --> 00:14:49,240
managed domain as a place where changes flow back into EntraID.
300
00:14:49,240 --> 00:14:52,240
So keep user and group management in the source directory.
301
00:14:52,240 --> 00:14:55,560
For a cloud-only company, that source is EntraID.
302
00:14:55,560 --> 00:15:00,120
For a hybrid company, it's the on-premises Active Directory that syncs into EntraID.
303
00:15:00,120 --> 00:15:02,280
This rule prevents a mistake we see often.
304
00:15:02,280 --> 00:15:06,200
Someone sees a user in the managed domain and changes them there assuming it will stick.
305
00:15:06,200 --> 00:15:11,360
But that change won't become the company record in EntraID or on-premises Active Directory.
306
00:15:11,360 --> 00:15:14,200
Keep the managed domain private inside Azure networking.
307
00:15:14,200 --> 00:15:18,520
It should support only the workloads that need it, not become a general company directory.
308
00:15:18,520 --> 00:15:22,880
Limit network access, protect the management machine and give admin access only to people
309
00:15:22,880 --> 00:15:23,880
who need it.
310
00:15:23,880 --> 00:15:25,840
You're choosing a service with guardrails.
311
00:15:25,840 --> 00:15:29,600
Those guardrails remove some work while stopping you from changing the parts that Microsoft
312
00:15:29,600 --> 00:15:31,400
owns.
313
00:15:31,400 --> 00:15:33,480
A simple Azure migration story.
314
00:15:33,480 --> 00:15:37,560
Imagine a finance company running an old app on servers inside their own office.
315
00:15:37,560 --> 00:15:39,640
That app relies on LDIP to find employees.
316
00:15:39,640 --> 00:15:41,440
It uses kerbos when people sign in.
317
00:15:41,440 --> 00:15:44,680
And its server authenticates with a service account to reach the finance database.
318
00:15:44,680 --> 00:15:49,320
The company wants to move both the app and its database into Azure Virtual Machines.
319
00:15:49,320 --> 00:15:52,880
One option is keeping the app connected to the office domain through a VPN.
320
00:15:52,880 --> 00:15:56,400
But then the Azure app depends on that network connection and the local domain controllers
321
00:15:56,400 --> 00:15:57,760
every single day.
322
00:15:57,760 --> 00:16:00,880
Another option is running new domain controller virtual machines in Azure.
323
00:16:00,880 --> 00:16:03,840
It keeps more traffic inside Azure, but adds Windows servers.
324
00:16:03,840 --> 00:16:07,000
The IT team has to patch, monitor, backup and recover.
325
00:16:07,000 --> 00:16:08,520
The team goes a different way.
326
00:16:08,520 --> 00:16:11,200
They're users and groups already sync into enter ID.
327
00:16:11,200 --> 00:16:15,880
They enable intradomain services, connect the Azure Virtual Network and configure the Azure
328
00:16:15,880 --> 00:16:18,360
Virtual Machines to use the managed domain.
329
00:16:18,360 --> 00:16:20,600
After that, they join the app servers to that domain.
330
00:16:20,600 --> 00:16:24,320
The finance app keeps using LDIP, Kerbos and its service account.
331
00:16:24,320 --> 00:16:28,160
The domain behavior it expects now sits right next to the app in Azure.
332
00:16:28,160 --> 00:16:29,440
Microsoft runs the domain controllers.
333
00:16:29,440 --> 00:16:30,560
The company runs the app.
334
00:16:30,560 --> 00:16:33,880
But this doesn't mean every new project should go through domain services.
335
00:16:33,880 --> 00:16:38,400
If the company builds a fresh expense app next year, that app should use enter ID directly
336
00:16:38,400 --> 00:16:40,240
for modern cloud signing.
337
00:16:40,240 --> 00:16:42,240
Domain services exist for that finance app.
338
00:16:42,240 --> 00:16:46,120
Its older design still depends on a Windows domain.
339
00:16:46,120 --> 00:16:50,760
Entra domain services gives Azure workloads a managed Windows domain when Entra ID alone
340
00:16:50,760 --> 00:16:52,880
can't meet their older sign in needs.
341
00:16:52,880 --> 00:16:58,040
Start by listing Azure apps that ask for LDIP, Kerbos, NTLM, Domain Join or Group Policy,
342
00:16:58,040 --> 00:16:59,360
then sort each one.
343
00:16:59,360 --> 00:17:00,920
This is the app for Entra ID.
344
00:17:00,920 --> 00:17:05,480
Keep it on your existing Active Directory domain or place it behind Enter Domain Services.
345
00:17:05,480 --> 00:17:06,600
But watch for one limit.
346
00:17:06,600 --> 00:17:11,120
If the app needs LDIP right access or schema changes, domain services won't work.
347
00:17:11,120 --> 00:17:14,440
For the wider identity picture, continue with the Entra ID Knowledge Nugget.
348
00:17:14,440 --> 00:17:16,040
That's where the cloud reception desk begins.
