Microsoft Active Directory is a directory service that provides the foundation for distributed networks built on Windows 2000 and later domain controllers. The Active Directory APIs provide access to the data stored in a directory.
Active Directory Architecture.
The directory system agent (DSA) is the process that provides access to the store. The store is the physical store of directory information located on a hard disk. Clients access the directory using one of the following mechanisms supported by the DSA:
- LDAP clients connect to the DSA using the LDAP protocol. LDAP is an acronym for Lightweight Directory Access Protocol. Active Directory supports LDAP 3.0, defined by RFC 2251, and LDAP 2.0, defined by RFC 1777.
- MAPI clients such as Microsoft Exchange connect to the DSA using the MAPI remote procedure call interface.
- Windows clients that use a previous version of Windows NT connect to the DSA using the Security Account Manager (SAM) interface.
- Active Directory DSA's connect to each other to perform replication using a proprietary remote procedure call interface.
Active Directory data model is derived from the X.500 data model. The directory holds objects that represent things of various sorts, described by attributes. The universe of objects that can be stored in the directory is defined in the schema. For each object class, the schema defines what attributes an instance of the class must have, what additional attributes it may have, and what object class can be a parent of the current object class.
Active Directory schema is implemented as a set of object class instances stored in the directory. This is very different than many directories that have a schema but store it as a text file read at startup. Storing the schema in the directory has many advantages. For example, user applications can read it to discover what objects and properties are available.
Active Directory can consist of many partitions or naming contexts. The distinguished name (DN) of an object includes enough information to locate a replica of the partition that holds the object. Many times however, the user or application does not know the DN of the target object or which partition might contain the object. The global catalog (GC) allows users and applications to find objects in an Active Directory domain tree, given one or more attributes of the target object. The global catalog contains a partial replica of every naming context in the directory. It contains the schema and configuration naming contexts as well. This means the GC holds a replica of every object in Active Directory but with only a small number of their attributes.
The global catalog is built automatically by Active Directory replication system. The replication topology for the global catalog is generated automatically. The properties replicated into the global catalog include a base set defined by Microsoft. Administrators can specify additional properties to meet the needs of their installation.
Interfaces for accessing the Active Directory.
- LDPA. The Lightweight Directory Access Protocol (LDAP) is a directory service protocol that runs on a layer above the TCP/IP stack, and provides a mechanism for connecting to, searching, and modifying Internet directories. The LDAP directory service is based on a client-server model. The function of LDAP is to allow access to an existing directory. The data model (data and namespace) of LDAP is similar to that of the X.500 OSI directory service, but with lower resource requirements due to its streamlined features. The associated LDAP API simplifies writing Internet directory service applications.
- ADSI. Active Directory Service Interfaces (ADSI) is a set of COM interfaces used to access the capabilities of directory services from different network providers in a distributed computing environment, to present a single set of directory service interfaces for managing network resources. Administrators and developers can use ADSI services to enumerate and manage the resources in a directory service, regardless of the network environment that contains the resource.
- System.DirectoryServices. System.DirectoryServices is a namespace in the .NET Framework that provides simple programming access to LDAP directories such as Active Directory. System.DirectoryServices is built on the Active Directory Service Interfaces (ADSI) API.
Using System.DirectoryServices namespace.
This article will emphasize in the benefits of using the namespace System.DirectoryServices, such as:
- Designed completely within common language runtime parameters. System.DirectoryServices leverages common language runtime features, such as garbage collection, custom indexer, and dictionaries (hashtables). It also offers other common language runtime features such as automatic memory management, efficient deployment, an object-oriented framework, evidence-based security and exception handling.
- Simple to use. Although ADSI scripting was effective for many tasks, C++ applications for ADSI are sometimes difficult to develop. System.DirectoryServices implements some basic ADSI tasks to enable more efficient and effective application development.
System administrators can use System.DirectoryServices to automate tasks to manage network resources in the directory, such as users and computers and also to build applications that search, create, or modify objects in a directory.
Requirements. System.DirectoryServices is supported on Windows Server 2003. System.DirectoryServices can be redistributed on Windows 98, Windows 98 SE and Windows NT 4.0, as long as the DS Client is installed on client machines. It can also be redistributed on Windows 2000 Windows XP.
I developed a lot of business objects which access the Active Directory, leveraging any application which needs the platform as its main database and for publishing objects in enterprise network.
It's defined the interface for the business objects which serve as changing or setting up the password for a specific user in the directory. Later this interface is implemented with a class, which instances make the real interaction with the directory.
In listing 1, it's shown the contract IADPasswdManager and the class ADPasswdManager.
using System;
using System.DirectoryServices;
namespace OLAActiveDirectory.Management
{
public interface IADPasswdManager
{
void ChangePassword(IADUser objUser,string strOldPasswd,string strNewPasswd);
void SetPassword(IADUser objUser,string strPasswd);
}
public class ADPasswdManager : IADPasswdManager
{
public ADPasswdManager()
{
}
public void SetPassword(IADUser objUser,string strPasswd)
{
DirectoryEntry objLoginEntry=objUser.DirectoryEntry;
if(objLoginEntry!=null)
{
objLoginEntry.Invoke("SetPassword", new object[]{strPasswd});
objLoginEntry.CommitChanges();
}
}
public void ChangePassword(IADUser objUser,string strOldPasswd, string strNewPasswd)
{
DirectoryEntry objLoginEntry=objUser.DirectoryEntry;
if(objLoginEntry!=null)
{
objLoginEntry.Invoke("ChangePassword",new object[]{strOldPasswd,strNewPasswd});
objLoginEntry.CommitChanges();
}
}
}
}
Listing 1.
A business entity must be defined for the users of the directory. It has all the information of a particular user in the directory knowing its Distinguished Name (DN).
It's defined an interface IADUser and the implementation is realized in the class ADUser as shown in the Listing 2.
using System;
using System.DirectoryServices;
using System.Collections;
namespace OLAActiveDirectory.Management
{
public interface IADUser
{
DirectoryEntry DirectoryEntry{get;}
bool IsUser{get;}
PropertyValueCollection this[string strKey]{get;}
}
public class ADUser :IADUser
{
private readonly DirectoryEntry m_objUserEntry;
public ADUser(string strLogin,string strRootPath)
{
DirectoryEntry objRootEntry=new DirectoryEntry(strRootPath);
DirectorySearcher objADSearcher=new DirectorySearcher(objRootEntry);
objADSearcher.Filter="(&(objectClass=user)(anr="+strLogin+"))";
SearchResult objResult=objADSearcher.FindOne();
this.m_objUserEntry=(objResult!=null)?objResult.GetDirectoryEntry():null;
}
public DirectoryEntry DirectoryEntry
{
get
{
return this.m_objUserEntry;
}
}
public PropertyValueCollection this[string strKey]
{
get
{
return this.m_objUserEntry.Properties[strKey];
}
}
public bool IsUser
{
get
{
return this.m_objUserEntry!=null;
}
}
}
}
Listing 2.
In the Presentation Layer resides an instance of the class ADUserInfoShower whose role is to create an information string for a specific user. This object is independent of the technology used for showing the user information. That is, this string can be rendered in a Web Browser, a Windows Client and a Mobile Device. In the listing 3, it's shown the code for this business object.
using System;
namespace OLAActiveDirectory.Management
{
public interface IADUserInfoShower
{
string GetInformation(IADUser objUser,string strSep);
}
public class ADUserInfoShower : IADUserInfoShower
{
private string prvInfoBuilder(IADUser objUser,string strSep)
{
string strResult;
strResult="Fullname:"+objUser["givenName"].Value+" "+objUser["sn"].Value;
strResult+=strSep+"Mail:"+objUser["mail"].Value;
strResult+=strSep+"Telephone(s):"+objUser["telephoneNumber"].Value;
foreach(string strPhone in objUser["otherTelephone"])
strResult+=strSep+strPhone;
return strResult;
}
public ADUserInfoShower()
{
}
public string GetInformation(IADUser objUser,string strSep)
{
return this.prvInfoBuilder(objUser,strSep);
}
}
}
Listing 3.