用于在 AD 中验证用户身份的性能最佳的通用 LDAP 查询是什么？
我们使用 LDAP 来验证用户身份。 LDAP 管道的另一端是一个非常大的 Active Directory 实现。我们发现身份验证查询花费的时间太长（15 秒或更长时间）。
以下是我们正在做的事情的描述：
ldap://ldap.myco.com/DN?dc=myco,dc=com??sub?(sAMAccountName=John)
实现这一目标的最佳方法是什么？对于任何大型 AD 实施来说，这种方法都可以很好地工作？
谢谢！
We're using LDAP to authenticate users. The other side of the LDAP pipe is a very large Active Directory implementation. We're finding that the authentication query is taking too long (15 seconds and longer).
Here's a representation of what we're doing:
ldap://ldap.myco.com/DN?dc=myco,dc=com??sub?(sAMAccountName=John)
What is the best way to accomplish this is a way that will work well for any giant AD implementation?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
尽管您的搜索还包括计算机和组，但 sAMAccountName 已明确索引。您可以使用
(&(objectCategory=person)(objectClass=user)(samAccountName={0}))进一步限定它。更大的问题是您为什么要进行搜索？如果您只想通过 LDAP 绑定检查用户名和密码，请绑定到 LDAP://DC=myco,DC=com 并访问
myDirectoryEntry.NativeObject。如果它抛出异常，你就有问题了。另外，什么是“
ldap.myco.com”？那是负载均衡器吗？这是您的域名吗？您应该能够在这里进行无服务器绑定......sAMAccountName is definetely indexed, although your search also includes computers and groups. You could further qualify it with
(&(objectCategory=person)(objectClass=user)(samAccountName={0})).The bigger question is why are you doing the search to begin with? If all you want to do is check a username and password via LDAP bind, do a bind to LDAP://DC=myco,DC=com and access
myDirectoryEntry.NativeObject. If it throws an exception you have a problem.Also, what is "
ldap.myco.com"? Is that a load balancer? Is it the name of your domain? You should be able to do a serverless bind here...如果
sAMAccountName已建立索引，则此查询的时间复杂度应为 O(1) 或 O(log(N))，具体取决于索引结构。如果花费了 15 秒，那么听起来像是 O(N)，这意味着它没有被索引。If
sAMAccountNameis indexed this query should be O(1) or O(log(N)) depending on the index structure. If it's taking 15 seconds it sounds like O(N) which would mean it isn't indexed.布莱恩·德斯蒙德（Brian Desmond）的回答很准确（我也因此投了赞成票）。您将从简单的绑定中获得最佳性能。
为了冗余（并分散负载），您应该有多个可供绑定的 DC。 Microsoft AD 客户端用于定位 DC 的算法（基于站点成员资格和 SRV RR 权重和首选项值）并不简单，但您可以通过获取要绑定的几个 DC 的地址（或名称）来进行近似。
Brian Desmond is spot-on with his answer (and I've upvoted as such). You'll get the best performance from a simple bind.
For redundancy's sake (and to spread the load) you should have multiple DCs available to bind to. The algorithm that Microsoft AD clients use to locate DCs (based on site membership and SRV RR weights and preference values) is non-trivial, but you could approximate by getting the addresses (or names) of a few DCs to bind against.