使用 Active Directory

more ... 打印 E-mail 添加到收藏夹 评价 RSS (Issues) Add RSS to Any 相关信息 Live Spaces Digg This Slashdot del.icio.us BlogThis! Technorati

如果您曾经玩过 Windows PowerShell，那么您一定尝试过 Get-WMIObject cmdlet — 也称为 gwmi，这是它更为方便的别名。如我在上个月的专栏中所述，此 cmdlet 展示了 Windows PowerShell 相对于以前的脚本语言和命令行外壳的一项重要改进

（请参阅 technetmagazine.com/issues/2007/05/PowerShell）。通过 Gwmi 可以快速、方便地访问 Windows^® Management Instrumentation (WMI)，从而可以完成许多令人难以置信的工作，而无需编写复杂的脚本。

Get-WMIObject 就是尽显 Windows PowerShell™ 能力的一个最佳例证，每当我在课堂上展示它时，学生们总是能够将它的功能拓展到 Windows 管理的其他方面。但是，通常人们提出的第一个问题总是围绕着“存在 Get-ADSIObject cmdlet 吗？”。

ADSI 是 Active Directory^® 服务接口的缩写。尽管其名称如此，但实际上 ADSI 并不是特定于 Active Directory 的。该名称更为精确的解读应该是“Active（停顿）Directory Services Interface”（活动的目录服务接口），因为 ADSI 可以连接到各种目录服务，其中包括 Windows NT^® 样式的目录 — 注意，不仅仅是 Windows NT 域，还可以连接到独立的或成员计算机上的本地安全帐户管理器 (SAM)。凭借这种灵活性，Get-ADSIObject cmdlet 无疑用途广泛。但遗憾的是，Windows PowerShell 团队未能在其第一版中纳入该 cmdlet。

但这并不是说 Windows PowerShell 缺乏 ADSI 支持。事实上，Windows PowerShell 中的 ADSI 支持是如此优秀，您甚至不会注意到 Get-ADSIObject cmdlet 的缺失！

这一切始于 [ADSI] 类型适配器。我们需要对类型适配器稍加解释。我们知道 Windows PowerShell 是在 Microsoft^® .NET Framework（具体而言，是 2.0 或更高版本）上构建的。因此，Windows PowerShell 中的几乎所有内容 — 从 WMI 对象到文件和文件夹 — 都表示为该 Framework 中的对象。但是，Windows PowerShell 团队并不喜欢只将原始的 Framework 对象呈现给 Windows 管理员。例如，许多 Framework 对象的使用都有一定的不一致性，而一致性是 Windows PowerShell 的一个主要设计目标。另一个原因是某些 Framework 对象在涉及 Windows 管理时有些多余，而简洁性也是 Windows PowerShell 设计思想的一个主要方面。这样就诞生了类型适配器。

顾名思义，类型适配器将 .NET Framework 对象类型“适配”为一种更一致、有时也是更简单的格式。例如，假设您创建一个如下所示的新字符串变量：

[string]$var = “Hello”

您使用了一个由 .NET 适配器处理的 System.String 类型的实例。[ADSI] 类型适配器连接至 .NET Framework DirectoryServices 类，其中包括 DirectoryEntry 类型。

连接到目录对象比较直接。例如，要连接到 Contoso.com 域的 IT 组织单位 (OU) 中名为 Don 的用户，可使用如下代码：

$user = [ADSI]”LDAP://cn=Don,ou=IT,dc=
Contoso,dc=com”

如果您在 VBScript 或其他语言中使用过 ADSI，对此应当并不陌生。它是一个标准轻型目录访问协议 (LDAP) 查询字符串，是访问 Active Directory 的本机方式。您无需指定域控制器 (DC) 名称或任何其他详细信息；此完全限定域名 (FQDN) 已包含足够信息来定位 DC 和检索对象（当然，假设您具有相应权限）。

本地安全帐户的处理过程基本相同，只是这时要使用 WinNT 提供程序，而不是 LDAP 提供程序：

