39.3. Objective 3: LDAP Configuration LDAP is an open standard protocol for accessing directory information services. The LDAP protocol runs over TCP protocols and other Internet transport protocols. LDAP can be used to access either standalone directory services or X.500 directories. The hardest part about LDAP is its X.500 heritage. X.500 was part of the now failed OSI network protocol suite. There are many good reasons for the OSI suite failing, and one of them is complexity. The suite was designed by a committee, and the old joke "a camel is a horse designed by a committee" is not without justification. From X.500, the IETF (Internet Engineering Task Force) derived and specified LDAP (Lightweight Directory Access Protocol). LDAP provides the same kind of services as DNS and NIS. When it is combined with SSL (Secure Sockets Layer) and some tricks, it should also be quite secureunlike DNS and NIS. LDAP directory service is based on a client/server model, quite similar to NIS. One (or more) LDAP servers contain the data used to make up the LDAP directory tree or backend database. An LDAP client connects to the LDAP server to make a request. The server responds to the request with either an answer or a pointer to where the client can get an answer to its request. One of the biggest benefits of LDAP over NIS is that LDAP servers synchronize in increments that can be pushed immediately to slave servers, whereas NIS synchronizations transfer all the data every time. The LDAP implementation used on Linux is OpenLDAP. The OpenLDAP project is a collaborative effort to provide an open source LDAP suite of applications and tools. Like Netscape's Directory Server, OpenLDAP is based on the original University of Michigan LDAP server project. Most LDAPs mirror DNS in how they are structured. At example.com, they store their LDAP data under dc=example,dc=com. The dc attribute is a domain component, referring directly to a part of a DNS domain. As in DNS, the order is significant, and the names are hierarchical with the rightmost element being the top of the tree (the start of the tree, because like all trees in computing, the LDAP tree grows from the top down). 39.3.1. Setting Up OpenLDAP Server The OpenLDAP package provides the server slapd, which is complete in itself. There is also an X.500 gateway called ldapd. OpenLDAP accomplishes replication with slurpd.
slapd This is the standalone LDAP daemon. It listens for LDAP connections on default port 389 (636 for SSL).
slurpd This propagates changes from one LDAP database to another using a master/slave topology. OpenLDAP multimaster replication support is under development. The configuration file that sets up LDAP server behavior is /etc/openldap/sldap.conf. The following example file is a good start: include %SYSCONFDIR%/schema/core.schema pidfile %LOCALSTATEDIR%/run/slapd.pid argsfile %LOCALSTATEDIR%/run/slapd.args # Load dynamic backend modules: # modulepath %MODULEDIR% # moduleload back_bdb.la # moduleload back_ldap.la # moduleload back_ldbm.la # moduleload back_passwd.la # moduleload back_shell.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self-write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=my-domain,dc=com" rootdn "cn=Manager,dc=my-domain,dc=com" # Clear text passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory %LOCALSTATEDIR%/openldap-data # Indices to maintain index objectClass eq
Here is the same file customized for a particular installation: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/solaris.schema pidfile /var/lib/run/slapd.pid argsfile /var/lib/run/slapd.args database bdb suffix "dc=company,dc=com" rootdn "cn=Manager,dc=company,dc=com" rootpw {SSHA}qBhyzgbrdg2HFEA4oy9S0VfxLfVlZCuaa directory /var/lib/openldap-data index objectClass eq
And the following command validates the customized configuration: # slaptest config file testing succeeded
The following list describes the directives in the file:
include Specifies that slapd should read additional configuration information from the given file.
pidfile Specifies the file that will contain the slapd server's process ID if it is not running in the foreground.
argsfile Specifies the file that will contain the slapd daemon parameters.
database Specifies which database backend to use to store directory information. Currently, the types listed in Table 39-4 are supported: Table 39-4. Databse backends supported by OpenLDAPType | Description |
|---|
bdb | Berkeley DB transactional backend | dnssrv | DNS SRV backend | ldap | LDAP Proxy backend | ldbm | Lightweight DBM backend | meta | Meta directory backend | monitor | Monitor backend | passwd | Provides read-only access to passwd | perl | Perl programmable backend | shell | Shell (external program) backend | sql | SQL programmable backend |
suffix Specifies the DN suffix of queries that will be passed to the backend database.
rootdn Specifies the directory administrator's username.
Warning: The user specified in rootdn can read and write everything.
rootpw Specifies the hash of the password for the rootdn user.
Warning: Never use an empty or clear password here.
A strong hash can be generated using slappasswd with the CRYPT, MD5, SMD5, SSHA, or SHA schemes. The default, and strongest, scheme is SSHA. # slappasswd -h {SSHA} New password: Re-enter new password: {SSHA}qBhyzgbrdg2HFEA4oy9S0VfxLfVlZCuaa
directory Specifies the database files. Typical contacts are: # ls -l /var/lib/openldap-data total 548 -rw------- 1 root root 8192 Dec 29 2004 _ _db.001 -rw------- 1 root root 270336 Dec 29 2004 _ _db.002 -rw------- 1 root root 98304 Dec 29 2004 _ _db.003 -rw------- 1 root root 368640 Dec 29 2004 _ _db.004 -rw------- 1 root root 24576 Dec 29 2004 _ _db.005 -rw------- 1 root root 8192 Feb 17 19:26 dn2id.bdb -rw------- 1 root root 32768 Feb 17 19:26 id2entry.bdb -rw------- 1 root root 118789 Feb 17 19:26 log.0000000001 -rw------- 1 root root 8192 Mar 10 2005 objectClass.bdb
Tip: All these files should be backed up frequently.
index Specifies the indexes to maintain for the given attribute. With the file in place, start the slapd daemon in debug mode to check whether things are working properly: # /usr/lib/openldap/slapd -4 -d10 -f /etc/openldap/slapd.conf @(#) $OpenLDAP: slapd 2.2.26 (Feb 16 2006 16:42:31) $ bdb_db_init: Initializing BDB database slapd starting daemon: added 6r daemon: select: listen=6 active_threads=0 tvp=NULL
Create organizational units using the ldapadd command and an LDIF file like the following: dn: dc=example,dc=com objectClass: dcObject objectClass: organization dc: example o: Corporation description: Corporation dn: cn=Manager,dc=example,dc=com objectClass: organizationalRole cn: Manager description: Directory Manager
Commit your entries to the directory tree: ldapadd -f file.ldif -x -D "cn=Manager,dc=example,dc=com" -w password
39.3.2. Setting Up Client Tools Setting up an LDAP client requires several steps, which we'll lay out in this section. Some of the tools available to LDAP clients include:
ldapmodify Opens a connection to an LDAP server, binds to it, and modifies or adds entries.
ldapadd Adds an entry. Implemented as a hard link to the ldapmodify tool.
ldapdelete Deletes one or more entries in a database.
ldappasswd Changes the password of an LDAP entry.
ldapsearch A powerful LDAP search tool.
ldapwhoami Implements the LDAP "Who Am I?" extended operation. First, enter the information in the LADP client configuration file needed to be retrieved by these tools. This file should be world-readable, but not world-writable. BASE dc=example, dc=com URI ldap://ldap.example.com ldap://ldap-master.example.com:666
Now verify the entries added to the directory server: ldapsearch -x -b 'dc=example,dc=com' '(objectclass=*)'
This will retrieve every entry in the directory. |
