eDirectory 9.1 added support for the extended DN control which changes the way how the LDAP server returns distinguished names.

When the extended DN control is used in a query then the response will include the object GUID in addition to the regular DN.

This control has been supported by Active Directory for a very long time, probably since Windows 2000.

Anyway, support for this control in the server doesn't do anything if the client library you are using doesn't support it.

I'm using the old Novell LDAP classes for Java, also known as JLDAP.

The library is open source but for all purposes it's dead, the latest binary release was in 2013 and prior to that it was updated in 2009. Any new projects would use a library that's more modern and supports modern Java features.

However, JLDAP it still works fine and there is no reason to throw it away if you aren't missing anything.

For that reason I've decided to write a Java class that implements the extended DN control and that can be used with JLDAP.

The source code is available on Github under the MIT license.

In this article I will explain how to use the extended DN control using a simple sample and show what the control actually produces.

First, the class we will be looking at is named

se.idsecurity.jldap.edirectoryjldapext.controls.ExtendedDnControl

The control is very simple, to create a new instance we call the constructor that looks like this:

public ExtendedDnControl(GuidFormatFlag flag, boolean critial)

The GuidFormatFlag is an enum that contains two values:

HEX and STRING.

Choosing HEX will cause eDirectory to return the GUID in (you guessed it), hexadecimal format:

<GUID=7467c7c083a8ca4848827467c7c083a8>;cn=adminadmin,o=System

Choosing STRING will return the GUID in the format we are usually accustomed to:

<GUID=c0c76774-a883-48ca-4882-7467c7c083a8>;cn=adminadmin,o=System

The boolean critical indicates if the operation should fail in case the server doesn't support this control.

The source includes a very simple class for testing the control:

se.idsecurity.jldap.edirectoryjldapext.sample.SampleExtendedDnControl

There you can see an actual example of usage, I won't go into detail, except to explain how to tell your LDAPConnection to use your control.

First create a new instance of the control, either with the HEX or STRING flag.

//Instance using HEX ExtendedDnControl guidAsHex = new ExtendedDnControl(ExtendedDnControl.GuidFormatFlag.HEX, true); //Instance using STRING ExtendedDnControl guidAsString = new ExtendedDnControl(ExtendedDnControl.GuidFormatFlag.STRING, true);

Next, get the current constraints from your LDAPConnection, set the control and update the constraints on the LDAPConnection object.

//Set the control LDAPConstraints constraints = lc.getConstraints(); constraints.setControls(guidAsHex); lc.setConstraints(constraints);

That's it! Now you can use your LDAPConnection as before, the respones to any searches you do will include the GUID of the object in addition to the DN as shown before.

I recommend reading about this control in the eDirectory documentation:

https://www.netiq.com/documentation/edirectory-91/edir_admin/data/t4562rkcaudt.html

Microsoft of course also has very good documentation on the subject that you can find here:

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/57056773-932c-4e55-9491-e13f49ba580c

I've decided to put the control in the same project as another control/extension I've wrote, the source code can be found here:

https://github.com/idsecurity/LdapTransactionsSampleCode