SSL Preparations

Accessing an authentication server through unencrypted LDAP has not been tested, and is not recommended for security reasons. The normal mode of operation is to use LDAPS.

Moria2 does not support client-side authentication through SSL when accessing the authentication server; that is, Moria2 does not use a client certificate.

The authentication server's owner must provide the Moria2 administrator with the CA certificate used to sign the authentication server's certificate, or, less preferably, the authentication server's certificate itself.

Indexing Information

Following a successful connection and SSL handshake with an authentication server, Moria2 will perform a subtree search to resolve the username into a user element Distinguished Name (DN) for subsequent user authentication.

The following information is needed from the authentication server's owner:

• Authentication server hostname, for example ldap.my.org.
• Authentication server LDAPS port, for example 80636.
• LDAP search base, for example dc=users,dc=my,dc=org.

ldaps://ldap.my.org:80636/dc=users,dc=my,dc=org

This information is then linked to a realm identifier through what is called implicit indexing; in the example above this identifier would typically be my.org, and a user from this organization might have a username on the form someuser@my.org. However, this depends on the realm policy of the Moria2 instance's user base and may take other forms as long as the basic identity@realm pattern is preserved.

Moria2 will by default perform an anonymous search for the user element. However, if the authentication server does not allow for anonymous searches from the search base described above, the authentication server's owner must provide the Moria2 administrator with the credentials required to do a non-anonymous search:

• A bind DN ("username").
• A bind password.

Also, Moria2 may have more than one entry for each organization; that is, for an organization my.org Moria2 may be configured to search for users using more than one LDAP URL. As a result, one organization may employ more than one search base, and even more than one LDAP authentication server. If this is the case, each LDAP URL will be searched through in sequence.

As can be seen in the Directory Manager's configuration documentation, Moria2 also supports explicit indexing, but this is outside the scope of this overview.

Authentication Server Requirements

The LDAP authentication server and its user elements must conform to the following rules:

• Each user element must have an attribute containing the username. Moria2 may be configured to use an arbitrary attribute as username; contact the Moria2 administrator to learn what the correct attribute for usernames should be. The usernames must be on the form given by localID@organization, where localID should be unique within the organization, and the realm organization is the organization short-form identifier described in the above section.
• The server must either allow Moria2 to do a subtree equality search (at least non-anonymous; see the above section) for the attribute containing the username, or have user element DNs on the form

                          uid=localID,LDAP search base
                      

  where localID can be extracted from a username on the form localID@organization. Note that the Moria2 administrator may configure Moria2 to use a different attribute than uid; however, uid is used in the Moria2 instance provided by FEIDE.
• The server must allow LDAP simple bind using the user element's DN and the user's password.
• The server must allow reading of attributes from the user element given by DN following a simple bind using the DN itself.

Optimally, Moria2 should be able to do an equality subtree search for a user element's DN and then perform a non-anonymous simple bind using this DN. Unless the DN contains sensitive user data the initial search phase could potentially be done as an anonymous search.