A DirectoryEntry is the .Net class used to encapsulate an entity in Active Directory representing a person, group or thing.  When we find what we are looking for in AD or interrogate it's attributes and members, we are doing so using a DirectoryEntry.  For the duration of this article we will be looking at DirectoryEntries which represent people unless otherwise specified, just know that people are only one thing that can appear in a DirectoryEntry object.

There are two ways we will look at to access this information.  One assumes you know exact ally who you are looking for and have their UserName, the other that you need to find them by searching their attributes.  The attributes we will search on are First and Last name.

First of all, the namespace in .Net for accessing Active Directory information is System.DirectoryServices.  Besides System, this is the only other namespace you need in your using statement:

using System;

using System.DirectoryServices;

Some basic information is needed to access your instance of Active Directory including the Default Domain, a UserName and Password with proper permissions. It is recommended that you use an account specifically created for communicating with AD.  (In the solution you will find this abstracted to a BaseObject)

protected const string DEFAULTDOMAIN = @"LDAP://127.0.0.1";

protected const string DEFAULTUSERNAME = @"MyLDAP_ServiceAccount";

protected const string DEFAULTPASSWORD = @"MyLDAP_ServiceAccount_Password";

Finally, there are two methods we will examine to access users within Active Directory.  This first one searches AD for any user with a First and/or Last Name beginning with the text passed in. The code shows a method returning a UserCollection object.  For now, disregard this as we don't want to get ahead of ourselves, we will examine the custom object referred to as a UserCollection in Part 3.

public UserCollection FindUsers(string FirstName, string LastName)

{

    DirectoryEntry serviceDE = new DirectoryEntry(DEFAULTDOMAIN, DEFAULTUSERNAME, DEFAULTPASSWORD, AuthenticationTypes.Secure);

    // dir searcher to find user

    DirectorySearcher searcher = new DirectorySearcher(serviceDE);

    string filterText = "(&(objectClass=user)";

    if(String.Empty != FirstName)

    {filterText += "(givenName="+FirstName+"*)";}

    if(String.Empty != LastName)

    {filterText += "(sn="+LastName+"*)";}

    filterText += ")";

    searcher.Filter = filterText;

    SearchResultCollection results = searcher.FindAll();

    UserCollection uc = new UserCollection();

    foreach(SearchResult result in results)

    {

        uc.Add(new User(result.GetDirectoryEntry(), false));

    }

    return uc;

}

What you see above, while unfamiliar is not really that complex.  If you have ever used the DataTable.Select() method or built a WHERE clause in SQL we are simply setting up a search string and using the .Net provided DirectorySearcher (which requires our service account to authenticate) to execute it against AD.  If you wanted to simply use this bit of code, you could create a DataTable out of the result set, and after the user chose the exact account they meant to access, use the method below to return the DirectoryEntry. 

And so, the final method assumes you have the complete LoginName of the account you want to access.  The DirectoryEntry object it returns is the object used by .Net to encapsulate AD entry information and is not one of the custom objects we will be creating later in this series.

DirectoryEntry serviceDE = new DirectoryEntry(DEFAULTDOMAIN, DEFAULTUSERNAME, DEFAULTPASSWORD, AuthenticationTypes.Secure);

// dir searcher to find user

DirectorySearcher searcher = new DirectorySearcher(serviceDE);

searcher.Filter = "(SAMAccountName=" + UserName + ")";

SearchResult result = searcher.FindOne();

return result.GetDirectoryEntry();

If you are following the code in the solution provided you will see it is cut out of 2 different files, ADQuery.cs and Authority.cs.  If you debug into the code and examine the DirectoryEntry object itself, you'll see how it is not terrible conducive to accessing it's members and attributes.  Next in Part 2, we will create our own object to do just that.