CODEWITHSUNDEEP
active-directoryldapreplication
user1236775
user1236775

Reputation: 21

Active Directory lookup failure due to replication delay

We have a third party tool that we use to create AD objects (users and groups). This tool uses ADSI to create the objects, and we do not and cannot specify a DC that it will write to. As such, it might write to DC1 today and DC2 tomorrow. Everything replicates around though, so no worries.

The problem we have is our process for creating groups looks like this:

  1. Issue group create to 3rd party tool.
  2. If success, lookup group object in AD via LDAP calls (this is a Java app) to get the SID. (The third party tool doesn't return this)

The problem is that the Java LDAP calls do specify a DC when performing a lookup. Let's say Java is set to read from DC1. If the third party tool writes to DC2, then the java lookup to DC1 fails to find the group.

the AD replication delay is small, so if we add a 15 second delay between the create and lookup, then it works, but it is a little ugly.

Also, I tried querying all DC's from Java. This works for the above example, but it still has the same basic trouble when we update an attribute on an user or group and immediately try to read it back. Delay seems to be the only working approach, but it seems like there should be a better approach than this.

Upvotes: 1

Views: 887

Answers (1)

Terry Gardner
Terry Gardner

Reputation: 11132

3d party tools should not be used in this way to update a directory. The eventual consistency model prevents results from being predictable in any meaningful way. The correct procedure is to perform the update (add/mod/delete) in the application code using an ADD, MODIFY, DELETE, or MODIFY DN request with the post-read request control attached. This method is defined by the standards process, and is guaranteed to be predictable if the update worked. Please carefully study the information at "LDAP: Programming Practices" and its accompanying article.

Upvotes: 2

Related Questions