Now it's time to start getting into understanding how a user can log into Active Directory through authentication in that AD environment, and that is through Kerberos, where we have a multi-step process that we're going to break down relatively easy, and we can see the actual network traffic for it here momentarily.
What we're talking about is the actual user logging into a system. It could be any of the workstations on the Active Directory domain, and then you go in, they say, OK, here's my username and password, and they make contact to the domain controller.
Now, I want you to think of the domain controller in this case as a ticket booth, and I'm going to come back to that in just a second, because that domain controller is acting as the KDC, and you've probably heard of this before, as the Key Distribution Center.
Now, they're going to, the domain controller being their pronouns, right, is going to issue a ticket to the actual user saying, OK, here's your ticket for admission into the amusement park.
Please, by all means, go and pick a ride to be on in standing queue for that ride.
So, once they've been issued a ticket from the KDC, the user is going to go about the Active Directory amusement park and pick a ride to go on.
Now, some of these rides include the Exchange server, the file share, the SQL, all the database and stuff, even stuff within the internal network or possibly external, depending on your configuration for web services.
See, you could integrate Active Directory into an actual web environment for login and just basic accreditation, and we see this through Microsoft.com using live in order to operate and login to Office 365.
And that also goes through the standard Active Directory login process by the visitor coming to the ticket booth, being issued a ticket by the KDC, the Key Distribution Center, and then the user going through and picking which ride they want to go on, i.e., the service that they want to take a part of, the role or the feature in this case.
Now, you may be wondering where does it go internally through that?
Now, network-wise, you're going to see a couple of things.
You're going to see an ASREQ, which is the actual request, where the client sends the message to the KDC by saying, hi, I'm the user.
Enter username here.
Now, most of all of this is going to be encrypted, and the password is going to be hashed, as we've seen in standard passwords before.
And you're going to then follow this up with an ASREQ, a reply from the KDC to the user to try to decrypt the actual message of, hello, this is Bob, and then using the copy of Bob's hash.
I'm just saying Bob is the user because Bob the sandwich maker.
And the KDC knows it's really Bob based on that authentication of password hash.
And then the ticket is actually issued from KDC, and you get a ticket granting ticket.
Now, I know that seems kind of redundant, but it is TGT.
And we'll have notes and bullet points on this below this video.
So, basically, I want you to think about this as the TGT, the ticket granting ticket, as being the wristband you get going into an amusement park.
You go in, and that wristband is going to indicate that you have a certain time allocated to you to be able to pick the rides that you want to ride on.
If you want to start with the roller coaster first and then partake in some of the waterboarding rides, I haven't been to an amusement park in quite some time.
But, basically, you have a certain amount of time as far as that wristband is allowing you to, the TGT.
So, we follow this up with the ticket granting service, getting the actual ride ticket.
You're going to see a TGS request, or a queue, where Bob is going to send his wristband in to the KDC and say, I want access to insert service here.
So, once you get that wristband, it then has to be verified again by the ticket granting service to make sure that that wristband is valid.
In this particular case, I want you to believe that once you go up to the KDC or the ticket booth, you get the TGT, and then you're going to have somebody on the other side of it saying, did you really get a ticket?
And they're going to verify it. And once they verify it, you get a TGS or a P, a reply.
And the KDC is going to verify with that second authentic, the verification source.
So, ticket booth, then dude or dudette behind the ticket booth, they're going to get together.
And if it's valid, it'll encrypt an actual service ticket using the actual files server service account hash.
Basically, this is how the ticket is actually generated and verified and issued to the actual user, in this case, Bob.
Now, this is all well and good, right?
There's a lot of different steps that you just heard.
And again, I'm going to try my best to put the bullet points below and give you a little bit more than this.
But the reason that I bring all this up is, is because the Kerberos authentication and the way the Active Directory does user validation for services inside of Active Directory is very complex.
And as pen testers, basically, at this point in your career, we are all basically engineers of some type.
We know that the more that you over engineer something, the more likelihood there is for us to be able to find a way to be able to make a fault out of something.
Because it's usually the most simplistic ways and methods that achieve greatest success with the fewest security flaws.
That's not to say that there's anything out there that's without security flaws.
What I'm saying is, is that because this authentication process is so complex, it does present problems for organizations to have their tickets picked up in the middle.
Usually called passing the hash as one of the attack methods, which we will review later on in different skills.
And then finally, we get the application request.
So you're inside the amusement park, you have your wristband, you've been verified by the ticket booth and the do-do-do that behind the ticket booth.
And so now you want to go up to the first roller coaster and you're going to get an AP request that you walk up and say, here's my wristband.
I want to ride that roller coaster.
And so the application is going to make contact with the KDC and just verify that that wristband is in fact valid and within the service time period of issuance.
Because if you come back five days later, that may be outside the scope of where that wristband is allowed to be used.
So you normally wristbands and amusement parks for like a day or two or something like that.
That's no different here. It's based on the actual defaults and whatever the configuration of that system administrators set.
Based on the CIO or CISO and the company's or organization's SOPs or standard operating procedures.