Directory Attributes

A directory entry is made up of various pieces of data. These pieces of data are known as attributes of the directory entry. Each attribute has a name, and the data associated with that name is the attribute's value. You use the attribute name when you want to retrieve data from a directory entry. Consider the following pieces of data: "Jane Clayton", "(800) 555-1111", "(800) 555-1112", "(800) 555-1113", "(800) 555-1114", "123 Main Street", "Seattle", "WA". Table 6-1 shows how this data would be stored in Active Directory. Notice that the otherTelephone attribute is multivalued.

Attribute Name Attribute Value

DisplayName
Display-Name

Jane Clayton

telephoneNumber
Telephone-Number

(800) 555-1111

street
Street-Address

123 Main Street

l
Locality-Name

Seattle

st
State-Or-Province-Name

WA

otherTelephone
Phone-Office-Other

(800) 555-1112
(800) 555-1113
(800) 555-1114

Table 6-1 Example attributes for an Active Directory entry.

Naming Conventions

Active Directory uses different naming conventions for attributes, the LDAP display name and the common name. With the LDAP display name, the first character is lowercase, there are no spaces between words, and words following the first word are capitalized. The common name convention usually capitalizes the first letter of each word and separates the words with a hyphen. Let's take, for example, the telephone number attribute. The Active Directory schema defines this attribute as having an LDAP display name of telephoneNumber and a common name of Telephone-Number. Sometimes, however, the names in each convention do not map directly. Consider the state attribute. It has an LDAP display name of st and a common name of State-Or-Province-Name. Since the LDAP display name is used in source code, I typically use that naming convention in this book. When necessary, I'll use the common name.

The common name and LDAP display name formats also apply to object classes. For example, organizationalUnit is the LDAP display name for the class that has a common name of Organizational-Unit.

Terminology

When working with Active Directory and ADSI, you'll frequently notice differences in the terminology of the various technologies involved. ADSI is a COM technology and uses terms such as interfaces, objects, and properties. To refer to these same items, Active Directory, which is based on Lightweight Directory Access Protocol (LDAP), leans toward terms like entries and attributes. In the previous chapter, you saw that ActiveX Data Objects (ADO) uses database terminology, such as records and fields. Table 6-2 compares the terminology.

LDAP ADSI ADO

Entry

Object

Record

Attribute

Property

Field

Result set

Result set

Record set

Table 6-2 Terminology comparison between LDAP, ADSI, and ADO.

Attributes vs. Properties

In this chapter, the differences in terminology become very apparent when dealing with directory data. LDAP, and thus Active Directory, use the term attribute to refer to the named values that make up a directory entry. COM, and thus ADSI along with ADO, use the term property to refer to a data member of a COM object.

In this book, I'll endeavor to use property or attribute according to which is appropriate for the context. I'll use the term attribute when referring to the pieces of data that make up a directory object, and I'll use the term property when referring to the ADSI/COM representation of an attribute. However, be aware that the Active Directory documentation, ADSI documentation, and other sources of information often use property and attribute interchangeably. Usually this isn't a problem, but keep in mind that attribute and property refer to different things.

In some cases, ADSI maps Active Directory attributes to interfaces as named properties. A named property is simply a piece of information that is part of the definition for a particular ADSI interface. For example, the IADsUser interface (which I'll discuss in Chapter 10) has the TelephoneNumber property that corresponds to the Active Directory telephoneNumber attribute.

When ADSI exposes an object's attribute through a named property, it always does so by using the Automation data types. Automation defines a small set of data types that can be natively passed from object to application using an interface. In most cases, the property is defined as accepting a binary string or a variant data type.

Briefly, a binary string, also known as a basic string, is a type of string that is prefixed with the number of characters in the string. Variants are a special data type that contain another data type, like a number, a date, a binary string, or even a reference to an object. Variants can also contain multiple values using arrays. Visual Basic handles the binary string and variant data types transparently. C and C++ developers can use the BSTR and VARIANT types to declare variables. Starting with version 6.0, Visual C++ makes working with binary strings and variants easier by using the _bstr_t and _variant_t classes, which I'll use in some of the code samples.

ADSI makes many of the commonly used attributes available as properties, however, not all attributes are directly mapped to ADSI properties. For example, the street attribute of the organizationalPerson class does not have a corresponding street property exposed on any of the ADSI interfaces. This is true of most of the 850 attributes defined in the schema. However, by using the Get method described later in this chapter, a program can access any attribute of an object.



MicrosoftR WindowsR 2000 Active DirectoryT Programming
MicrosoftR WindowsR 2000 Active DirectoryT Programming
ISBN: N/A
EAN: N/A
Year: 2001
Pages: 108

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net