Server Authentication

This page describes:

  1. the status of authentication,
  2. how to bind (authenticate) as the admin superuser after starting the server the first time,
  3. adding non-superusers and binding to the directory as them,
  4. how to protect user passwords,
  5. how to disable anonymous binds,
  6. how to customize the server to use different authentication mechanisms.

Status

Presently the directory server supports only simple authentication and anonymous binds while storing passwords within userPassword attributes in user entries. Passwords can be stored in clear text or one-way encryped with a hash algorithm like MD5 or SHA1.

Within a short while we'll be able to store passwords using the authPassword property which uses strong one way hashes for authentication such as MD5 and SHA1. These schemes and the schema used are described in detail here in RFC 3112.

How to bind as the admin superuser after initial startup?

You just downloaded the server and started it up for the first time. Now you're wondering how to bind to the server using a graphical LDAP client like JXplorer, Softerra LDAP Browser, or the LDAP Browser/Editor by Jarek Gawor. Maybe you prefer to use the command line tools provided by some operation systems (e.g. Solaris) and other LDAP servers (e.g. OpenLDAP), as shown in this document.

By default the super user or admin account is created when the system partition is created under the 'ou=system' naming context. This occurs when the server is started for the first time. The admin user can be found under the DN "uid=admin,ou=system", with a command line tool for instance you can bind like this (-w is the password option of this client)

$ ldapsearch -h localhost -p 10389 -D "uid=admin,ou=system" -w ***** -b "" -s base "(objectClass=*)" namingContexts

namingContexts=ou=system
namingContexts=dc=example,dc=com
$

The password is initially set to 'secret'. You definately want to change this after starting the server. For the first time you can bind to the server as this user with 'secret' as the password. To change the password for the admin user you'll have to make changes to two places. First you'll have to change the password in the directory for the user (command line tool or GUI client). Second you'll have to change the password in the server.xml configuration file for the java.naming.security.credentials property.

If you did not disable anonymous binds by setting the respective property (described below), then you can bind anonymously to the server without any username or password.

Even when anonymous binds are disabled anonymous users can still bind to the RootDSE as required by the protocol to lookup supported SASL mechanisms before attempting a bind. Don't worry the RootDSE is read only.

Adding and authenticating normal users

By default a user in the server can be just about any entry with a userPassword attribute that contains a clear text password. The DN can be anything reachable within one of the directory partitions. So if you add a partition to hang off of 'dc=example,dc=com' then you can add user entries anywhere under this naming context or just add user entries under the 'ou=system' naming context. Below is an LDIF of a user you can add to the directory as a test user.

dn: uid=jdoe,ou=users,ou=system
cn: John Doe
sn: Doe
givenname: John
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
ou: Human Resources
ou: People
l: Las Vegas
uid: jdoe
mail: jdoe@apachecon.comm
telephonenumber: +1 408 555 5555
facsimiletelephonenumber: +1 408 555 5556
roomnumber: 4613
userpassword: test

You can download this newuser.ldif file and use it to add the user. Below we use the ldapadd OpenLDAP client to import the LDIF file presuming the server was started on port 10389 on the localhost:

$ ldapadd -h localhost -p 10389 -D "uid=admin,ou=system" -w ***** -f newuser.ldif
adding new entry uid=jdoe,ou=users,ou=system
$

You can confirm the add/import by performing a search for the user. This time using the OpenLDAP search client you use the following command:

$ ldapsearch -h localhost -p 10389 -D "uid=admin,ou=system" -w ***** -b "ou=users,ou=system" -s one "(uid=jdoe)"
uid=jdoe,ou=users,ou=system
fax=+1 408 555 5556
telephonenumber=+1 408 555 5555
sn=Doe
...

You can start searching the directory using this new user like so:

ldapsearch -h localhost -p 10389 -D "uid=jdoe,ou=users,ou=system" -w test -s one -b "ou=system" "(objectClass=*)"

Protecting user passwords

Without access controls enabled userPasswords and user entries are accessible and alterable by all: even anonymous users. There are however some minimal built-in rules for protecting users and groups within the server without having to turn on the ACI subsystem.

Without ACIs the server automatically protects, hides, the admin user from everyone but the admin user. Users cannot see other user entries under the 'ou=users,ou=system' entry. So placing new users there automatically protects them. Placing new users anywhere else exposes them. Groups defined using groupOfNames or groupOfUniqueNames under the 'ou=groups,ou=system' are also protected from access or alteration by anyone other than the admin user. Again this protection is not allowed anywhere else but under these entries.

For simple configurations this should provide adequate protection but it lacks flexibility. For advanced configurations users should enable the ACI subsystem. This however shuts down access to everything by everyone except the admin user which bypasses the ACI subsystem. Directory administrators should look at the docomentation on how to specify access control information here: Authorization.

  • No labels