Central Register

Directory Hardening Cookbook

The following recipe demonstrates how to protect individual directories on the web server with usernames and passwords stored in LDAP. Instead of painstakingly maintaining individual htpasswd files, user accounts can be centrally managed on the LDAP server.

All of the necessary ingredients for this recipe are on the table and ready for use: All you need to complete the recipe is a user account for the HTTPD server, a group with a group member, and a user who is a member of that group.

The directory I want to protected in this example is /repositories in the root directory of the web server. Therefore, the path is – without making any further changes to the SELinux context – /var/www/html/repositories.

Apache version 2.2 fundamentally changed the way LDAP is used. The installation of additional modules is no longer required; the web server already comes with everything you need to use LDAP in the basic installation. The basis of this recipe is the httpd user account on the LDAP server, which I created earlier.

LDAP Modules Included

Authentication and authorization on the web server is handled by two modules: ldap_module provides the LDAP data structures on the web server, and authnz_ldap_module handles authentication. In the default web server configuration, both modules are already installed and enabled. After creating the directory, you need to configure the /repositories path on the server and enable directory protection. To test this, I'll do:

$ sudo mkdir /var/www/html/repositories
$ echo "Hello world" > index.html
$ sudo cp index.html /var/www/html/repositories/
$ sudo chown -R apache /var/www/html/repositories

01 <Location /repositories>
02     AuthType               Basic
03     AuthName               "Repositories"
04     AuthBasicProvider      ldap
05     AuthLDAPBindDN         cn=httpd,ou=systems,dc=acme-services,dc=org
06     AuthLDAPBindPassword   geheim
07     AuthzLDAPAuthoritative Off
08     AuthLDAPURL            ldap://localhost/dc=acme-services,dc=org?uid
09     Require                ldap-group cn=vcsldap,ou=groups,dc=acme-services,dc=org
10 </Location>

The complete configuration shown in Listing 5 was saved in /etc/httpd/conf.d/repositories.conf, and then I restarted the web server. I'll use Curl for the test:

$ curl -sL -w "%{http_code} %{url_effective}\n" http://localhost/repositories/index.html -o /dev/null
401 http://localhost/repositories/index.html

The output correctly shows a 401 error: The directory is protected. But does logging in as a user with the associated password also work? This can be checked easily with the following command:

$ curl -sL -w "%{http_code} %{url_effective}\n" -u uhabel:secret http://localhost/repositories/index.html -o /dev/null
200 http://localhost/repositories/index.html

Voilà, the directory is protected, and everything works as expected.

The web server configuration file has a few special features that are worth investigating. For simplicity's sake I only used ldap in this example, because access was on the localhost and thus routed via the loopback interface.

For production use of web servers that access the OpenLDAP server on the network, use SSL instead (ldaps). Directory protection is implemented here via the vcsldap group and the group members. This means you can set up slightly different groups to protect different areas of the web server.

Future

In this article, I provided a little insight into the world of the OpenLDAP server with the current configuration model (cn=config), and I installed a working OpenLDAP server. Still missing are more users and more applications, but that's reserved for future articles.

The OpenLDAP Server documentation [3] is improving all the time, but the official documentation still often describes the legacy configuration model with the /etc/slapd.conf configuration file. In this case, your only hope is to check the mailing lists, which may shed some light on the issue.