The LDAP connection and authentication model is a two-step process.
The client first establishes a connection to the LDAP server.
Non-secure, clear-text connections are established by default on port 389.
Data encrypted connections are established by default on port 636.
The port numbers are configurable and may vary from LDAP server to LDAP server.
After the connection is established, the client then binds with the appropriate credentials for the port. The bind authenticates the client to eDirectory and establishes an identity.
The Novell LDAP server listens on both ports for connections and can be configured to accept both types of connections.
LDAP supports various types of binds on port 389:
Anonymous binds require the client to send in an empty string for both the user name and the password. The Novell LDAP server accepts such a bind request and establishes the client as the NDS entry [Public].
Clear-text password binds require a valid distinguished name and a password. Since clear-text passwords compromise security, eDirectory by default accepts only encrypted passwords and must be configured to accept clear-text passwords. The client is authenticated with the identity of the distinguished name and given all of its eDirectory rights.
The SSL init functions exchange encryption keys as part of the connection process, and these keys are then used to encrypt all data sent across the connection.
The eDirectory server currently supports only server-side authentication. This means that the client must obtain a certificate file from each LDAP server to which the client will authenticate. Each Novell LDAP server must be configured for SSL authentication and export a certificate for clients to use.
The client sends this certificate with an SSL init function. The client then binds using a distinguished name and password, which establishes the client as the eDirectory identity of the distinguished name. The client can also bind as an anonymous user by sending empty strings for the distinguished name and password. Such a bind request establishes the client as the NDS identity [Public].
An anonymous bind request establishes the client as the NDS identity [Public].When using the ldap_get_context_identity_name function on an anonymous bind, the function returns an empty string rather than [Public].
When creating a user, a value must be set for the userPassword attribute in order for the user to log in to the directory.
When using an LDAP compare function to verify a userPassword value, the function can return true and the client can still be locked out of the account. eDirectory uses the following attributes, not just the userPassword attribute, to control access to an account:
Locked By Intruder
Login Allowed Time Map
Login Disabled
Login Expiration Time
Login Maximum Simultaneous
Password Expiration Interval
Password Required
If the password is verified as valid, these other attributes should be checked to determine why the client cannot access the account. See the NDK: Novell eDirectory Schema Reference for a description of these attributes.
In NDS eDirectory 8.5, these attributes can be accessed from LDAP by using the name without the spaces. In previous versions of NDS, these attributes must be mapped to valid LDAP names to access them.