我应该使用域名还是域控制器名称绑定到 Active Directory？
我正在开发一个应用程序，该应用程序使用 C# 和 C++ 通过 LDAP 提供程序与 Active Directory 进行通信。该应用程序在 Windows 2003、2008 和 2008 R2 上运行。我使用的绑定字符串如下所示：
LDAP://mydomain.com/CN=Fred,DC=mydomain,DC=com LDAP://server.mydomain.com/CN=Fred,DC=mydomain,DC=com。
应用程序负责目录中的读取和写入操作。例如，在一种情况下，它会创建一个新的 OU，然后在该新的 OU 中创建多个用户和组。在另一种情况下，它向交互式用户呈现目录视图并允许用户创建新组或用户帐户。
到目前为止，我一直在使用基于域的绑定（上面的第一个示例绑定字符串），基于 MSDN：
在大多数情况下，绑定不应不必要地绑定到单个服务器。 Active Directory 域服务支持无服务器绑定，这意味着 Active Directory 可以绑定到默认域，而无需指定域控制器的名称
当域上有多个域控制器时，就会出现问题；我现在称他们为左撇子和右撇子。如果我使用 LDAP://mydomain.com/blah 绑定到目录，我会隐式连接到 Lefty 或 Righty。以下是所发生情况的示例场景：
- 绑定到 mydomain.com 的根。 Active Directory 选择 Lefty 作为与之通信的服务器。
- 创建一个名为 Container 的新 OU。 OU 在 Lefty 上创建。
- 尝试绑定到新的 OU。 Active Directory 内部选择 Righty 作为与之通信的服务器，因此绑定失败，因为 Righty 不知道新的 OU。
- 等待 10-15 秒，然后再次尝试绑定。与任一服务器通信时绑定成功。
在步骤 3 中，重新绑定并不是严格要求的，但在某些情况下涉及两个不同的可执行文件，因此我无法共享 IAD 或 DirectoryEntry。在内部，我认为 Active Directory 内部正在使用 DsGetDcName< /a> 选择要与哪个服务器通信，其文档有一些关于它如何选择域控制器以及如何缓存该信息的讨论。不幸的是，据我所知，这不是应用程序可以真正控制的东西。在某些情况下，我看到应用程序始终连接到一个域控制器或另一个域控制器，但在其他情况下，应用程序似乎在域控制器之间来回切换（如上所述），并且无法正常工作。
解决实际问题：这只是基于域的绑定的基本限制吗？我认为如果我直接绑定到特定的域控制器，问题就会消失，但这会使应用程序代码显着复杂化，所以我希望避免它。
I'm working on an application that talks to Active Directory through the LDAP provider, using both C# and C++. The application runs on Windows 2003, 2008, and 2008 R2. I'm using binding strings that look like this:
LDAP://mydomain.com/CN=Fred,DC=mydomain,DC=comLDAP://server.mydomain.com/CN=Fred,DC=mydomain,DC=com.
The application is responsible for both read and write operations in the directory. For instance, in one scenario it creates a new OU and then creates several users and groups in that new OU. In another scenario it presents a view of the directory to an interactive user and allows the user to create a new group or user account.
So far I have been using domain-based binding (the first example bind string from above), based on the advice of MSDN:
Under most circumstances, binding should not be unnecessarily tied to a single server. Active Directory Domain Services support serverless binding, which means that Active Directory can be bound to on the default domain without specifying the name of a domain controller
The problem comes in when there are multiple domain controllers on the domain; I'll call them Lefty and Righty for now. If I bind to the directory using LDAP://mydomain.com/blah, I'm implicitly connecting to either Lefty or Righty. Here's an example scenario of what happens:
- Bind to the root of mydomain.com. The Active Directory guts choose Lefty as the server to talk to.
- Create a new OU called Container. The OU is created on Lefty.
- Attempt to bind to the new OU. The Active Directory guts choose Righty as the server to talk to, so the bind fails because Righty doesn't know about the new OU.
- Wait 10-15 seconds and try the bind again. The bind succeeds when talking to either server.
In step 3, the re-bind isn't strictly required, but in some of the scenarios there are two different executables involved, so I can't share an IADs or DirectoryEntry. Internally I think the Active Directory guts are using DsGetDcName to choose which server to talk to, and the docs for that have some discussion about how it chooses a domain controller and how it caches that info. Unfortunately it's not something that the application can really control, as far as I can tell. In some cases I see the applications consistently connecting to one domain controller or the other, but in other cases the applications seem to switch back and forth between the domain controllers (as described above), and things don't work.
Getting around to the actual question: is this just a fundamental limitation of domain-based binding? I think the problem would go away if I bound directly to a particular domain controller, but that complicates the application code significantly, so I was hoping to avoid it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
发布评论
评论（2）
首先：我会说@Kalyan：你编写了一个方法，首先在工作开始时选择一个域控制器并将其存储在共享位置，然后所有 EXE 使用它。
第二：您可能可以使用 System.DircctoryService 中的 或使用 Interop 与 DsReplicaSyncAll 函数。我不确定第二种方法是个好方法DirectoryServer 类上的 SyncReplicaFrom... 方法从首次创建 OU 的域控制器强制进行复制.ActiveDirectory
备注：从纯 LDAP 的角度来看，它可能在 RootDSE 或其他地方存在强制复制的属性，因为“schemaUpdateNow”强制 SCHEMA 重新加载。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
这是 LDAP 服务器复制的固有问题。我从来没有使用过 C# api。
我曾研究过 Linux 上的 eDirectory。创建对象后，如果您要引用它，最好的选择是坚持使用服务器/DC。
为什么它会使申请变得复杂？编写一个函数来获取服务器。功能
应该对域（example.com）进行 DNS 查找，如果您有多个域控制器，它将返回所有 IP 地址，选择正在运行的一个（ping、ldap root dse 搜索）并将其返回给调用者。
仅当您遇到上述问题时才尝试使用该功能。在其他地方，只需坚持域名即可。
This is the inherent problem with the ldap server replications. I never used the c# api.
I have worked on the eDirectory on linux. Right after creating an object if you are going to refer it the best option is to stick with a server/DC.
why would it complicate the application? write a function to pick up a server. The function
should do a dns lookup for the domain (example.com) if you have multiple domain controller it will return all the ip address, pick up the one that is functioning (ping, ldap root dse search) and return that to the caller.
Try using the function only when you face the problem you mentioned above. In other places just stick with the domain.