HP-UX Directory Server 8.1 deployment guide

Anonymous access can be limited. Usually directory administrators only allow anonymous
access for read, search, and compare privileges (not for write, add, delete, or selfwrite). Often,
administrators limit access to a subset of attributes that contain general information such as
names, telephone numbers, and email addresses. Anonymous access should never be allowed
for more sensitive data such as government identification numbers (for example, Social Security
Numbers in the US), home telephone numbers and addresses, and salary information.
If a user attempts to bind with an entry that does not contain a user password attribute, Directory
Server can either grant anonymous access if the user does not attempt to provide a password,
or deny access if the user provides any non-null string for the password.
For example, a user named Joe tries to view his own account, even though he does not have a
password in Directory Server:
ldapsearch -D cn=joe -w secret -b "dc=example,dc=com"
"(cn=joe)"
Although the directory allows anonymous access for read, Joe cannot access his own entry
because it does not contain a password that matches the one he provided in the ldapsearch
command.
8.4.2 Simple password
If anonymous access is not allowed, users must authenticate to the directory before they can
access the directory contents. With simple password authentication, a client authenticates to the
server by sending a simple, reusable password.
For example, a client authenticates to the directory via a bind operation in which it provides a
distinguished name and a set of credentials. The server locates the entry in the directory that
corresponds to the client DN and checks whether the password given by the client matches the
value stored with the entry. If it does, the server authenticates the client. If it does not, the
authentication operation fails, and the client receives an error message.
The bind DN often corresponds to the entry of a person. However, some directory administrators
find it useful to bind as an organizational entry rather than as a person. The directory requires
the entry used to bind to be of an object class that allows the userPassword attribute. This
ensures that the directory recognizes the bind DN and password.
Most LDAP clients hide the bind DN from the user because users may find the long strings of
DN characters hard to remember. When a client attempts to hide the bind DN from the user, it
uses a bind algorithm such as the following:
1. The user enters a unique identifier, such as a user ID (for example, fchen).
2. The LDAP client application searches the directory for that identifier and returns the
associated distinguished name (such as uid=fchen, ou=people,dc=example,dc=com).
3. The LDAP client application binds to the directory using the retrieved distinguished name
and the password supplied by the user.
NOTE:
The drawback of simple password authentication is that the password is sent in plain text. If an
unauthorized user is listening, this can compromise the security of the directory because that
person can impersonate an authorized user.
Simple password authentication offers an easy way to authenticate users, but it is best to restrict
its use to the organization's intranet. It does not offer the level of security required for
transmissions between business partners over an extranet or for transmissions with customers
on the Internet.
8.4 Selecting appropriate authentication methods 107