Select the product you need help with
- Internet Explorer
- Windows Phone
- More products
How to mark an attribute as confidential in Windows Server 2003 Service Pack 1
Article ID: 922836 - View products that this article applies to.
In the Active Directory directory service for Microsoft Windows Server 2000 and for Microsoft Windows Server 2003, it is difficult to prevent an authenticated user from reading an attribute. Generally, if the user requests READ_PROPERTY permissions for an attribute or for its property set, read access is granted. Default security in Active Directory is set so that authenticated users have read access to all attributes. This article discusses how to prevent read access for an attribute in Windows Server 2003 Service Pack 1 (SP1).
This article describes how to mark an attribute as confidential in Windows Server 2003 Service Pack 1.
Windows Server 2003 SP1 introduces a way to mark an attribute as confidential. To do this, you modify the value of the searchFlags attribute in the schema. The searchFlags attribute value contains multiple bits that represent various properties of an attribute. For example, if bit 1 is set, the attribute is indexed. Bit 7 (128) designates the attribute as confidential.
Requirements and constraintsOnly domain controllers that are running Windows Server 2003 SP1 or a later version enforce the read access check for confidential attributes. The confidential attributes feature is tied to the installation of Windows Server 2003 SP1 or a later version. This feature does not depend on whether a domain or a forest functional level is enabled.
Do not use the confidential attributes feature unless the following conditions are true:
TestingAs you would test any change to Active Directory and any schema extension, we recommend that you thoroughly test attribute changes in a lab that mirrors your production forest. Testing helps guarantee that the procedure works smoothly and that problems are detected.
Access control checksAfter Windows Server 2003 SP1 is installed and after Active Directory performs a read access check, Active Directory checks for confidential attributes. If confidential attributes exist and if READ_PROPERTY permissions are set for these attributes, Active Directory will also require CONTROL_ACCESS permissions for the attributes or for their property sets.
Note The Full Control permission setting includes the CONTROL_ACCESS permission.
Active Directory performs a read access check on an object in the following cases:
Generic and object-specific access control entriesEvery object in Active Directory has access control information that is associated with it. This information is known as a security descriptor. The security descriptor controls the type of access that is available to users and to groups. The security descriptor is automatically created when the object is created.
The set of permission entries in a security descriptor is known as a discretionary access control list (DACL). Each permission entry in the DACL is known as an access control entry (ACE).
You can grant permissions to the object or grant CONTROL_ACCESS permissions to confidential attributes by using a generic or object-specific access control entry on the object. You can grant permissions by stamping them explicitly on the object or by using inheritance. Inheritance means that you set an inheritable access control entry on a container that is higher in the container hierarchy.
Generic and object-specific access control entries are basically the same. What sets them apart is the degree of control that the access control entries offer over inheritance and over object access. Generic access control entries apply to the whole object. Object-specific access control entries offer more control over what objects inherit the access control entry. When you use an object-specific access control entry, you can specify the attribute or the property set of the object that will inherit the access control entry.
When you use the confidential attributes feature, CONTROL_ACCESS permission is granted by assigning a generic access control entry to a user. If CONTROL_ACCESS permission is granted by assigning an object-specific access control entry, the user will only have CONTROL_ACCESS permission to the confidential attribute.
The following permissions are granted when you use a generic access control entry:
The user interface in Windows Server 2003 does not expose Control_Access permissions. You can use the Dsacls.exe tool to set Control_Access permissions by assigning a generic access control entry. However, you cannot use this tool to assign an object-specific access control entry. The only tool that can set Control_Access permissions by assigning an object-specific access control entry is the Ldp.exe tool.
Note An in-depth discussion of access control is beyond the scope of this article. For more information about access control, visit the following Microsoft Web sites:
How to use inheritanceIn a large domain, it is not practical to manually assign control access to a user or to a group for every object that has a confidential attribute. The solution is to use inheritance to set an inheritable access control entry that is higher in the container hierarchy. This access control entry applies to all child objects of that container.
By default, inheritance is enabled for all organizational units (OU) and for all user accounts, except for the built-in administrator account. If you create user accounts that have inheritance disabled or if you create administrative accounts by copying the built-in administrator account, you must enable inheritance for these accounts. Otherwise, the inheritance model does not apply to these accounts.
How to create a confidential attribute
The following sample .ldf files can be used to do the following:
Sample .ldf filesThe following code adds an attribute to the schema and then marks the attribute as confidential.
The following code adds the new attribute to the user class.
How to let non-administrative users see the attribute dataNote The following procedures require that you use the Ldp.exe tool that is included with Windows Server 2003 R2 Active Directory Application Mode (ADAM). Other versions of the Ldp.exe tool cannot set permissions.
How to manually set Control_Access permissions on a user account
How to use inheritance to assign Control_Access permissionsTo use inheritance, create an access control entry that grants Control_Access permissions to the desired users or groups that are higher in the container hierarchy than the objects that have confidential attributes. You can set this access control entry at the domain level or at any point in the container hierarchy that works well for an enterprise. The child objects that have confidential attributes must have inheritance enabled.
To assign Control_Access permissions, follow these steps:
How to determine the systemFlags attribute value when you use an existing attributeIf you use an existing object, you must verify what the current searchFlags attribute value is. If you add an object, you can define the value when you add the object. There are many ways to obtain the searchFlags attribute value. Use the method that works best for you.
To use the Ldp.exe tool to obtain the searchFlags attribute value, follow these steps:
128 + current searchFlags attribute value = new searchFlags attribute value
How to determine whether an attribute is a base schema attributeTo determine whether an attribute is a base schema attribute, use the Ldp.exe tool to examine the systemFlags attribute value.
LDP output of Employee-ID – systemFlags: 0x10 = (FLAG_SCHEMA_BASE_OBJECT)In the following sample Ldp.exe output, Ldp.exe identifies the systemFlags attribute value as 0x10 and as a base schema attribute. Therefore, you cannot mark this attribute as confidential.
LDP output of Employee-Number systemFlags: 0x0 = ( )In the following sample Ldp.exe output, Ldp.exe identifies the systemFlags attribute value as 0. This attribute can be marked as confidential.
Object identifiersWhen you add an attribute or a class object to the schema, one of the required attributes is the object identifier (also known as OID). Object identifiers are used to uniquely define object classes and attributes. Make sure that your company obtains a unique object identifier to identify its attribute. Tools that generate object identifiers, such as the Oidgen.exe tool, are not supported. To obtain an object identifier from Microsoft, visit the following Microsoft Web site:
Attribute syntaxThe attributeSyntax attribute is also required to add new objects to the schema. This attribute defines the storage representation, byte ordering, and matching rules for comparisons of property types. The syntax defines whether the attribute value must be a string, a number, or a unit of time. Each attribute of every object is associated with exactly one syntax. Make sure that you select the correct attribute syntax for the new attribute. This is especially important if you synchronize a Lightweight Directory Access Protocol (LDAP) directory with another LDAP directory. After the attribute is added to the schema, its attribute syntax cannot be changed.
For more information about the attributeSyntax attribute, visit the following Microsoft Web site:
hhttp://msdn.microsoft.com/en-us/library/ms675236(VS.85).aspxFor more information about values in the searchFlags attribute, visit the following Microsoft Web site, and then search for "Effects of Indexing on Search Behavior":
Article ID: 922836 - Last Review: October 11, 2007 - Revision: 3.4