$user = [ADSI]”WinNT://don-pc/don”

请注意，LDAP 和 WinNT 别名都区分大小写。虽然 Windows PowerShell 本身通常不区分大小写，但这些 ADSI 资源却区分 — 因此在键入时应当注意。

图 1 显示了获取所得到的 $user 变量并将其通过管道传送至 Get-Member 时发生的情况：我将得到一个对象属性列表。但是，这不是所有用户属性的完整列表，并且其中不含用户对象的任何方法。从这个角度讲，基础 System.DirectoryServices.DirectoryEntry Framework 类的工作方式有些奇怪，并且 Windows PowerShell 只能显示 Framework 类所提供的内容。

图 1 检索对象属性列表 (单击该图像获得较小视图)

图 1 检索对象属性列表 (单击该图像获得较大视图)

检索对象主要是为了了解如何构造查询字符串。WinNT 提供程序的使用非常简单。只需指定一个计算机名或域名、一条斜线，再加上一个对象名即可。此技术非常适合 Active Directory 域（毕竟这些域与 Windows NT 域向后兼容）。事实上，有时使用 WinNT 提供程序从 Active Directory 中检索对象是最简单的方式，因为 WinNT 提供程序提供了一个域的平面视图。这意味着，您无需知道对象位于哪个 OU 中，因为 WinNT 提供程序看不到这些 OU。

LDAP 对象的检索要求更为精确些。首先要尽可能提供最精确的信息，如对象的规范名称 (cn) 或 OU 的名称。然后，应提供对象的完整路径，从其父容器开始，直至域本身。例如，检索位于 Sales OU（位于 Contoso.com 域的 West OU 中）中的用户 Don 应如下所示：

LDAP://cn=Don,ou=Sales,ou=West,dc=Contoso,
dc=com

此格式需要一点点的实践并要求您知道对象所在位置。图 2 汇总了 FQDN 的各种组件。

创建和删除对象通常要求首先连接到对象的容器（如 OU），然后请求容器创建或删除该对象。我总不记得正确的语法，幸运的是，Microsoft 脚本专家可以通过 ADSI Scriptomatic 助我们一臂之力。

虽然 ADSI Scriptomatic 最初是为 VBScript 创建的，但它仍是 Windows PowerShell 的一个非常有用的指南，因为实际的 ADSI 语法是相同的。例如，在下载该工具后，我选择了创建新用户的选项。我忽略了该工具生成的所有脚本代码，直至“End connect to a container”代码之后，如下所示：

Set objUser = 
 objContainer.Create(“user”, “cn=” & strName)
objUser.Put “sAMAccountName”, strName
objUser.SetInfo

转换到 Windows PowerShell 很简单。首先，我连接到要在其中创建用户的容器。为与 Scriptomatic 代码保持一致，我将使用变量 $objContainer 来表示 OU。我还要创建一个变量 $strName，用于存储新用户的名称：

$strName = “Don”
$objContainer = “LDAP//ou=Test,dc=Contoso,
dc=com”

接下来，我复制所有 Scriptomatic 代码，删除任何 VBScript Set 语句的所有痕迹，并向变量名添加 $：

$objUser = $objContainer.Create(“user”, 
  “cn=” & $strName)
$objUser.Put “sAMAccountName”, $strName
$objUser.SetInfo()

这就是所需的全部工作 — 一个新用户在 Contoso .com 域的 Test OU 中创建完毕。

连接到对象后 — 例如一个用户或组 — 您可以修改它。使用 WinNT 提供程序，您可以直接修改许多属性，如图 1 中所示的那些属性。例如，要显示然后更改用户的 Description 属性，可以编写如下代码：

Write-Host $user.Description 
$user.Description = “New Description”
$user.SetInfo()

有一点必须牢记，属性更改在本地属性缓存中进行，这是 ADSI 在计算机上维护的一个临时存储区域。调用 SetInfo 方法会将缓存写回您从中检索对象的计算机或域，其实质是将您的更改保存回目录。

