Anyone who has developed a line of business or other type of application within a corporate setting has likely encountered the need to programmatically obtain a list of people at the organization and reference their various attributes to perform some kind of function. Perhaps you would like the end user to select an employee from a list so they can send them a system-generated e-mail. Or maybe you would like to present a listing of one or more departments with a breakdown of the employees belonging to them. One approach might be to configure a scheduled job that runs against your corporate directory and produces an output file that your application could read against. Another would be to write a data feed out of the directory into a persistent data store and reference the data store directly. But there are limitations to these types of approaches. In the first example, the information could not be referenced in real time. And what if you decide in a future iteration that you would like to make use of new attributes or change some of the ones your code is currently referencing? In both scenarios, not only do you have to change your code, but you must also reconfigure your data source to include the data elements you are interested in.
A favorable alternative to these strategies is to use C# to execute an LDAP query against your domain controller (Microsoft Active Directory as demonstrated in this article) and bind the results to the relevant objects in your application. In addition to eliminating the intermediate step of running an export or building a staging area, this type of approach offers real-time accessibility and affords the flexibility to design a factory class for creating any number of bind-able data sources comprised of any of the attributes available in your directory objects. In the section below, I present an example of a class that allows a caller to retrieve users’ real names, along with their e-mail addresses. It consists of one method that returns the query results as an enumerable object so that it can be bound to a control.
In the attached source code, we begin by declaring a typical static utility class called EmployeeList. The class has one method called emplList, which returns a list of key/value pairs representing an identifier for each employee, along with one additional attribute to associate with that employee (for example Key=DisplayName, Value=Mail). This would be useful in a situation where you wanted the user to select an employee from a dropdown list and have it auto populate a textbox with the employee’s e-mail address, for example. The method accepts two parameters, where the first denotes an AD attribute to use as the key and the other serves as the value. Note that passing in an attribute other than the four that are pre-defined later in the processing logic will result in a blank entry for the employee (for example Key=”, Value=”).
Next, we set up some objects to execute the LDAP query and store the results. After returning the employees we are interested in, we iterate through each item, evaluate the parameters passed by the caller and add the requested attributes of each employee to the list of employees. The routine ends by returning an enumerable collection (List<KeyValuePair<string, string>>) that we can bind to a control or data container.
In this brief article, I have demonstrated one practical implementation of LDAP within a C# application. I encourage the reader to think of ways to elaborate on this example and to use it as a foundation for solving similar types of problems he or she may encounter in their endeavors as an application developer.