While developing a .NET application, you may find that you need to access data that is stored in the Active Directory (AD). In these cases, if you’re not experienced with querying the AD, you may be tempted to create a copy of the data you need into a SQL database – however, this would amount to unnecessary data redundancy.
Fortunately, pulling data from the AD and using it in your application is much easier than you might think, and allows you to maintain data integrity by keeping your data in just one place. Also, SharePoint developers will be happy to learn that the AD can be queried from within a SharePoint add-in with the same code that I'll be sharing here.
First, let’s have a brief review of what the Active Directory (AD) is:
The AD is, for the purpose being discussed here, basically a database, except that its storage is hierarchical in nature. The data it stores typically regards the different components in a computer network. For example, a very common use of the AD is to store various pieces of information about a user (email address, name, phone number, title/job description, etc.) It may also contain data about user groups, such as the marketing department, IT, etc.
The first thing you’ll need to do is figure out what your AD domain path is. Also, if you're querying the AD from within a SharePoint add-in, you'll need to make sure that the user under which the Add-in web service is running has the proper permissions to access the AD.
And finally, it should be said at this point that you’ll need to use a few .NET assemblies that you may have never touched before:
using System.DirectoryServices; using AD = System.DirectoryServices.ActiveDirectory; using AP = System.DirectoryServices.Protocols; using AM = System.DirectoryServices.AccountManagement;
Example: Getting User Info
Something I often find myself having to do is get a list of all users in the AD, along with some piece of data associated with them. In this example, we'll be building a Dictionary that associates each user with the name of their manager.
First, let's show you the code, then we'll explain it.
After we’ve declared an empty dictionary, and retrieved our current path, we go ahead and create an instance of the DirectoryEntry class, passing our domain path as a parameter to its constructor. It should be noted that most of these DirectoryServices classes implement the IDisposable interface, meaning that we need to make sure we dispose of them after we’re done using them. To make this easier, of course, we utilize “using” statements here, so that our unmanaged resources automatically get released.
Next, we pass our DirectoryEntry as a parameter to the DirectorySearcher class constructor. The DirectorySearcher class’ main purpose is to allow us to query the AD.
Now that we have our DirectorySearcher instance, the wise thing to do is to use a filter to narrow our search results – if we skip this step, we sacrifice performance. So we assign to the DirectorySearcher’s Filter property a string that represents an LDAP query. In this case, our query “(&(objectCategory=User)(objectClass=person))” returns only objects that are in the User category and that implement the “person” class.
Now, for a given AD object, there can be dozens or even hundreds of properties. So to save on performance, we only want our query to return those properties which we’ll actually be using. To do this, we add property names as strings to the PropertiesToLoad property of our DirectorySearcher. Finally, we execute the query by calling the FindAll method of the DirectorySearcher. This returns a SearchResultCollection.
Iterating through this collection gives us access to SearchResult class instances. To avoid a null reference exception, I like to ensure that each SearchResult actually has the properties that I’m looking for. After that, getting our values is a simple matter of accessing the Properties property of the SearchResult with a string indexer. In this case, both are properties are simply strings, so I only want to return element zero, but if the property I was querying were an array, I would probably be iterating through it or doing some other operation.
So the final step here is to add the value of our user’s display name and the value of the “manager” property as a KeyValuePair in my Dictionary, and move on to the next SearchResult. Once we’ve iterated through the entire collection, we can simply return our Dictionary.
Learn more about our Microsoft Consulting Services