Search Technologies

Because searching for information is a primary function of network directories, the designers of LDAP made it a top priority. Active Directory, being a good LDAP citizen, provides excellent searching support, including some useful extensions of the LDAP specification.

This support is available to clients in various forms, the major technologies being ActiveX Data Objects (ADO) and the ADSI IDirectorySearch interface, both of which I'll discuss in this chapter. Generally, if you are using Microsoft Visual Basic or a scripting language, you'll use ADO technology to search Active Directory. If you're developing in C or C++, you can use ADO, IDirectorySearch, and other options. What's notable about the ADSI architecture is how the various technologies build on each other. The basic relationship between the search technologies is shown in Figure 5-1.

Figure 5-1 Relationships between Active Directory search technologies.

As with everything related to Active Directory, LDAP provides the foundation with the LDAP query operation. ADSI builds on this and provides the COM-based IDirectorySearch interface. On top of that, ADSI supplies an OLE DB provider. The formal name of this provider is the "OLE DB Provider for Microsoft Directory Services" and its programmatic name is ADsDSOObject. I will refer to this provider as the ADSI OLE DB provider. This provider exposes OLE DB defined interfaces that C and C++ applications can use to access Active Directory information in the same fashion as for any other database. Although similar in architecture, don't confuse the ADSI OLE DB provider with the ADSI providers for LDAP, WinNT, and others. An OLE DB provider is a component that uses OLE DB to expose data from a data source. An ADSI provider is a component that uses ADSI to expose data from a directory service.

A disadvantage of OLE DB interfaces is that they do not support Automation. In other words, they are not dual interfaces. To rectify this, Microsoft provides the set of database objects called ActiveX Data Objects. ADO is built on OLE DB, and I like to think of ADO as a high-level abstraction of OLE DB. ADO supports Automation, which allows Visual Basic and the scripting languages to access information available from OLE DB providers.

ADO uses the ADSI OLE DB provider, which in turn uses the IDirectorySearch interface exposed by ADSI. C and C++ applications can use IDirectorySearch directly, however, they lose the benefits of data source abstraction that ADO and OLE DB provide. IDirectorySearch provides the best performance because it is low-level and thus low-overhead.

If you are familiar with ADO or OLE DB from programming for a SQL database or even Microsoft Access and Jet databases, you'll be able to transfer that experience to searching Active Directory with ADO. In fact, you can make SQL-style queries against Active Directory.

Using the ADSI OLE DB provider does have a major limitation. It's currently restricted to read-only operations. You cannot use the SQL UPDATE command or any of the ADO methods that modify or delete records. This is not an issue generally because it's trivial to access the Active Directory object for updating after locating it in a search.

The ADSI OLE DB provider is read-only.

In the following sections , I'll cover searching Active Directory using ADO, Visual Basic, and the scripting languages. In a sample application later in the chapter, I'll demonstrate IDirectorySearch using C++. C and C++ developers should read the entire ADO section carefully, as many of the options and search techniques are directly applicable to IDirectorySearch. Of course, C and C++ developers can also use ADO or OLE DB from their applications, but they may prefer the low-level nature of IDirectorySearch.