Working with Kerberos

Written by: James Immer

Editor-in-Chief

Overview

Kerberos is an authentication protocol used to allow for secure sign in for users and services. Working similar to federation, Kerberos allows for centralized sign in to services that share a centralized trust. The most common implementation of Kerberos can be found with Microsoft Active Directory; a service that comes packaged on the Windows Server line of Operating systems. This blog post will act as a comprehensive guide to using, understanding, and debugging Kerberos authentication.

Life before Kerberos

In on-premise Active Directory, Kerberos is king for domain/forest level sign-on. Prior to this, the only options where NTLM or CredSSP. Both these former options are fancy forms of basic authentication. Basic Authentication is typically Username and Password

The problem with these methods is they force the target service to handle all the authentication and authorization itself. For example, when you connect to an Azure File Share using Storage Account name + Access key, the authentication used by SMB will be NTLM. The target server, in this case an SMB share, is responsive for validating the credentials, and assigning the proper level of access to the share.

For a lot of implementations, this is not an issue. However, at scale this becomes a problem. One problem is there are no tokens used. When an NTLM sign-on is required, username and password will be passed to the requesting service. This opens the door for the potential of brute-force attacks against the target resource server itself. NTLM can also be used without a back end AD to handle the authentication or authorization. This is not an issue with NTLM, but can cause issues with credential management on the target server.

Differences in responsibility

Where NTLM authentication forces the target server to handle the authentication, Kerberos does not give us the same issues. In Kerberos authentication, the requesting client is responsible for requesting a token for the service provided by the target. In the case of SMB, the service defined for SMB in ADDS is CIFS. This means that when the client initiates the request with the target, instead of providing a challenge to the client, the server tells the client to get a Kerberos TGT (Ticket Granting Ticket) for CIFS. This forces the client to contact its local Kerberos KDC (Key Distribution Center). This a role provided by a Active Directory Domain Controller or AD DC. This role will listen for Kerberos requests on the dedicated Kerberos port 86. When a request is made, it will challenge the user accordingly. Once done, provide the client a TGT.

This TGT is then used to gain access to the target SMB service. Each TGT is provisioned for a specific service. If requesting access for SMB, the service will be listed as CIFS. If requesting access to a browser site, like ones hosted on IIS, the TGT will be for HTTP. The best part of this is that these tokens are stored on the machines. If a user needs to access the share again, the TGT can be passed in place of a new challenge; allowing for non-interactive SSO or Single-Sign-On.

The in depth steps of both NTLM and Kerberos will be explained in the next section. Here is are examples of the Kerberos and NTLM flows from a high level:

NTLM

Kerberos

Test header 2

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Summary