Active Directory

了解 AD LDS 中的代理身份验证

Ken St. Cyr

概览：

• 定义代理身份验证
• 为什么代理身份验证很重要
• 深入了解代理对象
• 实际执行身份验证期间发生的情况

目录

什么是代理身份验证？
代理身份验证的优点
深入了解代理对象
实际执行身份验证的方式
建立代理身份验证实验室
结论

与任何启用 LDAP 的目录服务一样，Microsoft Active Directory 轻型目录服务（AD LDS，前称 ADAM）也要求用户进行绑定后，才能对目录执行任何 LDAP 操作。这类绑定可通过几种不同的方法来完成，包括简单的 LDAP 绑定、简单的身份验证及安全层 (SASL) 绑定，甚至是绑定重定向。也可以进行匿名绑定，在这种情况下，用户需要提供空密码。在本文中，我将特别针对一种方法进行讨论和分析 — 绑定重定向，亦称作代理身份验证。

什么是代理身份验证？

代理身份验证允许用户对 AD LDS 实例执行简单的绑定，同时仍与 Active Directory 帐户保持关联。事务中涉及到两个帐户：第一个是 AD LDS 中的特殊对象，称为 userProxy 对象。第二个是用户在 Active Directory 中的帐户。

AD LDS userProxy 对象是 Active Directory 帐户的表示形式。代理对象通过 Active Directory 帐户的安全性标识符 (SID) 与帐户相关联。实际代理对象本身上并没有存储任何密码。

当用户通过代理对象对 LDS 实例执行简单的绑定时，该绑定会通过将 SID 和密码传送给域控制器而重定向到 Active Directory。AD LDS 服务器将执行身份验证，而且整个过程对最终用户来说不可见。此过程如图 1 所示，其中 Lucy 正使用她的 AD LDS 用户帐户连接到称为“CN=AppDir,DC=contoso,DC=com”的 AD LDS 实例。

图 1 使用 AD LDS 帐户进行连接（单击图像可查看大图）

为了进行身份验证，Lucy 使用的是简单绑定，而且就跟在正常的 LDAP 绑定过程中一样，她提供了可分辨名称 (DN) 和密码。虽然 Lucy 看起来使用的是典型的 LDS 用户帐户进行连接，但她实际上使用的是代理对象。对 Active Directory 的身份验证是在后台进行的，而 Lucy 完全不知道她实际上是在使用她的 Active Directory 帐户进行绑定。

代理身份验证的优点

代理身份验证的优点在于：它可授予应用程序开发人员对用户对象的访问权限，而不授予他们对 Active Directory 帐户的访问权限。设想一下，如果构建了启用新目录的应用程序且该应用程序需要将一些数据存储在 Active Directory 中，此时会发生什么情况。该应用程序可能会使用一个现有的属性或创建一个新属性。

使用一个未使用的现有属性的危险之处在于该属性很可能将用于其他用途。即使现在未使用，将来可能会用到，如果它有一些其他用途，Active Directory 管理员就必须跟踪它的使用情况。而且如果应用程序开发人员需要多个属性呢？

通过代理身份验证，AD LDS 目录中会存在 Active Directory 用户对象的表示形式。特定于应用程序的目录允许应用程序开发人员在 AD LDS 环境中任意修改架构。开发人员可通过所选的任何一种方式对属性执行添加、更改或重设用途操作，而 Active Directory 管理员不必担心需要进行多项架构更改，也不用跟踪属性的使用情况。如果有另一应用程序联机，并且想要使用相同的属性，也不成问题，因为它可以是不同的 AD LDS 实例，而且不会有任何属性冲突。

代理身份验证在要求使用 X.500 格式的情况下也相当实用。Active Directory 不会对 DN 使用典型的 X.500 命名。例如，用户对象在 Active Directory 中的 DN 是“CN=Lucy D. Smith,CN=Users,DC=contoso,DC=com”。而在 AD LDS 中，该用户的 DN 可能是“CN=Lucy D. Smith,CN=Users,O=Contoso,C=US”，也就是与 X.500 兼容的格式。

如果您使用的是第三方 LDAP 客户端或尝试与要求使用 X.500 格式的第三方目录集成，则此功能非常有用。因为这样一来，LDS 可作为第三方目录和 Active Directory 之间的中间目录。使用代理身份验证，第三方目录与 LDS 实例绑定需要使用的服务帐户便可以保存在 Active Directory 中，而不是 LDS 本身中。

深入了解代理对象

到目前为止，我简单地介绍了 LDS 代理对象如何与 Active Directory 用户帐户相关联。我现在要更深入地探讨并分析后台的运作情况，先从对象类讲起。

