1. Introduction to Hybrid Identity
So in this video, we’re going to talk about the next section of the course, which is “Implement and Manage Hybrid Identity.” Now, hybrid identity, in the context of Microsoft Azure, is the amalgamation of your on-premises identity. solution with Microsoft Azure. So you might have a Windows Active Directory server installed on your premises, managing your corporate network, your sign-ins from devices, both users and devices, and other objects within your network.
And then the concept is that you can synchronise that with the cloud using Azure Active Directory and Azure Active Directory Connect. So, in this section of the course, we’ll go over these concepts and show you how to synchronise an Azure Active Directory on premises with Microsoft Azure. So we’re going to go through a number of terms here. We can see this in the requirements. Azure Active Directory Connect password synchronization, seamless, single sign on Federation, and AD Connect Health, as well as how to troubleshoot synchronisation errors So the first concept is Azure Active Directory Connect. So this is a network agent that you install that synchronises your on-premises Active Directory with the cloud. As a result, you can select users who also have accounts in Azure Active Directory.
And Ad Connect runs on a regular schedule and keeps those two sources synchronized. So in fact, the on-premises ad is the primary ad. It’s the one that controls the data we used to call the master. And then the Azure ad is just synchronised with that. And any changes that happen on-premises get pushed to the cloud. So it says it synchronises identities primarily. Now, there is a concept called a source anchor, and that is an ID field that is going to uniquely identify an object. You can then map it using the cloud. So it’s not the email address or some other field. It’s an immutable ID that is the unique identifier for every object in your online ad. And so when you’re dealing with what’s called a “single forest,” where it’s just one cluster of machines that’s managing your Active Directory, then you can use something like an employee ID, which you might have and which is unique, or it’s a globally unique identifier that Microsoft provides.
And what you then need to do is verify what’s called a “routable domain.” So you’re going to, as we added a custom domain to Azure Active Directory, want to make sure that when you’re synchronising to on premises, you’ve got something that’s definitely routeable. You’re able to get to it from Azure AD Connect. So the next concept here is what’s called password hash synchronization. And so when the on-premises ad is pushing the identities into the cloud, it’s not actually pushing the actual passwords. I mean, that would be a security issue nonetheless. But what it’s doing is pushing the hashes. So there’s a one-way function that takes the passwords and stores them as hashes. And then, when someone tries to log in, you hash that login field and compare the hashes together.
And then that’s how you verify their identity. So with password hash synchronization, what you’re doing is pushing the passwords into the cloud. And then from that point on, anyone who logs into an application in the cloud, like Office 365 or your own applications, or any of these enterprise applications, doesn’t have to go on premises to check the password. Everything is done on the cloud. So that’s how we’re able to do the logins entirely in the cloud, which is through a process called password hash synchronization. And that’s probably the default setup or the way that you want to do it, unless you need to do something like pass-through authentication or federation. There are other ways to do it, but let’s say the first way is the password hash synchronization. Now the other way to do it is through passthrough authentication.
The concept here is that when someone logs into their account in the cloud, be it Office 365 or any of these enterprise apps, that login is actually passed through your firewall into your on-premises environment. And that on-premises Active Directory is the one that does the checks. So even though the identities are synchronized, the login has to be verified by the on-premises Active Directory. That means that the connection between Azure and your premises has to be active. That means that there are no network errors or any other kind of downtime on your premises that’s going to bring your public cloud applications down as well. So that is an alternative way of doing this, which is called pass-through authentication. The third way of doing identity management in the cloud in a hybrid fashion is called federation. So federation is the concept of basically delegating your identity to a third party.
So we could, for instance, say you have multiple offices and they each have their own authentication methods. So basically, a person tries to log in, and the domain that they’re logging in with is not what your primary Active Directory domain is. That means we need to know who the federation server for this domain is. And so again, as we can see in this diagram, the sign-in gets redirected to what’s called a “proxy,” and the proxy then has a connection to a federation server, which does the sign-in. Now, when we were talking about cloud models such as Google, LinkedIn, or even Microsoft itself, that’s kind of a federation model where that authentication is being done by a third party. And so you can set this up so that it’s being done by a partner. So let’s say you have a trusted partnership with a third-party company, then you can use federation authentication to verify their users with their Active Directory or other authentication server.
Now, single sign-on, as we know, is just the concept of using the same credentials in the cloud that you use on premises. And when your password changes in the cloud, then that’s automatically reflected in the cloud. And we get that through password hash synchronisation and pass-through authentication. However, the seamless nature of single sign-on means that you don’t even have to log in because your local machine has already identified you as an authenticated user, and your credentials are passed to the cloud, where we recognise them as valid. As a result, there is a seamless single sign-on. And so what this requires, of course, is that we can’t use traditional on-premises authentication methods like LDAP through the Internet. We need internet-friendly protocols, and one of those is what’s called a “Radius Server.” We’re not going to demonstrate installing a Radius server in this course, but it is a big concept where if you need to have corporate desktop users’ credentials recognised in the cloud, then you need a way of passing those credentials in an internet-friendly manner, and that would be through a Radius server.
Now, the last concept that we’ll talk about is monitoring this whole setup, because we already identified that as one of the top security concerns. Now, one thing you don’t want is for Auser, who left the company three months ago, to still be able to access their credentials in the cloud because the synchronisation is broken. And so the synchronisation does introduce another vector for attack. And so making sure that that connection is up and notifying people when it isn’t is going to be a relatively big factor. And so there’s a tool called AAD Connect Health. So AAD Connect is the software that synchronises your on-premises ad with the cloud, and AAD Connect Health is what’s going to monitor that connection, make sure that the connection is healthy, and set up a basic alert feature when something is not working.
So let’s say your synchronisation failed for the last 2 hours. Well, somebody needs to be notified about that. So you can basically configure Ad Connect Health. Now, since Ad Connect Health is something that’s running within the cloud, you can basically set various permissions without using role-based access control, and your administrators and other people in the team can be notified and go in there and see what those types of errors are. Now, you are going to need various licenses. We’re going to see this as a recurring theme in this course and in this exam: what is the licence required? So basic password synchronisation comes with AdConnect and does not require a premium license. When you need Federation Services, you’re going to need a P1 license. Licenses are also required for Ad ConnectSync Health health agents.
And the last topic of this section has to do with where you’re going to find errors, and so various attributes do basically raise certain errors. And so when you’re basically doing synchronization, you might find that an identity already exists in the cloud; for instance, the user principal name might already exist. And so it says the attribute must be unique, depending on the type of error you’re going to get. You’re going to have federation errors with proxies, and so those values are required. There can only be one synchronisation to a single proxy, and the premises security identifier must be unique as well. And so these are the types of errors that you’re going to see in error logs when you do these synchronizations. So let’s demonstrate setting up an Azure Active Directory connection synchronisation and see what that’s about.
2. Setup Azure AD Connect
Alright, so in this video, we’re going to set up Azure Ad Connect. Now you can see here that we have an active directory on premises with a couple of users in it. And I can start the installation process for the Azure Ad Connect agent. Now this is a piece of software that we downloaded and are installing. So in order to start, we have to connect our Azure Ad Connect agents to Azure. And so we have to have a user who is an administrative user, at least a hybrid administrator, who can login to Azure Ad and have it recognise the ad on premises.
And now we’re going to synchronise this with the cloud. So now we either have to provide it or we’re going to create a local account that is going to be doing the synchronisation to the cloud. Obviously, that account must have access to the local ad. Now we’re going through the process here—connecting the directory and figuring out exactly which domain is going to be synchronized. And we’ve picked a domain that we have validated in the cloud. Now we only want a certain group to be synchronized. We’re not synchronising the entire directory here. We’ve chosen a cohort called Instructors that is going to be synchronized. And as you can see, we’re using password hash synchronization, and we’re not enabling password writeback as an optional feature, which we could have. So we do have to provide credentials in order to enable these administrative credentials on the local account, of course.
And now we’re ready to go. So this is password hash synchronization. As we saw, we’re installing the software, and we basically have all the information that is required for this to run. Now this software, once installed, is going to run on a regular basis to make sure that any new accounts are synchronised to the cloud and any password changes are captured on the local device and synchronised to the cloud. Since we don’t have a password, rightback enabled is not concerned with password changes in the cloud at all. And probably with this type of thing, you would not enable the self-service password reset in the cloud because you’re not going to even capture those changes back into the local directory. So I’m going to speed this up a little bit because it does take a few minutes, but we can see messages coming across that are saying that it’s doing some configuration and enabling single sign-on. It is getting itself ready to basically install the software. So all of the local ad settings are being configured, and now that it’s doing the installation, it probably has to set itself up to run as an agent. So it’s sort of running in the background. The synchronisation is complete. The installation is complete now. doesn’t mean the synchronisation is complete. We have to give it a few minutes. We do have a very small directory, so it shouldn’t take too long.
And then we hit the refresh button. And now we can see that a couple of users are now listed as being synchronized. As a result, any changes to on-premises passwords will be reflected in these users. And if there are any additional fields, they will be reflected from on-premises to the cloud. Now, we can also look at what’s called Ad Connect Health, which will look at any errors that happen during the synchronization. Right now we don’t have any errors, but this is where they would show up within the portal. So in this video, we were able to install Azure AD Connect on a local machine, synchronize that with our local Active Directory, synchronise that into the cloud, and see that that synchronisation worked and that there were no errors.
