How I Was Wrong About Kerberos

Microsoft’s Active Directory includes a version of Kerberos that has had a bad reputation. There were problems several years ago, but the criticisms are now outdated. What was the problem, and how has it been fixed?

Origins of Active Directory

Windows 2000 was originally going to be called Windows NT 5.0. It was released in December 1999 and named for the coming new year. (Who remembers the Y2K panic?) There were four editions, three of them servers.

The server versions included Active Directory, a collection of network services originally intended just for Windows environments. Other operating systems have been able to utilize Active Directory components, as they are simply the DNS, LDAP, and Kerberos services. Since the 2012 release of version 4 of the Samba suite, a non-Windows system can function as an Active Directory Domain Server, also called an AD domain controller.

Next week I’ll start explaining how to build an AD server with free software running on a free operating system. But I must first straighten out some Kerberos confusion.


A Kerberos server, sometimes called a KDC or Key Distribution Center, accomplishes multiple security tasks. We discuss these in Learning Tree’s System and Network Security Introduction course and the CompTIA Security+ test-prep course.

Kerberos first authenticates a user, requiring them to prove their identity by using a long-term secret key. The successful user receives a TGT or Ticket-Granting Ticket.

Second, Kerberos authorizes users. Based on who you are, proved by possession of the TGT, are you allowed to access some specific service? If so, you get a Service Ticket.

Third, Kerberos controls the use of cryptography. If you are allowed to access some network service, you must do so while encrypting your network traffic with a specific cipher and key.

Kerberos was named for the three-headed guard dog of Greek mythology. There are the three heads: the TGT exchange, the Service Ticket exchange, and the secured connection to the system providing the Kerberos-aware service. The usual physical analogy is that the TGT is like your driver’s license, the Service Ticket is like your airline boarding pass, and the airplane ride is the desired service.


Early Compatability Problems

Microsoft was heavily criticized after the release of Windows 2000. I think that the criticism was justified. They had a network service that they claimed was Kerberos. But not really, it violated the standards in some of the packets. Non-Windows systems expecting true Kerberos often could not interoperate with the Windows approximation. It’s bad enough to casually violate the rules and mislabel products. It’s even worse when it’s a security product.

The encrypted TGT coming back from the Kerberos server can include a Privilege Attribute Certificate or PAC. This is where Microsoft violated the rules — they used their own proprietary PAC format.

Clients couldn’t use the official syntax to interpret the odd PAC. But it couldn’t be ignored. A user who belonged to several groups might receive a PAC that made the TGT too large to fit within one UDP datagram. The Windows KDC would direct the client to switch from UDP messages to a TCP connection. However, several client implementations didn’t support that then.

That meant that non-Windows Kerberos clients couldn’t use the partially correct Kerberos server. But that isn’t the fault of the clients.

Criticism, then Some Openness

As you might imagine, Microsoft was heavily criticized for breaking things, and on top of that, not explaining how or why. They eventually published a description of their proprietary PAC data structure, wrapped within dire warnings not to implement it in your designs.

Yes, it is weirdly different and sometimes too large. We already knew that much.

That Was Long Ago

The worry about Microsoft incompatability became entrenched. It’s still common to warn against relying on Microsoft’s Kerberos version because of incompatability. There are reasons to prefer non-Microsoft Kerberos, but incompatability is no longer a good one. I’ve been as guilty of this lack of understanding as anyone.

RFC 5021 standardized TCP support for Kerberos in 2007. I suspect that many implementations supported Kerberos over TCP port 88 for a significant time before that RFC came out. Only very old non-Windows implementations would still have compatability problems. And if they’re that old, what dangerous bugs do they contain?

The situation for several years has been that most non-Windows Kerberos implementations simply ignore the PAC field. If you really have compatability problems today, that means that you are running some dangerously old code. Even if you have all the bugs patched in your old operating system, imagine all the improvements over the past ten to fifteen years that you are missing!

Let’s Build a Proper Active Directory Server

Come back next week for the start of a multi-week series on building an Active Directory domain controller from Samba. There’s great performance, it’s surprisingly easy to set up, and you’re running real DNS, LDAP and Kerberos services!

Type to search

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.