Directory Sync

We've all done our fair share of LDAP operations, but one of the rarely used and not well understood aspects of this is the LDAP Control.

There are a variety of controls, the one I'm looking at specifically today is LDAP_SERVER_DIRSYNC_OID (1.2.840.113556.1.4.841). This control for ldap searching revolves around sending you results that include only objects that changed since your last search.

The idea here is you can send a search request now, get your results (plus a cookie) then an hour from now send that same cookie and it will only respond with results where the values have changed in the meanwhile.

There's a flag you can add to this to see only incremental changes for forward linked attributes (like member of a group).

So let's get right into how to do this.

The Powershell .NET Way

The first way we'll look at how to do this is with .NET in Powershell since it is the simplest.

Firstly we need to instantiate a couple variables. One for where we want to store our cookie once we get it, and one with the credentials we're going to use to bind to the directory:
This next part you can all do as part of the same command like this:

or break it down into its elements to understand it better and make it a bit more readable

Now some of you may have even created this kind of DirectorySearcher before, and know that now we're ready to just run $searcher.findall() and it will show us all our group objects and their members.

But in this case before we do that we want to declare the DIRSYNC control and assign it to the searcher and include our previous cookie if we had one.
Now the first time you run this it won't look much different than your standard search, since everything that changed since our null cookie is...well, everything. Th interesting part of this comes when we look at our results and store the cookie away to search later.

Now that we have the cookie stored, all we have to do is run it all again, and this time $changes will only contain entries that have had their member attribute changed since we last looked!

Reading Results

I know what you might be thinking, "But Mike, these results are pretty weird."

For responses for normal attributes that aren't forwardlinked like member is, the responses are way easier to read. For example, if we looked at user objects with useraccountcontrol, our results would just be the new useraccountcontrol value for any user which had that value change since our last cookie. Simple enough.

But with the member attribute it could change to add or remove members, and we want to be aware of both, so it send us a couple properties we can look at. Lets take a look at one of our response objects now:
member;range=0-0 is its way of telling us "these members were removed". So we can see that both Voldemort and BobSmith stopped being cool guys. As you probably guessed, member;range=1-1 is the people who got added, so MikeRyan started being a cool guy. Remember these are only the changes that happened since our last cookie, so we know these were pretty recent.

If you needed to know the exact time someone was added or removed you could always look at Replication Metadata to find out.

So now we're at a point where if we just ran the script in it's entirity the new cookie is already stored, and we can run it again to see more changes!

The Python ldap3 Way

Since I've been using python so much for my ldap operations I thought I would look into how to do this the python way. It feels a little more complex, but here's what I came up with.

This part is pretty standard of creating a new ldap connection in python using ldap3
And from here we could just do standard searches using the conn.search() method.

But we want to send the directorysync control. In python I ended up having to construct the "Sequence" object to pass to the control.
I got some info on how to do that from this Microsoft Documentation and this RFC Documentation.

Here's the code I used to build the control out:
If we look at our results here it's a little different than we got in powershell, before providing the cookie in powershell it iterated through all the results for us. In this case we've got a response including a "more_results" value, which we can see if we look at conn.result

So we need to run through a loop until there are no more results, storing all the results in a single list for us to look at when it's done. You could also do some evaluation and take some action in this loop if you were looking for something like if the users were set to pwnotrequired or pwneverexpires or something.
Once we're all out of results to iterate through, the last cookie returned is the one we want to store for later, like so:

Code Chunks

Here are the two code chunks, one for powershell and one for python if you want them kinda all in one place: