


Kerberos working group                                      John Brezak 
Internet Draft                                                Microsoft 
Document: draft-brezak-win2k-krb-authz-01.txt                           
Category: Informational                                   October, 2002 
 
 
 Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for 
                      Access Control to Resources 
 
 
Status of this Memo 
 
   This document is an Internet-Draft and is subject to all provisions  
   of Section 10 of RFC2026 [1] except that the right to create 
   derivative works is not granted. Internet-Drafts are working 
   documents of the Internet Engineering Task Force (IETF), its areas, 
   and its working groups. Note that other groups may also distribute 
   working documents as Internet-Drafts. Internet-Drafts are draft 
   documents valid for a maximum of six months and may be updated, 
   replaced, or obsoleted by other documents at any time. It is 
   inappropriate to use Internet- Drafts as reference material or to 
   cite them other than as "work in progress." 
     
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt  
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
1. Abstract 
    
   Microsoft Windows 2000 includes operating system specific data in 
   the Kerberos V5 [1] authorization data field that is used for access 
   control. This data is used to create an NT access token. The access 
   token is used by the system to enforce access checking when 
   attempting to access objects. This document describes the structure 
   of the Windows 2000 specific authorization data that is carried in 
   that field for use by servers in performing access control. 
    
    
2. Conventions used in this document 
    
   All defined data structures are defined using "C" style constructs 
   unless otherwise stated. All data is encoded as little-endian. 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in 
   this document are to be interpreted as described in RFC-2119 [2]. 
    
    
3. Top-Level PAC Structure 
    
   The PAC is generated by the KDC under the following conditions: 

  
Brezak                 Category - Informational                      1 
               Windows 2000 Kerberos Authorization Data   October 2002 
 
 
     o during an AS request that has been validated with pre-
        authentication 
     o during a TGS request when the client has no PAC and the target 
        is a service in the domain or a ticket granting service 
        (referral ticket). 
    
   The PAC itself is included in the IF-RELEVANT (ID 1) portion of the 
   authorization data in a ticket. Within the IF-RELEVANT portion, it 
   is encoded KERB_AUTH_DATA_PAC with ID 128. 
    
   The PAC is defined as a C data type, with integers encoded in 
   little-endian order. The PAC itself is made up of several layers. 
   The outer structure, contained directly in the authorization data, 
   is as follows. The top-level structure is the PACTYPE structure: 
    
        typedef unsigned long ULONG; 
        typedef unsigned short USHORT; 
        typedef unsigned long64 ULONG64; 
        typedef unsigned char UCHAR; 
         
        typedef struct _PACTYPE { 
            ULONG cBuffers; 
            ULONG Version;                          
            PAC_INFO_BUFFER Buffers[1]; 
        } PACTYPE; 
    
   The fields are defined as follows: 
   cBuffers - contains the number of entries in the array Buffers 
   Version - this is version zero 
   Buffers - contains a conformant array of PAC_INFO_BUFFER structures 
    
   The PAC_INFO_BUFFER structure contains information about each piece 
   of the PAC.  
    
        typedef struct _PAC_INFO_BUFFER { 
            ULONG ulType; 
            ULONG cbBufferSize; 
            ULONG64 Offset; 
        } PAC_INFO_BUFFER; 
    
   Type fields are defined as follows: 
    
   ulType - contains the type of data contained in this buffer. For 
           Windows 2000 access control, it may be one of the following, 
           which are explained further below: 
            
           #define PAC_LOGON_INFO               1 
           #define PAC_SERVER_CHECKSUM          6 
           #define PAC_PRIVSVR_CHECKSUM         7 
            
   Offset - contains the offset to the beginning of the data, in bytes, 
           from the beginning of the PACTYPE structure. The data offset 
           must by a multiple of 8. If the data pointed to by this 
  
Brezak                 Category - Informational                      2 
               Windows 2000 Kerberos Authorization Data   October 2002 
 
 
           field is complex, the data is typically NDR encoded. If the 
           data is simple (indicating it includes no pointer types or 
           complex structures) it is a little-endian format data 
           structure. 
    
