Question

我们正在为Microsoft的March AD更新做准备，以仅允许使用LDAPS进行安全调用，并且在检查.Net代码时，我发现对UserPrincipal.GetGroups（）和UserPrincipal.GetAuthorizationGroups（）的调用似乎使用LDAP（端口389））而不是LDAPS（端口636），即使UserPrincipal对象是使用通过LDAPS建立的PrincipalContext创建的，也是如此：

    // Explicitly using LDAPS (port 636)
    PrincipalContext principalContext = new PrincipalContext(ContextType.Domain, "our.corpdomain.com:636", "DC=our,DC=corpdomain,DC=com", ContextOptions.Negotiate);
    UserPrincipal userPrincipal = UserPrincipal.FindByIdentity(principalContext, "someuser");

    // These calls still use LDAP (port 389)
    var groups = userPrincipal.GetAuthorizationGroups();
    var groups2 = userPrincipal.GetGroups();

有人知道为什么会发生这种情况吗？如果发生，如何迫使这些调用使用LDAPS？如果不能强迫他们，有没有针对他们的解决方法？

Answer 1

这肯定是.NET代码中的错误，我会回答您的问题，但是就像您在其他问题中提到的那样，3月更新将不会“仅允许使用LDAPS进行安全调用”。在该更新之后，普通的LDAP端口389仍然可以使用。我没有看到任何证据表明他们打算禁用它。

但是，如果要确保它永远不会使用端口389，就不会使用this.temp = this.weather.main.temp;。直接使用constructor(weatherdataService) { this.weatherdataService = weatherdataService; this.temp = this.weather.main.temp; this.press = this.weather.main.temp;和/或this.temp = this.weather.main.temp; this.press = this.weather.main.temp;，这就是this.weather = data;在后台使用的方式。这不是UserPrincipal名称空间中的the first bug I've found。

我写了一篇有关finding all of a user's groups的文章，其中包含一些针对不同情况的示例代码。您将必须修改创建新DirectoryEntry对象并指定端口636的任何情况，例如：

DirectorySearcher

如果需要，您实际上可以省略域名（只是UserPrincipal而不是AccountManagement）。

我在那篇文章中没有提到的一种情况与DirectoryEntry等效，即读取new DirectoryEntry("LDAP://example.com:636/CN=whatever,DC=example,DC=com")属性。这为您提供了组的SID列表，然后您可以查找这些列表以查找组的名称。这是一种可以做到这一点的方法：

:636

这将使用您用于创建传入的example.com:636对象的任何端口。但是，如果您的环境中有多个域，则此操作将中断。如果您想始终使用端口636，事情会变得很复杂。

有没有一种方法可以使UserPrincipal.GetGroups（）和UserPrincipal.GetAuthorizationGroups（）调用使用LDAPS（端口636）而不是LDAP（端口389）？

1 个答案: