本文以 Visual Studio 2008 的预发布版为基础。文中包含的所有信息均有 可能变更。
本文讨论:
System.DirectoryServices.AccountManagement 类
Active Directory 域服务
Active Directory 轻型目录服务 (AD LDS)
管理用户、计算机和组主体
本文使用了以下技术:
.NET Framework 3.5, Visual Studio 2008
目录
目录服务编程体系结构
建立上下文
创建用户帐户
创建组和计算机
管理组成员身份
查找 自己
查找匹配项
让困难的搜索操作变简单
验证用户
扩展性模型
结论
目录是企业应用程序开发非常重要的组件，但却很少 有人掌握它。针对 Windows 平台，Microsoft 提供了三个主要目录平台： Active Directory 域服务、每台 Windows 计算机上的本地安全帐户管理 器 (SAM) 数据存储，以及比较新的 Active Directory 轻型目录服务或 AD LDS （即您先前已经知道的 Active Directory 应用程序模式或简称 ADAM）。虽然 大多数的企业开发人员至少了解 SQL 编程的基本知识，但是却很少有人有目录 服务编程的经验。
Microsoft .NET Framework 的最初版本在 System.DirectoryServices 命名空间内为目录服务编程提供了一组类。这些类 是一个简单的托管互操作层，位于现有的基于 COM 的操作系统组件（具体说是 Active Directory 服务接口或 ADSI）之上。这种编程模型具备相当强大的功能 ，并且，与完整的 ADSI 模型相比，它更为简约通用。
在 .NET Framework 2.0 中，Microsoft 已将一些功能添加到其 System.DirectoryServices，并提供了两个新的命名空间： System.DirectoryServices.ActiveDirectory 和 System.DirectoryServices.Protocols。（我们会在整篇文章中分别将其称为 ActiveDirectory 命名空间和 Protocols 命名空间。）ActiveDirectory 命名 空间引入了丰富的新类，以便对目录基础结构级组件（例如服务器、域、林、架 构和副本）进行强类型化管理。Protocols 命名空间则专攻另一个方向，即为轻 型目录访问协议 (LDAP) 编程提供备用 API。这直接与 Windows LDAP 子系统 (wldap32.dll) 配合工作，完全跳过 ADSI COM 互操作层（请参见图 1）。
Figure 1Microsoft Directory Services Programming Architecture
开发人员仍然眷恋 ADSI 中的某些强类型化接口，他 们之前将这些接口用于管理安全主体，例如 Users 和 Groups。您可以使用 System.DirectoryServices 中更通用的类来执行大部分此类任务，但是这些操 作并不像您想像的那么简单，很多任务都非常模糊。在 .NET Framework 3.5 中 ，Microsoft 添加了专为管理安全主体设计的新命名空间： System.DirectoryServices.AccountManagement，从而解决了这个问题。（在本 文中我们将 System.DirectoryServices.AccountManagement 称为 AccountManagement 命名空间。）
这个新命名空间有三个主要目标：简 化跨三个目录平台的主体管理操作；不管底层目录为何，使主体管理操作保持一 致；以及为这些操作提供可靠的结果，这样您就不必了解每一个注意事项和每一 种特殊情况。
在等待 .NET 逐步完善的这几年中，Microsoft 通过为利 用 NET 功能的这些功能提供更好的 API，同时也对诸如 AD LDS 的新目录平台 提供更好的支持，实际上早已胜过了它之前在 ADSI 中的表现。