OpenLDAP Workshop

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

Listing 5

/etc/httpd/conf.d/repositories.conf

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.

Infos

  1. ldapvi: http://www.lichteblau.com/ldapvi/
  2. Apache Directory Studio: http://directory.apache.org/studio/
  3. OpenLDAP project: http://www.openldap.org

The Author

Ulrich Habel is a Perl evangelist and supporter of the test-driven development method. He is committed to the use of open source technologies in the enterprise and a member of the NetBSD project.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • LDAP integration with popular groupware suites
    Your LDAP directory holds user data for the whole network. Why not save time and avoid duplication by integrating the LDAP directory with your groupware environment?
  • Quick and easy SaaS provisioning for OpenLDAP
    Provisioning SaaS apps for OpenLDAP users with Okta Cloud Connect lets you retain control of your users' data and access to applications, yet gives them the tools they want.
  • Migration from LDAP to FreeIPA
    The change from centralized user authentication on a vanilla LDAP server to the FreeIPA identity management solution is easier than many admins think. Given attention to a few points, the migration takes very little time and effort.
  • Secure passwordless logins with FIDO2 and LDAP
    Log in to your account securely without a password with LDAP and a schema to establish the objects and attributes required for FIDO2 authentication.
  • Single sign-on with Keycloak
    Google and Facebook are two of the biggest providers for single sign-on on the web, with OAuth2 and OpenID, but if you don't want to put your customers' or employees' data in their hands, Red Hat's Keycloak software lets you run your own operations with the option of integrating existing Kerberos or LDAP accounts.
comments powered by Disqus