在.NET Framework 3.5中管理目录安全主体

在.NET Framework 3.5中管理目录安全主体2010-11-27 MSDN / Joe Kaplan and Ethan本文以 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 中的表现。