Active Directory Driver error get object changes - 0x0035 message

We changed the recommended rights and policy assignments in the 3.0 driver based on information that was learned during the development of the new driver. This all pertains to cases where the driver is running on the DC via eDir or the remote loader. If you are connecting to the DC from another machine then you would certainly need to give explicit rights assignments to the user account that was acting as the service account for the driver. The easiest and safest approach to this is to make the user a member of the domain administrators group. If you want to move forward with granular rights assignment then the account needs the Synchronize Directory Service Data privilege in the security policy. It also needs the Replicating Directory Changes and Replication Synchronization rights at the root of the domain (the mydomain.com object in Users and Computers). If the customer needs queries, the driver needs READ rights and if the customer needs subscriber functionality, it needs WRITE rights. In theory, the rights could be granted at the attribute level, but I have never done this. The bottom line in cases where the driver is not instantiated on the DC is you need to have an account with rights and the safest approach to that is to make the user a member of the domain admins group. In essence you are connecting as a client. As such any client needs rights to perform actions in the domain. That is fundamental to having a directory where information is protected from unauthorized access.

The API used to connect to AD is ADSI and we interface with dirsync to detect changes. ADSI provides an operational property called ADS_DIRSYNC_COOKIE that gives us the current high water mark in Active Directory as a blob of binary data. We do a base64 encoding of the blob so that we can store it as text within the XDS XML document. We then use this blob whenever polling loop executes to determine what the next batch of changes are.