Kerberos 5, the most secure authentication protocol, is a well-known public standard created by the IETF (Internet Engineering Task Force), and it implements a ticket-based authentication protocol. When is activating Integrated Windows authentication, Windows uses Kerberos automatically under the following circumstances:
– The client and the server are running Windows 2000 or higher.
– An Active Directory Domain with a primary domain controller (which automatically plays the role of the key distribution center) is available in the network.
In any other case, Windows will select NTLM as the authentication protocol described in the article How does NT LAN Manager Authentication work in ASP.NET.
The KDC (key distribution center), the core component of a Kerberos system, is responsible for issuing tickets and managing credentials. In the Windows world, an Active Directory primary domain controller plays the role of the KDC. Every client and all the servers, named actors, involved in the authentication process have to trust the KDC. It manages all the user and computer accounts and issues so-called authentication tickets and session tickets, where:
– Authentication tickets are issued after a successful authentication of a user or a machine, and are used for requesting any further tickets, such as session tickets.
– Session tickets are then used for establishing secure communication sessions between machines in the domain.
The big difference between Kerberos and NTLM is: while NTLM works for workgroup scenarios without a central authority, Kerberos requires a central authority for issuing any type of ticket. For that reason, if you want Kerberos to work, you need a connection to an Active Directory domain controller.
The next picture shows the flow for authenticating a user and then establishing a session between the client and the simple member server of a domain:
Kerberos authentication and tickets
The basics about Kerberos authentication and tickets are described in the next steps:
1. Every user authentication process starts with submitting a request to the authentication service, which runs on the KDC (Active Directory Domain Controller). This request contains the user name of the user to be authenticated. The KDC reads the user’s master key from the security account database. This is the hashed version of the user’s password.
2. Then it creates a TGT (ticket-granting ticket) which contains a session key for the user’s session as well as an expiration date and time. Before the ticket is returned to the client, the server encrypts it using the user’s master key.
3. With only the correct password entered on the client, the client operating system can create the correct master key (the hash) for successfully decrypting the TGT received from the server. If decryption of the TGT succeeds on the client, the user is authenticated successfully.
4. Finally, the client caches the TGT locally.
5. When the client wants to communicate with another member server in the network, it first must ask the KDC for a session ticket. For this purpose, it sends the locally cached TGT to a ticket-granting service that runs on the KDC. This service validates the TGT, and if it’s still valid (not expired, not tampered with, and so on), it generates a session key for the communication session between the client and the member server. This session key is then encrypted with the client’s master key. In addition, the session key is packaged into an ST (session ticket), which contains additional expiration information for the server. This session ticket is encrypted with the member server’s master key. Both the server and the client are well known to the KDC, as somewhere in the past both have been joined to the domain. Therefore, the KDC knows the client’s and the member server’s master keys and can use them for encrypting the information accordingly.
6. Both the encrypted session key and the encrypted session ticket are forwarded to the client.
7. The client decrypts the session key and keeps a local copy of this session key in a local cache.
8. Then the client forwards the encrypted session ticket to the server. The KDC has encrypted the session ticket for the server using the server’s master key, as outlined in step 5.
9. If the server can successfully decrypt and validate the session ticket received from the client, the communication session will be established.
10. Both the client and the server use the previously generated session key for encrypting the communication traffic. As soon as the session ticket has expired, the whole operation takes place again.
Important notes:
Every ticket—session tickets and ticket-granting tickets—is equipped with capabilities which are a set of defined properties that are required for certain features, such as impersonation or delegation:
1. Equipped with the right set of properties (capabilities), tickets can be used for impersonating the client user on the server or delegating the client’s identity to another server.
2. If the client and the KDC do not include these capabilities into the ticket, features related to these capabilities would not work.
3. If the ticket does not include the necessary information for impersonating a user, impersonation will not work.
From the security perspective, this is a good design, as the client and the server can decide whether certain features are allowed or not just by including or not including certain properties in the ticket.