As you may already know, Microsoft network security protocols rely on Kerberos for authentication. Since authentication and authorization are two coupled functions, it is natural to bind them together in a protocol that does both. Kerberos as specified by the IETF only provides authentication. Application services rely on it only to validate client identities. Kerberos does not offer means to verify whether a client has the right and privileges to perform a certain action. Microsoft has specified an extension to the Kerberos protocol to make it handle authorization as well as authentication. This article provides an overview of this extension and analyzes issues with regards to interoperability and the open-source world.

In order to be authorized for a certain action, a client must first prove its identity to the service. Second, the client needs to provide authorization data indicating that it belongs to a group authorized to perform the action. If for example the user requests editing a system configuration file, he must provide proof that he belongs to the Administrators group.

In open-source Kerberos implementations, the Kerberos database contains user and service credentials used for authentication purpose. No information about authorization or privileges is stored in the database.

Microsoft Active Directory Controller (ADC) on the other hand maintains additional information in its Kerberos database. Probably on of the most important is the group membership. This information is used to build authorization data also knows as Privilege Attribute Certificate (PAC). During the Microsoft logon process, the Microsoft Active Directory Controller delivers a Ticket (amongst other stuff) to the client, that can be used to authenticate him to different services in the domain. The ticket is encrypted using a key only known to the ADC and the service. The ticket also contains the PAC that indicates the user's group memberships.

When the user requests an action, the service uses its secret key shared with the ADC to decrypt the contents of the Ticket presented by the user. If the contents of the Ticket confirm the identity of the user, then the service proceeds to the next step which consists of verifying the user privileges. For this purpose, the service examines the contents of the PAC. If the user belongs to a group that is authorized to perform the requested action, then the user is authorized, otherwise the action is denied.

The exact contents of the Microsoft PAC can be found here.

This is an overview of the structure :

 1: typedef unsigned long ULONG;
 2: typedef unsigned short USHORT;
 3: typedef unsigned long64 ULONG64;
 4: typedef unsigned char UCHAR;
 5:
 6: typedef struct _PACTYPE {
 7:     ULONG cBuffers;
 8:     ULONG Version;
 9:     PAC_INFO_BUFFER Buffers[1];
10: } PACTYPE;

The fields are defined as follows:

• cBuffers — Contains the number of entries in the array Buffers.
• Version — This is version zero.
• Buffers — Contains an array of PAC_INFO_BUFFER structures. Each element of this array conveys actual authorization information.

The PAC_INFO_STRUCTURE can contains different kinds of authorization data encoded in NDR.

The Kerberos specification does not specify how authorization is performed however it leaves place for vendor extensions. Microsoft extension uses a placeholder called “authorization-data” dedicated for this purpose (see RFC4120). From this point of view, Microsoft has ensured compatibility with the Kerberos standard and other Kerberos implementations.

However, the use of NDR for encoding the PAC can be considered as an issue since NDR (defined by DCE RPC) is not an ISO standard. The Kerberos specification uses the ISO ASN.1 DER encoding rules which are widely understood and for which free compilers are available. I am not sure whether free NDR compilers are available. If this is the case, open-source developers may have to pay money to purchase the NDR compiler in order to build applications compatible with Microsoft extensions to Kerberos.

• Windows Communication Protocols (MCPP)