LdapConnection与PrincipalContext [英] LdapConnection vs. PrincipalContext

问题描述

我有以下两种使用LDAP和LDAPS对用户进行身份验证的实现，我想知道哪种更好/更正确.记录下来，这两个都可以在SSL和非SSL连接上使用.

I have the following two implementations of authenticating users with LDAP and LDAPS and I was wondering which was better / more correct. For the record, both of these work on both SSL and non-SSL connections.

我也很好奇，因为在使用Non-SSL PrincipalContext版本的Wireshark观看时，我仍然在端口636上看到流量.在四种组合(Non-SSL LdapConnection，SSL LdapConnection，Non-SSL PrincipalContext，SSL PrincipalContext)中，它是唯一在端口389和636上均具有流量的端口，而不是只有一个端口和另一个端口.可能是什么原因造成的?

I'm also curious because when watching with Wireshark on the Non-SSL PrincipalContext version, I still see traffic on Port 636. Of the four combinations (Non-SSL LdapConnection, SSL LdapConnection, Non-SSL PrincipalContext, SSL PrincipalContext) it is the only one that has traffic on both Port 389 and 636 instead of just one or the other. What could be causing this?

LDAP连接方法:

bool userAuthenticated = false;
var domainName = DomainName;

if (useSSL)
{
  domainName = domainName + ":636";
}

try
{
  using (var ldap = new LdapConnection(domainName))
  {
    var networkCredential = new NetworkCredential(username, password, domainName);
    ldap.SessionOptions.VerifyServerCertificate = new VerifyServerCertificateCallback((con, cer) => true);
    ldap.SessionOptions.SecureSocketLayer = useSSL;
    ldap.SessionOptions.ProtocolVersion = 3;
    ldap.AuthType = AuthType.Negotiate;
    ldap.Bind(networkCredential);
  }

  // If the bind succeeds, we have a valid user/pass.
  userAuthenticated = true;
}
catch (LdapException ldapEx)
{
  // Error Code 0x31 signifies invalid credentials, anything else will be caught outside.
  if (!ldapEx.ErrorCode.Equals(0x31))
  {
    throw;
  }
}

return userAuthenticated;

PrincipalContext方法:

bool userAuthenticated = false;
var domainName = DomainName;

if (useSSL)
{
  domainName = domainName + ":636";
  ContextOptions options = ContextOptions.SimpleBind | ContextOptions.SecureSocketLayer;

  using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, domainName, null, options))
  {
    userAuthenticated = pc.ValidateCredentials(username, password, options);
  }
}
else
{
  using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, domainName))
  {
    userAuthenticated = pc.ValidateCredentials(username, password);
  }
}

return userAuthenticated;

推荐答案

@ DTI-Matt，在上面的示例中，您使用始终返回true的VerifyServerCertificate回调.从本质上讲，这不符合通过SSL连接到LDAP的目的，因为不执行任何真实的证书检查.

@DTI-Matt, in the examples above, you use VerifyServerCertificate callback that always returns true. This, essentially, defies the purpose of connecting to LDAP over SSL, as no real certificate check is performed.

虽然您可以使用X509Chain和/或X509Certificate2类实施真正的证书检查，但似乎PrincipalContext为您处理检查.

While you could implement a real certificate check using X509Chain and/or X509Certificate2 classes, it seems PrincipalContext handles the checks for you.

总而言之，LdapConnection和PrincipalContext都提供了非常相似的功能，即通过普通或SSL连接连接到LDAP服务器的方式.您必须提供更多的LdapConnection手写代码，它才能正常工作.另一方面，PrincipalContext为您提供了相同的功能，而只需编写较少的代码.

To summarize, both LdapConnection and PrincipalContext provide very similar functionality, in means of connecting to an LDAP server over plain or SSL connection. You have to supply LdapConnection much more hand-written code for it to work properly. On the other hand, PrincipalContext gives you the same functionality with less code to write by hand.

请注意，此类可能会尝试尽可能安全地连接，这可能是由于非SSL PrincipalContext连接到端口636(通过SSL端口的默认LDAP)所致.

As a note, connections to port 636 (your default LDAP over SSL port), by non-SSL PrincipalContext may be explained by the fact this class tries to connect as secure as possible.

这篇关于LdapConnection与PrincipalContext的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！