1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
|
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
|