Working with objectGUID in Active Directory

objectGUID is a single-value attribute holding a 16-byte binary value that is supposed to be unique across all AD servers and across all time. This makes it a very useful join field when linking to other data-sources, as however much the entry is modified and renamed the objectGUID will not change.

The difficulty with objectGUID is that it is a binary octet string, not a text string. More standards-compliant LDAP servers use entryUUID which has a text representation and is therefore easier to work with.

So how can we use objectGUID?

The first thing to do in most cases is to convert it to text. TDI provides the system.binaryGUIDtoString() method for this, and the result looks like this:

    {4DCEC190-07B8-489B-BFA7-1C9DA0E0ECB9}

The AD change-detection connector provides objectGUIDStr for changed entries in exactly the same format.

You can store that text string in any database that you want to synchronise to or from, knowing that it will only ever refer to the AD entry that it came from. Now we can iterate through AD and for each entry found we can do reliable lookups in the other databases using the objectGUID string.

What about going the other way? It would be very reasonable to take an entry in another database and use the objectGUID string to search AD. Unfortunately it does not work that easily, as AD stores a binary value. To do the search, we have to convert from the text string to a valid LDAP search filter for a binary attribute. That should be easy as such filters have values expressed in hexadecimal, but there is a catch: for some reason, Microsoft have changed the byte order between the binary octet string and the text representation! There is even a suggestion that this might vary depending on whether your machine is big-endian like SPARC or little-endian like x86.

A bit of searching turned up some useful code snippets on Stack Exchange so I wrapped them up in a form that can be used with TDI:

• GUID-tools.js: Tools to manipulate AD-style objectGUID values

Drop that into a script in the resource library and include it as a prologue in your assembly-line settings, and you are ready to go. Assuming that you have an attribute called GUIDString in the work object, you can search for it in AD using an LDAP connector with the search criteria built by a custom script:

    var adGUID = guid_to_searchstring( work.getString("GUIDString"), 1 );
    return ("(objectGUID=" + adGUID + ")");

Now you have a reliable match in both directions.

-- AndrewFindlay - 08 Jul 2015