Dear everyone out there still working with Active Directory (so most all large orgs and Security Vendors and other Software Vendors), please stop writing whenChanged or uSNChanged based AD Sync methods for your applications. Those may be fine (still bad) for some small company with 1-2 domain controllers but they are utter crap for large companies and do nothing but cause issues and confusion and inconsistent data syncing.
There is a MSFT article, “https://learn.microsoft.com/en-us/windows/win32/ad/polling-for-changes-using-usnchanged” that makes it seem like uSNChanged polling is a good thing, it isn’t. I have seen so many large well-known vendors using this technique and just causing any number of issues because of it, usually inconsistency in the synced data but also in large directories it is abusive when you have much better mechanisms to just return actual changes being tracked by the directory.
Currently, the very first bullet of that article is wrong, and has been wrong for quite some time
Only for highly privileged applications: To use the DirSync control, an application must run under an account that has the SE_SYNC_AGENT_NAME privilege on the domain controller. Few accounts are so highly privileged, so an application that uses the DirSync control cannot be run by ordinary users.
Since Windows Server 2003 we have had the LDAP Control “LDAP_DIRSYNC_OBJECT_SECURITY” which allows anyone who can see AD to perform DirSync operations on AD. In AdFind you can use the OS option in –dirsync_opts switch to see it in action. I use it on a regular basis with completely normal basic userids to watch flow of changes in AD. It is kind of fun actually, it helps to find stupidity in AD like products that are changing shit all of the time that shouldn’t be.
Anyway, if you are writing some quick and dirty application to look for changes quickly in some small application in some small directory, have at it. If you are writing a full blown application, especially an application you expect to sell to companies for thousands or millions of $$, do it correctly. Use DirSync if you are syncing data between AD and your application, if you just need occasional notifications of specific changes (like a config change), then use Change Notification.
DirSync (this is the most common case)
https://learn.microsoft.com/en-us/windows/win32/ad/polling-for-changes-using-the-dirsync-control
LDAP Specific – https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ldap/ldap-server-dirsync-oid
Change Notification
I recall talking to one large, well known company, actually this has happened a few times over the last decade with large software developers, about their AD Syncing, their app was abusing my AD with whenChanged syncing + just pulling all objects (millions) every few hours in case whenChanged missed something (because it is likely to happen if you don’t know how AD works) and likely fell back on the full syncs every few hours because of issues they had already seen in the past. I explained they needed to switch to usinig DirSync and do it correctly, the response back is that that is complicated and will take months. I spent a few hours over the weekend and added the functionality to AdFind, which, was not ever originally set up or structured to use DirSync. Is it perfect? No, but it shows it isn’t a months long issue for a company with professional developers.
So companies, don’t let your developers using shitty AD Syncing mechanisms. And if you are buying software and you know it is doing AD Syncing, find out HOW they are doing it and doon’t let them use shitty AD Syncing mechanisms. If they won’t tell you, you can do some packet tracing and sort out exactly what they are doing and if they do shitty syncing, they probably do other shitty things. There are not a lot of amazing developers out there, there are just a lot of developers out there and some really good sales people.
My favorite quote about programming is the following quote that I first heard from a professor at Michigan State University in 1988, it is called Weinberg’s Law:
If Builders Built Buildings the Way Programmers Wrote Programs, Then the First Woodpecker That Came Along Would Destroy Civilization
Somewhat ironically, the professor that shared this with me also argued with me about the idea that the more people who get involved with programming the better the overall code space would get (which is the battle cry of open source you may notice). I thought that was a complete crap position based on the fact that not even our very small coding classes back then had but maybe 10% of people who didn’t write complete crap code and that was a highly filtered group of people. I could not visualize any world where adding a whole bunch of people who weren’t as highly filtered could possibly increase the percentage of decent coders. And now nearly 4 decades later with huge amounts of random people thinking they are developers now, I look around and feel I was 100% accurate in my assessment all the way back then. All we have been doing is making the door wider for more unqualified people to come in building more and more complex frameworks for people and web based RESTful APIs and now the shitty AI we have at the moment which is, basically, glorified google focused on Stack Overflow.
joe
What he asked does apply to most companies as well so if there was any confusion in your companies, I am sorry for that. I hope this clarifies things. 
