So, in Part 1 we did the baseline work needed to find a user in Active Directory and produce the DirectoryEntry object .Net uses to encapsulate their information.  If you debug into the code and examine a DirectoryEntry object, you'll see that it is not terribly friendly.  In this post, we will create a custom object in .Net and examine the DirectoryEntry object, exposing the attributes we will need to further our goal of creating an Object Oriented method for representing a person's position within an organization.

Since the premise behind this solution is to denote "Ownership" of a resource in an organization, this object is called the Owner object.

using System;

using System.DirectoryServices;

namespace ActiveDirectory_Demo1.GlobalObjects.AuthorityObjects

{

    /// <summary>

    /// Summary description for Owner.

    /// </summary>

    public class Owner

    {

        public Owner(DirectoryEntry de)

        {

            originaldirectoryentry = de;

This is a standard class for creating an Object in .Net.  We will need the System.DirectoryServices namespace for accessing the components of the DirectoryEntry object used to instantiate our Owner object.  The attributes we will start out exposing are:

private string commonname;

private string id;

private string login;

private DirectoryEntry originaldirectoryentry;

private string homepage;

private string objecttype;

private string path;

And in the standard manner we define our publicly exposed GET & SET methods:

/// <summary>

/// Name of the user.

/// </summary>

public string CommonName

{

    get {  return commonname; }

    set { commonname = value; }    

}

/// <summary>

/// NativeGuid of the DirectoryEntry

/// </summary>

public string ID

{

    get { return id; }

    set { id = value; }

}

/// <summary>

/// Login used to authenticate

/// </summary>

public string Login

{

    get{ return login; }

    set{ login = value; }

}

/// <summary>

/// HomePage

/// </summary>

public string HomePage

{

    get 

    { 

        if(homepage == null)

        {

            if(this.originaldirectoryentry.Properties["wWWHomePage"].Value == null)

            {homepage = "";}

            else

            {homepage = this.originaldirectoryentry.Properties["wWWHomePage"].Value.ToString();}

        }

        return homepage; 

    }

    set { homepage = value;}

}

/// <summary>

/// Path from the oringinal DirectoryEntry

/// </summary>

public string Path

{

    get{ return path; }

    set{ path = value; }

}

You'll see the derivation code for HomePage in the get method.  Some of what we are interested in resides in the Attributes collection, others are directly off the DirectoryEntry object.  Lets go back to the constructor for the Owner object and populate the rest.

public Owner(DirectoryEntry de)

{

    originaldirectoryentry = de;

    ID = de.NativeGuid;

    CommonName = de.Name.Replace("CN=","");

    ObjectType = de.SchemaClassName.ToLower();

    Path = de.Path;

    if(ObjectType == "user")

    {

        Login = de.Properties["sAMAccountName"].Value.ToString();

    }

    else

    {

        Login = String.Empty;

    }

    //System.Collections.IDictionaryEnumerator enmr = de.Properties.GetEnumerator();

    //while (enmr.MoveNext())

    //{

    //    object o = enmr.Current;

    //    string x = "";

    //}

}

So, what we see here is the assignment of the

• orginaldirectryentry
• ID which is unique to the user in Active Directory and thus makes a good identifier for us
• CommonName as in a good display name
• ObjectType which is obviously a User in our case but could be a Group
• Path, so we can find our way back to this person when our object is saved or cached
• Login, again for the purposes of accessing this DirectoryEntry in the future.

You'll also notice a bit of commented out code.  As I have said, the DirectoryEntry object is not terribly friendly.  In order to get a list of the Attributes, you will have to either find them documented on line, or as this little gem shows, use the IDictionaryEnumerator to examine them.  If you uncomment this code and run it against an actual DirectoryEntry, a wealth of Active Directory information will pour out (including custom schema entries if your organization has extended AD).  So, if the above attributes don't cover what you need in your particular application, now you can discover them yourself. (BTW, that useless declaration of "string x" is only there for a convenient breakpoint to examine "o".)

Next up is the User and Group objects, because our Owner doesn't exist in a vacuum and ultimately we want to show their connection to the rest of the organization.