Schema Attributes for Directories

Every directory attribute contains the following four properties, which are particularly useful to ADSI programmers: Description, Access Category, Heuristics, and Search Flags. The settings of these properties affect the behavior of the attribute on which they exist.

Description

LDAP and Exchange Server do not share a common schema. When the LDAP server receives a request for a search to be done for a particular class, such as organizationalPerson, the Exchange directory schema does not have a class called organizationalPerson. This LDAP class needs to be mapped to an Exchange class. The Description field for Exchange classes and attributes holds the LDAP name. Therefore, on the Mailbox class definition in the Exchange Server schema, the Description field holds the string "organizationalPerson". This also applies to attributes. For example, the LDAP attribute sn is mapped to the Exchange Server attribute Last Name. When an Exchange attribute does not have a similar attribute in the LDAP schema, the Exchange name is generally used. For example, there is no attribute in the LDAP schema similar to "NT-Security-Descriptor". Therefore, "NT-Security-Descriptor" is also used for the LDAP name.

Access Category

The Access Category property of an attribute determines what rights a user needs to modify the attribute. The Access Category property value definitions are:

0: Only the system can modify the attribute

1: Users with Modify Admin Attributes permission can modify the attribute

2: Users with Modify User Attributes permission can modify the attribute

3: Users with Modify Permissions rights can modify the attribute

For example, the Exchange Phone Number attribute, which is mapped to the LDAP telephoneNumber attribute, has an Access Category of 2, which means that users with "Modify Users Attributes" permission on the object can change the value. The Primary Windows NT Account associated with a mailbox is granted "Modify Users Attributes" by default, so that the primary user of the mailbox can change the phone number in the directory.

Heuristics

The Heuristics attribute on a class or attribute determines its visibility in the directory. The Heuristics attribute is on the class or attribute definition in the schema. The Heuristics attribute is a binary bit-mask. Each bit in the binary number is like an on/off switch. Values are shown in the Exchange Administrator as decimal values. To interpret these values you need to convert the values to binary.

For example, the Exchange schema's Last Name attribute (mapped to sn in LDAP) has a heuristics value of 22. The decimal number 22 has a binary value of 10110. Bit 0 is the least significant bit or the bit farthest to the right. In this case, the value is 0. Looking in the table above, we see that if Bit 0 is 0, this attribute is replicated between sites by the Exchange directory replication connector. If we look at bit 1, we see that it is set to 1. Looking in the table we see that if bit 1 is set to 1, this attribute is available to anonymous and authenticated LDAP clients. So this means that the "Last Name" attribute in Exchange is available to LDAP clients.

When writing your Exchange application, always check the visibility of the attribute or class in the schema.

Search Flags

The Search Flags attribute in the Exchange schema defines which attributes are indexed in the Exchange directory. Anyone familiar with database technology knows that by indexing a field in a database, queries execute quicker. Indexing an attribute that is often used in searches can reduce query times from minutes to milliseconds.

The Search Flags value definitions are:

0: Attribute is not indexed and not included in the Outlook Ambiguous Name Resolution process.

1: Attribute is indexed but not included in the Outlook Ambiguous Name Resolution process.

2: Attribute is indexed and included in the Outlook Ambiguous Name Resolution process.

The Exchange attributes in the following table have a Search Flag value of 1.

The Exchange attributes in the following table have a Search Flag value of 2.

If your program requires frequent searching of a particular attribute, then you should set that attribute to be indexed. For example, the Exchange directory does not have an attribute named Employee ID. You would need to use one of the custom attributes. Imagine that everyone's employee ID was inserted into Custom Attribute 1 (mapped to Extension-Attribute-1 for LDAP) on their mailbox object in the Exchange directory. Your application has the employee ID from another source and needs to look up the name of the person that has this employee ID in the Exchange directory. If you were to do this search often, you would want to index Custom Attribute 1.

To create a definition for a custom attribute

1. Go to the definition of Custom Attribute 1 in the Exchange schema container.
2. Double-click the Search-Flags attribute in the list box on the left.
3. The value is 0 by default. Change it to 1.
4. Click Set.
5. Restart the Exchange Directory Service. Upon restart, the index is created.

Now Custom Attribute 1 is indexed in the Exchange directory. Searches on the value of this attribute will be performed much faster.

Note  Custom attributes are not exposed to the Outlook Client Address Book. To do this, you must customize the Outlook address template using the Exchange Administrator application. Also, if you wish to only access this attribute programmatically, and do not wish to expose it through the default Administrator application, then you should select custom attributes 11 through 15. However, as mentioned above, custom attributes 11 through 15 are viewable through the Exchange Administrator application's raw mode option. They are also viewable using LDAP import and export.