3.1 Logon Authorization Information

The first of the PAC_INFO_BUFFER (section 2.4) structures indicates a logon information structure. This structure begins at offset 0x0000005E in this example, as noted previously. This KERB_VALIDATION_INFO structure is a complex structure that is NDR-encoded.

 00000050                                            01 10                ..
 00000060  08 00 cc cc cc cc a0 04 00 00 00 00 00 00 00 00  ................
 00000070  02 00                                            ..

The first 8 bytes, from 0x0000005E through 0x00000065, comprise the common RPC header for type marshalling. The next 8 bytes, from 0x00000066 through 0x0000006D, comprise the RPC type marshalling private header for constructed types. The RPC specification for type marshaling is specified in [MS-RPCE] section 2.2.6, and is the authoritative source for the meaning of these items.

The next 4 bytes, from 0x0000006E through 0x00000071, are an RPC unique pointer referent, as defined in [C706] section 14.3.10.

Following the first 20 bytes, the simple types of the KERB_VALIDATION_INFO structure appear.

 00000070        d1 86 66 0f 65 6a c6 01                      ..f.ej..     

The first field is the LogonTime member, a FILETIME type. This is followed in succession by the five other time values:

 00000070                                ff ff ff ff ff ff            ......
 00000080  ff 7f ff ff ff ff ff ff ff 7f 17 d4 39 fe 78 4a  ............9.xJ
 00000090  c6 01 17 94 a3 28 42 4b c6 01 17 54 24 97 7a 81  .....(BK...T$.z.
 000000a0  c6 01                                            ..

The next six fields are the RPC_UNICODE_STRING structures. The RPC_UNICODE_STRING structures contain pointers and, therefore, use more advanced features of NDR encoding. The definitive reference for NDR encoding of complex types is [MS-RPCE], but for example purposes, the structure is encoded as follows.

 000000a0  c6 01 08 00 08 00 04 00 02 00                    ..........     

The first field in the RPC_UNICODE_STRING structure is the Length field, which indicates the length of the buffer, in bytes. In this example the length is 8 bytes. Similarly, the second field is the MaximumLength field. In this example, MaximumLength indicates that the maximum length of the buffer is also 8 bytes. The last field is the Buffer pointer. In this case, it is 0x00020004. For NDR-encoded messages, this is a referent to the actual data. The data is packed after the main structure; for KERB_VALIDATION_INFO, 0x000000D8 bytes in length, this begins at 0x0000014A in the following example:

 00000140                                04 00 00 00 00 00            ......
 00000150  00 00 04 00 00 00 6c 00 7a 00 68 00 75 00        ......l.z.h.u.

The NDR information about the referent, including the length, in element size, can be seen above. It is followed by the actual data, in this case, the string "lzhu". The remaining RPC_UNICODE_STRING structures are filled in a similar fashion:

 000000a0                                24 00 24 00 08 00            $.$...
 000000b0  02 00 12 00 12 00 0c 00 02 00 00 00 00 00 10 00  ................
 000000c0  02 00 00 00 00 00 14 00 02 00 00 00 00 00 18 00  ................
 000000d0  02 00                                            ..

These RPC_UNICODE_STRING structures point to other strings in the encoded structure in the same fashion, yielding "Liqiang (Larry) Zhu" in the FullName field and "ntds.bat" in the LogonScript field, while the ProfilePath, HomeDirectory, and HomeDirectoryDrive fields are all empty. Following the RPC_UNICODE_STRING structures are a number of simple scalar types, which can be easily decoded. The GroupIds field is a pointer to an array of structures, and thus enters the more complex encoding rules.

 000000e0        1c 00 02 00                                  ....         

0x0002001C is the referent, and the actual array of GROUP_MEMBERSHIP structures (26 in total) is as follows.

 000001d0  00 00 1a 00 00 00 61 c4 33 00 07 00 00 00 09 c3  ......a.3.......
 000001e0  2d 00 07 00 00 00 5e b4 32 00 07 00 00 00 01 02  -.....^.2.......
 000001f0  00 00 07 00 00 00 97 b9 2c 00 07 00 00 00 2b f1  ........,.....+.
 00000200  32 00 07 00 00 00 ce 30 33 00 07 00 00 00 a7 2e  2......03.......
 00000210  2e 00 07 00 00 00 2a f1 32 00 07 00 00 00 98 b9  ......*.2.......
 00000220  2c 00 07 00 00 00 62 c4 33 00 07 00 00 00 94 01  ,.....b.3.......
 00000230  33 00 07 00 00 00 76 c4 33 00 07 00 00 00 ae fe  3.....v.3.......
 00000240  2d 00 07 00 00 00 32 d2 2c 00 07 00 00 00 16 08  -.....2.,.......
 00000250  32 00 07 00 00 00 42 5b 2e 00 07 00 00 00 5f b4  2.....B[......_.
 00000260  32 00 07 00 00 00 ca 9c 35 00 07 00 00 00 85 44  2.......5......D
 00000270  2d 00 07 00 00 00 c2 f0 32 00 07 00 00 00 e9 ea  -.......2.......
 00000280  31 00 07 00 00 00 ed 8e 2e 00 07 00 00 00 b6 eb  1...............
 00000290  31 00 07 00 00 00 ab 2e 2e 00 07 00 00 00 72 0e  1.............r.
 000002a0  2e 00 07 00 00 00 0c 00 00 00 00 00 00 00 0b 00  ................
  

Calling out the first element, there is a RID of 0x0033C461, and 0x00000007 for the flags, indicating that the M, D, and E flags from KERB_SID_AND_ATTRIBUTES (section 2.2.1) are set. These RIDs are all relative to the domain SID in the LogonDomainId field in the following location:

 00000100                                28 00 02 00                  (... 

This referent, 0x00020028, leads to:

 000002e0                    01 04 00 00 00 00 00 05 15 00        ..........
 000002f0  00 00 59 51 b8 17 66 72 5d 25 64 63 3b 0b 0d 00  ..YQ..fr]%dc;...
  

This is a SID with four subauthorities. Decoded into string format, this SID is "S-1-5-21-397955417-626881126-188441444". The SID for the preceding group would be "S-1-5-21-397955417-626881126-188441444-3392609" with the RID from the GROUP_MEMBERSHIP structure appended to the SID of the domain.

The remainder of the KERB_VALIDATION_INFO structure is a straightforward use of these concepts.