Authentication With LDAP (Basic)

LDAP (Lightweight Directory Access Protocol) is a widely used network protocol to access directory services. A directory consists of a tree of directory entries (also known as objects), that usually reflect organizational structures. Regardless of the overall complexity of a directory infrastructure and contents, the information contained will, eventually, branch down to an entry for a user, which is what we are interested in, in terms of authentication.

Entries in the directory consist of a “Distinguished Name” (DN), serving as basic unique identifier in the tree, plus a set of attributes, possessing a unique name and one or more values, each.

Note: The DN can change over the lifetime of a particular entry in the directory, for instance, when personnel are reassigned to another department. It is thus not suited for the purpose of external references that point to an entry in the directory.

The set of attributes is defined in a schema. These are part of the configuration of the directory server, and are referenced via the objectClass attribute of an entry.

User entry objects are usually identified by having the object class posixAccount assigned. Examples for attributes defined in the posixAccount object class: uid, loginShell, password, homeDirectory.

LDAP supports a set of actions that can be issued against the directory service; these actions include (but are not limited to):

• Search (search and, optionally, retrieve entries)
• Bind (authenticate)
• Add
• Delete
• Modify

Principle of Operation

Via LDAP, searches can be conducted for entries in the tree, depending on one or more of the attributes in order to find the desired entry and retrieve its DN.

A sample search expression to find a certain user could look like:

(&(objectClass=posixAccount)(uid=Cadence.Jones))

The ampersand denotes a conjunctive operation, thus only entries whose attribute objectClass contain posixAccount and attribute uid equals Cadence.Jones will be returned from the search.

Now, when a user login name is received by the Fabasoft Folio Web Service in the course of a HTTP authentication process, the user entry can be found in the LDAP service, using a search filter similar to the above example.

The resulting DN is used to issue a bind operation against the entry in the directory. Bind additionally requires a password, which has been supplied by the user via the HTTP authentication dialogue, too. If the LDAP bind operation succeeds, the user is granted access to the Fabasoft Folio Web Service.

For additional information, please refer to the documentation provided with your directory server software of choice and start off by reading http://en.wikipedia.org/wiki/Ldap: new window.

More information on HTTP basic authentication is available in http://en.wikipedia.org/wiki/Basic_authentication_scheme: new window.

Requirements

• A well-configured directory server, accessible via LDAP
• Anonymous search access to the directory
• Fabasoft Folio Web Service
• User entries have their attribute objectClass contain posixAccount (from nis.schema)
• Valid user entry and password to test proper operation.
• Verify that the package pam_ldap is installed.

Configuration

Create a new Service Data Source object. Alternatively, the default Fabasoft Folio LDAPDataSource object can be used. Add the following (minimal) set of parameters:

• Parameters
  • Data Source Type
    “LDAP” or “LDAPS” to define the LDAP protocol to be used.
  • Server
    The hostname of the LDAP server.
  • Searchbase
    The location in the LDAP where the search begins.
    Example: ou=org,dc=comp,dc=com
  • Filterkey
    The LDAP filter used for the user lookup.
    Example: (&(objectClass=posixAccount)(uid=%u))

Notes:

• The sequence %u will be replaced with the user logon name as retrieved from the HTTP basic authentication data entered by the user.
• The parameter Server may contain a whitespace-separated list of hosts to try to connect to, and each host may optionally be of the form host:port. If present, the :port overrides the Port parameter.

By default, anonymous directory bind access is required. Alternatively, the parameters Username and Password can be configured to authenticate before the directory bind operation.

To enable LDAPS, add the parameter Transport with the value ldaps. Additionally, make sure that the CA certificate of the LDAP server is trusted by the web server. Import the CA certificate into the Trusted Root Certificate Authorities store.

The created LDAP data source can be configured in the System Configuration tab of the Primary Domain.

Configuration (Linux Environment)

If LDAP authentication should also be used for signatures and/or the Fabasoft Folio Web Management, additional configuration steps are required.

Operating System

In /etc/pam_ldap.conf, change host and base to reflect your directory server settings. Verify proper operation by issuing ldapsearch, which should retrieve all entries under the search base in ldap.conf.

ldapsearch -x "objectClass=*"

Signatures

To allow password signatures for objects in Fabasoft Folio, a named PAM facility needs to exist.

Create the file /etc/pam.d/fscweb containing:

#%PAM-1.0
auth        required pam_ldap.so
account     required pam_ldap.so

Signatures will now be authenticated via LDAP against the directory service, except when Kerberos authentication is in use, because that will take precedence.

Web Management

Create /etc/pam.d/fscwmc identical to fscweb above. If the authentication scheme is identical to that of the web service, a symbolic link. (ln -s) can be created as well, pointing to the file fscweb.  The web management service uses a different facility to enable utilization of different authentication mechanisms for it.

Ensure that users permitted to authenticate on the web management service are members of the group fsc, either locally or via LDAP (attribute gid).

Recommendations

• All attributes that are searched for frequently (such as uid), should be defined as indices in the directory server's configuration, the LDAP backend database shall be re-indexed frequently, if so required.
• Confine LDAP search operations to the smallest possible sub tree in the directory;
  use ou=subcomp,dc=comp,dc=com instead of only dc=comp,dc=com as a search base.
• Using the unambiguous entry identifiers (i.e. entryUUID in OpenLDAP) as foreign keys when referring to the LDAP tree enables you to fearlessly adapt the layout of the tree frequently in order to reflect changes in your organizational structure.