7.2 Using the LDAP Directory Service

The ever-present complaint of systems administrators who deal with multiple user databases across multiple platforms is that of efficiency. Why can't all of my users be listed, configured, and managed from one set of tools? Why can't my various application servers—secured Web, email, newsgroups, and others—all tie into that one database and use its list? Without a centralized repository for user information, the effort of simply changing a password is multiplied by the number of systems on which a unique copy of the password is stored.

Fortunately, there is an answer, and better yet, it's standards based. The Lightweight Directory Access Protocol, or LDAP, is a directory-based database of information about users of a particular network. LDAP is a protocol that uses standard queries, much like SQL, to talk with a compliant backend. Using LDAP allows applications that support it to communicate with a centralized database and use its information in their internal operations. While a discussion about LDAP could fill volumes (and, in fact, has), the important fact to take away from this commentary is that FreeRADIUS has full and complete support for LDAP. This is part one of the equation. I have an LDAP client, but it needs something to talk to.

Enter CommuniGate Pro, an excellent email server product from the fine folks at Europe-based Stalker Software (http://www.stalker.com). CommuniGate Pro is designed to run on any number of processor architectures: from the Intel x86 regime to IBM's midrange servers and OS/400 computers. The product excels in every respect: it's intelligently designed, easy to install and use, and an excellent performer. The product has been subjected to numerous benchmarks in competition with other Internet mail servers and won each test hands down. It also is a fine LDAP server and can be configured to allow other applications to query its user database in full LDAP compliance. That's part two of our equation.

How does all of this fit together? Most organizations need email functionality. Of course, you're reading this book likely because your organization provides dial-up access to end users, either for profit or as part of your regular corporate business activities. Allowing FreeRADIUS, a robust RADIUS server, and CommuniGate Pro, an excellent mail server, to communicate with each other brings you the best of both worlds: stable server platforms and interoperability to ease the headaches of administration.

In this section, I'll detail how to make FreeRADIUS authenticate against the CommuniGate Pro LDAP user database. Most of the instructions in this section can be applied to any other LDAP database product, but there are a few instructions specific to CommuniGate Pro that are detailed. You can realize the benefits of this integration with any LDAP backend, but using CommuniGate Pro gives you a powerful email server to boot. On that note, let's begin!

7.2.1 Configuring FreeRADIUS to Use LDAP

To instruct FreeRADIUS to use the LDAP protocol instead of PAM or another local user authentication database, you need to install the OpenLDAP product. As of this writing, the latest version of OpenLDAP is 2.0.23. To install OpenLDAP on your system, perform the following steps:

FreeRADIUS Versions By press time, FreeRADIUS Version 0.6 should be released and available from the FreeRADIUS web site. However, the previous version, 0.5, has a buggy LDAP module that cannot handle transactions with LDAP servers that close their connections, such as CommuniGate Pro. The bug has been fixed in the development CVS system; however, the released versions have not been updated. If Version 0.6 is not available, a modified Version 0.5 with the repaired LDAP module code can be downloaded from the author's web site at http://www.jonathanhassell.com.

Now install FreeRADIUS with Version 0.6 or later. The latest information and updates to the FreeRADIUS product, as mentioned in Chapter 5, can be found at the official program web site at http://www.freeradius.org.

Once the programs are installed, some edits to the FreeRADIUS configuration files are required. Inside the main configuration file, radiusd.conf, you must add a modules section that instructs FreeRADIUS to look for and use an LDAP connection. In this case, the LDAP server I want to specify is the CommuniGate Pro server. The following is an example configuration:

modules {
    ldap {
            server = "YourCommuniGateProServer.isp.com"
            port = 10389
            basedn = "cn=isp.com"
            filter = "(|(uid=%u)(uid=%U))"
            start_tls = no
            ldap_connections_number = 5
            timeout = 4
            timelimit = 3
            net_timeout = 1
            }
}

Next, add the LDAP protocol to the authenticate and authorize sections of radiusd.conf. Note that these protocols are followed in the order listed when FreeRADIUS is authenticating a user, so it's certainly possible and, in fact, good practice to set up alternate methods of authentication, both in anticipation of future needs and as a backup source of authentication. The following example shows this section of radiusd.conf configured appropriately to use LDAP and a MySQL database as well:

authorize {
    preprocess
    suffix
    files
    sql
    ldap
}
authenticate {
    ldap
}
preacct {
    suffix
    files
    preprocess
}
accounting {
    sql
    unix
    radutmp
}

Now that FreeRADIUS knows to use the LDAP module as a first point of authentication, that's all that is required on that end. Next, configure CommuniGate Pro to expect and listen for FreeRADIUS' communication.

7.2.2 Configuring CommuniGate Pro for LDAP Use

The CommuniGate Pro LDAP module is amazingly easy to configure. The only caveat with authenticating is that the CommuniGate Pro passwords have to be stored in plain text. However, you can configure the LDAP module in CommuniGate Pro to hide all passwords from all users—even the administrative-like postmaster user—so that they're not accessible from the outside.

First, CommuniGate Pro needs to know that the passwords for the users it knows about (in this case, the users with active email addresses) should be stored in the LDAP directory and not internally. From the administrative web interface, commonly on port 8010, navigate to the Domains menu and then select Directory Integration. Under the section called Custom Account Settings, select the option Store Passwords in Regular Account Records. Click the Update button to refresh the settings.

Next, tell the product to populate the LDAP database with the contents of its current internal database. Navigate to Accounts and then select Domain Settings. On that page, find the Directory Integration section and select Keep in Sync. Finally, click Delete All to flush the database, and then click Insert All to repopulate.

And that completes the configuration. You can test your setup using the NTRadPing utility or the radtest program, both of which are programs covered in Chapter 5.