[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 Kim@Contoso.com
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]