4. PAC Credential Information (PAC_LOGON_INFO) 
 
   PAC_INFO_BUFFERs of type PAC_LOGON_INFO contain the credential 
   information for the client of the Kerberos ticket. The data itself 
   is contained in a KERB_VALIDATION_INFO structure, which is NDR 
   encoded. The output of the NDR encoding is placed in the 
   PAC_INFO_BUFFER structure of type PAC_LOGON_INFO. 
    
        typedef struct _KERB_VALIDATION_INFO { 
            FILETIME Reserved0; 
            FILETIME Reserved1; 
            FILETIME KickOffTime; 
            FILETIME Reserved2; 
            FILETIME Reserved3; 
            FILETIME Reserved4; 
            UNICODE_STRING Reserved5; 
            UNICODE_STRING Reserved6; 
            UNICODE_STRING Reserved7; 
            UNICODE_STRING Reserved8; 
            UNICODE_STRING Reserved9; 
            UNICODE_STRING Reserved10; 
            USHORT Reserved11; 
            USHORT Reserved12; 
            ULONG UserId; 
            ULONG PrimaryGroupId; 
            ULONG GroupCount; 
            [size_is(GroupCount)] PGROUP_MEMBERSHIP GroupIds; 
            ULONG UserFlags; 
            ULONG Reserved13[4]; 
            UNICODE_STRING Reserved14; 
            UNICODE_STRING Reserved15; 
            PSID LogonDomainId; 
            ULONG Reserved16[2]; 
            ULONG Reserved17; 
            ULONG Reserved18[7]; 
            ULONG SidCount; 
            [size_is(SidCount)] PKERB_SID_AND_ATTRIBUTES ExtraSids; 
            PSID ResourceGroupDomainSid; 
            ULONG ResourceGroupCount; 
            [size_is(ResourceGroupCount)] PGROUP_MEMBERSHIP 
        ResourceGroupIds; 
        } KERB_VALIDATION_INFO; 
    
   Reserved fields are not defined in this document and are not used in 
   the construction of access control tokens. 
    
   The fields are defined as follows: 
    
  
