[MUSIC]
Martin Coetzer: Hi, there. My name is Martin Coetzer. I’m a
Program Manager in the Microsoft Identity team. I’m here
to talk about how you can get started with Hybrid Identity
in Azure Active Directory. The story of Hybrid Identity
starts and ends with Azure AD Connect. In this video, I’m
going to cover all the details of moving your identities to
the cloud.
First, I’m going to set the scene with an overview of Azure
AD Connect and its requirements. Next, I will cover all the
sign-in methods that are available in Azure AD. After that,
I will explain the details of identity synchronization, custom
configuration options, and then I’ll leave you with some
online resources to learn more.
Azure AD Connect is a tool that helps you to synchronize
your identities that’s on-premises in your current AD
environment to Azure AD in the cloud.
Azure AD in the cloud then provides single sign-on
capabilities, multi-factor authentication, and even self-service
capabilities for your end users. But Azure AD Connect is a
tool that copies the users from your on-premises AD to the
cloud. So, this is really your identity breach to get the same
users into the cloud so that they can use the resources
in them.
So, let’s cover the prerequisites of Azure AD Connect.
Azure AD Connect requires forest functional level 2003 or
higher. This is typically not a problem for most organizations
because Windows 2003 is no longer supported, and you
may be running much later versions of Windows Server.
Keep in mind that this is a setting that you have to change
manually on your domain controllers and a lot of customers
don’t; they just upgrade their domain controllers, so this
may be something that you need to do. We also only
support writeable domain controllers. Read only domain
controllers are not supported because we have to also
write back to the domain controllers. And, obviously, we
won't be able to do that if it’s an auto DC. The server itself
needs to run on Windows Server 2008 or later. And if you're
going to use the express settings, that machine needs to
be domain joined as well. Password hash synchronization,
which I will cover later in this presentation, requires Windows
Service 2008 R2 Service Pack 1 or later. And then password
writeback requires Windows Server 2008 with the latest
Service Pack or later as well. The good news is with ports,
you only need outbound connections. Azure AD Connect
connects to Azure and it uses the default SSL ports that
everybody uses. Port 5671 is required if you’re going to use
the Azure AD Connect out features that gives Azure AD
monitoring updates of your environment and tells you if
your synchronization infrastructure is healthy.
In terms of licensing, Azure AD Connect is a free product
that you can use to synchronize your identities. You can
use it to synchronize for Office 365 so that you can have
an Exchange hybrid deployment. But some features, for
example writeback, requires Azure AD Premium. This is
a special license that you have to buy. Group licensing as
well as the connect health requires Azure AD Premium.
And then in some cases, you may need to have a full SQL
Server version and we’ll cover that. But in that case,
you’re also going to need a special licensing for that server.
This is our Azure AD Connect sizing recommendations.
Keep in mind that we are talking about objects. It’s not
just users. So, objects includes users, groups, as well as
devices. So, you have to add all of those objects together
to determine the sizing of your Azure AD Connect server.
The big difference here is when you’ve got over 100,000
users, you have to get a dedicated SQL Server. We still
recommend that you run SQL Server on the same server
so that you don’t have any latency between the sync engine
and the database. But in this case, you have to also look
at maybe running something like solid state disks, so that
you have really fast access on your databases.
If you have less than 100,000 users, you can use SQL Express,
which is a free version of SQL that works with Azure AD
Connect and it doesn’t require any additional licensing.
The easiest way to setup Azure AD Connect is with express.
This is for smaller organizations that don’t have multiple
forests, will use the SQL Express installation because they
have less than 100,000 objects in their forest and they
don’t want to do any custom installation options. It’s only
four clicks. And so you basically just setup Azure AD Connect
and you forget about it.
When you setup Azure AD Connect with customized settings,
you have the option to setup multiple forest topologies,
also specify a separate SQL Server. You also have the option
of filtering users so that you don’t synchronize all your users.
You have the option of setting up a staging mode server,
which is a standby server in order for you to failover to
if your primary server goes down. You can also setup other
sign-in methods, for example, federation or passthrough
authentication, and then you can also enable the optional
features like writeback and also synchronize custom
attributes.
So, custom settings are really for more complex organizations
that want to ensure that it also caters for the environment.
But smaller organizations will just go with the express
settings.
So, let’s talk about sign-in methods. Azure AD Connect is
the tool that configures the sign-in methods. This is the
way your users will sign into Azure AD.
We support basically two types of sign-in methods that
can be broadly put into these buckets. On the one side,
we have cloud authentication and on the other side,
we have federated authentication. With cloud authentication,
it means that the authentication happens in the cloud in
Azure AD. In here, we cater for cloud only users, which are
not hybrid identities. This means that you’ve only created
the users in the cloud. Or password hash sync, which means
you’ve synchronized password hashes from your on-premises
Active Directory or passthrough authentication, which uses
that agent on-premises to verify passwords. On the other
hand, you can use federated authentication. Federated
authentication includes options like Microsoft AD FS, a tool
that Microsoft supplies, as well as third party federation
providers. In this case, if you have a third party federation
provider and you want to integrate it with Azure AD, you
can use federated authentication.
So, you may ask me, which one is the correct one for me?
So, I’ve highlighted an article that you can go and look at.
It’s aka.ms/auth-options, which will actually give you a
breakdown of each one of these—the benefits, why you
should choose it, and what is the correct one for your
organization.
In that article, we provide you with a decision tree that will
ask the most important questions and then actually
recommend a sign-in method for you, but I want to just
explain each one of them.
So, the first one you have is password hash synchronization.
The way this works is the Azure AD Connect server reads
the password hash from Active Directory. It then hashes
that same password 1,000 times with a new hash and
moves that or copies that to Azure AD. So when a user
wants to sign-in, the Azure AD System will run the
password that the user provides through the same algorithms
and it will then verify if those hashes are the same. And if
they are the same, the user will get access to the application.
But if they’re not the same, then that authentication request
will fail. Keep in mind that there’s no dependency on Azure
AD Connect when the user signs in. The hashes will be
already in the cloud. Every time a user’s password is updated,
Azure AD Connect polls the Active Directory and it will update
Azure AD to make sure that the passwords are up to date.
It does this every two minutes.
Other features of users, for example, updating of the
telephone numbers or other user attributes will only happen
every 30 minutes. So if you disable a user, that can take up
to 30 minutes before the user is disabled in Azure AD. We
do recommend if you’re going to do a lot of disables and
do some sort of bulk operation that you go ahead and force
a synchronization cycle so that those users are immediately
updated and disabled in Azure AD.
Another option that you can run with password hash sync
is seamless single sign-on. The way this works is you actually
give your users a seamless single sign-in experience when
they are connected to your corporate network and they
have access to your domain controllers. During setup, Azure
AD Connect will go and create a disabled computer object.
And then when the user signs in and you’ve given the
computer access through a group policy to the sign-in page
as a trusted website, that sign-in page will go and check if
it can verify that the disabled computer account using
Kerberos authentication. If that succeeds, it means the
user was able to authenticate using his username and
password, and this also happens seamlessly in the background.
The user is not prompted for a password.
So, this means that the user will have a great experience
signing into Office 365 or other SaaS applications that uses
Azure AD for authentication. If it doesn’t work, then it’s not
going to be a big problem; it’s not going to throw an error
for your users. It will just fall back to the normal mechanism
of asking the user to specify a username and password. So,
this is a great way to give your users a good experience.
Our next option is pass through authentication. Passthrough
authentication works with running agents on-premises.
These agents make outbound connections to Azure AD,
so you don’t need to open up any firewalls to the PTA agents.
And any password request will then be delivered to those
agents via that open channel to the PTA agents. The PTA
agents will then connect directly to the domain controllers
to verify the username and password. So, this is a great
way to make sure that any password policy that you’ve
implemented on your on-premises Active Directory is always
honored when the users sign in. So, for example, if you
setup a user to only sign in during the day—they’re not
allowed to sign in after hours—the PTA agent when the user
authenticates will fail because the user’s not allowed to sign
in a that time—after hours—and, therefore, the user will not
gain access to their resources in the cloud. The PTA agent
is a nice way of making sure that your users will always have
that great experience of making sure that they pass with
policy or the sign-in experience is similar to what they have
in Active Directory.
Our last option for sign-in method is federation authentication.
A lot of customers already have AD FS servers or AD FS
infrastructure or another type of federation system, and they
may want to reuse that infrastructure. In this case, when
a user signs into application, Azure AD will know that this
user is a federated user and then will redirect the user to
the federation system. In most cases, that will be a federation
proxy form in your perimeter network, which will then
authenticate the user and send the request back to the
federation system on-premises that will do the validation
in Active Directory.
Keep in mind that in this case, you need multiple servers
to make sure that you have high availability, you need to
open up firewalls for the old users to be able to connect to
those servers. And you also need to have SSL certificates
to make sure that those connections are secure.
Users that are on-premises will actually connect to the
AD FS servers internally and they will use Windows
integrated authentication for the authentication process,
so they will also have a single sign-on experience.
This is a lot more complex installation and is needed for
some customers that need to do very advanced features,
like for example smart card authentication. Smart card
authentication will be handled by the AD FS system and
will allow users with smart cards to authentication if that
is a requirement.
Most users or most organizations can actually just do
password hash sync, and that is the easiest way and the
best way, the less complex way for you to handle authentication
in the cloud.
Now that we’ve covered authentication and sign-in methods,
let’s talk about how are we going to implement our
synchronization in Azure AD?
So, the first thing that you need to do is you need to
identify which users are you going to synchronize in your
organization? Now, this is normally not a problem for most
companies because you only have one user in your AD,
which will be one user in Azure AD. And you just want to
synchronize that one user. The lifetime of that user is
dependent on the lifetime of the user in AD. So if you delete
the user in AD, you want the user to be eventually deleted
in Azure AD as well.
In some cases when users can move between forests, you
have to think about this more clearly. And you want to
make sure that you actually track the way the user is
copied form one forest to another forest, if you’re going to
do a migration on-premises or something like that. So, you
have a few options here. You can go and choose mail
attribute. So if the mail attribute of the user is the same
between different forests, it means that you want to track
the user through mail attributes. You can also use MS
objectGUID and so on to make sure that those users
are tracked in that way.
So, the purpose of this is to make sure that you don’t
accidentally delete users when the users disappear in
your Azure AD. So, there’s a couple of options. Traditionally,
we chose objectGUID. ObjectGUID was a way for you to
make sure that the users are unique every time you create
them. But the problem with objectGUID is when you clone
a user to another forest, it will create a new objectGUID.
So, there’s no way of actually making sure that it’s still the
same user.
Now, we actually use a different attribute called the ms-DS-
ConsistencyGUID, which will allow you to track the user
across different forests. The way this works is initially that
attribute will be null. So, there will be no value in that
attributed. And then when Azure AD connects to that user
the first time, it will actually populate that GUID from the
objectGUID and then when you clone the user from one
forest to another forest, attribute’s already populated and
it will know that it’s the same user and it’s not going to
remove the user in Azure AD and create the new user in
that case because it’s just the same user. You can also use
other attributes, for example, employee IDs, but don’t use
something like email addresses or user account names,
user principal names because those can change. Sometimes
people change their names or they change their last names
and you want to make sure that any of those changes is not
going to cause you to create the new user. You want those
users to always be joined or matched during the lifetime of
the property of the identity.
Another important decision is user principal name. If your
organization created a domain called something like
Contoso.local, you actually created a domain that you
don’t own. Azure AD doesn’t allow you to have a domain
that you didn’t own. So, in that case, you have to go and
register a domain that you own with your local Active
Directory so that the usernames are valid in the cloud as
well. So, we recommend that you register a new suffix
that you own and then populate each user with that
username value that is a domain that you own. In this
case, you have to go and tell your users that these are
your new usernames. Maybe you make it the same as
the email address and then it will be easier for them to
remember the username when they sign into applications in
the cloud. So, this is an important thing that you have to
ensure works. Azure AD doesn’t support other accounts like,
for example, same account name. This is a domain/username
format. It doesn’t support it. You have to specify user
principal name, which looks like an email address. So, make
sure that you use that standard in your environment.
If you have multiple forests, you have to make sure that
your company effectively using multiple forests as well.
We see a lot of different ways people have multiple forests.
In some companies, forests are detached. This means
every user in every forest is a valid user. There’s no
duplicates of users in different organizations. So, if there’s
a Mary in one forest and a John in another forest, you want
both of them to also exist in Azure AD. Some companies
take that principle one step further and they actually
implement a solution called GALSYNC, or global address
list synchronization. What this does is it creates contacts
for every user in other forest so that every forest does
have a complete global address list of the organization.
The problem is you don’t want to go and create contacts
for all of those contacts that exist in every forest because
that will just duplicate all the users and it will be confusing
because now there will be a Mary user mailbox. There will
be a Mary contact object for every forest that you
synchronize. So, in this case, you want to tell Azure AD
to ignore or to actually match that user with the user
in the other forest and only create one object in Azure AD.
And this is something you can do with Azure AD Connect.
Another paradigm that we see is the account resource
forest model. This is for companies that actually have
dedicated forests for services. So, they may have a
dedicated forest for Skype for Business or maybe even
Lync, or they may have a dedicated forest for Exchange.
So the way that usually works is you have a disabled user
in those resource forests and those disabled users points
through to the account forest in other domains. And,
again, you don’t want to create duplicate users in Azure
AD. You want to tell Azure AD Connect to match those
users and only create one user in Azure AD. And that way,
it enables you to make sure that you have the lifecycle
under control of those users.
So, let’s look at how Azure AD Connect addresses those
requirements. The first option is to do no matching. This is
where you have multiple forests and you don’t have any
duplication between those multiple forests, so every user
in every forest will go to Azure AD. The next option is to
actually go and look at the mail attribute. So, this will look
at the email address of the user. And this is typical where
you have GALSYNC in place. So, we’ll see that this is the
same user in another forest because the email address is
the same. So, it’s not going to recreate that user. It will
just match them and create one object in Azure AD.
Our next option is to look at the ObjectSID of the primary
user and the MS Exchange master AccountSID or Exchange
or the msRTCSP-OriginatorSid for Lync or Skype for Business
users. So, those objects are referred to the original
account forest and when Azure AD Connect sees that it’s the
same SID in those attributes, it will again only create one
object in Azure AD or one user.
You can also match on other objects, for example,
sAMAccountName. This is typically in cases where you are
doing a migration from one forest to another forest and
you’re going to keep the same username, then you can
match them as well. And in some cases, you may even
want to match on other attributes as well. And this will make
sure that you don’t duplicate users and handle your perfect
multi-forest scenarios.
Our next topic is custom configuration settings. Custom
configuration settings allows you to go and extend the
functionality of Azure AD Connect or to do something
different than it normally does with express settings.
So to look at our options, the first option that you have is
to configure filtering. Filtering is a way of not replicating
all your users in your forests to Azure AD. You may want to
do this because you are currently running a POC or there
might be some objects that you just don’t want in the
cloud. Your options are, firstly, to do group based filtering.
How this works is you specify a group and only the
members of that group will be synchronized to Azure AD.
We recommend that you only do this for test labs or
POCs. It is actually quite taxing on the Azure AD Connect
server to go and look at the group membership of all
those users and to make sure that they are valid and
they should be synchronized. So, this is something that
you only want to do temporary while you’re doing a lab
or you’re doing a POC.
A next option is to do domain based. This works well and
maybe you have a configuration where there are certain
domains that are dedicated to management of services or
they are dedicated to other spots of the business and you
don’t want those users in the cloud. And so, you would just
unselect a domain and those users will not be synchronized
to the cloud.
Another way of doing this is with organizational units. You
can unselect certain organizational units. Maybe there’s some
organizational units that contains administration accounts or
service accounts, and you don’t want those accounts to be in
the cloud because they’re only used in your on-premises
services. So, you can actually just exclude them.
Keep in mind if you exclude any of these users, it will
sometimes cause undesired effects. Users that use Exchange
on-premises might see a larger global address than users in
the cloud. And you don’t want to confuse your users. So, be
careful on choosing how you’re going to filter users.
Another way of filtering is by using attribute filtering.
Attribute filtering is a way of selectively going and making
sure that some users are not synchronized. When you
use this method, it’s sort of a fine grained method of
excluding some users in OU. So if you want to exclude
specific users, but you don’t want to move a user out of
an OU, you can set up attribute based filtering and it will
then filter that user or not synchronize that filter if it
contains a specific attribute value. This is a nice way of doing
that fine grained filtering required in some organizations.
Let’s look at some other optional features that are available
in Azure AD Connect. Azure AD Connect allows you to also
synchronize your Exchange hybrid configuration. This is a
mechanism required for Exchange to live in a hybrid
environment where you have some users on-premises and
some users in the cloud and in Exchange hybrid, it tells
Azure AD Connect to also synchronize the attribute that is
required for Exchange hybrid components. Similarly, with
Exchange mail public folders, you want to synchronize those
or not as well if you’re running Exchange. Then you can
also setup your Azure AD Connect to do application filtering
as well. And you can also if you chose federation or passthrough
authentication, enable password hash synchronization on
top of federation and PTA. Now, you may ask why do I want
to do that? I decided to do federation or I decided to do
passthrough authentication, but you’re giving me another
option to do password hash sync. The reason why we do this
is to actually give you the ability to have a backup
authentication method for your users. Say, for example,
your federation system goes down. Something happened
to your network or you are a victim of a cyber attack
and it took down all your infrastructure. Now, your AD FS
system is down and users cannot authenticate and
basically your users cannot send emails. They cannot
connect.
If you have password hash sync enabled on top of
federation and this is where you do it, then you can actually
switch over to password hash synchronization in that
disaster moment and then allow users to authenticate
using password hash synchronization and carry on working.
Just imagine it’s a disaster and you can use your corporate
email and continue working. This could be a great benefit to
your organization.
Another benefit of using password hash synchronization
on top of federation or passthrough authentication is for
leaked credential detection. This is a feature of Azure AD
Premium P2 identity protection. And the way this works is
we go ahead and find any leaked credentials on the internet.
If there’s a leaked credential on the internet that we acquired
maybe through working with law enforcement companies,
we can go and take those passwords and run them through
the same algorithms and alert the administrator or the user
that the password is leaked. We know that sometimes users
use the same passwords with the corporate credentials as
well as with other websites where they register for social
media and so on. And if a site gets compromised, your
company can also be compromised because users use
the same password. So with leaked credential detection,
we can actually prevent that and we could block users or
force them to change their passwords next time they sign in
if their passwords were found leaked.
We also allow you to do password writeback with optional
features as well as group writeback and device writeback.
So, let’s talk about why would you want to do this. Password
writeback is for companies that want to deploy the self-service
password management capabilities of Azure AD. This is a great
way of allowing your users to go and change their password if
they forget their password by first verifying their identity
through something like the Microsoft Authenticator app or
through another email system. This is a great way of actually
cancelling out all the social engineering that can happen,
maybe if a hacker calls your help desk and they are really
difficult with the help desk, they might convince your help
desk to change a password for a user. But if you provide this
mechanism, they’re not going to convince the system to
change their password because it will verify the identity.
Group writeback is also required for if you want to synchronize
Office 365 groups as modern groups to your on-premise
environment. So, this allows you to email those groups for
any users that are still in the on-premises environment and
using Exchange.
And then finally, device writeback is for users that do an
Azure AD Join only and you want to synchronize those
accounts back to your AD environment so that you can
consider that device as part of an AD FS authentication
process, so device writeback will do that.
You can also set up an Azure AD Connect server as a
staging server. This allows you to have a backup server
if your primary server goes down. In this way, if your
primary server goes down, you can switch it over to your
Azure AD Connect staging server and carry on synchronizing
users to the cloud. Keep in mind that it’s not that important
to make sure that your Azure AD Connect synchronization
happens all the time, but if you want to make sure that your
Azure AD Connect system doesn’t get out of date, then we
recommend that you have a staging server. When you set
up a staging server, you set it up with the same configuration
that reads everything from your Active Directory system and
it doesn’t synchronize this to the cloud. It’s just there
waiting for that event to happen and then you enable the
server and you can go ahead and make sure that those
users stay synchronized.
So, once you’ve installed your Azure AD Connect system,
you have this final option to say whether or not you want
immediately synchronize. Some organizations want to make
sure that everything is set up perfectly, the schedules are
fine-tuned before they’re synchronized, or maybe they
want to wait until that evening to start the synchronization
process. So, this is your chance to say I want to synchronize
immediately or if you untick this box, you can synchronize
later.
When we setup Azure AD Connect, you have the option to
actually go and make sure that users are not deleted
immediately if it’s more than 500 deletes. You can disable
this feature if you regularly delete more than 500 users
in your Active Directory, but this is a safety mechanism
to make sure that if maybe you move users from one
organizational unit to another organizational unit, they
are not part of your scope that you filter and those users
disappear from the scope, that you don’t accidentally delete
them from your environment. So, this is something that
you may have to fine tune in your environment depending
on how many users do you delete on a daily basis.
I mentioned in the beginning that Azure AD Connect updates
every 30 minutes for users, so it only syncs changes, but it
does it only every 30 minutes. Password changes are done
every two minutes. But you can go and look at the schedule
with PowerShell on the Azure AD Connect server with the
command Get-ADSyncSchedule. You can also change this.
So if you have a large organization that have a lot of changes,
maybe you want to change your delta sync to only happen
once an hour. Or maybe you want to not run during certain
times, so this is a way of making sure that your sync cycle
is according to your requirements.
Azure AD Connect now also supports auto upgrade. If you’ve
upgraded a previous server or if you’re still running an
old version, you may not be doing auto upgrades. And so,
I would recommend that you go and look at the
Get-ADSyncAutoUpgrade status on your server to make
sure that it’s actually running. This is making sure that
your service is running the latest bit and it’s doing all the
new functionality that are available to our customers.
You can also look in the application event log if that is
happening on your system.
So, finally, I want to leave you with some resources. I
mentioned that authentication method article. In there,
we explain all the different authentication methods that
are available to you that will help you choose the right
authentication method. We also have an article that
explains Azure AD Connect performance factors. This
article goes into all the different details and all the
configuration options in filtering and why certain settings
are important and why certain settings will impact your
sync cycle. So, you can use that article to go and make
sure that you are optimized in your environment. If I’ve
convinced you to move to password hash sync or to
passthrough authentication, I actually do have whitepapers
available that will take you through the process of moving
AD FS to password hash sync, so check out those articles.
Then we also have the Azure AD blog, where we announce
all our product features and we also announce all sorts of
other new tidbits and interesting information to our customers.
And please sign up for our webinars. You can reach out to
that URL to find webinars.
Well, I hope you’ve enjoyed this session and you learned
about hybrid identity and thank you for watching.
[MUSIC]