在 Windows Server 2008 中，%SYSTEMROOT%\ADAM 目录包含两个表示代理对象的 LDF 文件。

• MS-UserProxy.LDF
• MS-UserProxyFull.LDF

MS-UserProxy.LDF 包含简单 userProxy 类的定义，其中有基本属性并包含 msDS-BindProxy 辅助类。MS-UserProxyFull.LDF 也包含 msDS-BindProxy 辅助类，但是它还将更多用户属性预填充到类的 mayContain 属性。因此，属性类必须事先就存在。所以当导入 userProxyFull 类时，必须先导入用户或 inetOrgPerson 类。用户和 inetOrgPerson 都包含 userProxyFull 使用的属性的属性类定义。图 2 显示了 userProxy 类与 userProxyFull 类之间的差异。

图 2 userProxy 与 userProxyFull 类（单击图像可查看大图）

两个类都包含 msDS-BindProxy 作为辅助类，这一点很重要。辅助类是一种可为结构类提供其他数据的类。例如，在 LDS 中，User 类是从 Organizational-Person 类继承的结构类，也就是说 User 类拥有 Organizational-Person 类所拥有的一切。但是 User 类还有一个称为 msDS-BindableObject 的辅助类，也就是说 User 类除了包含 Organizational-Person 类的属性之外，还包含 msDS-BindableObject 所有的强制属性和可选属性。在本实例中，使用 msDS-Bindable­Object 作为辅助类使 User 类可绑定。

由于 userProxy 类有 msDS-BindProxy 作为辅助类（如图 3 所示），因此它现在还包含 msDS-BindProxy 的全部强制和可选属性集。msDS-BindProxy 辅助类可使对象转变成代理对象。因此即使您拥有自定义类，您也可以添加 msDS-BindProxy 辅助类，然后使用自定义对象进行代理身份验证。

图 3 创建代理对象（单击图像可查看大图）

如果您仔细看一下 msDS-BindProxy 类，就不难发现其中只定义了一个强制属性 — objectSID。在这个属性中填充 Active Directory 用户帐户的 SID，即可在 LDS 中的代理对象与 Active Directory 中的用户对象之间建立关联。此属性只能在创建对象时进行填充，若要对其进行更改，必须删除对象，然后再重新创建对象。

实际执行身份验证的方式

为了真正了解后台的运作情况，我们必须更加深入地探讨执行身份验证的方式。我将逐步介绍两个网络跟踪，它们将帮助您了解代理身份验证的运作方式。第一个跟踪是代理用户从 Windows XP 工作站简单绑定到 Windows Server 2008 LDS 实例的网络捕获。在这个捕获中，Lucy 使用工作站的 LDP.EXE 与她的代理用户对象进行绑定。

图 4 显示了在捕获中我们需要分析的三个数据包。数据包 1 是从工作站 (10.0.0.107) 发送到 Active Directory LDS 服务器 (10.0.0.201) 的绑定请求。绑定请求包含 Lucy 的 DN“cn=lucy,cn=people,cn=appdir,dc=contoso,dc=com”。数据包 2 是从 Active Directory LDS 服务器发送到工作站的响应，指示已绑定成功。数据包 3 是从工作站发送到 Active Directory LDS 服务器的确认信息，指示已确认绑定响应。

图 4 绑定请求和响应（单击图像可查看大图）

如果深入研究数据包 1 的详细内容（如图 5 所示），您会大吃一惊。那就是 Lucy 提供的密码 (P@ssw0rd) 在捕获中会以明文的形式显示。这事实上是使用简单 LDAP 绑定进行身份验证的缺点之一。除非将绑定封装在 SSL 加密中，否则用户的密码将向网络上接听的任何人公开。

图 5 SSL 关闭情况下的简单绑定（单击图像可查看大图）

默认情况下，Active Directory LDS 会启用 SSL。您必须设法手动将其关闭，为了让网络跟踪具有可读性，我在此练习中执行了该项操作。此外，我没有费事地将证书分配给 Active Directory LDS 服务器，但在实际实施中，您必须确保 Active Directory LDS 服务器拥有可用于 SSL 的有效证书。

第二个跟踪是从 Active Directory LDS 服务器到域控制器 (DC) 的网络捕获。这个跟踪比第一个稍微大一点，因此我将分几部分进行介绍。这个跟踪的前 9 个数据包显示在图 6 中。

图 6 连接到域控制器的 AD LDS（单击图像可查看大图）