Brezak                 Category - Informational                      3 
               Windows 2000 Kerberos Authorization Data   October 2002 
 
 
   KickOffTime - the time at which the server should forcibly logoff 
           the client. If the client should not be forced off, this 
           field should be set to (0x7fffffff,0xffffffff). If a kickoff 
           time is to be enforced, the service ticket lifetime will 
           never exceed this value. 
   UserId - This field contains the relative Id for the client. If 
           zero, then the User ID is the first SID in the ExtraSids 
           field. 
   PrimaryGroupId - This field contains the relative ID for this 
           clientÆs primary group. 
   GroupCount - This field contains the number of groups, within the 
           clientÆs domain, to which the client is a member. 
   GroupIds - This field contains an array of the relative Ids and 
           attributes of the groups in the clientÆs domain of which the 
           client is a member. 
   UserFlags - This field contains information about which fields in 
           this structure are valid. The two bits that may be set are 
           indicated below. Having these flags set indicates that the 
           corresponding fields in the KERB_VALIDATION_INFO structure 
           are present and valid. 
            
           #define LOGON_EXTRA_SIDS             0x0020 
           #define LOGON_RESOURCE_GROUPS        0x0200 
            
   LogonDomainId - This field contains the SID of the clientÆs domain. 
           This field is used in conjunction with the UserId, 
           PrimaryGroupId,and GroupIds fields to create the user and 
           group SIDs for the client. 
   SidCount - This field contains the number of SIDs present in the 
           ExtraSids field. This field is only valid if the 
           LOGON_EXTRA_SIDS flag has been set in the UserFlags field. 
   ExtraSids - This field contains a list of SIDs for groups to which 
           the user is a member. This field is only valid if the 
           LOGON_EXTRA_SIDS flag has been set in the UserFlags field. 
   ResouceGroupCount - This field contains the number of resource 
           groups in the ResourceGroupIds field. This field is only 
           valid if the LOGON RESOURCE_GROUPS flag has been set in the 
           UserFlags field._  
   ResourceGroupDomainSid - This field contains the SID of the resource 
           domain. This field is used in conjunction with the 
           ResourceGroupIds field to create the group SIDs for the 
           client. 
   ResourceGroupIds - This field contains an array of the relative Ids 
           and attributes of the groups in the resource domain of which 
           the resource is a member. 
    
   When used in the KERB_VALIDATION_INFO, this is NDR encoded. The 
   FILETIME type is defined as follows: 
    
        typedef unsigned int DWORD; 
         
        typedef struct _FILETIME { 
            DWORD dwLowDateTime; 
  
Brezak                 Category - Informational                      4 
               Windows 2000 Kerberos Authorization Data   October 2002 
 
 
            DWORD dwHighDateTime; 
        } FILETIME; 
    
   Times are encoded as the number of 100 nanosecond increments since 
   January 1, 1601, in UTC time. 
    
   When used in the KERB_VALIDATION_INFO, this is NDR encoded. The 
   UNICODE_STRING structure is defined as: 
    
        typedef struct _UNICODE_STRING 
            USHORT Length; 
            USHORT MaximumLength; 
            [size_is(MaximumLength / 2), length_is((Length) / 2) ] 
        USHORT *  Buffer; 
        } UNICODE_STRING; 
    
   The Length field contains the number of bytes in the string, not 
   including the null terminator, and the MaximumLength field contains 
   the total number of bytes in the buffer containing the string. 
    
   The GROUP_MEMBERSHIP structure contains the relative ID of a group 
   and the corresponding attributes for the group. 
    
        typedef struct _GROUP_MEMBERSHIP { 
            ULONG RelativeId; 
            ULONG Attributes; 
        } *PGROUP_MEMBERSHIP; 
    
   The group attributes must be: 
    
        #define SE_GROUP_MANDATORY              (0x00000001L) 
        #define SE_GROUP_ENABLED_BY_DEFAULT     (0x00000002L) 
        #define SE_GROUP_ENABLED                (0x00000004L) 
    
   The SID structure is defined as follows: 
    
         
        typedef struct _SID_IDENTIFIER_AUTHORITY { 
            UCHAR Value[6]; 
        } SID_IDENTIFIER_AUTHORITY, *PSID_IDENTIFIER_AUTHORITY; 
         
   The constant value for the NT Authority is  
    
        #define SECURITY_NT_AUTHORITY           {0,0,0,0,0,5} 
         
        typedef struct _SID { 
           UCHAR Revision; 
           UCHAR SubAuthorityCount; 
           SID_IDENTIFIER_AUTHORITY IdentifierAuthority; 
           [size_is(SubAuthorityCount)] ULONG SubAuthority[*]; 
        } SID, *PSID; 
    
    
  
Brezak                 Category - Informational                      5 
               Windows 2000 Kerberos Authorization Data   October 2002 
 
 
   Other authorities are defined in the Microsoft Developer Network 
   Development Kit 3. 
   The SubAuthorityCount field contains the number of elements in the 
   actual SubAuthority conformant array. The maximum number of 
   subauthorities allowed is 15. 
    
   The KERB_SID_AND_ATTRIBUTES structure contains entire group SIDs and 
   their corresponding attributes: 
    
        typedef struct _KERB_SID_AND_ATTRIBUTES { 
            PSID Sid; 
            ULONG Attributes; 
        } KERB_SID_AND_ATTRIBUTES, *PKERB_SID_AND_ATTRIBUTES; 
         
   The attributes are the same as the group attributes defined above. 
   
