LDAP Searching Overview
In Chapter 3, we covered how we can connect to Active Directory or ADAM, bind to an object, and perform create, read, update, and delete (CRUD) operations. In each of the scenarios, we knew exactly where our object was located in the directory in order to construct our binding string (ADsPath). What happens when we do not know where the object is located, or we want to return a number of related objects? The facilities and methods for searching the directory are distinctly different from what we have used thus far.
LDAP Searches in ADSI
In ADSI, we had two sets of technologies that allowed us to search Active Directory. First, for automation languages like Visual Basic 6 and VBScript, we had ADO and its OleDb LDAP provider. This provider allowed us to use either a SQL-like syntax to specify our search, or a more typical LDAP style, and behind the scenes, ADO would connect to the OleDb provider, which in turn would connect to ADSI and the IDirectorySearch interface, which would ultimately connect to the native Win32 LDAP library that would perform the search. A number of layers were involved there, as well as some clunkiness in terms of trying to use an ADO Recordset to represent a hierarchical tree of data or to specify advanced search options, but it was easy to use and it performed relatively well.
On the other side, C/C++ developers could bypass all of the ADO and OleDb layers and directly tap into the ADSI IDirectorySearch interface, a low-level, nonautomation interface that is not available to scripting languages. This was a powerful alternative, but its downside was in the details. IDirectorySearch forces the developer to deal with many structures and pointers that need to be freed properly, and it requires significant chunks of code to properly initialize a search and interpret the results. The C++ requirement scares away most developers right off the bat, and the complexity of using the interface deters many more that try.
LDAP Searches in System.DirectoryServices
In System.DirectoryServices (SDS), we use the DirectorySearcher class to query the directory and read the attributes of the objects found. DirectorySearcher is the class that makes SDS so much more powerful than traditional ADSI scripting. It combines the ease of use of typical .NET Framework classes, while providing the full compliment of search features. Like ADO, it wraps the ADSI IDirectorySearch interface and all of its messy details. However, since the object model is specifically tailored to support LDAP searches, we are not compelled to accept any of the compromises forced on us by the ADO Recordset model. We get the power and performance previously available only to C++ developers, with the simplicity of ADO and a better programming model than that available with either of them!