在 AD 中搜索新创建的对象失败？
我有一个通过 Spring-LDAP 连接到 Active Directory 的服务。当调用创建新用户，然后立即进行单独的调用来搜索该用户时，搜索有时会失败，并出现“未找到对象”错误。
这似乎与复制有关，因为相同的搜索仅在几分钟后才起作用。请注意，这是两个单独的请求，因此不能保证使用池中的相同物理连接。
我有什么选择来解决这个问题？如果 AD 找不到对象的本地副本，是否不够智能，无法查询其他服务器？
I have a service that connects to Active Directory via Spring-LDAP. When a call is made to create a new user and then a separate call is made to search for that user immediately after, the search fails sometimes with a no-object-found error.
This appears to be related to replication since the same search works only a few moments later. Note, these are are two separate requests and as such can not be guaranteed to use the same physical connection from the pool.
What are my options to solve this? Is AD not smart enough to query other servers if it can't find a local copy of an object?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
由于复制的最终一致性模型（谁知道 Active Directory 是做什么的），LDAP 客户端永远不应该添加或修改条目，然后立即读回添加或修改的条目。正确的步骤是在添加或修改请求中添加读取请求控件。有关详细信息，请参阅 LDAP：编程实践。
LDAP clients should never add or modify an entry and then read the added or modified entry back immediately because of the eventual consistency model of replication (and who knows what Active Directory does). The correct procedure is to add the post read request control to the add or modify request. For details see LDAP: Programming Practices.
正如上面评论的那样，对于假设先写后读一致性保证的应用程序来说，复制延迟是有问题的。
通常人们会通过以下几种方式之一来处理这个问题：
0) 提高复制速度。这是您可以“调整”的。虽然它永远不可能达到 0，但您可以将其设置为秒。
1) 更改应用程序以在确定性 DC 上进行写入，然后从同一位置进行读取。您将在同一 DC 上获得先写后读的一致性，但 x-DC 读取会出现问题。
2）更改应用程序以完全不执行此操作。 :)
显然你也可以使用策略组合......
As was commented on above, replication latency is problematic for apps that assume write-then-read consistency sorts of guarantees.
Typically folks deal with this in one of a few ways:
0) Increase the speed of replication. This is "tunable" by you. While it can't ever get to 0, you can make it order-seconds.
1) Change the app to do a write on a deterministic DC and then do the read from the same place. You will get write-then-read consistency on the same DC, it is x-DC reads that are problematic.
2) Change the app to not do this at all. :)
Obviously you can use a combo of strategies as well...