Retirement of nds.berkeley.edu January 31, 2019
Please test your current LDAP integration against the QA directory service (ldap-test.berkeley.edu) or production directory service (ldap.berkeley.edu). Both tiers are now running ForgeRock Directory Services 6.0 (formerly OpenDJ) to allow you to validate your applications prior to the shutdown of nds.berkeley.edu on January 31st, 2019.
New OpenDJ Release April 5, 2015
Please test your current LDAP integration against the QA directory service (ldap-test.berkeley.edu). This QA tier is now running OpenDJ 2.6.2 to allow you to validate your applications prior to the migration on April 5 of the production tier (ldap.berkeley.edu).
ForgeRock has released OpenDJ 2.6.2, a maintenance release of the 2.6.x LDAP directory server series. This release will replace the OpenDJ 2.6.0 version currently running at UC Berkeley, and provide a number of bug fixes and security patches. We plan to migrate the current OpenDJ servers to 2.6.2 on April 5 starting at 6 am. This upgrade will last several hours, but will be a rolling upgrade of the servers with no interruption in service for the ldap.b.e VIP.
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 (220.127.116.11 and 18.104.22.168, respectively).
Information about the certificate and certificate chain can be found at this page: LDAP SSL Public Key.
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 22.214.171.124.4.1.14126.96.36.199.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".
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.
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.
To restore full search functionality, we need to update the Manage Your Identity application and fix all existing values of the berkeleyEduCalNetIDUpdatedDate to include a time zone indication. The following are some examples of how the content of that attribute will change after the update:
Value after fix
20120918091000-0700 (PDT, equivalent to 20130918161000Z)
20121120091000-0800 (PST, equivalent to 20121120171000Z)
20120918171000-0700 (PDT, equivalent to 20120919001000Z)
This will require all code that does comparisons or searches with date-time literals to include a time zone as well. According to RFC 4517, acceptable time zone indications include “Z” for UTC (but watch for day rollover, as in the third example), or time differences in the [+|-]hhmm format. Three-letter abbreviations (PDT, PST, EST and so on) are not accepted. A date-time without a time zone indication will also be rejected by OpenDJ.
Since the fix requires to update all entries having a CalNet ID, applications that check for the modifyTimestamp attribute to detect updates will see hundreds of thousands of changes happening in just half an hour or so. If this happens to be your case, please contact the CalNet team as described in the Resources section below.
Please send any questions and comments to CalNet Support at firstname.lastname@example.org.