You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add support for the undocumented @token. (0xfc) attribute token (Part of #135)
Windows implements a fifth conditional-expression attribute token, 0xfc, with the
SDDL prefix "@token.". MS-DTYP 2.4.4.17.8 documents only 0xf8-0xfb and its
2.5.1.1 ABNF admits only @user./@device./@resource., so a codec written to the
specification rejects it: Unmarshal failed with "unknown conditional-expression
token 0xfc" and the parser with "unknown attribute prefix".
The token is implemented in both directions by sechost.dll and advapi32.dll, which
parse "@token." into 0xfc and render 0xfc back to "@token.", and it is evaluated
by the kernel: ntoskrnl.exe's evaluator assigns it its own internal attribute
source class and reads it from the access token, not from the user-claims
collection that 0xf9 uses. It is therefore not a synonym for tokenUserAttr, and is
deliberately kept distinct.
Its wire encoding is identical to the other attribute tokens - token byte, DWORD
byte length, UTF-16 name - so the change is four small additions: the constant,
the prefix arm in parseAttribute, the serializer arm, and the token in the
decoder's attribute case. encode.go needed no change because it writes
Attribute.Token generically.
Serialization emits "@token." to match this package's existing capitalisation of
@user./@device./@resource. rather than Windows' all-caps rendering; parsing folds
case, so either form is accepted on input.
0 commit comments