kerberos AKA: How Authentication works on Windows Networks

Here I'll cover how the Kerberos works or how authentication works on a windows networks. This isn't a tutorial on setting up active directory isn't more of a low level explanation of what is happening on the network as a client tries to connect to a server, how it gets authenticated by a Domain Control and how all three know who's allowed access and what is there to prevent an attacker passing himself off as a client or even a domain controller.



Three types in the windows networking world, I'll only be covering active directory here but you just need to know the others exist.

Local

This is the simplest setup. You set up a password on your computer and you use it to log in. In the background it compares your password you type to the entry in a file and compares them to see if it's right. But if someone got that file they'd have all the passwords, so the password isn't stored in plain text. A one way encryption or hashing process is used to create a (pseudo)random bunch of characters. The random (seeming) hash that is stored in the file is compared to the random (looking) hash generated when you entered your password, and if they match you are granted access.

Workgroups

In very small networks like the network you might have in your small office or at home, where there is no central authority Windows Workgroups are used. Here each computer manages it's own security.

Windows NT Domains

This is deprecated now in favour of Active directory, I only mention it so you wont confuse it with active directory if you do further reading. Basically don't use it.

Active Directory

Active Directory is a type of database based on the telephone style directory. Unlike a relational database its organised in a treelike structure which is good for looking things up quickly. That's what the term means in it's purest form. More often though it us used to refer to a Windows system that keeps track of computers, user and other objects on the windows network and keep track of who has access to what. Confusingly enough it is used to refer to the entire network that uses one of these databases to keep track of the resources on the network. I will in general use the term to refer to the actual database system and I will be as clear as possible which one I'm talking about:

Domain Consolers are the computers on a network that contain the Active Directory database and the Software Systems that handle authentication and access to resources. Although not part of the definition these computers generally handle a number of other roles like DNS and DHCP.
LDAP is a network based protocol used for synching (getting, setting, editing) data within an active directory based system.

For example you have an Domain Controller with usernames, full names, passwords, contact information etc. and you have a mail server that uses the same kind of information. Now you could manfully enter the information into both. Every time you add or delete a user, change a password or some other detail; you'd have to do it for both but that's messy and odds are details wouldn't be changed properly unless they really needed to be. Former employees that have been removed from Active Directory still might have access to email. An LDAP enabled server would be able to get that information from the Domain Controller and update its own information.

Kerberos

Kerberos5 is the authentication protocol that is used on the network to deal with the tricky situation of a client, a Server and a Domain controller authenticating each other securely.

First consider the environment, you might have thousands of users using thousands of computers connecting to hundreds of hosts with resources the users need to work, file servers, mail servers, printers, internet connections. Consider the nightmare of setting up all the users at all those computers, changing passwords and other details maintaining information on individual computers. It's far easier to maintain that information at a central location and share it as necessary. Keep in mind through that there may be other people on the networking looking to grab passwords and other credentials floating over the network.

It's Kerberos's job to make sure valid users and hosts can get access to the services they are entitled to without giving away any passwords or credentials over the network and to do so without putting too much strain on the Domain controller/Key Distribution Centre (in this context, generally they are the same thing).


In the above diagram you can see a Client with a user who has just logged in, a Server with some service the client wants and a Key Distribution Centre. The messages and keys are colour coded to show which key is being used for encryption. Kerberos uses key exchanges extensively so I wanted to be clear.

On a Windows network the Key Distribution Centre is almost always the Domain Controller and the Authentication Service and the Ticket Granting Service run on the same machine. Microsoft doesn't own Kerberos, it was developed by MIT and anyone that want's to can set up there own Kerberos system, also the Authentication Service and the Ticket Granting Service could be broken up to spread out the load but in the simplest and most common case the Key Disruption Centre IS the Domain Controller and the two services run on it.

Step 1:

First of all the user sits down at his computer types in his password; let's say it's "password" and hits enter. Because keeping unencrypted passwords around is a bad idea the password is then passed through a sort of one way encryption process called Hashing to produce a seemly random combination of characters:  "8846F7EA­EE8FB117­AD06BDD8­30B7586C". Although this hash can't be reversed or decrypted every time the user types in "password" the same hash will always come out.
 Sitting on the KDC (Key Distribution Centre) in a database is the hash of the password from when the user first set up his account. Note the users password doesn't need to be saved onto his computer even in hashed from, he uses the KDC / Domain Controller to authenticate.






As the user enters his password a request is sent to the KDC for a ticket and a session key. What the KDC does next is quite clever, it creates the ticket and a session key even though the user hasn't authenticated yet but encrypts the session key using the hashed password as the decryption/decryption key and send's it to the Client.

The client is authenticated if the session key can be decrypted with a valid hashed password and the KDC is authenticated because it needed the hashed password encrypt it properly. The password is never sent over the network even in it's hashed form.

The KDS also sends a Ticket-to-Generate-Tickets (TGT) containing some simple data on the client but it can never be decrypted by the client, if the AS and TGS were separated it's contents like client ID and TTL would save the TGS from having to communicate with the AS but in this simple/typical example it might as well be random numbers or a randomly generated password. At this point the client has authenticated (and logged in) with the Key Distribution Centre (KDC) and has a session key (TGS) and a Ticket to Generate Tickets (TGT).
 Step 2:
 The user is happy working away on his client computer but now needs a resource from the Server. I'm using the term server broadly here, it could be a file server, mail server or really any resource on the network that supports AD/LDAP/Kerberos authentication.





To use the resource the client must first get permission from the Key Distributions Centres Ticket Generating Service. The client sends it's Ticket-to-Generate-Tickets to the TGS and a message containing the Clients ID and a Time stamp, encrypted with the session key It got from the Authentication service. The time and client name aren't as important as the fact that the client proves that it has the session key by encrypting the data with it. 

Assuming the client has rights to access the resource/server in question the TGS running on the domain controller sends on a Service ticket containing a client-server session key encrypted with a services secret key, this message can't be decrypted by the client since its encrypted using the services secret key with only the server and the Domain Controller have, the client will has this onto the server.

The client also receives a client-server-session key which it can decrypt using the TGS session key, it will use this for communication with the server.

Step 3:

The client now starts communicating with the server; it takes it's client ID and a timestamp and encrypts it using the Client-Server-Session key it just received and passes it along with the service ticket it couldn't decrypt earlier. The server can however decrypt it using the Services-Secret-Key. Now the client an server both have the Client-Server-Session key and the client has authenticated by being able to encrypt its UID and timestamp, the information itself isn't that important but it proves it has the Client-Service-Session key.

A new step added is the server now authenticates it's self by encrypting a timestamp with the Client-Server-Session key and now they can begin communication.


Conclusion
It's quite a clever system that prevents passwords from being sniffed in the air and allows for a Domain Controller to manage rights for the server but it has a couple of issues.

Pass the Hash:
I an attacker can get a NTML hashed password they can use that password to access resources even if they don't have the original password.

NTML relaying:
If an attacker can get the client can act like a server and get the client to attempt to authenticate to it the attacker can try to authenticate with the domain controller/legitimate server. The attacker connects to the DC and receives a challenge and passes the challenge back to the client, the client encrypts it with they're hash and passes it to the attacker who passes it to the DC and is authenticated.

Rainbow tables attacks in older version of NTLM:
It was possible for an attacker to send a challenge to an client that contained something like 11223344556677889900 to a client instead of a random number. The client would then encrypt that with they hash and send it back. They problem with this if the attack can control the challenge they can create Rainbow tables; pre-computed look up tables with every (or most) responses for 11223344556677889900 and quickly compare the response to find the original value.