...
Authentication options
This section describes the authentication options of ApacheDS 1.5. Anonymous and simple binds are supported, as well as SASL mechanisms. Configuring and using the first two of them is described below with the help of examples.
...
...
What is authentication?
Authentication is the process of determining whether someone (or something) in fact is what he/she/it asserts to be.
...
Assume this entry from the Seven Seas partition is stored within the directory (only a fragment with the relevant attributes is shown).
...
In the following search command, a user tries to bind with the given DN (option -D) but a wrong password (option -w). The bind fails and the command terminates without performing the search.
...
If the user provides the correct password during the call of the ldapsearch command, the bind operation succeeds and the seach operation is performed afterwards.
...
Binds from Java components using JNDI
Using JNDI, authentication via simple binds is accomplished by appropriate configuration. One option is to provide the parameters in a Hashtable object like this
...
...
If the DN of a user entry and the fitting password are provided as command line arguments, the program binds successfully and performs a search:
...
On the other hand, providing an incorrect password results in a failed bind operation. JNDI maps it to a NamingException:
...
In real life, you obviously want to separate most of the configuration data from the source code, for instance with the help of the jndi.properties file.
...
If passwords are stored in the directory in clear like above, the administrator (uid=admin,ou=system) is able to read them. This holds true even if authorization is enabled. The passwords would also be visible in exported LDIF files. This is often unacceptable.
...
...
Not only the administrator will be able to read your password, or be visible in LDIF files, but if one does not use SSL, the the password is transmitted in clear text above the wire...
...
Passwords not stored in clear text
ApacheDS does also support simple binds, if user passwords are stored one-way encrypted. An LDAP client, which creates user entries, applies a hash-function (SHA for instance) to the user passwords beforehand, and stores the users with these fingerprints as userpassword values (instead of the clear text values), for instance:
...
...
The value "{SHA}nU4eI71bcnBGqeO0t9tXvY1u5oQ=" means that SHA (Secure Hash Algorithm) was applied to the password, and "nU4eI71bcnBGqeO0t9tXvY1u5oQ=" was the result (Base-64 encoded). Please note that it is not possible to calculate the source ("pass" in our case) back from the result. This is why it is called one-way encrypted – it is rather difficult to decrypt it. One may guess many times, calculate the hash values (the algorithms are public) and compare the result. But this would take a long time, especially if you choose a more complex password than we did ("pass").
...
With some lines of code, it is quite easy to accomplish this task programatically in Java:
...
...
The output is "{SHA}nU4eI71bcnBGqeO0t9tXvY1u5oQ=".
...
From an LDAP client point of view, the behavior during authentication is the same as with passwords stored in clear. During a simple bind, a client sends DN and password (unencrypted, i.e. no hash algorithm applied) to the server. If ApacheDS detects, that the user password for the given DN is stored in the directory with a hash function applied, it calculates the hash value of the given password with the appropriate algorithm (this is why the algorithm is stored together with the hashed password). Afterwards it compares the result with the stored attribute value. In case of a match, the bind operation ends successfully:
...
Providing the hashed value of the userPassword attribute instead of the original value will be rejected by ApacheDS:
...
This is intended. If someone was able to catch this value (from an LDIF export for instance), s/he must still provide the password itself in order to get authenticated.
...
Please note that storing user passwords one-way encrypted only adds limited security. During the bind operation, the credentials are still transmitted unencrypted, if no SSL/TLS communication is used (thus you should definitely consider to do so).
Furthermore, if someone gets an LDIF file with userpassword values digested with SHA etc., s/he may be able to determine some of the passwords with brute force. Calculation of hash functions can be done very fast, and the attacker can attempt millions of values with ease, without you getting notice of it. Therefore protect your data, even if one-way encryption is applied to the passwords!
...
Anonymous access is enabled by default. Changing this is one of the basic configuration tasks. If you use the server standalone configured with a server.xml file, you can enable/disable it by changing the value for property allowAnonymousAccess in the Spring bean definition for bean defaultDirectoryService, as depicted in the following fragment:
...
A restart of the server is necessary for this change to take effect.
Example: Server behavior with anonymous binds disabled
Assume anonymous binds are disabled and our sample partition Seven Seaes present in the server. Here is an example with a search operation performed by a command line tool as a client. It
A restart of the server is necessary for this change to take effect.
Example: Server behavior with anonymous binds disabled
Assume anonymous binds are disabled and our sample partition Seven Seaes present in the server. Here is an example with a search operation performed by a command line tool as a client. It tries to connect anonymously (no DN and password given, i.e. options -D and -w missing) to the server. Afterwards the entry ou=people,o=sevenSeas should be displayed.
See the command and the resulting error message provided by the server below
...
...
Example: Server behavior with anonymous binds enabled
Now the same command performed against ApacheDS 1.5 with anonymous access enabled as described above. The behavior is different – the entry is visible.
...
...
Other clients
The examples above have used a command line tool. Of course graphical tools and programmatical access (JNDI etc.) allow anonymous binds as well. Below is a screen shot from the configuration dialog of Apache Directory Studio as an example. During configuration of the connection data ("New LDAP Connection", for instance), the option Anonymous Authentication leads to anonymous binds. Other UI tools offer this feature as well.
...
With anonymous access enabled it is not only possible to search the directory without providing username and password. With autorization disabled, anonymous users may also be able to modify data. It is therefore highly recommended to enable and configure the authorization subsystem as well. Learn more about authorization in the 3.2. Basic authorization section.
...
Usually the ID is an attribute within the user's entry. In our sample data (Seven Seas), each user entry contains the uid attribute, for instance uid=hhornblo for Captain Hornblower:
...
But how to authenticate a user who provides "hhornblo"/"pass" instead of "cn=Horatio Hornblower,ou=people,o=sevenSeas"/"pass" with the help of ApacheDS?
...
For illustration purposes, here is a simple Java program which performs the steps with the help of JNDI. It uses anonymous bind for the first step, hence it must be enabled (replace with a technical user, if it better meets your requirements).
...
Some example calls:
...
...
The examples consist of an unknown user (an inetOrgPerson entry with uid=unknown does not exist), a successful authenttication, and an attempt with an existing uid but a wrong password.
...