对于多数对象属性，Active Directory 对象并不直接提供属性。实际上，您应当使用 Get 和 Put 方法：

Write-Host $user.Get(“Description”)
$user.Put(“Description”,”New Description”)
$user.SetInfo()

WinNT 对象倾向于简洁化，因为 Windows NT 目录服务没有存储有关对象（如用户和组）的许多信息。相反，Active Directory 存储了众多信息，要找出正确的属性名称会有些难度。例如，如果要更改用户的姓氏，则必须更改 Sn 属性。为什么必须更改 Sn 呢？因为它代表姓氏。

幸运的是，Microsoft 提供了一个很好的交叉引用，您可以通过 msdn2.microsoft.com/ms677286.aspx 在线获得该引用。该引用显示了“Active Directory Users & Computers”（Active Directory 用户和计算机）控制台每个主要区域的属性名称，因此如果您知道要在控制台中进行哪些更改，则可以找出基础属性名称。请注意，Cade Fassett 所著的“ADSI Scripting:TFM”（ADSI 脚本：TFM）(SAPIEN Press, 2007) 一书中提供了更完整的控制台至属性交叉引用。

遗憾的是，Windows PowerShell 中的 ADSI 支持不像对其他技术（如 WMI）的支持那样强。例如，枚举本地计算机的组成员就有些困难。在处理 Active Directory 时，同样会遇到一些困难情况。根据我的经验，基本的对象检索、创建和删除比较容易。修改对象属性也相对简单，虽然有些属性不可访问。最大的难度来自通过 WinNT 提供程序对本地对象和组的处理。

这并不是说没有一点办法，只是有些事情要更困难一些，或者不那么直观。请看下面的例子：

$group = [ADSI]”LDAP://cn=Techs,cn=users,
  dc=contoso,dc=com” 
$group.Member.Add(“cn=user1,cn=users,
  dc=contoso , dc=com”) 
$group.psbase.CommitChanges()

该示例将名为 User1 的用户添加到 Techs 组中。它非常明了。它使用 FQDN 来检索该组，然后使用该组的 Member 集合 — 具体而言，是该集合的 Add 方法 — 来添加所需用户的 FQDN。但是，最后一步并不那么显而易见。它调用隐藏的 PSBase 类的 CommitChanges 方法来保存更改。

PSBase 是一个特殊类，直接代表基本的 .NET Framework 对象。在本例中，没有直接在 Windows PowerShell 中公开 CommitChanges（实际上，ADSI 适配器没有公开任何方法），因此您必须转向基础类。尽管这不是不可能的，但显然不够直观。这也表明目录服务功能尚未完全适合 Windows PowerShell。

这有许多原因。首先，在整个开发周期中，Windows PowerShell 团队向外壳添加当前 ADSI 支持的时机有些晚。就像外壳架构师 Jeffrey Snover 经常说的“提供就是选择”。该团队用来开发和交付外壳的时间是固定的，他们必须做出决定要为下一版本保存哪些内容。如果不是这样，他们可以轻易地花上几年时间来添加新功能，而永远不会实际发布一款支持的产品。

不过，还有一个原因就是基础 .NET Framework。它的 DirectoryServices 类非常复杂，使那种复杂性与 Windows PowerShell 相配需要大量时间和认真规划。在我看来，Framework 类也有些侧重于 Active Directory，并且没有为 WinNT 提供程序提供有力支持 — 当然，Windows PowerShell 会从 Framework 继承任何这类局限性。

我预计 Windows PowerShell 会逐渐拥有广泛的目录服务支持 — 甚至是可以不通过 ADSI 层，而是通过 .NET Framework 中的基本改进获得的支持。同时，Windows PowerShell 中的 ADSI 支持还允许您执行绝大部分管理任务，如创建用户、修改通用用户属性等。

请不要忘记，许多目录服务任务可通过 WMI 完成。请查阅 microsoft.com/technet/scriptcenter/scripts 中提供的某些优秀脚本示例，它们使用 WMI 提供有关本地组的更多信息，比 ADSI 本身提供的信息还要广泛。