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):
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:
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.
Create a new Service Data Source object. Alternatively, the default Fabasoft Folio LDAPDataSource object can be used. Add the following (minimal) set of parameters:
Note: The sequence %u will be replaced with the user logon name as retrieved from the HTTP basic authentication data entered by the user.
Note: 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 following settings are necessary for the configuration of LDAP:
The following relevant properties are available:
If LDAP authentication should also be used for signatures and/or the Fabasoft Folio Web Management, additional configuration steps are required.
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=*"
To allow password signatures for objects in Fabasoft Folio, a named PAM facility needs to exist.
Create the file /etc/pam.d/fscweb containing:
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.
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).