Explore AuthN and Azure AD and when to choose which option.
- [Instructor] That sign-in prompt that we saw when we looked at how end users signs into Azure Active Directory has a number of different ways that can actually work under the covers. There's about five different ways that you can actually configure Azure Active Directory Connect end users sign in. And which one you choose, I really going to depend on a lot of your business and technical requirements. We'll talk a little bit about what those are. The first option that's really simple, and this is great if you're a small business or you have no on-premises infrastructure, is actually what's called Cloud-only Authentication. And what happens there, if you think back to our architecture discussion, where we had Azure AD Connect and Active Directory on-premises, we take the on-premises Active Directory completely out of the picture, and we make Azure Active Directory authoritative for your users and passwords.
They means they typically only exist in Azure Active Directory. And if, like I said, if you're a small organization, this probably could work great for you. But if you're a larger business or an enterprise, chances are that's not going to scale so well, and the rest of the options are really targeted towards how do we solve that scale problem, and we look at these in the order of simplicity. The next option is something called Password Hash Synchronization. When people hear that, they start to freak out because they think, I'm sending my passwords to the cloud, what if they get compromised, what is something bad happens there, then someone could use that to compromise an on-premises system.
In reality, what happens here, is Azure AD Connect takes the password hashes from your on-premises Active Directory, and it rehashes those, and then synchronizes them into Azure AD. So already, we're not dealing with the actual end user's password, the clear text password because we're taking up password hash, and then we're taking that password hash, and we're re-hashing it and sending it to Azure Active Directory. At this point, when an end user goes to sign in, they'll use their User Principal Name, which is probably similar to their email address, and then they'll use the same password they use to sign into other applications and systems on their network, and Azure AD will check that against that re-hashed password hash.
This is great from a simplicity perspective. We don't need any additional infrastructure outside of Azure AD Connect to support this. But some people might not like this because users have to sign in again. And one of the Holy Grails of getting all this working is how do we get to single sign-on, where the user only has to sign in once or at least as few times as possible. To do this, there's another feature in Azure AD Connect that we can combine with Password Hash Synchronization called Seamless Single Sign-On. And what happens with Seamless Single Sign-On is if I'm on a domain join computer, I'm either on the network or I have line of sight to the domain controller, when I go to the Azure Active Directory sign-on page, rather than having to enter my username and password again, under the covers, it uses Kerberos, the same protocol that you're used to with your on-premises Active Directory, to authenticate you to Azure Active Directory and sign you in without prompting you for credentials again.
If you're off the network or you don't have connectivity, in case, you'll still be prompted, you'll just re-enter your username and password, much like you typically would if you're connecting remotely to a company asset. Now, the next option is something called Pass-through Authentication, and Pass-through Authentication solves the problem where you just can't bring yourself to synchronize those password hashes. Maybe you have compliance concerns, maybe you have security concerns, maybe you're just not quite there yet in terms of your readiness for the cloud. But you want to have the minimal amount of infrastructure necessary to support your cloud identity environment.
To do that, with Pass-through Authentication, you'll have at least one, preferably two agents that run on servers on-premises. Those agents will make an outbound connection to Azure, a tunnel if you will, and any time someone wants to connect or log in to Azure Active Directory, they'll enter their username and password. But instead of Azure validating that locally, using the password hash, it'll encrypt that username and password, send it back to the Pass-through Authentication agent, and the Pass-through Authentication agent will validate it with your on-premises Active Directory.
If it's valid, it'll let Azure know, you'll be able to sign in, and likewise, if it's invalid, it'll let Azure know, and you won't be able to sign in. The advantage here is that you have minimal infrastructure, you have a lightweight agent called the Pass-through Authentication agent, and you don't have to sync your password hashes to Azure Active Directory. Now, of course, you still want Single Sign-On 'cause with just Pass-through Authentication, you'll have to re-enter your username and password to sign in to Azure AD. So you can combine that same Seamless Single Sign-On feature we talked about with Pass-through Authentication as well.
If you're on the network, Kerboros will sign you in, we won't have to re-enter your credentials. If you're off the network, you'll re-enter your credentials, and it'll be securely sent to the Pass-through Authentication agent to validate those with your on-premises Active Directory. The final option is called Federation or Federated Authentication. Federation is the heaviest option, if you will, of all the options that we have to talk about here. With Federation, you'll use products like Active Directory Federation Services or a Federation platform from a third party, whether it's on Ping, for example, it's a really common third-party option.
With Federated Authentication, when you go to sign in to Azure AD, as soon as you enter your username, your User Principal Name, you'll be redirected back to the Federation provider, which typically you run on-premises, of if you're running in the cloud in an IaaS environment, that Federation product will be responsible for authenticating you, and then it creates a token that's sent securely via HTTPS back to Azure AD to discern that you really are who you say you are. Now, the advantage with Federated Authentication is it can get you very close to Single Sign-On because, typically, a lot of different applications in your enterprise are all connected to that Federation platform.
You sign in once, and then you're signed in to all those applications, and of course, you don't have to synchronize password hashes to Azure AD either. The downside is, there's a whole lot of infrastructure that you typically have to run in order to support these Federation tools, and if the Federation system is offline, you won't be able to sign in to Azure AD, which means Azure AD will effectively be offline for you as soon. So there's a whole bunch of different choices here in terms of how you sign in to Azure AD. I typically try to go for simple whenever I can. So I really like Password Hash Synchronization, with the addition of Seamless Single Sign-On.
But if synchronizing password hashes is just something that you're not going to be able to do, Pass-through Authentication can keep this simple, while removing the need to synchronize those hashes.
- Authentication options with Azure AD
- Configuring Azure AD Connect for sync and authentication
- Securing remote access with the Azure Application Proxy
- Managing apps and devices with Intune
- Building and deploying a basic Intune policy for iOS or Android
- Protecting data beyond the firewall with Azure Information Protection (AIP)
- Configuring AIP classification labels and protection
- Integrating Exchange and SharePoint with AIP
- Managing risk with Advanced Threat Analytics
- Connecting Office 365 to cloud app security