Claims based access control, supported attributes

Bruno van Dooren 21 Reputation points

I developing an app where I get information from the user's access token. Specifically, the user claims.
The API documentation for retrieving that info specifies that there are several possible value types.

For the sake of testing I've been working in a sandbox to work with different claim types: string values, boolean, integer work fine.
But for the life of me, I cannot figure out how to use a SID as claims type.
There are attributes in AD which are SID.
I even extended my schema with a dummy SID attribute which I assigned to the user class.
I verified in ADSI Edit that I can edit the dummy attribute in users via attribute editor.
But no matter what I do, there doesn't seem to be a way to use SID attributes in a user claim.
When I try to add a claims type, I can only choose from a fixed list that doesn't seem to support SID or really anything else but string, int and bool.

So that leaves me with 2 questions which I hope someone can answer:

  1. is it documented what the requirements or restrictions are for attributes that are used in claims types?
  2. is it possible at all to work with SID claims types, or is this a case of the low level win32 API simply supporting more possible data types than are supported by Active Directory claims types?
Active Directory
Active Directory
A set of directory-based technologies included in Windows Server.
6,008 questions
Windows Server Security
Windows Server Security
Windows Server: A family of Microsoft server operating systems that support enterprise-level management, data storage, applications, and communications.Security: The precautions taken to guard against crime, attack, sabotage, espionage, or another threat.
1,751 questions
0 comments No comments
{count} votes

2 answers

Sort by: Most helpful
  1. Bruno van Dooren 21 Reputation points

    At this point I'm also updating this thread in case someone else ever asks the same question :)

    This piece of documentation suggests that certificate based claims can only be unicode strings

    But it is irrelevant where the claims come from because, following that trail of breadcrumbs leads to this:
    No matter where the claims come from, the spec says clearly that the only datatypes that are supported are:

    1. Int64Values
    2. Uint64Values
    3. StringValues
    4. BooleanValues

    So I think I have enough evidence that the win32 API for getting claims information from the user token via GetTokenInformation doesn't match the Directory Services specification.
    I'm still interested to hear from others if they have reason to believe otherwise.
    My guess is that the GetTokenInformation information is simply based on possible attribute value types, and Directory Services simply uses only a subset of those for processing claims.

    1 person found this answer helpful.
    0 comments No comments

  2. Bruno van Dooren 21 Reputation points

    From this page it -seems- as if this is indeed a case of the API being more flexible than the API supports.

    There are 3 possible sources for claims: AD, TransformationPolicy, and Certificates
    For AD values (and by extention those from TransformationPolicy because they are basically sourced from another domain so logically they too start as AD claims)
    I managed to create claims based on custom attributes that I added to the schema, but only for attributes that are integer or string for example. No SID. This makes sense, but is still no assurance concerning claims that come from a certificate.

    msDS-ClaimAttributeSource must contain an attribute that has one of the following syntaxes:
    String:,, or
    Integer:,, or

    For certificate sourced claims there are no outright requirements specified other than

    cn and display-Name must be unique
    msDS-ClaimPossibleValues cannot be specified if your claim is sourced from an OID
    msDS-ClaimAttributeSource cannot be specified

    0 comments No comments