Yuma 4×4

Media and Communications

Azure AD Pass-through Authentication and Seamless Single Sign-on

Azure AD Pass-through Authentication and Seamless Single Sign-on

Coming up, we take a look at a new way of
how you can harness the power of cloud authentication while still keeping your passwords on-premises using Azure Active Directory pass-through authentication and
seamless single sign-on capabilities. We’ll show you how Azure AD can now
validate securely your passwords against on-premises Active Directory all without the need for expensive on-premises infrastructure and automatically sign
your users in while they’re at work. Microsoft Mechanics I’m joined today Swaroop from the Azure
Active Directory team, welcome. Thanks for having me on the show. So lets start with pass-through authentication. So is it fair to think of this as an
authentication bridge? Yes that’s fair but the big thing here is with the
release of this bridge, any company small or large can now
adopt cloud authentication. So that’s a pretty bold statement but what do you actually mean by that? Sure the control plane for security and access control is moving from the network layer to identity. That’s why more and more of you are
using Azure ad not just for user sign-in but for other things such as password
management in the cloud, group based assignments to applications, publishing on-premises applications to the cloud, conditional access policies and so on. Now with pass authentication,
you get all of that but you get to keep your
passwords on-premises. They don’t need to leave your internal
organizational boundary. it requires zero management and it’s free to use. So it’s easy to use,
it’s secure, scalable, authentication. But, can you show us what the experience
actually looks like? Sure I can do that. So here I am on the
standard Office 365 sign-in screen. I’m going to sign in using the same credentials that I used to sign in to on-premises applications. And I’m in. Although this looks like a
straightforward sign-in experience what’s happened is behind the scenes pass-through authentication has
successfully validated my password against my on-premises active directory in real time. So let me show you how this experience
gets even better this time by combining pass-through authentication with a new seamless
single sign-on capability. Here I am signed into my domain join machine. And I’m going to try to access my
on-premises and cloud applications using the application access panel. When I get to the Azure AD sign-in page,
notice that I don’t have to enter my username or my password to sign in, I just get in. Wow, so you didn’t have to enter your username or password you were just in. How did all of that work? Did you have to do anything special there? Well we had to do
a few things to set it up. But Azure AD now talks Kerberos. That’s the big thing. Great so I imagine it’s also pretty important for a lot of organizations watching that are concerned about security and compliance and maybe not
able to synchronize their passwords to the cloud. It’s also great that as a user you don’t
have to remember two sets of passwords to maybe access your on-premises
network and cloud applications. But how does this all
differ then for people that use Azure AD today? Azure AD always had a wide range
of authentication options. Some of you use directory
synchronization to sink just user names from on-premises Active Directory to the cloud. But that means you have to manage separate passwords in the cloud. we also have password hash sync which lets you securely sync password hashes from
on-premises to the cloud. that works really well for many of you. In both these cases,
authentication happens in the cloud. If you wanted authentication
to happen on-premises your primary option was to use Federation with AD FS. But this needs additional infrastructure
and network configuration on-prem. It works great if you’re trying to support other diverse forms of authentication beyond password. Such as smart cards and third party multi-factor authentication providers. Having said that, if you want to manage
passwords on-premises without implementation complexity then pass-through authentication is
the best option for you. It gives you the full power of Azure AD cloud authentication and it’s full feature set. And lets you do it in a low-cost secure
and scalable way. without the need for
any additional on-premises hardware. So let me know show you how pass-through authentication works. We start by installing a light weight on-premises agent on the same server as Azure AD Connect. We recommend that you install additional agents on other servers to get high availability of sign-in requests. You can install these agents on
domain controllers too, for example. These agents require zero management
and will auto update. When the user enters the username and password, on the Azure AD sign-in page our servers actually encrypts the
passwords using a public key and then places the username and
encrypted password on a queue for validation. One of your agents on-prem makes
an outbound call from your network to retrieve the username and encrypted password. So that must mean it’s using a listening mechanism for outbound https calls over port 443. That means there’s no inbound calls
coming through the firewall? Yes that’s right. So actually what happens next is the agent decrypts the password using a
private key that only it has access to and tries to validate it against the
on-premises active directory. Now the result of this which is returned by the
domain controller, success or failure is returned back to the agent which then
forwards it up to Azure AD. Azure AD then decides what to do with it. If multi-factor
authentication is enabled the user is challenged for it. If not the users just
signed into the application. So you really are then building a
bridge basically that goes between your on-premises
infrastructure and the cloud. And as you showed the experience gets even better using seamless single sign-on. But, how did that work? So let’s take the use case of a user
on a domain join machine inside the corporate network to
try to access a cloud application. During setup, Azure AD connect creates a computer account representing Azure AD inside your on-premises Active Directory. Now when the user visits the Azure AD sign-in page, we use JavaScript to request for a Kerberos ticket for the computer account. This users machine having line-of-sight
to the domain controller lets it acquire the Kerberos ticket. Now the ticket includes the identity of the user and is then forwarded up to Azure AD. Azure AD reviews that ticket and
decides what to do with it. And if everything looks good it signs the user in silently. No password is required and you
didn’t need to do Azure AD join. This works on Windows 7,
Windows 8 devices, even Macs. And across all major browsers. Let me show you how this setup experience works. Here I’m running Azure AD connect. When I run the wizard I should make sure to choose the custom installation pod instead of express settings. At this point we end up installing a few
of our required components for sync. We’ll get to the user sign-in page in a second. When you get to the user sign-in page, you need to choose Pass-Through Authentication. And, check this box to enable seamless single sign-on. Of course I still need to finish all my directory synchronization steps as before. So this will be familiar if you’ve run this tool before. For example in this case I’m connecting up to the WOODGROVE.ONLINE Active Directory using my enterprise domain credentials to actually start the sync configuration process. Then I figure out how users sign into Azure AD
by choosing the UPN. And then I figure out what kind of
domains and OU’s I want to sync. And basically just select the default
settings for other options. However, when I get to the Optional Features page I need to make sure that
the password synchronization is disabled because you don’t want password
hashes flowing into the cloud. Now it is at this stage that Azure AD
Connect uses my domain admin credentials to actually create that computer account
representing Azure AD that I talked about when we were talking about seamless
single sign-on. And finally at the end of the wizard this is when we get ready to install the pass-through authentication agent, enable the two features on the tenant, and also configure all of the sync that is required to make this work end-to-end. Okay so it’s just about completed there
it looks like. So those are all Azure AD connect settings. Anything that I need to do then on my endpoint outside of these server-side settings? Yeah, that’s a great question. So to allow Azure AD to actually
receive Kerberos tickets, what you need to do is you need to use Group Policy to push two new Azure AD URLs
to your users internet zone settings. So here I’m actually using
my Group Policy management editor. I’m trying to set up the site to zone
assignment list and enabling that policy. As part of enabling that policy, you see
that I’ve entered these two new Azure AD login URL. These are the same URLs for
every customer. And Value 1 there represents the internet zone. All right so now all this is running as a service. Is there anything that I need to
do in terms of monitoring this in the Azure portal? Yeah, so to verify that everything looks good you can actually go into the Azure portal. Click on the Azure AD connect blade and check that the two features
are showing up as enabled. You can click on the pass-through authentication link here to check the status of the agent
that we just installed. Great so this seems really
straightforward. But, is there anything else I need to
know about with this solution? As I said before installing additional agents gives you high availability out-of-the-box. All on-premises Active Directory actions such as disabling users and
setting user logon hours. For example for retail workers,
they are immediately enforced. We also protect your on-premises Active
Directory accounts by filtering out brute force password attacks in the cloud. This is the feature that’s on by default for all customers. So really having Azure AD is the control plane with password management, conditional access, auditing, identity protection. All of this is really powerful with keeping
passwords on-premises. But, what is the team working on next? So looking ahead, we want to make it even easier to deploy pass-through authentication. So things like setting it up from the Azure portal instead of Azure AD connect. And also providing admins rich sign-in
reports and health information about the agents on-prem. Really great new technology and
great overview, Swaroop. Where can people go to learn more if they want to set this up on their sites? Pass-through authentication and seamless single sign-on are both pre-features. They are now generally available to
all Azure AD customers including all Office 365 customers. You can learn more by visiting the links below. Thanks for joining us on the show. And don’t forget to keep watching Microsoft Mechanics for the latest tech updates across Microsoft. That’s all the time we have for this show,
Goodbye for now. Microsoft Mechanics www.microsoft.com/mechanics

9 thoughts on “Azure AD Pass-through Authentication and Seamless Single Sign-on

  1. How is the Outlook Client Experience using Seamless SSO with Pass-through Auth ? Does It works for non-domain join Machine ?

  2. I wish it was more clear if you can use Microsoft MFA and this technique. I keep seeing conflicting notes on this. I understand 3rd party MFA but can you use MS MFA and this AD Connect SSO?

  3. On the same lines as Michel Dumont, we used password hash sync for user sign in. Instructions say you can use Password Hash sync with SSO. However later on in the video it says you don't want to pass hashes to the cloud. Can you add some clarity to that?

  4. Hi Guys, Thanks for this video. I'm currently facing a dilemma. I set up SSO via AD connect and all works fine. But i created a scenerio where i turned off my on premise servers and after a few minutes i keep getting prompts to enter my password for office365 on my mobile device and on my laptop as well. Please what could the issue be. I enabled password sync but this is really strange. I thought password sync enables cloud storage of passwords so i can login to O365 even when my on premise server is down

Leave comment

Your email address will not be published. Required fields are marked with *.