【IT168 专稿】AD LDS是"Active Directory  Lightweight Directory Service"的缩写，意即"AD轻型目录服务"。

　　AD LDS 是为已启用目录的应用程序提供灵活支持的轻型目录访问协议 (LDAP) 目录服务，它没有 Active Directory 域服务 (AD DS) 必需的依存关系。AD LDS 提供的许多功能都与 AD DS 相同，但是无需部署域或域控制器。可以在一台计算机上同时运行多个 AD LDS 实例，每个 AD LDS 实例都有一个独立管理的架构。

　　AD DS 为 Microsoft(R) Windows Server 服务器操作系统和已启用目录的应用程序均提供目录服务。对于服务器操作系统，AD DS 存储有关网络设施、用户和组以及网络服务等的关键信息。在此角色下，AD DS 在整个林中必须遵循单一架构。

　　另一方面，AD LDS 服务器角色还专门为已启用目录的应用程序提供目录服务。AD LDS 不需要或不依赖 Active Directory 域或林。但是，在有 AD DS 的环境中，AD LDS 可以使用 AD DS 对 Windows 安全主体进行身份验证。

　　AD LDS 服务器角色包括以下功能：

　　－ 用于引导您完成创建 AD LDS 实例过程的向导

　　－ 用于执行无人参与安装和删除 AD LDS 实例的命令行工具

　　－ 用于配置和管理 AD LDS 实例的 Microsoft 管理控制台 (MMC) 管理单元，包括每个实例的架构

　　－ 用于管理、填充和同步 AD LDS 实例的 AD LDS 特定命令行工具

　　什么情况下应该使用 AD LDS 服务器角色呢？微软给出了常用的 AD LDS 企业目录解决方案，如下：

　　1、提供企业目录存储

　　对于企业来说，AD LDS 是成熟的 LDAP 目录解决方案。所有已启用目录的企业应用程序都可以使用 AD LDS 作为其目录存储。

　　AD LDS 可以将仅与应用程序有关的"专用"目录数据存储在本地目录服务（可能位于与应用程序相同的服务器上）中，而无需向服务器操作系统目录中添加任何其他配置。此仅与应用程序有关并且不必广泛复制的数据单独存储在与应用程序关联的 AD LDS 目录中。该解决方案减少了服务该服务器操作系统目录的域控制器之间的网络流量。但是，如有必要，您可以将此数据配置为在多个 AD LDS 实例之间复制。

　　企业应用程序必须经常将与经过身份验证的用户相关联的个性化数据存储在 AD DS 中。将此个性化数据存储在 AD DS 中将需要更改 AD DS 架构。这种情况下，应用程序可以使用 AD LDS 来存储特定于应用程序的数据（如策略和管理信息），而使用 AD DS 中的用户主体进行身份验证以及控制对 AD LDS 中对象的访问。这种解决方案将不需要每个 AD LDS 目录拥有其自己的用户数据库。因此，这种解决方案可以防止每次向网络中引入新的已启用目录的应用程序时最终用户的用户 ID 和密码的繁殖。

　　2、提供 Extranet 身份验证存储

　　考虑 Web 门户应用程序的示例，该应用程序管理对企业业务应用程序和位于企业 AD DS 外部的服务标识的 Extranet 访问。另一个示例是一个承载方案，该方案中提供商通过维护和更新客户专用的 Web 或数据服务器为其客户提供域和存储服务，而客户无需具有访问这些服务器的权限。

　　在 Extranet 中部署的这些服务器和门户应用程序都需要具有自定义标识。它们要求进行身份验证存储以保存它们所服务的标识的授权信息。AD LDS 是此身份验证存储的非常好的候选，因为它可以承载非 Windows 安全主体但可以使用 LDAP 简单绑定进行身份验证的用户对象。换言之，Web 客户端可以由门户应用程序提供服务，当将 AD LDS 用作简单的 LDAP 身份验证存储时，这些应用程序可以在任何平台上运行。

　　如果在 Extranet 中部署的门户应用程序必须服务当前位于企业防火墙之外经过 AD DS 身份验证的内部标识，则您仍然可以借助在 AD LDS 的 Extranet 实例上设置的这些标识的企业帐户凭据将 AD LDS 部署为身份验证存储，如下图所示。（图1）

