Identity Architecture: PHS and PTA Authentication | Azure Active Directory

Identity Architecture: PHS and PTA Authentication | Azure Active Directory


[MUSIC] Corissa Koopmans: Welcome back to the Azure AD Architecture Deep Dive Series. We get a lot of questions about how Azure AD works under the hood, which we will share with you throughout this architecture series. Ramiro, I have customers who are starting to move to the cloud and want to know how Password Hash Sync authentication works. Can you walk us through that flow? Ramiro Calderon: Sure. Remember the last video we saw the actual synchronization of the hash on-premises domain? We have it here on this slide just for us to remember. So, that was the first use case. Now, let’s see how it works for authentication, which is the second use case. So, let’s start with Kim here. She’s our user. And let’s say that she wants to go to Salesforce, which is configured to use Azure Active Directory for single sign-on, but she hasn’t authenticated to anything yet. So, in that case, Salesforce will say, I don’t know who you are. Go to Azure AD and then Salesforce will redirect the user to Azure AD. Azure AD needs to know first how to authenticate Kim. So, it renders a login page where she can type in her user name, which is what we call an identity lingo, the user principal name or UPN. This is where this diagram starts. Azure AD has a lot of services under the covers that supply services for the different scenarios and today, we have this blue box here, which happens to be the authentication service. This service implements the different authentication protocols and provides credential gathering and credential validation experience for the end user. So, let’s start with step number one. Kim here types her UPN; let’s say it is [email protected] and submits the form to Azure AD. This step right here is what we call Home Realm Discovery (HRD) because it’s Azure AD the way they discover what tenant the user belongs to. With that UPN Kim typed in, the authentication service then queries this core store to find out how she should authenticate with the system here in step number two. In this case, the core store will tell the authentication service that Kim is using the hash that’s stored in the cloud. This is determined by the domain configuration. The domain in this case is @contoso.com. Corissa: This means that all users in contoso.com will use PHS, right? What if my customers are not ready to move all users of the domain at one time and would like to test with a few users first? Ramiro: Well, that’s a very fair point, Corissa. We recently announced a feature called stage rollout, which will allow administrators to onboard a subset of users in the domain to use this configuration. So, the way it works is that here in the HRD stage in step number two, the system will reply with a specific configuration for Kim rather than the configuration of the entire domain. So, in step three the application service renders the username and password in an html form in Kim’s browser. Kim types in the same Active Directory password and she submits the form back to Azure AD, which is a fancy form to say she pushed the button to authenticate. Now, in step four, the authentication service takes a password that Kim typed in and applies the same hashing we discussed in the previous video. So, we take the password, derives the MD4 password hash, then we apply the password key derivation function 1000 times using the HMAC SHA 256. If the computed value is the same as the one that we have in the store, then that means the credential is valid and the authentication service continues the flow, in this case, will generate a token for Salesforce and sends Kim back to the application. Corissa: That’s great, Ramiro, but why don’t I see a domain controller in this diagram? Ramiro: Well, all the flow here happens in the cloud by design. As we can see here, this gives the customers for on-prem glitches or bad performance or flat-out outages, which unfortunately has happened with some of our customers when they are hit by malware, such as Non Petya. The malware sometimes take over like a bunch of domain controllers or all domain controllers, federation service, etc., etc. So, that’s a very important benefit to call out. Another benefit here is scalability. The blue box of authentication services here is deployed in data centers all over the world and the request over here, number 1, is routed to an instance close to the HTTP client location. It is very complex and expensive to have the similar geo load balancing behavior with on-premises federation infrastructure. Corissa: Being fully in the cloud is great, but I have some customers who are not ready yet to turn on PHS, but they really want to move away from on-premises federation infrastructure. One of the actions for them is pass through authentication or PTA. Can you walk through the architecture behind it? Ramiro: I knew that you were going to ask me that, so let’s walk through it. Let’s say we have our friend Bob over here and he wants to file a ticketing service now. So, same deal as the previous diagram, he goes through the app. The app bounces him back to Azure AD and he says, sees the Home Realm Discovery page, and types in the username and password. Corissa: It’s the exact same experience than Kim. Ramiro: Absolutely. You’re right. The user will not see any difference whatsoever. In fact, I literally copy the same three arrows from previous diagram. In the back end, the authentication service now needs to validate a password, but it won’t use the password hash in the cloud. It might not even be there to begin with if they don’t turn on synchronization. This is where the other components come into play. We have here the hybrid agents back end service. And that provides a capability to dispatch work to agents on-prem that do multiple tasks. One of those agents happens to be the password authentication agent. And the way it works is that authentication service puts a request to validate a password in a queue through the hybrid agent back end service. Then the PTA agents, which are likely lightweight Windows services installed on-premises, they have one job and one job only. It’s to pick up those requests from the queue. The message in the queue over here is encrypted using the public key of the agents. And the agent that picks up the work, decrypts the message with its private key. Corissa: This means the agents are now in the critical path for every authentication. How should customers avoid a single point of failure and make these agents highly available? Ramiro: Well, that’s why I put PTA agents, plural; in this diagram, I have two. And the idea is that they load balance automatically. So, you sell another one, then you start picking the log with each other. This practice we recommend deploying multiple agents to have high availability. This agents are very easy to install and after they are deployed, they behave like an appliance. One of the agents picks up the message; it will call the Windows login user Win32 API to validate that the username and password is validated against the domain controller and you’ll get a yes or no answer and we’ll report back to the authentication service. Then after that, the authentication continues and if it’s successful, then authentication server issues a token to Service Now. Corissa: So based on what you told me, this is what I am taking away. PHS as a form of authentication is simple and does not require a complex on-prem infrastructure. PTA is also simple but requires light on-prem infrastructure. It’s a good fit for those customers who want to simplify their federation, but they’re not yet able or willing to synchronize password hashes. And last but not least, customers can do either of these gradually with this new feature, staged rollout. Ramiro: That’s right, Corissa. Corissa: We hope you found this video useful. We’ll be adding more videos on different topics like authentication, provisioning, governance, and many more. If you want to get a copy of the diagrams we used today or want to give us feedback and help us figure out what to cover, please follow the link on the screen. [MUSIC]

Daniel Ostrander

Related Posts

Leave a Reply

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