I started learning about ldap when my company felt the need for a centralized storage of user account information, and wanted to use ldap for this. I soon found that there were bits and pieces of documantation everywhere, but that there was no document that put it all together. This has been the reason to start it.
Furthermore, Ldap is becoming more widely used every day. I think it is useful that when people are considering to use Ldap, they can get a full overview of which applications are Ldap aware. This might help them to choose their system setup carefully, without throwing everything about every time they want to change something or add functionality.
It started out as a project roadmap on how we wanted to implement Ldap for our own uses. But thanks to my employer, Linvision, who gave me the opportunity to do some research on things that weren't really useful to our own cause, it changed from a roadmap to a technical overview of applications that are ldap aware.
Most of the common services can be authenticated through PAM, Pluggable Authentication Modules. With the pam_ldap and nss_ldap modules, all pamified programs can get their information from LDAP. More information about PAM in general can be found on the Linux-PAM site. Information about pam_ldap and nss_ldap can be found on the padl software site.
For Samba, things are a little difficult at this moment. The current stable Samba versions do not have Ldap support. Ldap support can be found in the HEAD and TNG branch, and probably also in the combined tree. The problem is that samba has it's own usernames and passwords. It does have usage for PAM, in fact, but that is not sufficient to do all the authentication and retrieval of user information. Because the implementation of LDAP in samba is not fully finished yet, there are a few limitations to the use of ldap with samba. From my experiences, the HEAD is at this time (early June 2000) not stable enough, and the performance is unsatisfying. However, when the ldap support is fully functional in the new releases, samba too can be configured to get all of it's user information from ldap.
Another thing that can be stored into an ldap database is DNS. When the amount of machines connected to your network increases, it is no longer feasable to edit the DNS files by hand. When machine accounts are stored into ldap, two simple DNS entries (one for the lookup, and one for the reverse lookup) can easily be added at the same time. This too provides a simplification of system management. Although the storage of DNS entries in an ldap database may not be neccesary for most systems, it may prove useful to some people.
Since sendmail version 8.9 (see sendmail.net for more details), sendmail has Ldap support. Postfix and QMail are ldap-aware too. When setting up an email system which has multiple mailhosts and or fallback hosts, it is convenient to store all the information in one place. Normally, every system needs to be configured separately, with the same information. When using ldap, this can be avoided.
Roaming access can also be used with LDAP. Netscape versions 4.5 and up have the possibility to store user data like bookmarks and such via an HTML or LDAP server. This gives users their good old preferences, wherever they log in and use Netscape.
Microsoft's office programs can import address books. Thay can also use an Active Directory service to automagically match emailaddresses to user names or nicknames. With Ldap this can be done on a Linux system, without the need for Microsoft Exchange Server or something the like.
First thing: I will try not to talk too much about the actual setup and administration of Ldap itself. There is an excellent Ldap HOWTO available at the Linux Documentation Project that discusses this.
Secondly, I will not discuss things regarding the applications itself, when they have nothing to do with Ldap.
Lastly, in most cases, I cannot tell you if it is wise to use Ldap. I don't have that kind of experience. I can tell you how to do it, if you want, but i cannot tell you if you should. There is plenty documentaion available that discusses the useability of Ldap in general.
At first, I would like to thank my employer, Linvision, for giving me the opportunity to work on this document in their time.
Furthermore, I would like to thank the following people, who have contributed to this document in some way (in no particular order): Giuseppe Lo Biondo.
This document is provided as is and should be considered as a work in progress. Several sections are as yet unfinished, and probably a lot of things that should be in here, aren't. I would greatly appreciate any comments on this document, of whatever nature they may be.
In any case, think before you go messing around with your system and don't come to me if it breaks.
This section focuses on how to use LDAP as a NIS substitute for user accounts management. Having a lot of user accounts on several hosts often causes misalignments in the accounts configuration. LDAP can be used to build a centralized authentication system thus avoiding data replication and increasing data consistency.
At the moment the most used method to distribute users account data and other information through a network is the Network Information Service (NIS). Like LDAP, NIS is a distributed service that allows to have a central server where configuration files such as passwd, shadow, groups, services, hosts etc. are kept. The NIS server is queried by NIS clients to retrieve this information.
LDAP can offer the same functionality of NIS, moreover there are several advantages on using LDAP:
Herein I'll focus on how an LDAP server can be used for authentication and authorization on systems providing the Pluggable Authentication Module (PAM) and the Name Service Switch (NSS) technologies, in particular I'll refer to the Linux operating system even if this instructions can be applied to other operating systems.
The environment proposed consists of an LDAP server where users account data is stored in a convenient format and a set of Un*x clients using this information to authenticate and authorize users on resources in a standard Un*x fashion.
A secure channel is also required in client/server communications since critical information such as user account data, should not be sent in clear over the network, this channel will be provided by the Secure Socket Layer.
On the client side a caching mechanism, needed for performance issues, can be provided by the Name Service Caching Daemon.
All (almost) the software used to build this system is Open Source.
This section outlines the various components that are used to build the authentication system. For each component is given a brief description.
The Pluggable Authentication Module allows integration of various authentication technologies such as standard UNIX, RSA, DCE, LDAP etc. into system services such as login, passwd, rlogin, su, ftp, ssh etc. without changing any of these services.
First implemented by Sun Solaris, PAM is now the standard authentication framework of many Linux distributions, including RedHat and Debian. It provides an API through which authentication requests are mapped into technology specific actions (implemented in the so called pam modules). This mapping is done by PAM configuration files, in which, for each service are basically given the authentication mechanisms to use.
In our case, the pam_ldap module, implemented in the shared library pam_ldap.so, allows user and group authentication using an LDAP service.
Each service that needs an authentication facility, can be configured through the PAM configuration files to use different authentication methods. This means that it is possible, using the PAM configuration files, to write a custom list of requirements that an user must satisfy to obtain access to a resource.
Once an user is authenticated, many applications still need access to user information. This information is traditionally contained in text files (/etc/passwd, /etc/shadow, and /etc/group) but can also be provided by other name services.
As a new name service (such as LDAP) is introduced it can be implemented either in the C library (as it was for NIS and DNS) or in the application that wants to use the new nameservice.
Anyway, this can be avoided using a common, general purpose, name service API and by demanding to a set of libraries the task of retrieving this information performing technology based operations.
This solution was adopted in the GNU C Library that implements the Name Service Switch, a method originated from the Sun C library that permits to obtain information from various name services through a common API.
NSS uses a common API and a configuration file (/etc/nsswitch.conf) in which the name service providers for every supported database are specified.
The databases currently supported by NSS  are:
Using the nss_ldap shared library it is possible to implement the maps above using LDAP, anyway here I'll focus only on the LDAP implementation of shadow, passwd and group database tough all the maps above can be implemented. For most of the other maps it is even unadvisable to store them in ldap, as they tend not to change too often, so it is not a problem to have them locally as files, and storing them in ldap would cause some minor performance loss.
For our application LDAP is used to provide clients with information about user accounts and user groups. The standard objectclasses that are used to represent users and groups are: top, posixAccount, shadowAccount and posixGroup.
Users entries on the database must belong at least to the top, posixAccount and shadowAccount objectclasses. Group entries must belong to the top and posixGroup objectclasses.
The implementation of pam_ldap and nss_ldap that we use refers to this objectclasses, that are described in RFC 2307.
The Name Service Caching Daemon (NSCD) is used to cache name service lookups and can improve performance with the services provided by the NSS.
It must be tuned with a large cache for passwd entries in order to have acceptable performance on the client side.
It has some disadvantages however, like the introduction of cache inconsistencies, so you would want to be sure you need this before you use it. We have succesfully running some systems without it, and personally i think that it isn't really neccesary on relatively small systems.
For details on SSL refer to Section 10.
SSL is needed in the communication between the LDAP server and the clients libraries (pam_ldap.so and nss_ldap.so), since sensible data, such as password entries, needs to be encrypted between the client and the server. SLL also permits the client to uniquely identify the server, thus avoiding to obtain authentication informations from an untrusted source.
Client authentication (the server identifies the client) is not supported in the current implementation of pam_ldap and nss_ldap modules tough it may be useful.
This section describes the steps needed to build the authentication system using the components described in the previous section.
Though this layout may seem quite complex to implement, most of the components are already in place in a Linux system.
On the server side an LDAP server must be installed and configured. The LDAP server used is OpenLDAP, an open source LDAP toolkit including an LDAP server (slapd), library and utilities.
At the moment OpenLDAP comes with two implementation of LDAP: a V2 implementation (OpenLDAP 1.2.x) ad a V3 (OpenLDAP 2.0.x) implementation
The V3 implementation provides native SSL, the V2 doesn't. Anyway it is possible to use an SSL wrapper to add SSL capabilities to the server (see Section 10).
You can refer to the LDAP-HOWTO for instruction on installation and configuration of LDAP
Once slapd is properly configured we need to insert some data for the initial creation of the database. Therefore an LDIF (LDAP Data interchange format) file must be created. This is a text file that can be imported in the LDAP database with the command:
If you use OpenLDAP 2.0.x (LDAPv3) you can find the standard nis schema in the file etc/openldap/schema/nis.schema, include it in your slapd.conf with the include directive, to have schema enforcement.
Here is an example of a minimal LDIF file. Each entry is separated by a blank line.
Here we defined the base DN for the orgazation dc=yourorg, dc=com under which are contained two sub organizational units: people and groups. Then is described a user that belongs to the people organizational unit and a group (which the users belongs to) under the groups organizational unit.
The LDIF file must be imported in the server while it is not running since the ldif2ldbm command builds the database directly, bypassing the LDAP server. Once the LDIF file is imported into the database, the server can be started.
On the client side pam_ldap.so and nss_ldap.so are required and they must be compiled using the Netscape LDAP Library (Mozilla) since it provides the required LDAPS (LDAP over SSL) API. The library is distributed in a binary package under Netscape One license and is not open source (it is public domain anyway).
The package can be extracted, for example, in the directory /usr/local/ldapsdk.
Client libraries must also have access to a certificate database containing the LDAP (stunnel) server certificate and the CA certificate of the CA that signed the server certificate (marked as trusted).
The certificate database must be in Netscape format since the Mozilla LDAP API used to compile pam_ldap and nss_ldap uses certificate databases in Netscape format.
To deal with such certificate databases it is convenient to use the certutil utility found in the PKCS#11 package provided by Netscape .
The main configuration file for LDAP clients is /etc/ldap.conf.
Note that if you use nss_ldap, you don't strictly need to use pam_ldap.
You can use the pam_unix_auth module instead, since nss_ldap maps all getpw* and getsh* calls into LDAP lookups and pam_unix_auth uses this calls to authenticate users.
To compile and install pam_ldap, do the following:
The configure switch --with-ldap-lib tells which LDAP library you are going to use.
The switch --with-ldap-dir tells where you have installed your Netscape ldapsdk toolkit.
This will install /lib/security/pam_ldap.so.1 and the various symlinks.
PAM has to be properly configured in order to access the new authentication system. PAM configuration files are located in the directory /etc/pam.d and are named after the service for which authentication is provided.
For example this is the PAM configuration file for the login service (in a file named login).
Standard PAM configuration files for use with PAM can be found in the pam_ldap source distribution, in the directory pam_ldap-version/pam.d.
This files can be copied in the /etc/pam.d directory. Caution must be given when performing this operation, since if something goes wrong you probably will not be able to login again. It is suggested to make a backup copy of /etc/pam.d before installing new files there and to leave an open privileged shell.
After you've unpacked the sources, check the makefile. For most configurations, it doesn't need to be edited. Anyway, if you want to use SSL you must link against an SSL aware LDAP library, such as the Netscape one.
Assuming that the ldap sdk is in /usr/local/ldapsdk you have to modify the Makefile to enable SSL. Look for NSFLAGS in Makefile.linux.mozilla and uncomment -DSSL.
Also check the LIBS definition to see if the ldapssl library specified in the file is the same that you have installed (ldap_nss.so compiles with both libldapssl40 and libldapssl30).
Then you can install the library:
this installs /lib/libnss_ldap.so, which is the nss_ldap library, and a set of example configuration files, /etc/nsswitch.ldap and /etc/ldap.conf, in case they do not exist already.
Once you have installed it you must edit the NSS configuration file /etc/nsswitch.conf. Tough LDAP can be used for all the services we use it only for passwd, group and shadow therefore we should have something like:
in the first lines of the configuration file. With this configuration, entries are first looked in the system files and, if no value is returned, the LDAP server is queried.
NSCD is already available in many Linux distributions, anyway it can be found within the GNU C library package.
The NSCD configuration file is /etc/nscd.conf. Each line specifies either an attribute and a value, or an attribute, cachename, and a value. Fields are separated either by SPACE or TAB characters. cachename can be hosts, passwd, or groups (in our case we won't cache hosts).
Keep in mind that the nscd program caches passwd entries obtained from LDAP.
This means that when an user is modified on the ldap server, the nscd cache remains valid. This is avoided when using flat unix files by the check-files directive that invalidates the cache when the corresponding file is modified. Such a mechanism should be generalized, at the moment anyway does not apply to LDAP. A way to avoid possible misalignments between the LDAP server and the cache is to invalidate the cache manually when updating passwd entries with the command:
Where TABLE can be passwd, groups or hosts.
To avoid confusion when testing, do not use nscd.
Moreover using nss and nscd will produce a lot of open filedescriptors, so is easy to run out of available filedescriptors on the system (this can hang your system).
You can increase the maximum number of filedescriptors in a Linux box (Kernel 2.2.x) with something like:
The maximum number of filedescriptors suggested for a system depends anyway from the configuration of your system.
The LDAP client configuration file /etc/ldap.conf is read by pam_ldap and nss_ldap as well as other LDAP clients. The following is an example of how it should look like in our environment.
The pam_groupdn directive is useful when an LDAP server provides authentication information to a pool of clients, but the user should be authorized only on a set of clients. This directive can provide the same functionality of NIS netgroups.
The SSL configuration directives are not documented in the package, but they tell to enable SSL and where the file containing the LDAP server certificate and the CA certificate is stored.
A Netscape certificate database named cert7.db is searched in sslpath. This file must contain the server certificate and the CA certificate (unless the server certificate is self signed). There are two ways to generate this file: using the Netscape PKCS#11 tools or using the Netscape browser.
With the Netscape browser, after you have started slapd and stunnel on the server you can use Netscape Navigator to connect to the URL https://your.ldap.server:636/, you will be prompted to insert the server certificate in your database. Also the CA certificate (provided by your CA) must be loaded in the database (unless you are using a self signed certificate). At this point you can copy the $HOME/.netscape/cert7.db in sslpath. It is preferred that you use a scratch account with a default cert7.db file since other server certificates, that may be present in your personal certificate database, will be considered by your LDAP client as trusted authentication servers. Once the browser has imported the server certificate it can be used to debug SSL since it will behave like the pam and nss libraries.
On the server side you have to start slapd (the LDAP daemon process) with a command like:
If you use stunnel, it has to be started on the LDAPS port 636:
If you use OpenLDAP 2.0.x, compiled with TLS (OpenSSL), you can start the server using the command
On the client nscd can be started with the a startup script, usually found in many Linux distributions:
If PAM and NSS are correctly configured this should be enough.
At this point account creation and maintenance should be done using LDAP client tools.
Unfortunately these general purpose tools are not intended for Un*x accounts maintenance. The one that seems to be enough versatile is the LDAP Browser/Editor (http://www-unix.mcs.anl.gov/~gawor/ldap) that allows to set passwords in various formats and can use SSL to connect to the server.
As it is for NIS with a single master server (no slave servers), LDAP without a replication mechanism represents a single point of failure for the authentication system. For authentication purposes it is rather important to implement LDAP replication. The server that cames with OpenLDAP (slapd) provides replication capabilities.
The following are the file permissions that should be applied to some of the files used by the authentication system.
A Radius Server, is a daemon for un*x operating systems which allows one to set up (guess what!) a radius protocol server, which is usually used for authentication and accounting of dial-up users. To use server, you also need a correctly setup client which will talk to it, usually a terminal server or a PC with appropriate which emulates it (PortSlave, radiusclient etc). [From the freeradius FAQ]
Radius has its own database of users, anyway, since this information is already contained in LDAP, it will be more convenient to use it!
There are several freeware Radius servers, the one that has good support for LDAP is the FreeRadius server (http://www.freeradius.org), it is still a development version, anyway the LDAP module works fine.
Once you have installed the server you have to configure it using the configuration files, that are located under /etc/raddb (or /usr/local/etc/raddb)
In the radiusd.conf file edit :
Also edit the dictionary file:
And the users file to have a default authorization entry:
If you alreay set up an LDAP server for Un*x accounts management, this is enough.
On the LDAP server ensure also that the radius server can read the all the posixAccount attributes (expecially uid and userpassword).
To test everything server start radiusd in debugging mode:
Then use the radtest program whith a syntax like
If everything went fine you should receive an Acces-Accept packet from the Radius server.
You can also use stunnel in client mode to provide SSL in the connection between the Radius server and the LDAPS server. For details on SSL refer to Section 10.
Just for completeness, here is a sample Cisco IOS configuration. Anyway, this is outside the purpose of the HOWTO so it may not suit your needs.
The current stable samba tree does not contain ldap support. The HEAD and TNG branches should, but are still under heavy development. When stable version are released I will document the implementation of samba in it here. Until then, you might want to take a look a document written by Ignacio Coupeau, where he describes the setup of Ldap for both of these branches.
Anyway, at this point, the smbpasswd file still has to be used. User account information is already retrieved from ldap, though. (As this is done by nsswitch, not samba.) When samba supports ldap, it should be possible to store the information that is now contained in the smbpasswd and optionally smbusers files in ldap. Whether it is possible for shares to be dynamically defined in ldap, I don't know, but I suppose it is not.
There are to ways of dns that can be configured via ldap, client side and server side. The first, client side, is using the name server switch to access the dns entries in the Ldap database. This means that only clients that modify their /etc/nsswitch.conf file will see the dns entries from ldap. The second way to do it is to use ldap as a backend for bind or tinydns. There are some projects going on about this subject and i will describe them below.
When using nss to access (additional) host entries, please take not that only "friendly" machines (e.g. machines that you know of and whoes configuration you can control) can use this service. It might be useful for intranet host lookups that change often, but it cannot be used to distribute your webservers virtual hostnames to the world. Note that also the nslookup command bypasses both /etc/hosts and ldap, so it cannot be used to check if your setup is working. Use something like host or ping instead, which does a lookup with the internel gehostbyname() function.
To have the name server switch use ldap for dns lookups it must be configured with nss_ldap. How to set up nss_ldap, you can find in Section 2. Here i will assume you have a working nss_ldap configuration. The dns lookups of nss are controlled with the hosts line in /etc/nsswitch.conf. It is very unlikely that you do not already have a hosts line. Most probably it will contain the files and dns entries. You should add ldap to it like this:
Think well about the order in which you specify these! It is advised always to put files as the first entry. Then, if you want ldap to override your local dns server, you have to make sure that the ip of the ldap server can be found in the /etc/hosts file. If not, you will have a nice recursive lookup going. -- You want to look up a host, it's not in files, so we try to contact the ldap server, whoes ip we don't know, so we try to look it up in files, where we cannot find it, so we try to contact the ldap server -- get the point? You could bypass this problem entirely by referring to your ldap server with an ip number instead of a hostname (in /etc/ldap.conf, that is.)
The schema used for this, and similar services, can be found in RFC 2307. Entries used for mapping names to ipnumbers are in an objectclass ipHost. The name part of the mapping is given in the attribute cn, while the ip part lives in ipHostNumber. A typical ldif entry would therefore look like this:
Of course, the usual restrictions and possibilities that come with dns apply.
There are a few possibilities with bind or tinydns nowadays, but imho none of them is a "real" solution (yet). I must say, however, that i have no experience with any of them. They are listed below.
David Storey is working on a patch for Bind, which makes it get its data directly from ldap. This means that every time a request is performed on the bind daemon, it does a lookup in ldap. At this time, his future plans were: (Taken from the source) to have at least two modes of operation: cached and dynamic. Cached mode operates just like an rbtdb by loading the entire zone into memory and reloading whenever the server is HUP'ed. Dynamic mode is much like it is now: every request means an LDAP lookup. For up to date information you should check out the sources.
Taken entirely from their website:
ldap2dns is a program to create DNS records directly from a LDAP directory. It can and should be be used to replace the secondary name-server by a second primary one. ldap2dns helps to reduce all kind of administration overhead. No more flat file editing, no more zone file editing. After having installed ldap2dns, the administrator only has to access the LDAP directory. If he desires he can add access control for each zone, create a webbased GUI and add all other kind of zone and resource record information without interfering with the DNS server. ldap2dns is designed to write binary data.cdb files used by tinydns, but also may be used to write .db-files used by named.
The projects homepage is here.
i will describe three different MTA's in this section, Sendmail, Postfix and Qmail. These are three MTA's that can be configured to use Ldap for the retrieval of information. From personal experience, I must say that Postfix is much easier to set up than sendmail, but this may change in the future, as the ldap support in sendmail develops to a more mature state. I have not used qmail myself.
Sendmail has support for ldap since somewhere around version 8.8.x using the map type ldapx.From version 8.10 and up an ldap database type ldap is supported. Please note that the ldap map support is not enabled per default in the RedHat package. Debian versions 2.2 and later do have ldap support in their sendmail, I am told. If you have to compile it yourself, please read the file sendmail/README from the sendmail sources. It contains valuable information about how to compile in the ldap support.
Both the old and the new ldap map type have the ability to look up entries in an ldap database. There is one thing that must be noted however. When a search is being done, only one result should be returned. If more results are found, only the first is used. Additionally, is multiple return values for that result are found, only the first is returned. Let's take a look at the following example ldif file:
If a search is performed with a simple search filter like cn=mailuser1, and the attribute that is asked for is mail, only email@example.com, is returned. To get both results, they should we stored in a single-valued attribute with comma-separated values, like this:
An email message containing information related to this subject can be found at the LIH home.
When ldap maps are available, almost anything can be looked up in an ldap database. What we would like to do is to simplify the configuration of the following setup.
Let's say we have a medium-sized or large network where we recieve for many domains. We have two mailhosts and two or three fallback hosts. This setup will normally have four places where three types of information are stored.
To understand how this information is read from an ldap database instead of the regular files a little background knowledge of the sendmail.cf file is neccesary. The information we're dealing with here is stored in two different ways. The local-host-names file is read into a class (class w, to be exactly, hence the old extension cw), while the virtusers file is used through a simple map. The aliases file is also a map, but it is defined in a different manner and used internally, instead of being referred to in rules.
When information is retrieved from a ldap database, it always ends up being in a map. This is somewhat problematic with the information stored in the local-host-names file, because this used to be a class. I have been unable to fill the class with the information from the map or something alike. That would be the easy way, but I think it's not possible. (If I'm incorrect about this, please let me know). Therefore, I had to define a new map, and insert rules in the sendmail configuration to make sure that (almost) every time when a value is looked up in the class, the new map is searched for the value too.
For the maps, the change of configuration is easy. A map is normally defined with a name and database type, and some database-specific options, (like the location of the file, for the normally used newdb database types). So for maps, it suffices to change the definition of the map and voila, we're done. Ldap maps have a few more options, some of which can be predefined. They are explained in the following list (largely taken from Booker Bense's document):
Ldap-specific map options in sendmail.cf
PLease note that all ldap options must be double-quoted and must immediately follow the sendmail option. Here is an example:
For this particular setup I have defined a subtree mail in the ldap directory, under which all mail-related information will be stored. I t would have been possible to store some of the user-related mail-information in the ou=Users subtree, but I have specificalle chosen not to do this. When using a separate subtree, all information for sendmail is stored in a single place, and, when having many users, searches may be faster, because not the entire ou=Users subtree needs to be searched, but only the ou=mail subtree.
In this subtree two kinds of records will appear.
Here are a few sources of information that might be useful:
Postfix has native ldap support. A lot of options in postfix can be configured using maps which can be of various types. One of those types is ldap. For each ldap map a couple of options can be configured. (See Section 6.2.2.)
The process of having postfix look up certain data in an ldap database is pretty straightforward. The most common use (so i think) is to have postfix look up virtual users in the ldap database. Together with the above explaind nss_ldap feature, this allows you to have all your email users in an ldap database. But other things can be configured too, like the domains postfix is allowed to relay mail for, or relay mail from, or for which is should act as a backup mail server.
The description of the configuration options is completely taken from LDAP_README in the postfix docs from version 20001217.
If you want a virtual domain (say foo.virtualdomain.com) and you want to store email addresses in Ldap for this domain, youwould need the following piece in your main.cf.
With this setting, if postfix receives mail for a user with a domain part "foo.virtualdomain.com", to do a search in the database for entries that have an attribute mailacceptinggeneralid that matches "firstname.lastname@example.org". If such an entry is found, the values of all available maildrop attributes are returned, and to these values the mail is delivered. If "email@example.com" is not found, another query is performed, that tries to match the catchall user, "@foo.virtualdomain.com". If this is again not found, the message will be bounced.
A very useful feature of an Ldap database on a linuxserver is that when you have an internal network in your organization, you can have a single place to store all your external contacts. You could even divide it in groups, or departments. It is no longer neccesary to give each employee a seperate address book. Apart from using Ldap, this could also be done with Microsoft Exchange Server, Lotus Domino, and Netscape Active Directory.
To use Microsoft Address Book and programs that rely on it, such as Microsoft Outlook, Microsoft Outlook Express and Microsoft Outlook 2000 there is no need to change the basic ldap configuration. There are two things that need to be modified though.
At first, you have to create a directory tree to store your addresses and relevant data. In Section 11 will be shown which entries will be used in this tree.
Second, you have to make sure that all hosts on your local network have read access to this tree. This will be dealt with in the chapter 'security' which is not finished yet.
All Microsoft Email programs can use the Ldap Directory Services. If you want to search for people, you have to use the Address Book. When composing a new email message, a name can be automatically matched to an email address. To do this, the cn,sn,givenname and mail fields are searched. When you want to configure your Microsoft email program to use an Ldap server as your address book, or to look up email addresses, you need to do the following:
Now, when you enter a name in the to: field, the email address is looked up in the Ldap Directory, and automagically filled in for you. If an entry is not found, a window is presented, and any typos can be corrected, or a new search can be done.
This section focuses on how to publish digital certificates into an ldap server. You need to publish digital certificates if you run a Certificaton Authority. Publishing to LDAP is a simple way to make this information available in the network .Also many certificate aware software uses LDAP as a preferred repository for user certificates.
This allows to keep users certificates with the rest of the user information avoiding useless replication of data.
To deal with certificates you need a cryptographic toolkit, the one used here is OpenSSL.
The LDAP server used here is OpenLDAP 2.0.x.
Your LDAP server must support objectclasses that allows attributes to store certificates. In particular you need to store in the LDAP server the Certification Authority certificate, the Certificate Revocation List, the Authority Revocation List and end users certificates.
The certificationAuthority objectclass implements the authorityRevocationList, certificateRevocationList and cACertificate attributes.
The inetOrgPerson objectclass supports the usercertificate (binary) attribute.
You can also use the mix-in objectclass strongAuthenticationUser to add certificates to non inetOrgPerson entries.
You can include required schemas to OpenLDAP including the following schemas into your slapd.conf file.
Certificates are encoded using ASN.1 DER (Distingushed Encoding Rules). So it must be published into the LDAP server as a binary piece of data (using BER encoding).
You can convert a pem certificate into der format using openssl
Then an LDIF file can be created using the ldif utility provided with OpenLDAP. The command:
creates an usercertificate attribute encoded in BASE64. You can add this certificate to an LDIF entry and then use ldapmodify to add the certificate to an entry.
Where cert.ldif contains something like:
It is also possible to specify the certificate in the LDIF file as:
Once you stored certificates in the server you may wonder to retrieve them.
Among other clients, Netscape has supprt to retrieve certificates automatically from an LDAP server. Using the Security Panel-->User Certificates-->Search Directory; you can search for certificates in the LDAP dierctory and have them automatically installed in your Netscape certificate database.
Another client that has good support for certificates is web2ldap www.web2ldap.de
The Secure Socket Layer (SSL) is an application layer protocol that provides a secure transmission channel between parties. It stands between TCP/IP and application level protocols, such as HTTP, LDAP, SMTP etc... It is based on public key cryptography systems (various ciphers can be used) and on X.509 certificates.
SSL was initially a Netscape protocol, then it has gone trough a standardization process and now is called TLS (Transmission Layer Security). It is commonly referred as SSL/TLS.
The SSL/TLS protocol provides:
Since OpenLDAP 2.0.x, that is an LDAP V3 toolkit, SSL/TLS is provided by the server. OpenLDAP 2.0.x needs to be compiled using the OpenSSL library to add SSL/TLS. It also has Start-TLS support.
OpenLDAP 1.2.x, instead, is an LDAP V2 protocol implementation and does not provide SSL/TLS.
Valuable information on SSL/TLS on OpenLDAP 2.0.x can be found on the OpenLDAP web site, here we will focus how to use an SSL tunnel to secure LDAP parties that are not SSL/TLS aware
If you use OpenLDAP 1.2.x you need a general purpose SSL wrapper to add SSL capabilities to the server. Stunnel (www.stunnel.org) has been found to be stable and suitable for this application.
Installing it is quite simple, but first you have to install OpenSSL (www.OpenSSL.org) to have the required library and tools.
OpenSSL, is an open source implementation of the SSL protocol that provides the SSL library and a set of cryptography tools.
To install OpenSSL you have to type the following commands:
usually, everything will be installed in /usr/local/ssl.
If OpenSSL is correctly installed the only command needed to compile and install stunnel are:
Stunnel uses a server certificate for SSL, this can be a self signed certificate, or, better, a certificate signed by your own Certification Authority (the SSL client has to trust the CA too).
A commonly used place used to store such certificate is:
If having a Certification Authority is not a concern, a self signed certificate can be produced using the tools provided by the OpenSSL suite.
In the stunnel directory (to use the configuration file stunnel.cnf) type the following commands:
This will produce a self signed certificate, valid for a year, in the file stunnel.pem.
Once stunnel is installed, you can start up first the LDAP server on port 389 (the default LDAP port):
Then stunnel on port 636 (the port used by LDAPS client):
For debugging you can start stunnel in foreground with the following syntax:
Many LDAP client are not SSL aware, anyway, it is possible using stunnel in client mode, to provide SSL to these clients.
This is quite simple. You can start stunnel on the client host, using the LDAPS port, and forward requests to this port to the actual LDAP server:
Now LDAP clients must be configured using localhost:636 as the LDAPS server to use.
At the moment slurpd (slapd replication daemon) hasn't SSL capabilities, anyway you can use stunnel in client mode to have this job done.
Using stunnel in client mode on the master, you can forward a local port to a remote port:
and have on the master LDAP server in slapd.conf
Warning: this section is terribly incomplete and outdated. I should be updating it, adding the various rfc's or other authoritive sources of schematic data.
This is a proposition of a schema that can be used to accommodate all the data needed for the previously listed functions. It should under no circumstances be regarded as authoritative. It is an example that should serve it's purpose, but it is likely you have to adapt it to match your specific needs.
Because it has been a lot of work (for me, maybe it's out there but I don't know where?) to find out the specific meaning of each entry, and what information it should contain, I'll try to do this as well. It should be noted, however, that it doesn't fit together seamlessly. The Microsoft Addressbook does not seem to use some of the fields it is presenting. I suspect that for the "Title", "Nickname", "Home City", "Home State/Province", "Home ZIP Code", "Home Country/Region" and "Home Web Page" entries no information is requested. For the "Personal", "Netmeeting" and "Digital IDs" I didn't yet bother to figure out how it should be put in the Ldap database. Any information is welcome. The netscape address book has a similar problem. When a record is copied from an LDap directory to a local address book, some of the fields are lost. As the nature of an company-wide addressbook should discourage users to copy addresses locally, this is not a big problem though. But netscape address book has another little oddity though. In a normal address record, the Ldap attribute associated with "Nickname" is xmozillanickname. When searching for addresses however, the associated attribute is simple nickname. That is the reason why the nickname entry shows up twice in the schema.
This schema is known to work with Microsoft Outlook 2000, and Netscape 4.73. If you find I'm wrong about a description, function, or neccessity of an entry, please do let me know!
The schema file that represent this schema can be found in Section 12.1.
Table 1. Ldap attributes and objectclasses - quick description
Beware, the description given on the Microsoft page doesn't match the fields where the content shows up in address book. Also, not all fields in address book contain information, but if the listed keys don't work I wouldn't know which keys do work.
Here are the example files that can be used to setup an installation as I described here.