如果应用程序服务器在Active Directory A中，如何查询Active Directory B？

Question

这是我的问题。我有一个基于表单的Asp.net应用程序，它使用表单身份验证。我在数据库中有用户，但这些用户也必须在活动目录中。

以下代码是为了检查用户是否在A域中：

            DirectoryEntry de = new DirectoryEntry();
            de.Path = "LDAP://domainA.com";
            de.AuthenticationType = AuthenticationTypes.None;
            DirectorySearcher search = new DirectorySearcher(de);
            search.Filter = "(SAMAccountName=" + account + ")";
            search.PropertiesToLoad.Add("displayName");

            SearchResult result = search.FindOne();

这段代码运行良好。问题在于客户端要求域名B也能连接到应用程序。因此创建了以下代码：

            DirectoryEntry de = new DirectoryEntry();
            de.Path = "LDAP://domainB.com";
            de.AuthenticationType = AuthenticationTypes.None;
            DirectorySearcher search = new DirectorySearcher(de);
            search.Filter = "(SAMAccountName=" + account + ")";
            search.PropertiesToLoad.Add("displayName");

            SearchResult result = search.FindOne();

由于我的服务器在domainA中，所以这不起作用。有没有办法让我查询domainB，知道服务器在domainA中？我找到了一篇文章说需要为domainA和B建立信任关系，但这些域不应该链接。仅针对此应用程序，它们需要这种功能。

P.S. 我可能忘记解释一个重要细节。domainA和B不在同一网络中。但是domainA可以ping通domainB。

- TheProvost

---

如果不允许域之间的信任关系，您需要在DirectoryEntry构造函数中提供来自域B的用户凭据，或者使用模拟身份。这意味着您必须存储/请求域B中用户的用户名和密码。 - oldovets

@oldovotes 很遗憾，没有起作用...我收到了“服务器不可操作”的错误。这是最常见的错误。你有什么想法为什么会出现这种情况？ - TheProvost

@oldovets 尝试使用LDAP.exe。成功连接到服务器，但无法使用提供的凭据进行绑定。出现了超时错误。有什么想法吗？ - TheProvost

@MatthiasLoerke 对不起，我不确定您所说的域控制器是什么意思。 - TheProvost

@oldovets：我同意，如果没有可靠的网络连接，这根本行不通。在使用AD时，拥有适当的DNS通常也是重要的要求之一。由于在这种情况下的目标是查询非受信任的外部域，因此无服务器绑定对我来说似乎不太有用。我的示例提出了与服务器和命名上下文绑定的方法，而不仅仅是将域名替换为服务器FQDN。即使使用IP地址，我也已经成功实现了这个样例。 - Matthias Loerke

Answer 1

您需要提供具有在B域上查询AD权限的凭据。

var de = new DirectoryEntry("LDAP://domainB.com", "Username", "Password");
var search = new DirectorySearcher(de);

- Martin Lee

Answer 2

在尝试对外域进行样本测试时，我注意到当使用错误的身份验证类型时，外部DC会出现“服务器不可用”的错误消息。请尝试：

de.User = @"DOMAINB\user";
de.Password = "YourPassword";
de.AuthenticationType = AuthenticationTypes.None;

当然，这会导致不安全的基本简单绑定，从而删除ADSI可能提供的任何加密。如果这有效，您应该尝试更安全的服务器接受的身份验证类型。

另一种选择可能是使用“System.DirectoryServices.Protocols”命名空间，它为AD访问提供了更轻量级的方法。如果您想朝这个方向走，我可以为您提供一个示例。

- Matthias Loerke