　　还可以将 AD LDS 部署为 Extranet 身份验证存储以及 Active Directory 联合身份验证服务 (AD FS)。此配置使 Web 单一登录 (SSO) 技术能够借助单一用户帐户对多个 Web 应用程序的用户进行身份验证。

　　3、合并标识系统

　　你可能拥有一个方案，在该方案中对企业已启用目录的应用程序施加数据模型限制[如单一 LDAP 分区视图或单一组织单位 (OU) 视图]，该应用程序必须访问与经过 AD DS 身份验证的用户、应用程序或位于企业的多个林、域或 OU 中的网络资源关联的数据。必须将多个 Active Directory 林、域和 OU 或多个标识系统和其他目录（如人力资源数据库、SAP 数据库、电话目录等等）中的此已启用目录的应用程序的标识信息进行合并。

　　AD LDS 提供一个合并的目录解决方案，因为可以将其与元目录一起部署。元目录，如 Microsoft Identity Integration Server (MIIS) 或者是免费的轻型版本的 MIIS 的 Microsoft Identity Integration Feature Pack (IIFP)，可以通过在 AD DS 和 AD LDS 之间执行身份集成、目录同步、帐户设置和取消设置以及密码同步，为已启用目录的应用程序提供有关企业用户、应用程序、网络资源的所有已知标识信息的统一视图，如下图所示。（图2）

　　4、为 AD DS 和 AD LDS 提供开发环境

　　由于 AD LDS 使用的编程模型与 AD DS 相同，并且提供的管理体验也几乎与 AD DS 相同，因此它非常适合于正在暂存和测试各种 Active Directory 集成的应用程序的开发人员。例如，如果正在开发的应用程序需要一个不同于当前服务器操作系统 AD DS 的架构，则应用程序开发人员可以使用 AD LDS 为该应用程序提供一个量身定制的架构，该架构适合于业务需求、数据要求以及工作流程，而没有改变企业 Active Directory 部署的配置。开发人员可以在开发人员工作站上使用 AD LDS 的本地实例，之后再将该应用程序移动到 AD DS。

　　开发人员可能希望拥有一个简单的目录，他们可以轻松对其进行编程，而无需在开发过程中扩展设置或硬件支持。AD LDS 在开发人员工作站上易于安装或卸载。这样便允许在应用程序原型制作和部署过程中迅速还原为清除状态。

　　5、为分布式应用程序提供配置存储

　　你可能拥有一个分布式应用程序，该应用程序要求具有多主机更新和复制功能的配置存储来服务其多个组件，例如，访问网络和应用程序端口数据的防火墙应用程序、访问电子邮件地址列表的垃圾邮件筛选应用程序或访问企业和策略数据的工作流程应用程序。对于此类应用程序，可以将 AD LDS 部署为轻型配置存储，如下图所示。（图3）

　　在此方案中，作为应用程序配置存储服务的 AD LDS 实例与分布式应用程序捆绑在一起。采用这种方法，应用程序设计者不必在安装该应用程序之前担心目录服务的可用性。相反，它们可以将 AD LDS 作为其应用程序安装过程的一部分包含，以确保安装后该应用程序立即具有访问目录服务的权限。然后该应用程序根据应用程序对 AD LDS 管理的暴露程度完全自己或部分自己配置和管理 AD LDS，并且它使用 AD LDS 来解决其各种数据要求。

　　6、迁移旧版已启用目录的应用程序

　　某些公司可能使用一个具有 X.500 样式命名（O=<组织>，C=<国家>） 的已建立的目录来服务各种旧版应用程序，但它也可能希望将其企业目录迁移到 AD DS。在此方案中，可以使用 AD LDS 作为临时解决方案。可以部署 AD LDS 以服务依赖于 X.500 样式命名的旧版应用程序并为其提供支持，可以在企业中使用 AD DS 来提供共享安全基础结构。可以使用元目录（如 MIIS）自动同步 AD DS 和 AD LDS 中的数据以便获得无缝的迁移体验。下图为 AD LDS 的部署流程。（图4）