| LINUX REVIEW |
|---|
The information served by LDAP (Lightweight Directory Access Protocol) is referred to as a "directory service". A directory service is a specialized database typically tuned for reading, browsing and searching, unlike traditional databases where complex updating is involved. Inside that directory service you can store anything from personal information and web links to jpeg images and your friends' phone numbers and e-mail addresses. To access the information stored in the directory, you use an access protocol called LDAP, which runs over TCP/IP (see RFC2251).
Information inside an LDAP directory is stored in "entries". Each entry is a collection of attributes that have a globally unique Distinguished Name (DN), which contain a type and one or more values. An example of a type would be "mail", the value of which is an e-mail address. On the LDAP server, this information is arranged in a tree-like fashion from top to bottom. Typically, at the top of this tree you define the country (c=US) or domain (dc=com). Below this, we might have an organization (o=Acme) and organizational units (ou=People). An organizational unit can contain all your Human Resource employees, printers in a building or any other kind of category. In turn, each attribute contained under the organizational unit is controlled by an objectClass. The value of each objectClass attribute obeys a schema or set of rules that add attribute capabilities to your directory. For example, the inetorgPerson objectClass requires the sn (surname) and cn (common name) attributes but also allows optional entries like mail, telephoneNumber and localityName (see example below).
dn: o=Acme, c=US
All of Acme's organizations and attributes will be stored under this DN, which is unique to the directory stored on the server. Acme wants to organize its employees under two departments, Managers (ou=Managers) and Employees (ou=Employees). The resulting relative distinguished names (RDN), meaning relative to the top DN, are
dn: ou=Managers, o=Acme, c=US dn: ou=Employees, o=Acme, c=US
Below you will see the hierarchical structure forming, with US at the top, down to our Management organizational unit and, thus, each individual employee. Acme is just starting out, so let's begin by constructing one manager and two employee entries.
dn: cn=Jason H. Smith, ou=Managers, o=Acme, c=US dn: cn=Ray D. Jones, ou=Employees, o=Acme, c=US dn: cn=Eric S. Woods, ou=Employees, o=Acme, c=US
To reference the common name entry Jason H. Smith, LDAP starts by taking the RDN cn=Jason H. Smith, and concatenating the previous parent entries till it reaches the top level DN.
cn=Jason H. Smith + ou=Managers + o=Acme + c=US -> cn=Jason H. Smith, ou=Managers, o=Acme, c=US
Now that we have the basic structure for our directory, importing the data is next. We will place all this information into an LDIF file. LDIF is the default file format for importing directory information. You can easily write Perl scripts to automate the creation of LDIF data files from system files such as /etc/passwd, NIS or you can grab the excellent migration scripts from the resource sidebar below.
The listing shows our test data, save the information as testdata.ldif. More information on this file format can be found in the LDIF man pages, sections five and eight.
Acme DN, which must exist in the directory before we can add any organizational units
dn: o=Acme, c=US objectClass: organization
The o attribute is required here
o: Acme
Manager organization unit DN. This entry must exist in the directory before we can add any managers.
dn: ou=Managers, o=Acme, c=US objectClass: organizationalUnit
The ou attribute is required here
ou: Managers
The first manager DN
dn: cn=Jason H. Smith, ou=Managers, o=Acme, c=US objectClass: inetOrgPerson
Both cn and sn are required attributes
cn: Jason H. Smith sn: Smith
But these are optional attributes
telephoneNumber: 111-222-9999 mail: headhauncho@acme.com localityName: Houston
We can define another organizational unit
dn: ou=Employees, o=Acme, c=US objectClass: organizationalUnit ou: Employees
And add employees below
dn: cn=Ray D. Jones, ou=Employees, o=Acme, c=US objectClass: inetOrgPerson cn: Ray D. Jones sn: Jones telephoneNumber: 444-555-6767 mail: jonesrd@acme.com localityName: Houston dn: cn=Eric S. Woods, ou=Employees, o=Acme, c=US objectClass: inetOrgPerson cn: Eric S. Woods sn: Woods telephoneNumber: 444-555-6768 mail: woodses@acme.com localityName: Houston
We are going to be using the freely available OpenLDAP package suite for Linux. The OpenLDAP team recently released v2 of their software, which now supports both LDAP v2 and v3. Notable additions with the introduction of LDAP v3 are the Transport Layer Security (TLS) and improved authentication methods. OpenLDAP can be installed in one of two ways: from source code or from a prepackaged deb/rpm. At the time this article was written, the latest stable version was openldap-2.0.6. Packages and/or source can either be obtained from http://www.openldap.org, your distribution CD, http://rpmfind.net, or apt-get. You will likely need both client and server packages if installing via rpm. Here is a quick rundown to install from source.
tar -xzvf openldap-2.0.6.tgz
cd openldap-2.06 ; ./configure --prefix=/usr/local
I like to place my ldap files in /usr/local, but it is not a requirement. The --prefix option will install the software relative to that value. Once configure is done, we need to make the dependencies and then the software.
make depend ; make
Let's run some comprehensive tests to make sure everything is okay before we install.
make test
su -c 'make install'
If any compilation errors occur, consult the OpenLDAP mailing list for information. You might need to add /usr/local/libexec, /usr/local/bin and /usr/local/sbin to your shell PATH.
Begin by editing slapd.conf, the configuration file that controls the slapd dæmon. Slapd is responsible for returning query requests made by client applications accessing the directory service. The config file is located in /usr/local/etc/openldap.
We will need to add some extra schemas to be able to use Netscape address book attributes. Add these lines to the top of your slapd.conf file, near the other include statements. Note that, depending on how you installed OpenLDAP, the path to your schema directory might be a little different than what is shown here.
include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema
Further down in slapd.conf, replace the suffix and rootdn lines to reflect our Acme DN.
suffix "o=Acme, c=US" rootdn "cn=root, o=Acme, c=US"
The cn=root entry is our administrative DN, which is not subject to any type of access control or restrictions. It defaults to cn=Manager, but like all UNIX geeks, I want root access.
Add these lines to the bottom of the slapd.conf file, which will give Netscape the read access it needs to perform directory filtering and searches. All unauthenticated requests to our directory service will connect as anonymous. The DN entry below is "normalized", which means all spaces where taken out, and values are separated with commas. In access control, you MUST normalize the entry, or it will not work.
access to dn=".*,o=Acme,c=US" by anonymous read
Access permissions to the directory can be finely tuned to meet your personal preferences and needs. The OpenLDAP 2.0 Administrators Guide has a wonderful section on configuring access permissions in slapd.conf. For our testing purposes, though, this access level will be sufficient.
Now we need to start the LDAP server daemon slapd. If you installed via rpm/deb, depending on which flavor of Linux you are running, the rc script is probably /etc/rc.d/init.d/ldap or /etc/init.d/ldap. A manual startup for testing can be performed:
slapd &
Test to see if slapd is running.
ps -ef | grep -i slapd | grep -v grep root 15479 1 0 10:42 ? 00:00:00 slapd root 15483 15479 0 10:42 ? 00:00:00 slapd root 15484 15483 0 10:42 ? 00:00:00 slapd root 15491 15483 0 10:43 ? 00:00:00 slapd root 15492 15483 0 10:43 ? 00:00:00 slapd
And then double-check we are bound to the default port 389.
netstat -an | grep 389 tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN
Everything looks good there. Now, let's import the data into the database.
ldapadd -D "cn=root, o=Acme, c=US" -W -v -f testdata.ldif
We bind to the directory using the -D parameter and our unrestricted cn, which effectively allows us to write information to the directory. The -W parameter causes the server to prompt for a password. The default password is configured with the rootpw line inside slapd.conf and is secret. Leaving in the default password is a serious security risk; please change this after testing is done! Be sure to watch the verbose output (-v) for any strange errors that might appear.
Open up Netscape, then Address Book, then click File->New Directory. Enter the appropriate information for your LDAP server.
Description: Acme Address Book
LDAP Server: the IP/hostname address of your LDAP server
Server Root: o=Acme, c=US
The port number and rest remain untouched for now. Again, we are connecting unauthenticated, so no name and password need to be set here.
Click okay, and then highlight "Acme Address Book" inside the directories box on the left. Finally, in the Show names containing: box, enter a query, such as Smith, and hit return. You should see a single line of data returned.
If you want to have a separate list for each organizational unit, you can create another new directory entry in Netscape address book.
Description: Acme Managers
LDAP Server: the IP/hostname address of your LDAP server
Server Root: ou=Managers, o=Acme, c=US
This will only search the organizational unit Managers inside our Acme directory, which gives us a level of filtering. The same can be done for Employees or any other category you might have.
Using Netscape's address book to access an LDAP server is a great way to get experience using basic LDAP concepts. Below is a list of resources you might find useful if you wish to venture out and have your LDAP directory authenticate some common Linux services, such as system logons and access to Samba.
Copyright 2001 Specialized Systems Consultants, Inc.
|
|