【问题标题】:.NET LDAP Libraries with NTLM support支持 NTLM 的 .NET LDAP 库
【发布时间】:2017-09-08 19:22:18
【问题描述】:

我正在尝试在我的应用程序中替换 Microsoft 的 DirectorySearcher,主要是因为它在我们的用例中确实很慢(当我搜索单个用户帐户以使用 sAMAccountName 作为过滤器,每个用户大约需要 400 毫秒,在某些情况下,我必须为许多用户获取它)。

所以我尝试了 Novell LDAP,包括原始版本和 .NET Standard 版本。 原始性能很好,但 .NET Standard 更好。微软需要 400 毫秒的相同情况,这个需要 3 毫秒。到目前为止一切顺利。

为了快速达到这一点,我对我的域凭据进行了硬编码。现在尝试在我们的应用程序中替换 Microsoft 的实现,我意识到我们正在使用 NTLM 身份验证,我希望这个更改对我的用户是透明的(不必向他们询问他们的域凭据)。

查看协议细节、使用wireshark 的LDAP 调用和Novell 的源代码,我很快意识到这是他们没有实现的东西。所以,我有点回到原点......

我需要一个可以通过 NTLM (sasl gss-spnego) 进行身份验证(绑定)的快速 LDAP 库。

这样的事情存在吗?我搜索了 nuGet 并询问了谷歌,但没有找到太多。

谢谢!

【问题讨论】:

  • 根据我的经验,DirectorySearcher 是最快的选择。你在用the overload that allows you to restrict which properties are loaded吗?我注意到这会产生重大影响。
  • 是的,我只加载了我需要的属性。我的问题最终是我的客户和我的测试域控制器/活动目录之间的协商。有人建议我使用相同的凭据,来自我的真实域,在我的测试域上,以避免必须实际登录它和所有......这是一个错误,是 NTLM 身份验证速度减慢的原因。当正确登录到我们的生产域/活动目录时,我无法复制此问题。在这种情况下,简单身份验证和 NTLM 之间没有明显区别。

标签: c# .net active-directory ldap ntlm


【解决方案1】:

如果您将 SASL 与 NTLM 结合使用,您可能会发现任何 LDAP 库都运行缓慢。

简单绑定意味着您在 TCP 三向握手之后在一个请求中获得身份验证。无论是什么库,使用 SASL 和 NTLM,在您发送搜索请求之前,您还有另外三条消息。

我发现 MS system.directoryservices.protocols 命名空间是一个非常快速的 LDAP 客户端库。根据您的用例,您可以进行许多优化。 https://msdn.microsoft.com/en-us/library/ms808539.aspx

我会在目录搜索器上对 theitsme86 提出异议。它使用 ADSI,这意味着它必须首先转换为 LDAP 客户端。 S.DS.P 让您制作纯 LDAP。

【讨论】:

  • 有趣。我将进一步调查,看看完全放弃 NTLM 是否会产生重大影响。之后会报告:) 谢谢!
  • 更新:好吧,看起来我正在寻找错误问题的解决方案。我得到的 400 毫秒/用户仅在我的测试 ActiveDirectory/Domain 上(在 VM 下)。我使用 S.DS、S.DS.P、Novell、Novell NET Standard 调用了一个基准应用程序……最终获得最佳性能(令我惊讶)的是 S.DS……我还决定为了将我从多个调用中获取数据的方式更改为单个更大的调用,我现在可以在每个用户不到一毫秒的时间内获取我想要的所有信息(3117 个用户为 2280 毫秒)。感谢您让我走上正轨!
  • 如果您对测试性能非常认真,您将需要在测试之间重新启动 DC 上的 AD。它是缓存目录中常用部分的冠军。
猜你喜欢
  • 1970-01-01
  • 2011-06-10
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-05-13
相关资源
最近更新 更多