Edirectory Anomalies

LDAP Edirectory#

Empty namingContext#

Novell's implementation leaves has a RootDSE's namingContext attribute value that maybe empty.

When there is a "ROOT" Partition on the server, there is a namingContext entry that has no value.

We have seen this cause issues with several LDAP applications and browsers.

Boolean Entries and RFC 2252#

Boolean Syntax values in NDS are stored in lowercase letters (true/false) but LDAP requires uppercase values (TRUE/FALSE) according to RFC 2252, section 6.4:
6.4. Boolean

   ( DESC 'Boolean' )

   Values in this syntax are encoded according to the following BNF:

      boolean = "TRUE" / "FALSE"

   Boolean values have an encoding of "TRUE" if they are logically true,
   and have an encoding of "FALSE" otherwise.
In addition, EDirectory assumes if there are no values for Boolean Syntax attribute the values is FALSE.


EDirectory can not supply timestamps with values before 1/1/1970.

Any attribute that uses the syntax OID, Description Generalized Time, will fail on trying to set a values before 1/1/1970.

You will have to create an attribute that does not use and use "Generalized Time" syntax and workaround this issue.

RFC 4517#

EDirectory is not compliant GeneralizedTime syntax. The fraction is allowed, but optional.

Attempting to add a fractional value, EDirectory responds with a LDAP Result Codes - [LDAP: error code 19 - NDS error: syntax violation (-613)]

EDirectory won't accept the fractional value and so it must be entered without the fractional value:

This can be an issue when performing imports from other LDAP Server Implementations that do support fractional GeneralizedTime values as described within 

We see this as non-compliant as EDirectory should support the fractional values.

EDirectory does support the <g-differential>. In the latter case, coordinated universal time can be calculated by subtracting the differential from the local time. The "Z" form of <g-time-zone> SHOULD be used in preference to <g-differential>.

The values are converted to the proper "Z" value upon imputing the value as an offset.



More Information#

There might be more information for this subject on one of the following: