假设我有两个活动目录：AD-1 和 AD-2，我想要获得以下行为：
当有人尝试在 AD-2 上进行 LDAP 搜索以进行身份验证时，首先检查 AD-2 数据库，如果找不到用户，则将其委托给 AD-1。
对于尝试验证凭证的客户端来说，这必须是透明的。
原因：我有一些使用 LDAP 身份验证并检查 AD-2 服务器的 Web 应用程序。AD-1 将是主要的公司服务器，我无法控制，但 AD-2 在我的控制之下。
我需要能够将不在 AD-1 中的用户添加到 AD-2。来自 AD-1 的任何用户仍可被视为对 AD-2 有效。
AD-2 包含来自公司外部的用户。
注意：我配置 AD 的经验很少。
答案1
这至少不是 Active Directory 中已经存在的东西。恰恰相反 - 当针对 Kerberos 或 LDAP 进行身份验证时，您必须明确指定登录用户的专有名称 - 其中包括相同的域名。在这种情况下，任何类型的“后备”都是无效的，因为明确指定的域名“ad1”与“ad2”不匹配，并且在任何情况下查询 ad2 服务器时身份验证都会失败。
实现您想要的“目录联合”的唯一方法是使用所用目录上方的覆盖/抽象来执行两次搜索 - 每个目录一次。如果您可以修改 Web 应用程序，您可能会实现一个 API 来执行此操作，否则您需要实现某种代理服务才能使用此功能进行身份验证。
解决此类问题的常见方法称为“身份管理”，尽管其预期方向 - 统一所有用户相关数据和所有应用程序的单点登录 - 与您想要实现的目标完全相反。
答案2
这是您必须在应用程序级别处理的事情。如果您的应用程序对 AD 进行身份验证调用，您只需对应用程序进行编码以将两者用作身份验证源，并在每次迭代时在用户名前加上正确的域名即可。
目前没有本机的 AD 功能。
答案3
我们通过将 AD2 创建为 AD1 的子域（例如：ad2.ad1.com）来实现类似的解决方案。这使我们能够将父域中的用户添加到子域中的组中，从而允许来自两个域的帐户向应用程序进行身份验证。
请记住，这是在 IT 人员的全力配合下完成的。事实上，他们开发了该解决方案以供应用程序使用。
第二种可能的解决方案是将 crossRef 对象添加到您的客户 AD，该对象将根据名称将授权请求重定向或引用到辅助 LDAP。这将要求您传递多个登录名来查找对象。更多这里在 AD 中的自定义 crossRef 对象上。
答案4
可以使用单向信任来实现此目的。我不确定，但应该可以将信任与内部域中的只读域控制器结合使用。如果失败，可以使用 Atlassians Crowd 等第三方应用程序来提供针对多个目录的单点登录。
编辑 - 正如指出的那样，信任仅适用于完全限定名称。我发现这对我的内部用户来说很有效，因为要求他们包含他们的域名很容易。
我已经成功使用人群将多个目录合并到一个界面中。不确定您的网络应用程序的具体情况，但此产品（或类似产品）可能是一种可能性。