Before starting this topic, I need to tell you that I am planning to have a video in which I talk about the Password Through Authentication, so since that is the case, I am not going to talk on how PTA works. But instead, this post is going to be how PTA is related with Kerberos.
As you know in Active Directory, main authentication protocol and the one who is in charge is Kerberos. If you have not yet read how Kerberos works, you can refer to this video I created earlier (it is a 60 minutes video on how Kerberos works) and get an idea of how Kerberos works. Just for people who are not interested to watch that, I will just simplify the process here.
When a client wants to access a server, a share trough RDP, SMB or whatever, the client should be authenticated to Active Directory and obtain a TGT. Once he is authenticated, he can present his TGT to other servers to obtain access token for them. If it is hard for you to understand imagine that you are going to a park. Before entering the park, you need to obtain a ticket. That ticket will only let you enter the parc. If you do not hold that ticket; you cannot enter the park. Once you are in, for each game, you may need to buy separate ticket because that first ticket was only for entrance (Not DisneyLand). Here, the first ticket is TGT and the second tickets which we buy for each game is called TGS.
You may ask yourself what is the relation between PTA and Kerberos here? The answer is they are completely dependent. Because, with PTA, you basically direct all the authentication request from cloud to On-Premise domain controllers and once we talk about on-premise, it is Kerberos involved. The point here to know is, for Kerberos to work, SPN is necessary. So how someone in cloud can request a ticket when SPN is not know for him? The key point here is, in PTA, the request is sent to Azure AD Connect server and from there, Azure AD Connect will talk to Kerberos and end point domain controllers.
So, what happens in the background with Kerberos and PTA? In PTA is that the Kerberos concept of TGT and TGS also comes into play. In PTA scenario, a client request is sent to Azure AD, and from there, AZURE AD will send the request to Azure AD Connect server. So, we can say that this works like a proxy that handles the request. Look at this screenshot:
This is an event logged on my DC. As you can see, my AADC server (192.168.5.6) is requesting a TGT token for account ‘Serj’. So, once the TGT is requested, it is clear that a TGS should be requested. Here is the TGS logged on my DC:
In this screenshot we can see that the service requested is AAC which is my AADC server. However, in previous screenshot, the service was krbtgt account. So, we can say that all the Kerberos concept are kept into place here.
I asked myself what happens if our DC is unavailable during the PTA? Does it inform the client that DC is unavailable? So, I stopped the DC and tried connecting to a resource with PTA:
And this is what happened:
That’s it for today. :)