5. Signatures (PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM) 
 
   The PAC contains two digital signatures: one using the key of the 
   server, and one using the key of the KDC. The signatures are present 
   for two reasons. First, the signature with the serverÆs key is 
   present to prevent a client from generating their own PAC and 
   sending it to the KDC as encrypted authorization data to be included 
   in tickets. Second, the signature with the KDCÆs key is present to 
   prevent an untrusted service from forging a ticket to itself with an 
   invalid PAC. The two signatures are sent in PAC_INFO_BUFFERs of type 
   PAC_SERVER_CHECKSUM and PAC_PRIVSVR_CHECKSUM respectively. 
    
    
   The signatures are contained in the following structure: 
    
        typedef struct _PAC_SIGNATURE_DATA { 
            ULONG SignatureType; 
            UCHAR Signature[1];      
        } PAC_SIGNATURE_DATA, *PPAC_SIGNATURE_DATA; 
    
   The fields are defined as follows: 
    
   SignatureType - This field contains the type of checksum used to 
           create a signature. The checksum must be a keyed checksum. 
    
   Signature - This field consists of an array of bytes containing the 
           checksum data. The length of bytes may be determined by the 
           wrapping PAC_INFO_BUFFER structure. 
    
   For the serverÆs checksum, the key used to generate the signature 
   should be the same key used to encrypt the ticket. Thus, if the 
   enc_tkt_in_skey option is used, the session key from the serverÆs 
   TGT should be used. The Key used to encrypt ticket granting tickets 
   is used to generate the KDCÆs checksum. 
    
   The checksums are computed as follows: 
    
  
Brezak                 Category - Informational                      6 
               Windows 2000 Kerberos Authorization Data   October 2002 
 
 
     1. The complete PAC is built, including space for both checksums 
     2. The data portion of both checksums is zeroed. 
     3. The entire PAC structure is checksummed with the serverÆs key, 
        and the result is stored in the serverÆs checksum structure. 
     4. The serverÆs checksum is then checksummed with the KDC's key. 
     5. The checksum with the KDC key is stored in the KDC's checksum 
        structure. 
 
6. PAC Request Pre-Auth Data 
    
   Normally, the PAC is included in every pre-authenticated ticket 
   received from an AS request. However, a client may also explicitly 
   request either to include or to not include the PAC. This is done by 
   sending the PAC-REQUEST preauth data. 
    
   This is an ASN.1 encoded structure. 
    
        KERB-PA-PAC-REQUEST     ::= SEQUENCE { 
                include-pac[0] BOOLEAN -- if TRUE, and no pac present, 
                                       -- include PAC. 
                                       ---If FALSE, and pac 
                                       -- PAC present, remove PAC 
        }  
    
   The fields are defined as follows: 
    
   include-pac - This field indicates whether a PAC should be included 
           or not. If the value is TRUE, a PAC will be included 
           independent of other preauth data. If the value is FALSE, 
           then no PAC will be included, even if other preauth data is 
           present. 
    
   The preauth ID is: 
        #define KRB5_PADATA_PAC_REQUEST         128 
    
7. Security Considerations 
 
   Before the PAC data is used for access control, the 
   PAC_SERVER_CHECKSUM signature MUST be checked. This will verify that 
   the provider of the PAC data knows the server's secret key.  
   Validation of the PAC_PRIVSVR_CHECKSUM is OPTIONAL. It is used to 
   verify that the PAC was issued from the KDC and not placed in the 
   ticket by someone other than the KDC with access to the service key. 
    
   Caution must be used with accepting the SIDs present in the logon-
   info part of the PAC. Only SIDs from a domain that is authoritative 
   for a particular domain's SIDs should be used in the construction of 
   access tokens. If a SID is found to be from outside of a domain's 
   authoritative SID namespace, it MUST be ignored for purposes of 
   access control. 
    
8. References 
    
  
Brezak                 Category - Informational                      7 
               Windows 2000 Kerberos Authorization Data   October 2002 
 
 
 
   1 Kohl, J., Neuman, C., "The Kerberos Network Authentication Service 
      (V5)", RFC 1510, September 1993 
    
   2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 
     Levels", BCP 14, RFC 2119, March 1997 
    
   3 Microsoft Developer's Network - http://msdn.microsoft.com 
    
 
9. Author's Addresses 
    
   John Brezak 
   Microsoft Corporation 
   One Microsoft Way 
   Redmond, Washington 
   Email: jbrezak@microsoft.com 




































  
Brezak                 Category - Informational                      8 
               Windows 2000 Kerberos Authorization Data   October 2002 
 
 
    
Full Copyright Statement 
 
   Copyright (C) The Internet Society (1999).  All Rights Reserved. 
    
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works.  However, this   
   document itself may not be modified in any way, such as by removing   
   the copyright notice or references to the Internet Society or other   
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
    
   This document and the information contained herein is provided on an 
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 
    
    
    






















  
Brezak                 Category - Informational                      9 