On the Source Attribute page you can select, view or change the source attribute for the claim type. The source attribute is the Active Directory attribute from which the value is obtained for claims of this claim type.
The page provides a list allowing you to select the desired attribute. The list includes the attributes for the User, Computer, InetOrgPerson, ManagedServiceAccount, GroupManagedServiceAccount and Auxiliary classes of object, with the exception of:
- Attributes marked as defunct in the Active Directory schema
- Password attributes such as dBCSPwd, lmPwdHistory, and unicodePwd
- Attributes that are not replicated among domain controllers
- Attributes that are not available on read-only domain controllers
- Attributes with an Active Directory syntax type other than
- String: DN String, Unicode, NT Security Descriptor, or Object ID
- Integer or Large Integer
- Boolean
For an existing claim type, the page displays the claim type’s current source attribute, and allows you to select a different attribute of the same syntax type. However, changing the source attribute does not change the claim type’s ID.
The claim type identifier (ID) determines the Common Name (cn) of the claim type object in Active Directory. Normally, Active Roles automatically generates an ID when creating a claim type. The automatically generated ID has the following format:
ad://ext/attributeName:uniqueHexidecimalNumber
In this format, attributeName
stands for the LDAP display name of the claim type’s source attribute and uniqueHexidecimalNumber
is a randomly generated string of hexadecimal characters that ensures the uniqueness of the claim type’s ID.
To enable authorization scenarios where claims are used across a forest trust, you need to create claim types in both the trusted forest and trusting forest with the same claim type ID. Domain controllers in a trusting forest receiving claims from a trusted forest cannot understand these claims unless:
- Each claim has a claim type object created in both forests
- The claim type ID in the trusting forest is identical to the claim type ID in the trusted forest
- A Claim Transformation Policy object is applied to allow incoming claims across the forest trust
Therefore, when you create a claim type object, you may need to specify the appropriate claim type ID by hand. The option Set ID to a semantically identical claim type in a trusted forest serves this purpose, allowing you to type in an ID instead of having it created automatically. If you choose to enter an ID by hand, ensure that your ID string specifies a unique ID and conforms to the following format:
- Starts with the
ad://ext/
prefix
- The prefix is followed by 1 to 32 characters
- Does not contain space characters or these characters:
\ * ? " < > |
- If a slash mark (
/
) occurs after the ad://ext/
prefix, then the slash mark must be surrounded by a character on each side. The surrounding character must not be a colon (:
) or slash mark.
A valid example of an ID string is ad://ext/BusinessImpact
.
The option Set ID to a semantically identical claim type in a trusted forest is available only when you create a claim type object. The ID should not be changed on existing claim type objects. When you create a claim type object, it is advisable to let an ID be generated automatically unless a business need justifies otherwise, such as the use of claim transformation policies in a multi-forest environment. This ensures that the newly created claim type has a valid, unique ID.
The display name of the claim type object is used to represent the claim type as a choice throughout the user interface. Thus, when you configure a conditional expression for an access rule, the condition builder allows you to select a claim type from a list where each list item is the display name of a certain claim type object. For this reason, each claim type object must be given a unique display name. The display name accepts alphanumeric characters as valid data.
You can use the description of the claim type object to specify a short comment about the claim type. Comments typically include purpose, department usage, or business justification.