In the infrastructure, there can be different types of authentication protocols in use. Active Directory uses Kerberos version 5 as the authentication protocol in order to provide authentication between the server and the client. Kerberos v5 became the default authentication protocol for Windows Server from Windows Server 2003. It is an open standard, and it provides interoperability with other systems that use the same standards. Before we look into improvements in AD DS security, it is important to understand how Active Directory authentication works with Kerberos.

The Kerberos protocol is built to protect authentication between the server and the client in an open network where other systems are connected as well. The main concept behind authentication is that two parties have agreed on a password (secret), and both use it to identify and verify their authenticity:

In the preceding example, Dave and server A have regular communications. They exchange confidential data between them more often. In order to protect this communication, they agreed on a common secret code 1234 to be used to verify their identities before exchanging data. When Dave makes initial communication, he passes his secret to server A and says Hay! I'm Dave. Then server A checks the secret to see whether it's true. If it's correct, it identifies him as Dave and allows further communication:

Communication between Dave and server A happens in an open network, which means there are other connected systems. Sam is a user connected in the same network where Dave is. He is aware of the communication between Dave and server A. He has an interest in data exchange between them and would like to get his hands on the data. He starts listening to the traffic between these two hosts to find out the secret they use. Once he finds it, he starts to communicate to server A and says he is Dave and also provides the secret code 1234. From the server A point of view, system doesn't see a difference between requests from Dave and Sam, as both provide the correct secret.

Kerberos solved this security challenge using the shared symmetric cryptographic key instead of secrets. It uses the same key for encryption and decryption. The Kerberos name comes from a three-headed strong dog in Greek mythology. As the three-headed dog, the Kerberos protocol has three main components:

• A client
• A server
• A trusted authority to issue secret keys

This trusted authority is called the Key Distribution Center (KDC). Before we look into Kerberos in detail, it's better to understand how a typical key exchange works:

If we revisit our scenario, now we have a KDC in place. Instead of communicating to server A directly, Dave goes to the KDC and says he needs to access server A. It needs a symmetric key to start communication with server A. This key should be used only by Dave and server A. The KDC accepts the request and generates a key (key D+S) and then distributes it to Dave and server A. By the looks of it, this seems quite straightforward, but from the server point of view, there are a few challenges.

In order to accept a connection from Dave, the system needs to know key D+S, so it needs to keep this key stored in server A. We are considering only one connection in here. But if there are a hundred connections, it needs to store all the keys involved. This will cost resources for server A. However, the actual Kerberos protocol operation is more efficient than this.

In an Active Directory environment, the KDC is installed as part of the domain controller. The KDC is responsible for two main services: one is the authentication service (AS) and the other is the Ticket-Granting Service (TGS).

In the preceding example, when Dave logs into the system, it needs to be proved to the KDC that he is exactly the same person that he claims to be. When he logs in, it sends username to the KDC along with a long-time key. The long-time key is generated based on Dave's password. The Kerberos client on Dave's PC accepts his password and generates the cryptographic key. The KDC also maintains a copy of this key in its database. Once the KDC receives the request, it checks its username and the long-term key with its records. If it's all good, the KDC responds to Dave with a session key. This is called a ticket-granting ticket (TGT).

The TGT contains two things:

• A copy of a session key that the KDC uses to communicate with Dave. This is encrypted with the KDC's long-term key.
• A copy of a session key that Dave can use to communicate with the KDC. This is encrypted with Dave's long-term key so only Dave can decrypt it.

Once Dave receives this key, he can use his long-term key to decrypt the session key. After that, all future communication with KDC will be based on this session key. This session key is temporarily and has time to live (TTL) value.

This session key is saved in Dave's computer's volatile memory. Now it's time to request access to server A. Dave has to contact the KDC again, but this time, he uses the session key provided by the KDC. This request includes the TGT and the timestamp encrypted by the session key and the service ID (the service that is running on server A). Once the KDC receives it, it uses its long-term key to decrypt the TGT and retrieve the session key. Then, using the session key, it decrypts the timestamp. If the time difference is less than 5 minutes, it proves it came from Dave and is not the same request as the one from the previous time.

Once the KDC confirms it as a legitimate request, it creates another ticket, and this is called a service ticket. It contains two keys: one for Dave and one for server A. Both keys include the requester's name (Dave), the recipient, the timestamp, the TTL value, and a new session key (that will be shared between Dave and server A). One key of this is encrypted using Dave's long-term key. The other key is encrypted using server A's long-term key. In the end, both are encrypted together using the session key between the KDC and Dave. Finally, the ticket is ready and sent over to Dave. Dave decrypts the ticket using the session key. He also finds his key and decrypts it using his long-term key.

This process reveals the new session key that needs to be shared between him and server A. Then, he creates a new request including server A's key retrieved from the service ticket and the timestamp encrypted using the new session key created by the KDC. Once Dave sends it over to server A, it decrypts its key using its long-term key and retrieves the session key. Using the session key, it can decrypt the timestamp to verify the authenticity of the request. As we can see, in this process, it is not server A's responsibility to keep track of the key used by the client or it's not the client's responsibility to keep the relevant keys.

Let's go ahead and recap what we have learned about the Kerberos authentication:

1. Dave sends the username and his long-term key to the KDC (domain controller).
2. The KDC checks the username and long-term key with its database and verifies the identity. Then, it generates a TGT. It includes a copy of a session key, which the KDC uses to communicate with Dave. This is encrypted with the KDC's long-term key. It also includes a copy of a session key Dave can use to communicate with the KDC.
3. KDC responds to Dave with its TGT.
4. Dave decrypts his key using his long-term key and the retrieved session key. His system creates a new request including the TGT and the timestamp encrypted by the session key and service ID. Once the request is generated, it is sent to the KDC.
5. The KDC uses its long-term key to decrypt the TGT and retrieve the session key. Then, the session key can be used to decrypt the timestamp. Then, it creates a service ticket. This ticket includes two keys. One for server A and one for Dave. Dave's key is encrypted using his long-term key and server A's key is encrypted using server A's long-term key. In the end, both are encrypted using the session key used by the KDC and Dave.
6. KDC sends the service ticket to Dave.

7. Dave decrypts the ticket using the session key and retrieves his key. Then, he goes ahead and decrypts it to get a new key, which can be used to establish a connection with server A. In the end, it creates another request, including server A's key (which was created earlier) and the timestamp that is encrypted by the session key that Dave decrypted earlier in this step. Once everything is ready, the system sends it to server A.
8. Server A goes ahead and decrypts his key using its long-term key and the retrieved session key. Then, using it, server A can decrypt the timestamp to verify the request's authenticity. Once everything is green, it allows a connection between Dave and server A.

There are a few other things that need to be fulfilled in order to complete the process:

• Connectivity: The server, client, and KDC need to have a reliable connection between them in order to process requests and responses.
• DNS: Clients use DNS to locate the KDC and servers. Therefore, a functioning DNS with the correct records is required.
• Time synchronization: As we can see, the process uses the timestamp to verify the authenticity of the requests. It allows up to 5 minutes' time difference. Therefore, it's a must to have accurate time synchronization with the domain controllers.
• Service principal names: Clients use service principal names (SPN) to locate services in the AD environment. If there is no SPN for the services, the clients and the KDC cannot locate them when required. When setting up services, make sure that you set up SPN as well.