第一个数据包对您来说应该不陌生，它位于从工作站传入的绑定请求中。此数据包同样以明文的形式提供了 Lucy 的 DN 和密码。数据包 2 至 9 显示了连接到域控制器 (10.0.0.200) 的 AD LDS 服务器 (10.0.0.201)。这包含一些地址解析协议 (ARP) 消息，随后是到 DC 的远程过程调用 (RPC) 连接。

在图 7 中，数据包 10 和 11 调用一个名为 LsarLookupSids3 的方法，此 RPC 调用将告知 DC 取得一批 SID，然后返回其对应的名称。AD LDS 服务器在数据包 10 中提出要求，并在数据包 11 中收到来自 DC 的响应。

图 7 Kerberos 身份验证尝试（单击图像可查看大图）

然后，经过简短的 TCP 握手来启动 Kerberos 会话（数据包 12-14）之后，在数据包 15 中，AD LDS 服务器试图从密钥发行中心 (KDC) 获取身份验证服务票证 (AS-REQ)。在数据包 16 中，身份验证服务票证请求被拒绝，因为 AD LDS 服务器没有提供 DC 预期的一些预先身份验证数据。在这种情况下，DC 希望使用时间戳进行身份验证。Kerberos 会话结束并请求重置（数据包 17–19）。

图 8 显示了捕获的其余部分。数据包 20–22 建立了新的 Kerberos 会话，在数据包 23 中新的身份验证服务请求从 AD LDS 服务器发送到 DC。此新请求包含必要的预先身份验证数据，数据包 25 中 DC 返回的成功答复表明了这一点。AD LDS 服务器现在已拥有身份验证服务票证，而且可以向票证授予服务提出请求以对 Lucy 的凭据进行身份验证。

图 8 成功的身份验证（单击图像可查看大图）

票证授予服务请求和响应在数据包 33 和 34 中捕获。在数据包 34 中收到 KRB_TGS_REP 表示 Lucy 已顺利通过身份验证。最后，在数据包 38 中，AD LDS 服务器将绑定响应返回到工作站，让 Lucy 知道她已顺利绑定到 AD LDS 实例。虽然这个过程涉及到几个步骤，但整个事务所花的总时间大约仅为 1/10 秒。

如果 Lucy 输入密码错误会发生什么情况呢？在我们的示例中，身份验证服务请求会在数据包 25 失败。身份验证服务请求的失败将告知 AD LDS 服务器 Lucy 的凭据无效。AD LDS 服务器会将绑定响应发回工作站（而不是票证授予服务），指明凭据无效。

以下简要概述了成功交换过程中发生的情况：

1. 工作站向 AD LDS 服务器发送绑定请求。
2. AD LDS 服务器与 DC 建立连接。
3. AD LDS 服务器请求 DC 将 Lucy 的 SID 转换成它可用来进行身份验证的标识符。
4. DC 将 Lucy 的 ID 提供给 AD LDS 服务器。
5. AD LDS 服务器使用 Lucy 的 ID 从 DC 取得授予票证的票证 (TGT)。
6. AD LDS 服务器使用 Lucy 的 TGT 为自己取得会话票证。
7. AD LDS 服务器将成功的绑定响应返回工作站。

这个过程显示了从工作站到 AD LDS 服务器的连接是标准的 LDAP 绑定事务。而从 AD LDS 服务器到 DC，则使用 Kerberos 安全地对用户进行身份验证。

建立代理身份验证实验室

现在您已经了解了代理身份验证的工作方式，让我们来看看如何在实验室环境中进行代理身份验证。请注意，在此练习中，我将禁用代理身份验证中的 SSL 要求。但是，正如我之前提到的，您不应该在实际实施过程中禁用该要求。

在开始之前，您需要有一个功能完备的域，其中包含一个 Windows Server 2008 成员服务器和一个工作站。Windows Server 2008 成员服务器将运行 AD LDS，而工作站将作为客户端端点。分开这些计算机的优点在于您可以网络捕获它们之间的交互。为了建立实验室，我将指导您逐步完成下列步骤：

• 在成员服务器上安装 AD LDS。
• 禁用代理身份验证的 SSL 要求。
• 将 userProxy 类导入 AD LDS 架构。
• 创建代理对象并为其分配权限。
• 通过代理对象绑定到 AD LDS 目录。

第一步是在 Windwos Server 2008 成员服务器上安装 AD LDS。在“服务器管理器”中，您将在“添加角色”向导中找到安装 LDS 的选项。角色安装好之后，“管理工具”菜单中将出现一个新的选项，称为“Active Directory 轻型目录服务安装向导”。使用此向导创建新的 LDS 实例。

当向导提示输入应用程序分区的名称时，输入任何您想要的 DN。请记住，LDS 支持以 X.500 格式命名，因此您并不仅限于使用“DC=”风格的名称。在我的示例中，我使用的是“cn=appdir,dc=contoso,dc=com”，但也可以使用“cn=appdir,o=contoso,c=us”。

