Project Description
Provides sample code for performing common activities in Active Directory using custom .NET code. As with any database access library, this is intended as a library to encapsulate the functionality required to perform AD functions without embedding that type of lower-level code in your other projects.

Features
  • ConnectionManager - tests existing/specified domain controllers, and maintains a cache of known good/offline dc's. When an activity is performed, the bind path is modified to insert a domain controller from the known good list. If an error occurs during an operation, the faulted dc is removed from the good list, placed on the offline list, and the operation is re-attempted using another dc.
  • Query samples. Specific idioms are provided for performing common queries. There are overloads to specify if using the global catalog or local partition, search filter, and the attributes to retrieve..
  • Operation methods. Various methods for adding, removing, moving, or modifying objects such as users or computers, organization units, and the various attribute types.
  • Group Membership. Various methods/examples for performing types of group membership queries.
  • Complex Types. For most of the commonly-used objects such as users, groups, computers, there are complex types that include the most commonly-used attributes.

This project is referenced in other projects on CodePlex, so I thought it may be useful to publish it here.

The companion Tests projects provides a few code samples that demonstrate the idioms for how to use the code.

The ConnectionManager attempts to maintain an affinity with a particular domain controller for a given domain. This is due to a typical Active Directory environment with multiple domain controllers may never be 100% consistent; there are typically some differences in the database between dc's. One approach to maintain this affinity when performing an operation is to maintain a handle or reference to the same DirectoryEntry between operations. In practice, this is of only limited usefulness, and to have a robust Enterprise-class application, a more comprehensive strategy is required.

During review of app.config, you may notice that it is possible to specify Sites that are used to populate the list of available domain controllers, and domain controllers that are 'preferred' and/or should be the least used. In a large distributed environment with a lot of spoke sites and one or two data centers, it may be preferable to use only the data center dc's on the list of available dc's. If there is a recovery site, where domain controllers frequently come online and go offline when testing is performed, it may be a good idea to leave the recovery sites dc's on the list of available dc's, but specify that they are the least used.

Last edited Mar 28, 2013 at 6:25 PM by GregAskew, version 8