NetWare 5 includes support for a RootDSE request from a v3 client. The RootDSE request allows the client to discover what features are available from the LDAP server (authentication mechanisms, controls, schema). In NetWare 5, the RootDSE object is Read-only. If the RootDSE were writable, then it would be possible to extend the NDS schema through a write operation on the RootDSE object.
There is support for the auxiliary classes currently required by Netscape and Entrust in NetWare 5. A more flexible auxiliary classes mechanism is pending support of this feature in NDS itself.
NetWare 5 LDAP supports a clients bind request that includes v3 in the version field. Simple authentication is the only supported authentication mechanism in NetWare 5 LDAP.
NetWare 5 LDAP will perform an implied bind if a request from a client is received without a prior explicit bind request. For instance, if a server sees a search request from a client that has not issued a bind request, it will perform a bind for this client as an anonymous user and proceed with the search request.
LDAP v3 requires simple authentication (username and password) and recommends protected and strong mechanisms as defined in X.500. Any authentication mechanism in LDAP v3 other than simple is handled through SASL. NetWare 5 LDAP supports the required simple mechanism and fails other mechanisms (through SASL) as specified in the LDAP v3 spec.
LDAP v3 specifies that a client can request or demand controls on a search request (sorted, paged, etc). Supported controls are contained in a RootDSE response. If a client requests a control, it can be ignored by the server (which is done in NetWare 5). If a client demands a control (termed 'critical control') and the server cannot handle it, then it must return a failure (which is done in NetWare 5). LDAP does not support any controls in NetWare 5.
Supported extended requests in LDAP v3 are reported through RootDSE (there currently aren't any). Any unsupported extended requests must return a failure (which is done in NetWare 5).
The NetWare 5 LDAP supports international characters in UTF-8 format, as specified by the LDAP spec. UTF-8 is basically an ASCII-safe transformation of Unicode.
LDAP v2 supported a ModifyRDN operation, which could only rename an object within its existing container. LDAP v3 supports ModifyDN, which can move an object to a new container. ModifyDN in supported in NetWare 5.
In LDAP v3, referrals were returned to clients by forcing them into an error field in the protocol. LDAP v3 provides for a new, more explicit method of returning referrals. The new mechanism is supported in NetWare 5. However, the referral that is returned is not a true NDS referral to an NDS server that contains the information requested. Instead, the user can enter, via NetWare Administrator, a single-server URL that will be returned in all referrals from this server. If LDAP URLs were included in the NDS replica set information, then true NDS referrals could be returned via LDAP.
NetWare 5 LDAP supports LDAP access over an SSL encrypted channel.
LDAP uses the Dclient interface to NDS. This allows for multiple parallel connections, rather than serializing requests as the 1.0 version did. It also provides faster NDS access.
LDAP can be configured to access NDS data from a catalog. This provides significantly faster access, especially in a tree that is geographically widely distributed or a tree that is structurally flat with large numbers of objects per container. LDAP can be configured to use catalog data only, to use live NDS data only, or to use the catalog first and fall back to NDS for data not contained in the catalog.
LDAP now stores its configuration data in NDS rather than in a separate config file. Configuration can be updated at any time using NetWare Administrator.