Good day, Cloud Gurus, and welcome back.
In this lesson, we're going to take an introductory look
at Active Directory Domain Services on Azure.
Let's take a look at what we're going to cover.
First up we'll take a look at the options
for deploying Active Directory Domain Services on Azure.
Then we'll explore one of those options
being Azure AD Domain Services,
and then finally we'll explore the alternative,
which is Active Directory Domain Services
on Azure Virtual Machines.
Let's get started.
We've already spoken about how you can extend
your Active Directory Domain Services identities
to Azure using Azure Active Directory and Azure AD Connect,
and we already spoke about the advantages of Azure AD
and how it supports cloud-based authentication protocols.
But at the same time,
we also mentioned some of the limitations of Azure AD
and some of those limitations include functionality
that is natively supported
in Active Directory Domain Services,
including Kerberos authentication, NTLM authentication,
and support for LDAP, lightweight directory access protocol.
And if you have these requirements,
you have a couple of options
to support this functionality in Azure.
The first option is to deploy Azure AD Domain Services.
Azure AD Domain Services
provides two Microsoft-managed domain controllers
in a new ADDS forest
in a virtual network and subnet of your choosing,
and Microsoft configures an automatic, one-way,
background synchronization of identities
from Azure AD to Azure AD Domain Services.
And it's important to point out here
that this synchronization is one-way,
from Azure AD to Azure AD Domain Services.
Another important point to make here
is that you can actually create users and groups
in each of these directories.
Active Directory Domain Services supports the creation
of users and groups, as we've already covered,
as does Azure AD,
and Azure AD users are referred to as cloud-only users,
and you can even create users and groups
directly in Azure AD Domain Services.
But Azure AD Domain Services
also support synchronizing identities
from on-premises Active Directory Domain Services
using Azure AD Connect Sync.
And you can synchronize user accounts
to provide authentication
in both the on-premises domain
and the Azure AD Domain Services domain
using the same username and password combination,
despite them being separate forests,
which will feel a little odd,
but it does improve the user experience.
The second option is to deploy domain controllers
on Azure Virtual Machines
and use Active Directory replication
to replicate between the domain controllers.
As you would expect,
there are some significant differences between 2 options.
Each option has its own advantages and disadvantages,
and the way you implement each of these
is quite different too.
Let's take a high-level look at each of these options
and then we'll dive into each of these
in more detail later in this section.
Firstly, let's take a look at Azure AD Domain Services.
And let's first take a look at the advantages.
With Azure AD Domain Services
you get a separate Microsoft-managed
Active Directory Domain Services forest
deployed in an Azure virtual network.
And because the domain controllers are Microsoft-managed,
you don't need to manage or update those domain controllers.
And because replication of AD objects,
like users and groups is done via Azure AD
to Azure AD Domain Services,
you don't necessarily need a VPN connection
between your Azure AD Domain Services virtual network
and your on-premises network.
And because it supports domain join,
you can domain join your Azure VMs
to the Azure AD Domain Services managed domain
and use Active Directory to authenticate
and authorize access to resources,
and you can also use group policy
to push configuration settings
to those Azure virtual machines.
Now group policy is something
we haven't spoken too much about
but we'll take a very good look at it in the next section.
But despite these advantages,
there is a fairly long list of limitations
with Azure AD Domain Services.
Let's go through them.
Firstly, as you don't have access to Enterprise Admins
you can't extend the schema.
So any applications requiring a custom schema will not work.
You're also limited
to one managed Azure AD Domain Services domain
per Azure AD tenant.
And because you don't have access to domain admins,
you can't deploy additional domain controllers or domains.
But in a multi-region Azure environment
you can deploy a replica set,
which is used to deploy
additional Microsoft-managed domain controllers
to additional Azure regions
connected with virtual network peering.
Now, as we mentioned back in section 2,
normally you can organize your objects
in Active Directory Domain Services
into a tree structure.
But with Azure AD Domain Services, by default,
you get a flat structure within the database.
You can create a structure as required,
but users and groups will be synchronized
to the top of the structure.
There's also limited support of synchronization
with Active Directory Domain Services on premises.
As the synchronization traffic flows through Azure AD,
you lose some other information like SID history,
the structure of your Active Directory environment,
SYSVOL replication, and group policies.
And there is also limited support
for some group policy features,
which we'll cover in more detail in the next section.
You also cannot change the passwords
in the Azure AD Domain Services managed domain,
as the automatic background sync is one way,
you will need to change your passwords
either in Azure AD
or Active Directory Domain Services on-premises.
If you change the password for a synced user
it will be out of sync in Azure AD
and Active Directory Domain Services on-premises.
You also cannot perform lightweight,
directory access protocol, or LDAP, write operations,
which will limit the compatibility of some applications.
And finally, you cannot authenticate directly against
Azure AD Domain Services,
with certificates or smart cards.
Only the usernames and passwords are supported,
and I know that's a pretty decent list of limitations.
So why would you choose Azure AD Domain Services?
Typically you'd choose Azure AD Domain Services
if your organization is cloud first
and doesn't have
Active Directory Domain Services on-premises
or is looking to move away
from Active Directory Domain Services,
but still has some applications
that depend on Kerberos, LDAP, or NTLM.
All right, now let's take a look
at Active Directory Domain Services
using Azure Virtual Machines.
You can deploy a private connection
between your on-premises network
and your Azure virtual network,
using either a VPN or ExpressRoute,
and then you can deploy
additional domain controllers
for your existing domains and forests in Azure.
And this will extend your domain to Azure.
You get full support for Active Directory replication,
including replication of the Active Directory database,
it's structure and objects,
and you get full replication of SYSVOL and group policy.
And with this configuration
you would configure an Active Directory site
for each of these locations.
One for your on-premises site
and another for your Azure Virtual Network
to ensure that your computers
can locate a domain controller close to them,
and you can control replication
between your on-premises network
and your Azure Virtual Network.
And you can still deploy Azure AD Connect,
either on-premises or in Azure
to synchronize your identities to Azure AD.
With this option, you get more flexibility and capability
but that is at the cost of having to deploy
and manage the additional domain controllers
and the network connectivity.
And there are some gotchas
for domain controllers
when deployed to Azure virtual machines.
And we'll cover those off towards the end of this section,
so hold tight.
All right, let's take a look
at what we've covered in this lesson.
Active Directory Domain Services provides Kerberos
and NTLM authentication
and LDAP functionality that is not provided by Azure AD.
Azure AD Domain services
is limited to one managed domain per Azure AD tenant.
Synchronization to Azure AD Domain Services
is a one-way replication from Azure AD
to the Azure AD Domain Services managed domain,
and passwords cannot be changed in Azure AD Domain Services.
Instead, you should change them using something like
self-service password reset
or you can change them in the on-premises
Active Directory Domain Services forest,
and Active Directory Domain Services on virtual machines
requires network connectivity
between on-premises
and Azure to enable Active Directory Database
and SYSVOL replication.
All right, thanks for being with me in this lesson
and I hope you found it useful.
And I look forward to seeing you in the next lesson.