Welcome back. In this episode, we're gonna discuss a little bit more about Azure 80 Connect and how we can get our own premises Active director identities into the cloud.
Our objectives include understanding as your 80 connect, looking at some azure 80 connect apologies and then talking about some different authentication methods will round out the episode by looking at how we install as your A D connect and how it incorporates some of the concepts that will be learning in the first half of the episode.
So to start, what is that? You're 80. Connect as your 80 connect is a tool deployed in your data center that is used to synchronize your on premises identities from a traditional active directory environment into your cloud as your 80 deployment. This prevents the need to manually recreate every identity you already have. From on premises to the cloud.
Users and administrators can continue to use their own premises, user names and passwords for accessing new service is found in as your a. D.
Our office 3 65 or Dynamics CR M Online
as your 80 connect is a free tool that is available is a part of your Azure 80 subscription. The goal of Azure A D Connect is to bring your own premises identities to the cloud to create a single user identity for authentication and authorization to both cloud based and on premises. Resource is
one important topic for the exam is to understand what apologies are available for Azure 80 connect. We're gonna cover two and these slides to illustrate some important points.
The first is a single forest single azure 80 tenant here Azure 80 Connect synchronizes one or more domains from a single on premises forest to a single as your 80 tenet
here as your A D connect synchronizes one or more domains from a single on premises force to a single azure active directory in your azure tenant. This topology is the default apology when installing Azure 80 connect and using the express installation option.
An important thing to note here is that you don't need multiple sink servers in order to sink multiple domains from the same forest.
A single sink server can replicate multiple domains as long as they're part of the same forced.
The next apology gets a little more complicated here. We might have multiple on premises force that need to be sink into a single azure active directory tenant. The ideas you might be consolidating multiple on purpose is forced into a single azure active directory. Or this might occur in a merger or acquisition scenario.
Even if a user exist in more than one of the's forest, you can sink them so they have a single identity in the cloud.
The key point here is that all forced use the same azure 80 connects. Think server. The sink server here must be ableto access each force directory servers. It doesn't have to be a part of any of the domains, but it must be reachable from all forest.
The other key point is that you can't use multiple azure 80 connect servers for each forest and sink them all to the same azure active directory tenant.
I've mentioned in the last two to apologies that a single azure 80 connects server is supported to sink to your azure 80 tenant. This doesn't mean you have to rely on a single server in your environment. There is the concept of a staging server. This staging server is a second instance of azure A D connect deployed in your environment.
It will run in parallel with the primary sink server and what is called staging mode
and this mode. The server will record imported objects and synchronize data in its database, but it doesn't actually talk to Azure 80. If you take it out of staging mode, it turns into a regular sink. Sir,
this is useful for high availability and testing. If your primary sink server is taken off line and cannot be recovered, you simply switch the other server out of staging mode in your objects began sinking again.
Now that we've covered the identity part, we need to talk about authentication in order to authenticate. With your new hybrid identity, there has to be a way to use your current on premises password. This is accomplished through three different authentication methods. The first is a password hash synchronization
as your 80 connect will take a hash of a hash of your own promises password
from active directory and stored in the Cloud base as your active directory. Instance. This will allow you to sign into Azure 80. Service is like office 3 65 using the same password. While this could be the primary method of using your own premises password. It can also be used as a backup for
Active Directory Federation Service's, which will discuss later in this episode.
The next option is past their authentication. Here, your on premises password is not stored in the cloud like you are doing with password hash sink. Instead, a pass through agent is installed in your own premises. Data center. When a user enters their username and password to access the cloud resource, say a SharePoint online site,
this agent will pick up the encrypted authentication request for Mazur, a D
user name and password, or then verified by on premises Active directory Domain controller and returns the response to the agent. The agent then returns this response back to Azure A D, which then takes the appropriate action of allowing are not allowing the authentication request. This agent on Lee needs outbound access to the Internet
and doesn't require being placed in something like your *** Z network.
Our third option is Federation.
This is a trust relationship between domains in this case between Azure 80 and are on premises 80 infrastructure. This trust allows for authentication and authorization to each other's resource is what we may think of as your 80 and on purposes as being the same for your organization. They're technically
two separate domains that require establishing this trust relationship
in this model like past their authentication. Thes authentication requests are sent from Azure A D to the federation servers located on premises to verify authentication attempts.
These attempts Congar through Web application proxy located in your DMC, which forced the requests to the Internal Federation servers for verification. Using Federation service is also allow for single sign on or es eso.
You can place rules saying that if you're already on the internal corporate network have already authenticated that you don't need to provide credentials again. To access online service is
A. T. F s and Web application proxy our server roles that could be installed on top of Windows Server
instead of a live demo. This time, I'm just gonna walk through some screenshots of installing azure 80 connect, and we can take some of the concepts we've just learned and see how they're incorporated during the installation.
When you first launch Azure active directory connect, install this first screen, ask if you want to do the express settings, which are for a very basic installation of a single active directory forest. And you're going to be using password hash sink, and you want to synchronize all your attributes and everything in the forest.
It's also going to enable auto upgrade, which means the Azure active directory connects software is automatically updated to newer versions when they become available. In our case, we're gonna click on customize and check out some additional options.
Next we come into installing the required components. You can customize the installation location if you want to put it in a different folder, a drive, and you can also use an existing sequel server. Now, as your 80 Connect needs to store all this information inside of a database
by default, it will install a lite version of Sequel. But this is limited to 10 gigabytes of data.
If you have a large environment or feel you want to store that data off the Azure 80 connects server, you can check the box to use an existing sequel server and connect and use that one instead. You can also select the option to select an existing service count in your environment. If not, will be. Look, creating one later in the Wizard.
Next, you're gonna be choosing your user signing options, and somebody should be familiar. We just discuss them. We have password, hash, sink the past through authentication or federation with a T. F. S. You also have the option to configure federation with being fed aerate third party provider. And we have the option to enable single sign on
next we needed connect our sink server out to Azure A. D. So we can verify and create this trust relationship here. I'm entering in the user name and password of a global admin that is out in our azure 80 tenant.
And I do want to note that my Microsoft account apparently wasn't good enough to be able to put in here. So I had to go create a new global admin account
that I named Jeff admin. And as you can see, we're using our new domain that we verified in the last episode.
Next, we need to choose our own premises directors, Air Force that we want to sink.
In this case, active directory is our only directory type option, and I have selected our new on premises forest ese 300 tech dot com.
When you click on the ad directory button,
you're gonna have the option of selecting a new A D account for the service account or use an existing one and then down below. You need to enter in the username and password for an enterprise admin in order for it to create this account. Once we click okay
and the installation wizard verifies the permissions you can see down below are configured directories that we have now added R a Z 300 tech dot com domain.
Next, The Wizard is just verifying that ese 300 tech dot com is a verified domain out our azure A de domain and down here the bottom. We're selecting the attributes that we want to sink between the two that are users are gonna be using toe log into both. Service is here. We have just user principal names selected.
This next screen gives us the option of filtering out domains and organization and units inside overactive director environment. If we don't want to sink them
in this case, you can see I'm just not going to select the HR organizational unit, and you might want to use this so you don't seek service counts that you may not need up in your azure 80 tenant.
Next, you need a uniquely identify your users, and this get comes into play. When you have more complex environments that you're trying to sink, like multiple forced here, I'm just gonna be selecting. Users are only represented once across all directories, but if you have more directories and users are represented across them, you have to match them up based on an attribute.
Finally, you can choose to synchronize all your users and devices. Or, if you're doing a pilot program
for your azure 80 connect sink, you can synchronize just specific groups inside of your active directory on premises.
Finally, we have some optional features, like If you have exchange on premises, you might enable the exchange hybrid deployment. You can also allow password right back, so if they change their password in the cloud, it come right back to the on premises version as well as group and device right back.
Finally, we're ready to install and configure our azure active Directory Connect server, and I wanted to pause here and show that if this was the 2nd 1 in our environment, we could select the second box to say, Hey,
this one is in staging mode. You're not actually gonna be synchronizing you're just gonna be holding on and waiting out in case our primary one goes down.
Once the configuration is complete, we can then skip out to our azure portal. And if we go back into our
azure active directory tenant and then azure 80 connect, we can see that it now showing that we have a sink status and the last time a sink was performed
following that on the left. In my I t o u, you can see I have a Jeff Brown in a Johnny Appleseed user, and they're now synchronized. And to Azure 80 and our cloud, you can also see the source of where these users came from.
Either Windows Server. I d mean, that came on premises.
My new global admin account that had to create is hosted an azure active directory
than our original Cyberia ese 300 which is a Microsoft account, or M s A.
That does it for this episode. Coming up next, we're gonna dive a little bit into federation and single sign on, and how we can configure those in our new azure 80 tenet.
See you in the next episode.