In This Article
Unless anonymous searches are being done, all LDAP operations must be performed over a secure connection: either SSL on port 636 or TLS on port 389. The server uses a commercially signed certificate from Thawte.
Authentication and authorization should be handled as two separate operations by applications: authentication is the proof of identity (e.g. uid & passphrase) whereas authorization is the determination rights or privileges (e.g. membership is a specific department).
Applications which require simple authentication should consider using the CAS-based Common Login service. DIT also supports Shibboleth and ActiveDirectory.
It is much more efficient to include an explicit list of attributes to be returned rather than omitting the attribute list. In the latter case, the server must select all of the attributes for an object and then determine which ones the ACLs allow you to access. Also, explicit attribute lists allow for effective auditing.
When testing for the existence of an object, use the string "1.1" as the attribute list. This is the "no attributes" attribute and indicates that the server should not look up or return any attributes.
Negative clauses in search filters are very inefficient and should be avoided whenever possible. For example, use (umStudent=FALSE) rather than (!(umStudent=TRUE)). The one exception to this rule is testing for the non-existence of an attribute, e.g. (!(umTermDate=*)).
The UMD root suffix is dc=umd,dc=edu and should be used as the search base.
The default search limit for applications is 1000 entries; higher search limits can be granted with appropriate approval. Applications with higher limits should use paged results whenever possible to improve efficiency. For more information please contact the Directory administrators in DIT Technical Services and Support (TSS).
An annotated schema of person attributes can be viewed in the UMD Directory Services: Schema article
We are currently running the OpenLDAP server version 2.4.47.
Here is a selection of RFCs relating to LDAP:
||Technical Specification Road Map
||Directory Information Models