LDAP for Security, Part I
The main server dæmon in OpenLDAP is called slapd, and configuring this program is the first step in getting OpenLDAP working once it's installed. Its configuration is determined primarily by the file /etc/openldap/slapd.conf. The “OpenLDAP 2.0 Administrator's Guide” at www.openldap.org/doc/admin20/guide.html has an excellent quick-start procedure for getting slapd up and running: it's in Section 2, starting at Step 8. That document also explains directory services and LDAP concepts in more depth than this article does, using tree/hierarchy diagrams.
Let's walk through this procedure to make sure you get off to a good start. The first thing to do is edit slapd.conf, an example of which is shown in Listing 1. As you can see, slapd.conf is a typical Linux configuration file: each line consists of a parameter name followed by a value.
The first parameter shown in Listing 1, database, specifies what type of database back end to use. Usually, the best choice here is ldbm, which uses the fast dbm database format, but shell (for custom shell-script back ends) and passwd (to use /etc/passwd as the back end) also are valid choices. There may be multiple database definitions, each with its own set of applicable parameters; all the lines in Listing 1 comprise a single database definition.
The next parameter in Listing 1 is suffix, which determines what queries match this database definition. Here, the specified suffix is wiremonkeys.org, expressed in LDAP-speak as a series of domain component (dc) statements, which are parsed from left to right. In other words, if an LDAP client queries our example server for information about the distinguished name (dn) cn=bubba,dc=wiremonkeys,dc=org, our server matches that query against this database definition, as the dn ends with dc=wiremonkeys,dc=org. See the Sidebar “A Crash Course in X.500 Naming” for more information about distinguished names.
The next two entries in Listing 1 have to do with LDAP database administration; rootdn and rootpw specify the user name and password, respectively, that must be supplied by remote or local commands that perform administrative actions on the LDAP database. Interestingly, this entry is used only for this purpose. It doesn't show up in regular LDAP database queries.
This addresses the paradox of how to authenticate the actions required to populate the authentication (LDAP) database. Later, after you've populated your LDAP database with real entity records, designate one of them as the administrative account, using slapd.conf access control lists (acls), and delete the rootdn and rootpw entries. I'll cover that step in a future column; for now, rootdn and rootpw suffice.
It's a very, very bad idea to store the value of rootpw as clear text. Instead, you should use the slappasswd command to generate a password hash, shown in Listing 2.
As you can see, slappasswd prompts you for a password and prints that password hashed with the algorithm you specify with the -h option. Be sure to enclose this value in curly brackets—see the slappasswd(8C) man page for a list of valid choices. You can copy and paste slappasswd's output directly into slapd.conf, which is precisely what I did to create the rootpw value in Listing 1.
Getting back to Listing 1, the next parameter in this directory definition is directory. Obviously enough, this specifies in which directory on the local filesystem your LDAP directory should be created. Because /var is the customary place for growing files such as logs and databases, Listing 1 shows a value of /var/lib/ldap. This directory must already exist, and make sure it's owned by OpenLDAP's user and group, usually ldap and ldap. Its permissions should be set to 0700 (-rwx------).
Technically, that's enough to get started: you can try starting slapd with your ldap startup script, most likely /etc/init.d/ldap, though this may vary among distributions. I encourage you to start adding practice entries to your LDAP database using the ldapadd command—the quick-start procedure I mentioned earlier shows how.
Before you begin managing and querying your LDAP database over the network, however, you'll want to configure and enable TLS encryption. This is important, as the simple authentication method used by OpenLDAP sends authentication credentials over the network unencrypted. But I'm out of space for now, so we'll cover that next month. If you can't wait until then, Vincent Danen explains how in his on-line article “Using OpenLDAP for Authentication”, at www.mandrakesecure.net/en/docs/ldap-auth.php, though it is somewhat Mandrake-centric. I'll also discuss some considerations in determining the structure of your LDAP database and show how to build one. Until then, good luck!
Mick Bauer, CISSP, is Linux Journal's security editor and an IS security consultant for Upstream Solutions LLC in Minneapolis, Minnesota. Mick spends his copious free time chasing little kids (strictly his own) and playing music, sometimes simultaneously. Mick is author of Building Secure Servers With Linux (O'Reilly & Associates, 2002).
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Control Your Linux Desktop with D-Bus
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)