AD LDS 实例安装好之后，下一步是禁用代理身份验证的 SSL 要求。在 ADSI 编辑管理单元 (adsiedit.msc) 中，您应该使用在安装期间指定的管理员帐户连接到 AD LDS 实例的配置分区。如果您不知道配置分区的 DN，可在 ADSI 编辑的连接设置对话框内，从“选择一个已知命名上下文”下拉列表中选择“配置”。

浏览到容器“CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={guid}”并打开“CN=Directory Service”容器的属性对话框。属性列表中包含一个名为 msDS-Other-Settings 的多值字符串属性，该属性列出了多个字符串，每个字符串都表示一种不同的 AD LDS 实例设置。编辑该属性并将“RequireSecureProxyBind”字符串的值更改为 0。

下一步是导入 userProxy 类的架构类定义。您可能在 AD LDS 向导提示您执行该操作时已经将其导入，若是如此，可跳过此步骤。如果您尚未将其导入，请使用下列 LDIFDE.EXE 命令执行该操作。请确保您在命令中指定了 AD LDS 服务器的名称和正确的端口。

C:\> ldifde –i -f c:\windows\adam\ms-userproxy.ldf –s
   server:port –k –j . –c 
   "cn=schema,cn=configuration,dc=X"
   #schemaNamingContext

现在已导入对象类，可创建代理对象。我将使用 LDP.EXE，但您可以使用其他工具或某种编程方法。使用 LDP 连接到 AD LDS 实例，并使用管理员凭据绑定。浏览到您 AD LDS 实例的 DN，然后选择您要在其中创建代理对象的容器。右键单击该容器，并从下拉列表中选择“添加子项”。在“添加”对话框中，您需要在“DN”字段中输入新代理对象的 DN。例如，您可以使用“cn=lucy,cn=appdir,o=contoso,c=us”。

您还需要为此对象来创建两个属性。第一个属性是 objectClass，用以表示创建的对象类型。此示例的值应该是 userProxy。将此信息添加到对话框的“编辑条目”部分中，然后单击“输入”按钮。

第二个要添加的属性是 objectSID，其中包含与此代理对象相关联的 Active Directory 用户帐户的 SID。您可以通过各种方法获取此 SID，但我是直接在单独的 LDP 实例中连接到 Active Directory，并从该处的用户帐户中复制 objectSID 属性。输入此信息之后，“添加”对话框应与图 9 中所示的对话框类似。最后，单击“运行”按钮，提交更改。

图 9 创建代理对象

为了使用您刚刚创建的代理对象，您将需要为它授予一些权限。您可以通过在 LDP 中的“CN=Roles”容器下选择“CN=Readers”对象，轻松完成这项任务。右键单击并从下拉列表中选择“修改”。添加名为 member 的属性，并输入您创建的 userProxy 对象的 DN 作为值。切记单击“运行”之前先单击“输入”按钮。现在，userProxy 对象应该是 LDS 实例中 Readers 组的成员。

一切应该已经就绪，所以您现在就可以测试代理身份验证。打开一个新的 LDP 实例，并连接到 AD LDS 服务器。不过，这次在绑定到实例时，请选择“简单绑定”，并在用户名称字段中键入代理对象的 DN。至于密码，请输入您将此代理对象关联到的 Active Directory 帐户的密码。单击“确定”，现在您应该已在只读模式下绑定到实例。

花一些时间进行网络跟踪，并尝试使用不同的绑定方法。您可以练习重新打开 SSL，然后捕获 LDAP 绑定过程。您甚至可以故意键入错误的用户名称或密码，然后查看身份验证过程会发生什么情况。

结论

在使用代理身份验证时，不要遇到困难就惊慌失措。我采用的方法是通过 LDP 和 ADSI 编辑演示此过程，因为这样可以更好地了解后台操作。正因为如此，我在本文中逐步介绍的示例从实际操作角度说明如何进行代理身份验证。

实际上，创建和操作 userProxy 对象的漫长过程通常通过身份管理系统或自定义开发的用于创建帐户的前端进行处理。我鼓励您构建自己的 LDS 实验室，亲自了解一下如何使用代理身份验证集成第三方目录和应用程序。

Ken St. Cyr 是 Microsoft 的一位顾问，自 Active Directory 问世以来，他已在其基础上设计和实施了多种目录解决方案。最近，他成为首批获得目录服务的 Microsoft Certified Master 认证的人员之一。可通过电子邮件 ken.stcyr@microsoft.com 与他联系。