Search Flags and Indexing

We need to consider two more things when adding new attributes to the schema: how they will be indexed, and what other types of behavior we wish them to support. In Active Directory and ADAM, two flags control these behaviors: searchFlags and systemFlags. Both of these attributes represent a set of bitwise flags. Let's try to understand how they work so that we can set them appropriately.

searchFlags

Table 7.3 shows the values for the various searchFlags enumeration members and describes their use.

Table 7.3. Active Directory and ADAM searchFlags values

Flag Value	Behavior
1 (bit 0)	The attribute is indexed.
2 (bit 1)	The attribute is indexed and is also indexed in each container, so searches at a specific point in the hierarchy may be optimized. Requires 1 to be set as well.
4 (bit 2)	Add this attribute to the ambiguous name resolution (ANR) set (see Chapter 4). The attribute must also be indexed, so 1 (bit 0) must also be set.
8 (bit 3)	Specifies that the attribute value is preserved when the object is deleted (turned into a tombstone object). By default, most attribute values are cleared on deletion.
16 (bit 4)	Specifies that the attribute will be copied when the object is copied.
32 (bit 5)	Specifies that a tuple index for the attribute will be created. This improves searches where the wildcard appears at the front of the search stringfor example, (sn=*mith). Note that this feature requires Windows Server 2003.
64 (bit 6)	Special index value used to enable Virtual List View (VLV) searches (see Chapter 5) on ADAM for versions past Windows Server 2003 SP1.
128 (bit 7)	Marks the attribute as Confidential in Windows Server 2003 SP1+. If this flag is set, the attribute data may be read only by domain administrators (by default), even if the ACL on the object would grant access to the data otherwise.

Unlike the systemFlags values, all of the flag values in searchFlags are intended for use by "end-user" schema enhancements. Generally, if we will be querying on the attribute, we will want to index it. Note that link value paired attributes are implicitly indexed on Windows Server 2003, so it is not necessary to set this flag in that case.

The flags generally speak for themselves. As with any database indexing, there is an inherent performance and storage implication for indexing, so we should make sure to index judiciously. Multivalued attributes can be especially costly to index.

ANR (see Chapter 4) is not something that is generally used, unless we are building some kind of address book lookup function. Remember that ANR searches can be especially costly, so definitely think twice before setting this value.

From Chapter 4, we learned about substring searches. Tuple indexes are a type of index meant to enhance these types of searches. Tuple indexes are also especially expensive and will provide a real performance benefit only if the substring searched is three characters or longer.

To use VLV searches on ADAM, we should make sure we have Windows Server 2003 SP1, and that we set the 64 value (bit 6) along with the 1 value (bit 0). Otherwise, VLV will not work properly.

The new 128 (bit 7) flag is especially intriguing, as it provides an easy mechanism to hide data in Active Directory without having to use elaborate ACL schemes. We might use this for storing Social Security numbers or something similar, although this data will still be available to domain administrators. As such, we should consider its use carefully.

The MSDN documentation[4] provides more detail on searching behavior and on these flag values.

[4] www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/8196d68e-776a-4bbc-99a6-d8c19f36ded4.mspx

systemFlags

Unlike searchFlags, many of the systemFlags values are not intended for general use. For example, Active Directory and ADAM provide no extensibility mechanism for populating constructed attributes, so we probably will not be setting bit 2. In general, we probably should not be setting anything other than bit 0 or 1. Table 7.4 provides the full documentation.

Table 7.4. Active Directory and ADAM systemFlags values

Flag Value	Behavior
1 (bit 0)	Prevents an attribute from being replicated.
2 (bit 1)	Adds the attribute to the global catalog in Active Directory only, not in ADAM.
4 (bit 2)	Indicates a constructed attribute.
16 (bit 4)	Indicates that an attribute is Class 1, which essentially means it is part of the base schema and has special rules applied to it. Generally, only Microsoft uses this, but OEMs who bundle ADAM with their product might use it as well.
32 (bit 5)	Indicates that an attribute is available only via a baselevel search.
33554432 (bit 26)	The object is deleted immediately instead of being moved to the Deleted Objects container.
67108864 (bit 27)	The object cannot be moved to a new location in the directory.
134217728 (bit 28)	The object cannot be renamed.
268435456 (bit 29)	Allows an object in the Configuration partition to be moved with restrictions. It is not set by default. Note that this value must be set at creation time and cannot be changed later.
536870912 (bit 30)	Allows an object in the Configuration partition to be moved. It is not set by default. Note that this value must be set at creation time and cannot be changed later.
1073741824 (bit 31)	Allows an object in the Configuration partition to be renamed. It is not set by default. Note that this value must be set at creation time and cannot be changed later.
2147483648 (bit 32)	The object cannot be deleted at all.

We are uncertain what bits 3 and 625 do, as Microsoft does not officially document them.