OpenDJ Developer Notes

Host names and ports

The OpenDJ test environments may be reached at ldap-test.berkeley.edu, on TCP port 389 (cleartext and StartTLS) and port 636 (SSL/TLS). The OpenDJ production environment may be reached at ldap.berkeley.edu, on TCP port 389 (cleartext and StartTLS) and port 636 (SSL/TLS). Note that in the DNS, CNAME alias records for ldap-test.b.e and ldap.b.e point to the canonical names for the corresponding VIP addresses (169.229.54.238 and 169.229.54.228, respectively).

Certificates

Information about the certificate and certificate chain can be found at this page: LDAP SSL Public Key.

Attribute Ordering

It is very unsafe to rely on the attributes being in any specific order when you parse the output from the ldapsearch tool. If you ask for attr1, attr2 and attr3, in that order, your results may not follow the same order.

When used against Oracle DSEE, the ldapsearch tool always returns the attributes you requested in the order you specified, but this is not mandated by either the LDAP standard or the ldapsearch specifications. In fact, OpenDJ (and other LDAP servers) will return the attributes in the most efficient way they can, i.e. by following the order in which the attributes are stored in the backend database.

Therefore, please don't rely on any specific order. The accepted and official way to parse the output of ldapsearch (which is in LDIF format) is by identifying the attributes by their names.

Filters involving dates and times

Dates and times in LDAP must follow the 1.3.6.1.4.1.1466.115.121.1.24 syntax notation, i.e. they must be represented as a string, in the format YYYYMMDDhhmmssZ.

The "hhmmssZ" part is not optional in the standard, yet Oracle DSEE was somewhat lenient and accepted dates in the YYYYMMDD format, by assuming that time was 00:00:00 GMT (Z). OpenDJ is not as lenient, and requires a full time specification, with trailing "Z".

Filter syntax

The LDAP filter specification says that the space character is invalid between an attribute name and the filter assertion. OpenDJ is more strict in this check than Oracle DSEE. Thus (uid =123456) may have worked with DSEE, but will fail with OpenDJ.

Supported controls in root DSE

If you want to read operational attributes of the root DSE (such as supportedcontrol) you need to explicitly use the attribute names in your query, or use the "+" wildcard. Oracle DSEE extended the standard practice to allow the use of the "*" wildcard for operational attributes, but this is not the case with OpenDJ.

berkeleyEduCalNetIDUpdatedDate format

As a result of the migration from Oracle Directory Server to OpenDJ, some applications have encountered issues when searching for entries based on the berkeleyEduCalNetIDUpdatedDate attribute.

We found out that the Manage Your Identity application, that allows people to choose and update their own CalNet ID, populates that attribute without a time zone indication. This was done by design (in order to make things easier for application developers, seehttps://wikihub.berkeley.edu/display/calnet/Detecting+Entry+Changes#DetectingEntryChanges-DetectingachangetoaCalNetID), and it worked just fine with Oracle DSEE, but unfortunately OpenDJ is more strictly compliant to the LDAP specification from RFC 4517, and refuses to allow certain search operations on entries that do not follow the standard.