Azure AD Domain Services is an often misunderstood product
that has specialized use cases as well.
When I first heard of Azure AD Domain Services,
I mistakenly thought this must be a cloud‑hosted AD DS forest,
so we could decommission our local Active Directory forest
or domain and just run it in the cloud.
Well, guess what?
This is not that. It's not. What we've got with Azure AD Domain
Services is a platform for legacy application migration.
You have line‑of‑business applications that run in your local Active
Directory, and we call them legacy because instead of using token‑based
identity federation REST APIs and web services,
we're using things like LDAP binding,
we're using Group Policy objects for server management
because we're running these services on VMs,
these applications on VMs. And importantly, we need to
support Kerberos and NTLM authentication.
Those are not cloud compatible protocols by any stretch.
So here's the pattern. With Azure AD Domain Services, if you want to
give your local Active Directory users single sign‑on or just in the
name of migrating local Active Directory users,
you're going to have to set up account synchronization with Azure AD
Connect into your Azure Active Directory tenant. Then, you'll need to
deploy an instance of Azure AD Domain Services.
Now note that this is a managed domain and not a managed forest. You
don't get forest‑wide scope, so you can't extend the schema like you can
with your local forest. It's a managed domain, and that resource is
embedded into your virtual network. It's actually running on a couple of
VMs that are abstracting, the domain controller VMs that are being
abstracted away from you.
This is a platform as a service. And then the idea is the
identities that are surfaced in your managed domain will come
from Azure AD. So as you can see,
you've got local accounts being replicated into Azure AD, those accounts
being surfaced into your managed domain. And then yes,
indeed,
the idea is you can migrate your workload VMs into the Azure virtual network,
and you can do all of your legacy stuff with Group Policy management, and
LDAP, and Kerberos, and NTLM sign‑ins, and this, that, and the other. That's
the basic what's it of Azure AD Domain Services. High‑level deployment steps
set up in Azure AD Connect account synchronization, this is assuming that you
do want to surface those local AD accounts and not just go cloud only. Then,
as I said,
deploy the managed domain to a virtual network. You'll need to update the DNS
settings and the VNet to point to those two managed domain controllers, and
then you will have to do a bit of work to enable user accounts for Azure AD
DS. And there's some guidance on this.
We don't need to get that deep into the weeds.
I give you some links in the exercise files that basically has to do
with the fact that we need to get the NTLM Kerberos compatible
password hashes into your managed domain. And Azure AD is a REST
API. It's a web service that doesn't have anything to do with those
legacy password hashes.
So there's some, like I said, a little bit of work.
The steps are different, depending upon whether you're doing
cloud first or staying only in Azure AD versus account synchronization with Azure AD Connect.