Question

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=com
LDAP://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:

1. Bind to the root of mydomain.com. The Active Directory guts choose Lefty as the server to talk to.
2. Create a new OU called Container. The OU is created on Lefty.
3. 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.
4. 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.

Answer 1

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.