This chapter is not meant to be a complete description of the Kerberos protocol.

Instead, this chapter is intended to be an initiation to some important Kerberos concepts that are often misunderstood, and that will be useful to help you better manager your Active Directory domain.

About Kerberos

In Greek mythology, Kerberos is a three headed dog that bars the entry door to hell. It is the master of the key, so the name is very appropriate to an authentication service whose role is to give the user her key to identify herself on the network.

As mentioned in the presentation of the history of Samba, Kerberos was created within MIT for a DARPA sponsored project. The objective of the project was thus to put security ahead of simplicity.

Kerberos may seem complicated at first glance, but it is a lot simpler than it looks.

Microsoft has done a real good job of integrating Kerberos Inside Active Directory, so that anybody could benefit from the technology without having to understand it fully.

Note

Kerberos v4, Kerberos v5. The first versions of Kerberos to be massively deployed are version 4 at the beginning of the 1990s. In the 1990s, version 5 of Kerberos was released and Active Directory is based on that version, with no possible retro-compatibility with version 4. In reality, only Kerberos v5 is used today. So, if you find a documentation giving advice on Kerberos v4, it is completely obsolete.

Kerberos is an authentication mechanism between two systems based on a trusted third party:

  • The trusted third party is the Kerberos server.

  • The domain joined client workstation trusts the Kerberos server.

  • The file server trusts the Kerberos server.

So the file server will trust the client workstation when the client workstation connects by presenting a ticket obtained from the Kerberos server (we talk about the notion of ticket just after. So here we have a mutual authentication system based on a trusted third party.

Note

An Active Directory server integrates a Kerberos server that is also called a KDC.

So, we’ll allow indifferently the use of AD, DC, Domain Controller, KDC or Kerberos server to designate the server that provides the Kerberos service.

Simplifying a little, we can summarize how Kerberos works with the Following diagram. It is however a summary that voluntarily forgets some details to facilitate understanding; however the diagram contains the necessary details to debug Kerberos problems in your Active Directory environment.

On the left, we have a Windows Workstation:

  1. Upon opening a session, the user authenticate herself with the Kerberos server using her password. It is a challenge authentication based on symetric cryptography (the server asks the workstation to encrypt a message that contains somes informations, notably the timestamp);

  2. Once the Kerberos server has authenticated the user, it provides her with a TGT. One can see the TGT as a temporary password used by the workstation for asking other tickets. In a way, this method removes the need to ask again the user to provide her password. One trades a long-lived password (your password that is changed every 3 months for example), with a short-lived password (the TGT may be renewed several times a day). In practice, the TGT is renewed every day when the user opens up her session.

  3. The user wants to connect to the file server srvfiles.mydomain.lan. In the file explorer, the user writes srvfiles.mydomain.lan. The Windows client will ask the Kerberos server a ST for the SPN that matches the string of characters HOST/srvfiles.mydomain.lan.

  4. The Kerberos server looks up in its LDAP an entry that has a servicePrincipalName whose name matches the requested value. If it finds a corresponding entry, it assembles a ST for the corresponding Kerberos account and sends it back to the user.

  5. The client workstation connects to the file server using the newly obtained ST. The file server validâtes that the ticket has been generated by the Kerberos server that it trusts, and thus the file server authenticates the user.

  6. The file server validates that the user has the proper rights to access the resource, and then choses to authorize or prevent the user from accessing the resource.

Note

Authentication vs. authorizations

The role of the Kerberos server is to authenticate a user on a network, and not to validate whether such and such user has access rights to the resource.

As an example, you may ask for a ticket to an accounting server that you have no right to access, the Kerberos server will give you the ticket.

When you will present the ticket to the accounting server, the server will validate the ticket and authenticate you as the person that you pretend to be, but then the account server will verify that you belong to a group of users that is authorized to connect. The accounting server will see that you belong to no authorized group and it will refuse you the access.

Therefore, we repeat once more: the role of the Kerberos server is to authenticate a user, that means that it will ensure that the user who asks to connect to a service that is a member of the Kerberos domain is who she pretends to be; the Kerberos service does not manage user access rights.

In this diagram, it is important to realize that the file server has not needed to connect to the Kerberos server to authenticate the user, it is very different from a NTLM based authentication.

As mentioned in the above note, the member server of a Kerberos domain may have to validate user access rights with an LDAP request against the Active Directory server. In practice, the Service Ticket uses an extension called PAC that allows the Kerberos server to embed a signed list of groups to which the user belongs. The file server will use this list to validate the user access rights, thus avoiding a LDAP request on the Active Directory server.

Note

The attributes servicePrincipalName in AD are free text fields. One can have as many SPN as needed. When a client of the Kerberos realm wants to connect to a given service, it must find by itself the correct Matching SPN. If the client is not able to find the right SPN, it will not be able to ask for a Service Ticket. The formating of SPN has thus been globally normalized:

For a fileserver, we can have the following SPN and one can add as many more as one wants:

For a LDAP server or the GC service (cf. chapter on LDAP):

  • LDAP/srvads.mydomain.lan;

  • GC/srvads.mydomain.lan;

For a proxy server:

  • HTTP/srvproxy.mydomain.lan;

For a web server:

  • HTTP/srvintranet.mydomain.lan;

in practice, one can map a SPN on an IP address, even though it is not really well advized:

As one may observe from ,the above list, the aim is to find the right kerberos account for which to get a Service Ticket.

Note

The Kerberos protocol may be used with TCP or UDP. In reality, Windows clients only use TCP. Windows XP clients had used UDP by default, which may pose problems with VPN with low MTU.

The Kerberos package has a default maximum size MaxTokenSize that is configured on clients and Kerberos server to 12000 octets. If a user belongs to more that 120 groups, problems may appear with authorizations, because the list of groups in PAC may be truncated.

One may also note that the relation of trust between the file server and the Kerberos server was established when the file server had been joined to the domain.

Note

Kerberos and time

All Kerberos messages (initial authentication, authentication with TGT, Service Tickets, etc) are timestamped to prevent replay attacks.

By default, the Kerberos protocol authorizes a maximum shift of 5 minutes between the clock of the client and the clock of the Kerberos server. It is therefore very important that all systems in a network by correctly configured to stay on time with respect to the NTP server.

Depending on the configuration of your Windows clients, it is possible that they connect even though the clock is skewed. In fact and in that case, the Windows client will downgrade its authentication protocol to NTLM which is not subject to the clock skew restriction.

Based on the operating diagram above, one may draw several more conclusions:

  • If one uses an IP address instead of a DNS name, the server will go look for a servicePrincipalName attribute that matches the IP address.

    This mode is not configured by default, and it is not at all recommended to implement it. The Windows client will fallback and downgrade its authentication mode to NTLM. One will have the impression that everything works correctly, even though a less secure protocol is being used.

  • If one uses the name of a host, the host must be referenced in DNS.

    If the machine is not referenced in DNS, the Windows machine will try to make a NetBIOS request if NetBIOS is not disabled. NetBIOS is a security hole, it must be removed, so as a corollary, you need well-configured DNS!

  • If one uses an alias for a host name, the Windows file explorer will request a Service Ticket with that name. When the request fails, it will do a DNS request to get the real CNAME of the host, then request a Service Ticket for the SPN. However, Following CNAME is not standard in Kerberos spécifications, it is a choice of implementation in the Windows file explorer. Below are some tips to make good aliases.

  • If workstations are clock skewed, the Kerberos authentication will not work. The Windows client will eventually downgrade to NTLM authentication.

There are some books on Kerberos, but they are often either obsolete or unpalatable.