Hello, Cloud Gurus,
and welcome back for this lesson
where we're going to take a look
at implementing Azure AD Domain Services.
Let's take a look at what we're going to cover.
First up,
we'll cover off some of the important considerations
that you need to keep in mind
when you're deploying Azure AD Domain Services.
And then we'll take a look
at the types of forests you can deploy.
We'll take a look at the special considerations
around password synchronization.
And then we'll finish it off with a bit of a demo,
where we will implement Azure AD Domain Services.
Let's get started.
Now, there are a few important considerations to make
when planning your Azure AD Domain Services deployment.
Firstly, you're going to need to decide
the resource group and the subscription.
And these are important
because you can't change the resource group
or the subscription
for your Azure AD Domain Services domain,
or move the resource group or the subscription
that the Azure AD Domain Services domain is deployed to.
So choose a subscription and resource group
that will not change
after you've deployed Azure AD Domain Services.
You're also going to need to provide the domain name,
and that domain name can't be changed after deployment.
Now by default,
Microsoft will provide an onmicrosoft.com domain,
like you receive with Azure AD,
but it's not recommended to use this name.
Instead, use a unique routable domain name that you own.
And routable just means
that it can be found using recursive DNS.
So not a .local domain.
It also must be less than 15 characters long,
and much like you choose a subdomain
for your on-premises Active Directory domain,
consider using a separate unique subdomain
for Azure AD Domain Services.
You will also need to select a virtual network and subnet
that your Microsoft-managed
domain controllers will be deployed to.
This virtual network cannot change
once you have deployed Azure AD Domain Services,
and Azure AD Domain Services domain controllers
cannot be moved to a different subnet or virtual network.
Like all virtual networks,
always use a private IP address space to avoid conflicts
and choose a range
that has at least 5 available IP addresses.
You can also choose to put other workloads
in the same subnet as Azure AD Domain Services,
but it can be more complex to manage.
You're also going to need to decide a forest type,
and there are are 2 to choose from,
and they both have very different implementations.
They are user forests and resource forests
and we'll dive deeper into each of these choices up next.
And there are 3 different SKUs to choose from:
They are Standard, Enterprise, and Premium,
and Enterprise and Premium are designed
to provide support for more users and simultaneous logons,
but they also provide additional backups
and the addition of resource forests.
So what's important to know about the SKU?
Well, you can't have a resource forest on the standard SKU
and you need a premium SKU for daily backups.
All right, now let's take a look at the types
of Azure AD Domain Services forests that you can deploy.
Now, it's important to remember
that with both types of forests,
Azure VMs are joined directly
to the Azure AD Domain Services managed domain.
But there are some significant differences
in the way users are authenticated
and groups and users are synchronized.
The first type of forest is a user forest,
and a user forest works by synchronizing your groups,
users, and their passwords from the Azure AD tenant
to your Azure AD Domain Services managed domain,
and these include users from your on-premises domain
and those users created directly in Azure AD.
And users authenticate directly
against the Azure AD Domain Services domain
using the same username and password
that they use on-premises.
And Azure AD Domain Services authorizes them
to access resources based on their group memberships
or directly assigned permissions.
And the alternative is a resource forest.
With a resource forest,
you grant access by creating a one way outbound forest trust
from Azure AD Domain Services
to your Active Directory Domain Service's
on-premises deployment,
and this trust allows users to authenticate
using their on-premises domain credentials.
And it does not require password hashes to be synced
because the on-premises domain is used for authentication.
And because the on-premises domain
is used for authentication,
smart cards and certificates can be used.
And with this configuration,
only cloud users are synced to Azure AD Domains Services.
And on-premises domain users are not synced.
It's worth mentioning that users can authenticate directly
against Azure AD Domain Services
when using a resource forest,
but as only cloud users are synced,
this is intended for administrative purposes only.
With a resource forest,
authorization is performed by Azure AD Domain Services
using the trust relationship,
and the trust requires a VPN or ExpressRoute connection
between the virtual network
that your Azure AD Domain Services deployment
is deployed to
and the network that your on-premises domain controllers
are deployed to.
All right, now, let's take a look
at the special considerations
around password synchronization
and Azure AD Domain Services.
For user forests,
Azure AD Domain Services requires
password hash synchronization
from your on-premises Active Directory to Azure AD,
and for resource based forests,
only your cloud users are synced,
so password hash synchronization is not required.
But passwords in Azure AD,
which are either synced or stored directly in Azure AD,
are not stored in clear text
or stored in a way that can be used to generate
the NT LAN Manager, NTLM,
or Kerberos compatible password hashes.
Once you enable Azure AD Domain Services for your tenant,
Azure AD will start to store passwords
in a compatible format for NTLM and Kerberos.
Because of this,
your cloud users that only exist in Azure AD
will need to reset their passwords
before they can use Azure AD Domain Services,
and this can be achieved by requiring all users
to change their password at next logon.
And they can use something
like self-service password reset to complete the change.
Once they have reset their password
Azure AD will generate a Kerberos,
and optionally, an NTLM compatible hash,
and provision the user in Azure AD Domain Services.
And for your on-premises,
Active Directory Domain Services users,
which are referred to as directory synced users,
you will need to update
the Azure AD Connect password hash synchronization,
so that NTLM and Kerberos compatible password hashes
are sent to Azure AD,
and Microsoft provides a script to do this,
and we'll take a look at this in the demo.
Now there's no need to reset the passwords
for your on-premises Active Directory users.
Their user accounts will be created in the managed domain
when their password hashes have been synced to Azure AD,
but it is important to point out here
that Azure AD Connect cloud sync is not supported
when using Azure AD Domain Services.
All right, let's take a look at a demo
of implementing Azure AD Domain Services.
We already have our Active Directory Domain Services domain
deployed on-premises,
and it's currently synchronizing our users to Azure AD,
and is configured to sync our password hashes to Azure AD
using password hash sync.
In this demo,
we will create a managed Azure AD Domain Services domain,
named az.barrierreefaudio.com.
And we will configure it as a user forest.
We'll use the standard SKU.
And we'll deploy it
to an existing subscription, virtual network, and subnet.
And to do this, we need to be a member
of either the Application aAministrator
or Groups administrator,
Azure AD roles in the Azure AD tenant,
and we need to be assigned
the Domain Services Contributor role,
or a more privileged role in the Azure subscription.
And then we will expire our cloud-only user password.
So new NTLM and Kerberos compatible password hashes
are generated,
and then we will update the Azure AD Connect synchronization
to synchronize compatible password hashes
for our on-premises users.
Let's take a look at the demo.
All right, here we are on the Azure portal
and we're going to go ahead
and search for Azure AD Domain Services,
and then we'll select the option
to create Azure AD Domain Services.
And then we're going to go ahead
and select an existing resource group
for our Azure AD Domain Services instance,
but you could create one if required,
and now we're going to provide a DNS domain name
for our domain.
Now it's not best practice
to use the default Microsoft domain.
So we're going to go ahead and use a subdomain
of our company's domain name, az.barrierreefaudio.com.
And we're going to go ahead and use the standard SKU
as we don't require the scalability
or the features of Enterprise or Premium.
And we're going to go ahead and use a user forest,
and then we can go ahead and click Next.
And now I've already created a virtual network
for our Azure AD Domain Services domain controllers.
So I'll go ahead and select that.
And I've already created a subnet
in the virtual network for the domain controllers.
So we'll go ahead and select that
and then we can go ahead and click Next.
Now, you'll want to add members
to the AAD DC Administrators Azure AD group,
but we're going to do that in an upcoming lesson.
So we'll go ahead and click Next.
Now you can set the scope
to only synchronize selected users or groups,
but we're going to sync all of the users and groups.
So we'll go ahead and select Next.
Now you can secure Azure AD Domain Services
by changing some of the security settings from the default.
So I'll go ahead and set TLS 1.2 Only Mode,
disable NTLM Password Sync.
We'll make sure Password Sync from On-Premises is enabled,
and we'll disable Kerberos RC4 Encryption
and enable Kerberos Armoring.
I'll include a link to some details
on how you can harden Azure AD Domain Services
in the resources for this lesson.
All right,
we don't need to configure any additional settings
so instead of clicking Next,
we'll go ahead and click Review and Create.
And this will just take a moment to validate,
and then we can go ahead and click Create.
And it provides us with a warning
about the items we can't change
once we've deployed Azure AD Domain Services,
and we're aware of this,
so we'll go ahead and click Okay.
And this will take quite a while to deploy.
So we'll come back when this is done.
All right, the deployment is now complete.
So let's jump over
to our Azure Active Directory Connect server
where we will expire our cloud-only user passwords
and then we'll update
the Azure AD Connect sync settings
to synchronize our NTLM and Kerberos compatible passwords
for our on-premises Active Directory Domain Services users.
All right, so here we are on our Azure AD Connect server.
And we're going to go ahead
and use the Azure AD PowerShell module
to expire the password for one of our cloud-only users.
First up, we'll go ahead and install the Azure AD module.
So I'll just select that line and then select Run Selection
and this will just take a moment to install.
So we'll come back when this is done.
All right.
And then we're going to import the Azure AD module.
And then we need to go ahead and connect to Azure AD.
So I'll just select that and run that line.
All right.
And we need to log on with credentials
for a user that has permissions to update user passwords.
So I'm going to go ahead and log on with a user account
that has those permissions.
All right, we're now successfully authenticated
to Azure Active Directory,
and now we're going to go ahead
and set a temporary password for the user,
so that we can use that when we update their password
and force them to change their password.
So I'll go ahead and select line 11,
and then select Run Selection,
and now I'm going to provide a temporary password.
And now I'm going to go ahead
and use the Get-AzureADUser PowerShell cmdlet
Aad I'm going to search for just one user,
who's a cloud-only user, and that's Adam Bevin.
And then we're going to use
the set Azure AD password PowerShell cmdlet,
and we're going to set a temporary password for Adam,
and then we're going to force him
to change his password at next log on.
So I'm going to select this line and then hit Run Selection.
All right, now, Adam Bevin's password has been expired
and he'll need to change his password at next logon.
Now let's go ahead and update the Azure AD Connect,
password synchronization settings for our on-premises users.
To do that, we first need to navigate
to the Azure AD Connect Synchronization Service
and collect some information.
So I'll select Start,
and then I'll select Azure AD Connect,
and then I'll select Synchronization Service,
and then we just need to grab some information
from the Connectors tab.
So I'll select the Connectors tab,
and the information that we need to run the script
that's provided by Microsoft is
the 2 names for these connectors.
The first is the Azure Active Directory connector name.
And the second is
the on-premises Active Directory connector name.
So we'll grab both of these names
and then we'll put them in the script
that Microsoft provides.
All right,
and we need to provide the Azure AD connector name
and the AD connector name.
And these are case sensitive,
so make sure you provide them exactly as displayed
in the synchronization service.
And then we can go ahead and run this script
to update the password hash synchronization settings.
So I'll go ahead and save the script,
and then we'll go ahead and run the script.
All right,
and the password hash synchronization
has been successfully updated,
and I'll provide a link to this script
and the resources for this lesson.
All right.
That concludes this demo.
Let's go ahead and wrap up with a bit of a summary
of what we've covered in this lesson.
All right.
So what have we covered in this lesson?
It's important to choose a unique, routable domain name,
containing less than 15 characters
for your Azure Active Directory,
Domain Services managed domain.
It's also important to remember
that network connectivity is required
when you're using
an Azure AD Domain Services resource forest.
And you need to choose a non-standard SKU
if you want to deploy a resource forest,
and password hash synchronization is required
for Active Directory Domain Services users
when using an Azure AD Domain Services user forest.
And finally, it's important to remember
that Azure AD Connect cloud sync
does not support Azure AD Domain Services.
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.