Authentication to OpenLDAP | Windows And Linux Integration Hands-on Solutions for a Mixed Environment

OpenLDAP is the open -source answer to the call for rich directory services. LDAP is the basis of both this product and Active Directory. Hence, there will be some similarities. OpenLDAP is still a work in progress and needs a little help in the "ability to scale" category, but it's getting better all the time.

Note

Turns out OpenLDAP doesn't just run on Linux boxes. If you wanted to, you could also run it on various other Unix-style machines tooand also Windows boxes! The home page for the Windows OpenLDAP project is http:// lucas .bergmans.us/hacks/openLDAP/ . If it has "hacks" in the URL, you know it's going to be fun!

Setting Up an OpenLDAP Server on Linux

Setting up your first OpenLDAP server on Linux takes only a handful of steps. One thing that's not immediately obvious, however, is that an OpenLDAP server doesn't have any inherent security during the transmission of data. To shore that up, we'll show you how to use Secure Sockets Layer (SSL) to encrypt the LDAP traffic. Buuuut it's not quite as easy as flicking a switch somewhere labeled "Enable Encryption." In order to do the job right, you'll need set up your server to encrypt its traffic, and to identify itself with an SSL "certificate." That certificate will be signed by an authority that the clients recognize and trust. We'll show you how to set up such an authority and teach clients to trust it.

Here are the steps you'll need to take to make a secure OpenLDAP server:

First, you'll adjust the firewall and install the OpenLDAP server software itself if it is not already installed.
Next , you'll create your own Certification Authority (CA). Not only might this process come in handy later, but right now you'll need it to pump out an SSL certificate for your OpenLDAP server.
Finally, you'll be ready to move your attention to the configuration of the OpenLDAP server itself.

Firewall Passthrough

Using LDAP does not require that you disable you Linux server's firewall. However, you do need to allow traffic from two additional ports. Specifically , you need to open up traffic on ports 389 and 636 for both TCP and UDP traffic. To open your firewall to allow traffic on ports 389 and 636 for both TCP and UDP traffic:

From the Applications menu, select System Settings Security Level. When you do, the "Security Level Configuration" dialog appears.
If you disabled your firewall for NIS and are no longer using NIS, you may safely reenable it now for OpenLDAP. In the "Firewall Options" tab, ensure the "Enable firewall" selection is active. Then, in the "Other ports:" dialog box, add the following entries, separated by spaces:
```
 389:tcp 389:udp 636:tcp 636:udp 
```
Click "OK" to finish.

Verifying Installation of the LDAP Server

It's easy to miss the installation of the LDAP server, even though we covered it in Chapter 1. That's because it is necessary to use the "Details" button and specifically select it from the "Network Servers" list during the package selection process. To verify that the server software is installed and, if necessary, install it, follow these steps:

Select Applications System Settings Add/Remove Applications.
At the "Package Management" dialog box, scroll down to the "Servers" section, locate the "Network Servers" entry and click the "Details" button. When you do, the "Network Servers Package Details" appears, as shown in Figure 2.7. Check the "openldap-servers" box, if i t is not already checked, and select "Close." Then click "Update," accept the disk space requirements, and you're golden.
Select "Quit" to leave the Add/Remove Applications tool when the installation is complete.

Figure 2.7: Ensure that "openldap-servers" is selected.

Don't go running off and starting the OpenLDAP services quite yet; you're not secure enough for prime time. In the next section, we'll show you how to shore up OpenLDAP so you can have decent security as you go.

Creating a Signed SSL Certificate without Paying for It

Out of the box, OpenLDAP traffic isn't encrypted. But it can be.

Specifically, your goal is to encrypt logon attempts via SSL, the same protocol that underlies secure websites . You may be familiar with SSL certificates and the need to purchase them from a well-known Certification Authority (CA), such as Verisign. Using SSL certificates establishes secure communications, so sensitive information can flow between two points. In web browsers, the "lock" icon appears to alert users to this secure nature.

SSL certificates are also used to secure OpenLDAP transactions. These SSL certificates must also be signed by a Certification Authority. Fortunately, however, it is not necessary to rely on an expensive third-party Certification Authority, because you have control over the client systems and the power to decide which certificate authorities they trust . A client trusts a Certification Authority by storing a copy of the public key certificate for that CA in its local certificate store. Using this certificate, it can decrypt the digital signature applied by the CA to the certificates it issues.

This means that you can create your own Certification Authority and use it to sign your own certificates.

You can also, of course, choose to obtain each LDAP server's certificate commercially from Verisign or a similar company. By doing so, you'll avoid the need to make each LDAP client aware of your own newly created Certification Authority (as you'll have to do a little later). Windows and Fedora Core 3 ship with the Root CA certifications from Verisign and other companies. Some Linux distributions do not.

About Public-Key Encryption

To understand certificate authorities and certificates, it is necessary to understand a few simple things about public-key encryption. Let's compare it to regular symmetric-key encryption. This is where both parties agree on a password in advance and they use that password to encrypt and decrypt their messages. This is the encryption method used by Winzip to protect zipped files.

The problem with symmetric key encryption is that the person who encrypts the file (the sender) has to phone or e-mail the person who needs to decrypt the file (the receiver) and tell them the password. And that could be the time when the bad guy is listening.

If the sender and receiver don't have a confidential way to agree on a symmetric-key password, how do they communicate something privately over a public channel ? Indeed, how can you use something ludicrously insecure , such as the Internet, without first exchanging a password privately in advance?

Public key encryption, despite the name , actually solves this problem by using two keys. The sender generates a key pair, two very large numbers that are mathematically related , so that anything encrypted with one key can only be decrypted by the other.

One key is designated as a private key, which the sender keeps confidential. The other key is called the public key and the sender shares this key freely . There is no practical way to deduce the private key from the encrypted message .

So how does this allow us, the sender and receiver to talk privately? Simplifying somewhat, it works like this:

We send you our public key.
You send us your public key.
You encode a message for us with our public key.
We decipher your message with our private key.
If we wish to respond, we encode a reply with your public key, which you decipher with your private key.

All well and good, but how do we know we're really talking to you and that your public key wasn't tampered with in transmission? If the bad guy taps into the line and replaces your public key with his own, we'll wind up sending our private message encrypted in a way that the bad guy can read!

One solution would be to exchange public keys in advance over a channel we know to be secure. But this is no better than symmetric key encryption. And what if we want to talk to thousands of people? A more practical solution is needed. This is where Certification Authorities come into the picture.

A Certification Authority (CA) is a server with two jobs: it validates the identity of entities who generate key pairs, and it puts its stamp of approval on the public key of the key pair by placing that key in a digitally signed certificate.

Other entities that trust the CA can use their copy of the CA's public key to validate the authenticity of the CA's digital signature, and then they can trust the public key found in the signed certificate. The Certification Authority signs the certificate like this:

An entity such as a web server or LDAP server sends a "certificate request" to the Certification Authority along with acceptable proofs of its identity. A "certificate request" contains a newly generated public key and a short description of the entity.
The CA validates the entity's identity then places the public key in a certificate that has information about the entity and the CA. It then calculates a hash of the certificate and encrypts the hash using its private key. The algorithm used to calculate the hash is so sensitive that if one little bit within a byte of the certificate is modified, the resulting hash will be wildly different than the original. The CA includes the signature inside the certificate.

If you want to send a secure message to the entity holding the certificate, you obtain a copy of the entity's certificate and use the public key inside to encrypt the message. You can be assured of the authenticity of the public key if you trust the CA that issued it. Here's a typical transaction:

An entity in corp.com transmits a copy of its signed certificate to an entity in boutell.com .
The entity in boutell.com uses the public key of the CA that issued the certificate to decrypt the signature on the certificate.
The entity in boutell.com now hashes the certificate using the same algorithm used by the CA that issued the certificate. If the result matches the hash in the decrypted signature, then the entity in boutell.com accepts that the entity in corp.com is the genuine article.
The entity in corp.com now sends a message encrypted with its private key.
The entity in boutell.com decrypts the message with the public key extracted from the certificate.

Creating Your Certification Authority

Installing a Certification Authority of your own gives you the power to issue certificates to entities in your own organization as long as you have the ability to distribute the CA's public key certificate to each of the systems that will participate in secure transactions.

Creating a Certification Authority is a bit of a chore, but the openssl library already installed on the server does include a script that simplifies the process.

To create a Certification Authority:

Open a terminal prompt and ensure you're logged in as root.
Enter the following command:
```
 cd /usr/share/ssl 
```
Now enter this command:
```
 misc/CA -newca 
```
You will see the following prompt in response:
```
 CA certificate filename (or enter to create) 
```
Press Enter to create the CA certificate. At this point, you're creating the private and public keys for your Certification Authority. The private key will be stored in a file with restricted permissions and a special password. That's because the private key can be used to sign new certificates. The public key will be copied to each client and server on the network.
Next, you'll encounter a prompt that says Enter PEM pass phrase . Enter a strong password and keep it in a secure place. It will only be possible to sign certificates for additional servers using this password. Enter the password again when prompted.

You will next be prompted for additional information about your organization. Most of your answers here are not crucial, but answer sensibly to reassure nosy users who decide to check the certificates installed on their client systems. Our example responses are shown in bold in the reproduced interaction below:

 Country Name (2 letter code) [GB]:  US  State or Province Name (full name) [Berkshire]:  Pennsylvania  Locality Name (eg, city) [Newbury]:  Philadelphia  Organization Name (eg, company) [My Company Ltd]:  corp.com  Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []:  linserv1.corp.com  Email Address []:

So far, so good! You have created your own Certification Authority. The CA certificate, consisting of the public key and identifying information, is now in the file:

 /usr/share/ssl/demoCA/cacert.pem

Later, you'll copy this file to each of the systems involved so that they can use it to verify the certificates you sign.

The CA private key, which needs to remain confidential, is now in the file:

 /usr/share/ssl/demoCA/private/cakey.pem

The CA utility doesn't do a good job of securing this file, so fix that using the chmod command:

 chmod a-rwx,o+r /usr/share/ssl/demoCA/private/cakey.pem

This ensures that only the root user can read the Certification Authority's private key file.

Read the sidebar "About chmod and chown " to learn more about the meaning of this syntax.

Next, you'll create an SSL certificate for your LDAP server. The LDAP server will use this certificate to identify itself at the beginning of every conversation with an LDAP client (SSL handshake) and to encrypt traffic to and from the client (SSL encryption). LDAP clients will then verify the server's certificate using the CA certificate installed on each client.

Creating Your LDAP Server Certificate

Now you'll create a certificate request , a file that contains a potential public key for a new server-identifying certificate, and you'll ask the Certification Authority to sign that certificate request.

Warning

We recommend that you not change the filenames involved at this stage because the signing command that follows expects newreq.pem . We will rename things later.

To generate a certificate request:

At the terminal prompt, enter the command:
```
 pwd 
```
It should inform you that you are in the /usr/share/ssl directory. If not, type cd /usr/share/ssl first.

Next, enter

 openssl req -new -nodes -keyout newkey.pem -out newreq.pem

A series of prompts will appear in the terminal window. Your exchange should look similar to the following. As with the creation of the Certification Authority, your answers are not too critical, but answer reasonably to avoid disturbing nosy users who check certificates:

 Country Name (2 letter code) [GB]:  US  State or Province Name (full name) [Berkshire]:  Pennsylvania  Locality Name (eg, city) [Newbury]:  Philadelphia  Organization Name (eg, company) [My Company Ltd]:  corp.com  Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []:  linserv1.corp.com  Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:  corp.com

Once again, your answers can vary from the preceding example, but it is absolutely crucial that the "common name" field match your LDAP server's DNS name . Clients will verify that they match! This may seem like an annoyance, but bear in mind that avoiding man-in-the-middle attacks is one of the major benefits of using SSL encryption.

The preceding steps generate two files:

newkey.pem This file contains the private key for your LDAP server. You'll move this file to an appropriate location later.
newreq.pem This file contains the public key and is your certificate request which you must sign to produce a certificate to identify your LDAP server!

To sign the certificate:

At the terminal prompt, use the CA tool to do the job. Enter the following command:
```
 misc/CA -sign 
```
At the terminal prompt, enter the "PEM pass phrase" password that you chose earlier and press Enter. Confirm the signing when asked to do so by typing y and pressing Enter.

You have created a signed certificate, which can be found in the file newcert.pem in the current directory.

Now that you've created a private key and obtained a signed certificate containing a public key, all you need to do is copy the CA certificate, the newly signed LDAP server certificate, and the LDAP server's private key to the /etc/openldap directory:

Copy the CA certificate to the LDAP configuration files directory:
```
 cp demoCA/cacert.pem /etc/openldap/cacert.pem 
```
Copy the LDAP server's private key to the LDAP configuration files directory:
```
 cp newkey.pem /etc/openldap/slapdkey.pem 
```
Copy the LDAP server's private key to the LDAP configuration files directory:
```
 cp newc`ert.pem /etc/openldap/slapdcert.pem 
```

This allows them to be more conveniently referenced from the various LDAP configuration files.

When you installed OpenLdap, a special user, with the name ldap was automatically born. This built-in account, is what is actually performing the work behind the scenes. In this example, we'll change the ownership of the *.pem files so that only this special built-in user account (again, named ldap ) has access.

 chown ldap /etc/openldap/*.pem chmod a-rwx,o+r /etc/openldap/*.pem

Setting up a Certification Authority is a lot of work, but it allows you to use the full security capabilities of OpenLDAP. Heck, it's better than moving cleartext passwords around the network. You can also reuse the Certification Authority to create certificates for secure intranet websites and other SSL-enabled applications.

Warning

If you make a mistake during this section and need to recreate a certificate, you'll need to revoke the original certificate first before the Certification Authority software will allow you to create it again. To revoke a certificate, just enter the following command: openssl ca -revoke certfilename.pem .

Now you're ready to move on to configuring the server software itself.

About chmod and chown

chmod is a very useful command for setting permissions. That gabble of letters after chmod can be read as follows:

( a )ll users should not (-) have ( r )ead, ( w )rite, or e( x )ecute permission(,) but the ( o )wner of the file should ( + ) have ( r )ead permission. These rules are applied consecutively, so that the owner is again given read permission after everyone's permissions are conveniently wiped out.

Use the command man chmod for more information.

chown is the Unix command to set the ownership of a file. The username that follows chown becomes the owner of the file. You can also specify a group to own the file by placing a period (.) between the username and the group .

See man chown for more information.

Configuring the OpenLDAP Server Software

In Chapter 1, it took several steps to create Windows' directory service (Active Directory). At this point, you're ready to leverage the previous step of creating a certificate to finally configure Linux's OpenLDAP, which will be configured in five steps:

You'll set up the slapd.conf file that contains technical details about the OpenLDAP server, such as the type of password encryption to use and just enough additional information to "bootstrap" a new LDAP database.
You'll configure the ldap.conf file, which gives LDAP client applications running on your serverincluding, for instance, the Webmin LDAP administration module itselfenough information to make a connection to the LDAP server.
You'll launch the LDAP server and ensure that it always starts at boot time.
You'll create the uppermost objects in the LDAP database hierarchy: the organization (o) object and organizational unit (OU) objects to contain Unix users and groups.
You'll use Webmin to create and manage individual users and groups. Unfortunately, however, Webmin isn't ready to manage OUs. We'll give you some other options for that.

Tip	Be sure to save a copy of your slapd.conf . To rename your original file, we suggest ou simply type mv /etc/openldap/slapd.conf /etc/openldap/slapd.old .

slapd.conf : Essential Server Settings

Your system will already contain an /etc/openldap/slapd.conf file. In short, our suggestion is to throw it out and use what we're providing here. (A fully commented version of our version of the file is available on the book's website ( www.WinLinAnswers.com ) if you don't want to type it in by hand.)

 include         /etc/openldap/schema/core.schema include         /etc/openldap/schema/cosine.schema include         /etc/openldap/schema/inetorgperson.schema include         /etc/openldap/schema/nis.schema allow bind_v2 pidfile         /var/run/slapd.pid argsfile        /var/run/slapd.args TLSCACertificateFile /etc/openldap/cacert.pem TLSCertificateFile /etc/openldap/slapdcert.pem TLSCertificateKeyFile /etc/openldap/slapdkey.pem security ssf=1 update_ssf=112 simple_bind=64 database        bdb suffix          "dc=ldap,dc=corp,dc=com" rootdn          "cn=root,dc=ldap,dc=corp,dc=com" directory       /var/lib/ldap index objectClass                       eq,pres index ou,cn,mail,surname,givenname      eq,pres,sub index uidNumber,gidNumber,loginShell    eq,pres index uid,memberUid                     eq,pres,sub index nisMapName,nisMapEntry            eq,pres,sub

Here's what each line means:

The lines beginning with include define the various types of objects that will be allowed in our LDAP database. For instance, nis.schema defines objects that correspond to information you would otherwise deliver via NIS.
allow bind v2 allows a more modern version of the LDAP protocol to be used.
pidfile and argsfile record the process ID and initial parameters passed to the slapd server.

The prefix TLS refers to Transport Layer Security, a newer term for SSL (Secure Sockets Layer), the same protocol that protects secure web shopping sites. These three lines point to the Certification Authority's own signature ( cacert.pem ), the publicly advertised certificate of the LDAP server ( slapdcert.pem ), and the private key of the LDAP server ( slapdkey.pem ).

Note

Note the slight differences in spelling: TLSCACertificateFile refers to the Certification Authority's certificate file, while TLSCertificateFile refers to your LDAP server's own certificate file. TLSCertificateKeyFile refers to the file containing the server's private key, with which it encrypts outgoing traffic.

The line that starts with security instructs OpenLDAP that only secure connections to the server are permitted. This ensures that passwords aren't going across the wire in cleartext.
database bdb states that you will be using the Berkeley Database (BDB) for the storage of data. BDB is a simple, lightweight, open-source database that integrates easily into applications like OpenLDAP, which require a simple data store but not the complexity of a full SQL database.
The line that starts with suffix specifies the top, or root , of the LDAP tree. In other words, you can't store LDAP objects higher in the tree than this. Every object in this database will be contained within dc=LDAP,dc=corp,dc=com .
The line that starts with rootdn specifies the name of the administrative root user (analogous to the Unix root user). It must be specified in the configuration file rather than the database itself. This avoids a "chicken and egg" problem, since you must have the authority to create the first object in the database. Note that the root user has unlimited privileges to modify (not just query) the database.
directory specifies the location, /var/lib/ldap , where the actual database will be stored.

You must also specify a password for this LDAP root administrator, of course. You take care of this with the slappasswd command, which generates an encrypted password that you can paste into slapd.conf . This is definitely preferable to an unencrypted password in the configuration file!

To create an LDAP administrator root password and add it to the slapd.conf file:

At the command prompt, enter slappasswd .
When prompted, provide the same password twice. For our examples, we used p@ssw0rd . You'll be presented with a password hash, such as
```
 {SSHA}bxC3A8Hilc0FEx32/Lloa/4YVwDalqUH 
```
To complete the root-password-setting process, add the following line into slapd.conf :
```
 rootpw {SSHA}bxC3A8Hilc0FEx32/Lloa/4YVwDalqUH 
```

Of course, be sure to copy and paste the response you received from slappasswd in place of ours.

Leveraging LDAP Authentication While Logging onto the Server

When you log on the server, you'll want to authenticate to the LDAP database you've built. You'll be acting as an LDAP client, even though the LDAP server happens to run on the same computer. So, in addition to server configuration, linserv1.corp.com must also be configured correctly to allow LDAP client software to work.

The easiest way to set up LDAP authentication is for you to first use Fedora's graphical configuration tools, which conveniently turn on LDAP authentication in a variety of configuration files you would otherwise have to modify by hand.

Then you'll turn your attention to the configuration file for LDAP clients. Since the Fedora tools don't set up that file quite the way you need, you'll make a few modifications to that file after you're done using the Fedora tools.

To turn on LDAP authentication support for logins while on your server:

From the Applications menu, choose System Settings Authentication. The "Authentication Configuration" dialog will appear.
You will default to the "User Information" tab within the "Authentication Configuration." Check the "Enable LDAP Support" box. Select the "Configure LDAP" button. Set the LDAP server name to linserv1.corp.com , check the "Use TLS to encrypt connections" check box, set the "LDAP search base DN" field to dc=LDAP,dc=corp,dc=com and then click the "OK" button.
Select the "Authentication" tab. Select the "Enable LDAP Support" check box.
Click "OK" to save the changes and close the "Authentication" window.

At this point, the settings in /etc/ldap.conf are probably sufficient for unencrypted LDAP. If you're just authenticating to the server from itself, this is sufficient. However, since you plan to authenticate logins from workstations, you need full encryption.

To slightly complicate matters, there are two LDAP client configuration files, /etc/ldap.conf and /etc/openldap/ldap.conf . Apparently this situation exists to allow the LDAP utilities and the authentication system to have different LDAP configurations, but in practice this leads to nothing but confusion and wasted hours of testing!

You can solve this problem by taking advantage of one of the nicest features of Linux and Unix in general: the symbolic link.

Enter the following commands, as root:

 mv /etc/openldap/ldap.conf /etc/openldap/ldap.conf.orig ln -s /etc/ldap.conf /etc/openldap/ldap.conf

From now on, attempts to read either filename will yield the contents of /etc/ldap.conf , giving you a single place to correctly configure all LDAP client parameters for the system.

Next, open /etc/ldap.conf with your text editor and make sure it matches the following, in the order shown; make any modifications as needed. Comments and blank lines are not shown:

 host linserv1.corp.com uri ldaps://linserv1.corp.com base dc=ldap,dc=corp,dc=com pam_password md5 tls_checkpeer yes tls_cacert /etc/openldap/cacert.pem

Here's what each line means:

host linserv1.corp.com tells the client piece (on the server) to connect to the default LDAP port (389) on linserv1.corp.com (the server itself). You'll support connections both this way, with SSL negotiated later, and on the pure SSL port described next.
uri ldaps://linserv1.corp.com : the server then insists that the client "switch on" SSL encrypted communications, a feature known as "start_tls." The second line presents an alternative: the client may also connect to the "LDAPs" (LDAP over SSL) port (636), using SSL from the very beginning (if the default port does not respond). This is the method that Windows clients will use later in this chapter.
base dc=ldap,dc=corp,dc=com tells the client piece (on the server) where in the directory to start looking for your username.
pam_password md5 tells the client piece (on the server) to use MD5 password hashing (a popular and strong password hashing algorithm).
tls_checkpeer yes tells the client piece (on the server) to insist that the server's certifica teis valid before continuing.
tls_cacert /etc/openldap/cacert.pem tells the LDAP client on the server where to find the Certification Authority's public key certificate. Without knowing this, the client cannot verify the signature and your LDAP SSL certificate will be rejected.

Your LDAP client settings on the server are now complete. This means you can begin to use LDAP tools on this server to populate your LDAP database with data, just as soon as you launch the LDAP server program itself.

Starting the LDAP Service

At this point, you need to start the LDAP server daemon and ensure that it also launches at every reboot. To do this:

Open a terminal window and ensure you are root.

Enter the following commands:

 chkconfig --add ldap service ldap start

Mini-Checkout: Making Sure TLS Encryption is Set Up Correctly for LDAP

You've done quite a bit already. Let's stop and review a bit:

You opened up ports 389 and 636 in the firewall.
You created your own Certification Authority.
You created and signed a certificate for your LDAP server.
You performed initial configuration of the LDAP server by creating the file /etc/openldap/slapd.conf .
To authenticate the server to itself, you configured LinServ1 as an LDAP client by using Fedora's Authentication tool and by editing /etc/ldap.conf . You created a symbolic link from /etc/openldap/ldap.conf to /etc/ldap.conf so that all LDAP clients see the same settings.
You launched the LDAP server and configured Fedora to start the LDAP server again on each reboot.

You can verify your success at this point using the ldapsearch command. ldapsearch is a utility that acts as an LDAP client and requests information from the LDAP server. You will use the -x option, which specifies that you want to use LDAP "simple authentication." Simple authentication theoretically passes a username and password as cleartext, but in this case you are just binding anonymously. To verify that you can connect successfully to the LDAP server, use the following command:

 ldapsearch -x -ZZ

This command should produce output ending in:

 result: 0 Success # numResponses: 0 # numEntries: 0

If you do not see result: 0 Success , review the output for clues to the problem. Make sure your TLS options are set correctly in ldap.conf and that the LDAP server key and certificate are installed properly. Then try the command again with the -d 2 option added to produce even more detailed debugging output.

Initializing the LDAP Database

Once LDAP is installed, there are exactly zero user accounts (other than the root account you specifically created earlier.) You need to create the root of the LDAP database. First, you need to tell it our organization, or "o" name. You'll create ldap.corp.com .

Next, you need a place, an organizational unit (OU), to hold your first gaggle of users. You'll create two OUs, one called Users and one called Groups. Guess what you'll be placing inside each?

Wouldn't it be great if you could just fire up Webmin and get started adding user accounts? Too bad you cannot. You need to bootstrap LDAP with the barest amount of initial organizational information. After that, you can use Webmin for ongoing administration. At this point, you need to create the "parent" organization and organizational unit objects in which to store those account objects.

There is a simple plain text format for describing LDAP objects called LDAP Directory Interchange Format (LDIF). Just fire up your favorite text editor and create an LDIF file called /tmp/linserv1.ldif . You need to define your organization and your first two OUs. Therefore, enter:

 dn: dc=ldap,dc=corp,dc=com o: linserv1.corp.com dc: ldap objectClass: dcObject objectClass: top objectClass: organization dn: ou=Users,dc=ldap,dc=corp,dc=com objectClass: top objectClass: organizationalUnit ou: Users dn: ou=Groups,dc=ldap,dc=corp,dc=com objectClass: top objectClass: organizationalUnit ou: Groups

Take the file you just created and create the root of the LDAP tree with two OUs using the ldapadd utility. Type the following all on one line:

 ldapadd -x -W -D "cn=root,dc=ldap,dc=corp,dc=com"  -f /tmp/linserv1.corp.com

Here's the breakdown of the commands:

The -x option specifies "simple" authentication, which sends the password in cleartext. You're covered because you are encrypting the entire conversation via SSL.
The -W option forces you to enter a password at a password prompt.
The -D option specifies an account to use for binding. At this point, the only available account is the LDAP root account you specified in slapd.conf . Changes can only be made by the root account.
The -f specifies the LDIF file to import, / tmp/linserv1.corp.com .

Now you need to verify that you have a simple LDAP hierarchy. You'll use the ldapsearch command. To dump the LDAP hierarchy, type ldapsearch -x (where -x has the same significance as with ldapadd ).

You should receive a plain-text, LDIF-format representation of the same information you inserted into the database. If not, double-check your slapd.conf and ldap.conf files carefully . Take special care to make sure you set up the rootpw option correctly in slapd.conf . Then restart slapd with the command:

 service ldap restart

Using Webmin to Manage OpenLDAP Server Graphically

While you have to suffer through the command for initial configuration, you needn't suffer additionally past this point for ongoing administration. Fortunately, there is a Webmin module for this purpose.

Installing the LDAP Users and Groups LDAP Module

First things first: get Webmin to talk to your LDAP server.

To install the Webmin module for LDAP:

Log into Webmin and click the "Webmin" button, then "Webmin Configuration."
Next, click the "Modules" button, select the "Install Standard Module" radio box, and click the " " button next to it.
From the list of modules that appears, select "LDAP Users and Groups." Then click "Install Module" to carry out the installation.
A progress display will appear. When the installation of the module has completed, click "LDAP Users and Groups" at the end of the installation status page.

From now on, you'll always find "LDAP Users and Groups" within Webmin's "System" button, as shown in Figure 2.8.

Figure 2.8: You can easily get to the "LDAP Users and Groups" button from the main "System" button (at the top).

Configuring the LDAP Users and Groups LDAP Module

You need to tell Webmin where we want to store users and groups. Remember, you've already used an LDIF file with ldapadd to create your "base" location for users and groups. All you have to do is tell Webmin where those locations are.

To specify the base locations for users and groups:

Using Webmin, select System Users and Groups.
Select the "Module Config" tab, as shown in Figure 2.9.
On the "Configuration options for LDAP Users and Groups" screen, shown in Figure 2.10, look for the "LDAP Use TLS?" radio button and select "Yes" to enable encryption. You've already made this a requirement for all LDAP connections.
At "Bind to LDAP server as," click the radio box next to the entry blank, then enter:
```
 cn=root,dc=ldap,dc=corp,dc=com 
```
For "Credentials for bind name above" enter the same LDAP root password you entered when running the LDAPpasswd utility ( p@ssw0rd , in our examples).
For "Base for users," select the radio box next to the text field and enter:
```
 ou=Users,dc=ldap,dc=corp,dc=com 
```
This is the dn (distinguished name) you chose earlier for the organizational unit that will contain Unix user accounts in your LDAP database.
For "Base for groups," select the radio box next to the text field and enter:
```
 ou=Groups,dc=ldap,dc=corp,dc=com 
```
Under "Other objectClasses to add to new users" be sure to add the word account , which is necessary to avoid a "no structural class for object" error. Every object in an LDAP database must have at least one structural class that provides its context in relation to other types of objects.
For "Encryption method for passwords," select "LDAP MD5."
Finally, click "Save."

Figure 2.9: The Module Config can be hard to find. After you select "LDAP Users and Groups," it will be hiding in a little tab.

Figure 2.10: You're ready to move on to creating users and groups!

Administering Users and Groups Using LDAP Users and Groups Module

You've already got your Users OU. And that's great. But here's where Webmin falls down a bit. It doesn't seem to have any native way of creating additional OUs or sub-OUs within existing OUs, and that's a crying shame. To see what can do the job, see the sidebar "Other Graphical Interfaces to OpenLDAP." For now, you're going to continue using Webmin (heck, it's already installed) and make sure your OpenLDAP server is functioning properly. If, you later want to install one of the other recommended tools, go for it! There's nothing stopping you.

In this example, you'll create two Linux groups, doctors and nurses and put them in the OU named Groups.

Begin by adding two LDAP groups called doctors and nurses . To create LDAP groups using Webmin:

While in Webmin, click the "System" icon on the Webmin toolbar. Select "LDAP Users and Groups" from the icon list.
Click "Add a new LDAP group," then enter nurses in the "Group" name field. The defaults are acceptable for the remaining options. Now click "Create." Repeat this process for the doctors group.

You'll create users in a minute, but first you have a bug to squash. In the version of the Webmin LDAP module that you tested , the Webmin "LDAP Users and Groups" module does not immediately list your new groups as potential primary groups for new users, even though it lists them as secondary groups! If you see this problem, there is a simple workaround. First, restart Webmin, which kicks it in the pants. To do this, click the "Webmin" button ( upper-left corner of the screen), then "Webmin Configuration." Scroll down the page that follows and click the "Restart Webmin" button.

The restart only takes a moment and allows Webmin to correctly recognize the newly created groups that the server itself can already see.

Now, to create LDAP users:

Using Webmin, click the "System" button, then the "LDAP Users and Groups" button.
On the "LDAP Users and Groups" page, you should see the two new groups listed. Click "Add a new LDAP User" to add your first LDAP user.
On the "Create User" page, enter the username nurse1 and the real name Nurse One . Click the "Normal Password" radio button and enter p@ssw0rd next to it.
In the "Group Membership" section, locate the " " browse button next to "Primary group" and click nurses in the list that appears.
You can accept the defaults for the remaining queries; in particular, "create home directory" should already be checked. Now, click "Create."

You have added our first user to the LDAP database.

Repeat the process for nurse2 . Then repeat the process for doctor1 and doctor2 , selecting " doctors " as the group for these. In short, you should have four accounts in two groups, like this:

User	Group
nurse1	nurses
nurse2	nurses
doctor1	doctors
doctor2	doctors

Viewing Your New LDAP Users with getent passwd

Your users and groups are ready to test! You could just configure the Linux client and start logging in via LDAP authentication, but it's prudent to have a little stop along your journey and check in. You need to make sure the accounts you created with Webmin are being seen by the server.

The getent command, a convenient utility, prints out the users and groups available from all authentication systems configured for this machine, including the LDAP server on your system. If you created any users with NIS and left NIS enabled in the Fedora authentication tool, you'll see those as well. On LinServ1 , enter the following command to dump out information about all users:

 getent passwd

Other Graphical Interfaces to OpenLDAP

As a one-stop -shop tool, Webmin can't be beat to configure lots of different aspects of Linux. However, for LDAP-specific tasks, there some alternative choices that specialize in manipulating your day-to-day LDAP tasks . Because none of these packages are inside Fedora, each has its own way of installing so be sure to carefully read the notes on the download pages. Here are our two cents about our experiences of installing and running each:

Luma: http://luma. sourceforge .net/ Because I was using the GNOME desktop, I found Luma is a little clunky to work with. It has various preinstalled plug-ins that work independently against the LDAP database. I couldn't create an OU or move users around between OUs. You need to have the KDE development tools installed for this package to install, along with the most current version of the Python scripting language. If you're already using KDE, you might find it easier to install than I did, but you'll still need to install the KDE development libraries as well as a possible upgrade of Python.
Directory administrator: http://diradmin.open-it.org/index.php I tried installing rpms for RedHat 9 but had no luck. I re-downloaded the whole source and, per their suggestion, tried to create an rpm from that source. That failed. Then I tried compiling the whole package from the source. That worked, but it couldn't find the icons. Once I made a symbolic link to help the program finds its icons, it did work and had a charming wizard to get me started. Once going, the interface was keen and allowed me to change all sorts of properties about the user (including both Unix and Windows attributes), but I still couldn't create an OU or move users around LDAP. Overall impression : better than the Webmin module but not being able to create OUs is a bummer.
PhPLDAPAdmin: http://www.phpldapadmin.com/ This tool requires you to have an Apache web server up and running first. I didn't try to test it, but there's a spectacular live demo available at the website that really shows this tool off. The tool allows an administrator to create OUs as well as Windows and Linux user accounts and a bunch of other types of LDAP objects. For $50, it appears to be a steal, and includes support and a user-community. In all, looks like a real winner.
LDAP Administrator 3.1: www.ldapadministrator.com Here's a twist: use a Windows application to manage OpenLDAP. That's the case with Softerra's LDAP Administrator 3.1. It'll manage Active Directory, too, so it's a nice one-stop-shop. However, it's a little on the geeky sideyou'll have to get familiar with the specific attributes you might want to managebut it's got some nice reporting functionality, and the interface can't be beat. It's $215 for a license and worth it. If you're trying to manage both Active Directory and OpenLDAP (or another LDAP server), give this a look. They also have a 100 percent free tool that allows a read-only inspection of your LDAP directories.

The response you receive should end with the following lines:

 nurse1:x:505:503:Nurse One:/home/nurse1:/bin/sh nurse2:x:506:503:Nurse Two:/home/nurse2:/bin/sh doctor1:x:507:504:Doctor One:/home/doctor1:/bin/sh doctor2:x:508:504:Doctor Two:/home/doctor2:/bin/sh

If getent passwd doesn't list the nurse and/or doctor accounts:

Try the ldapsearch -x command. At the end of the output, you should see information about the nurse and doctor accounts. If so, be sure to reread the section (verifying along the way) "Leveraging LDAP Authentication While Logging onto the Server."
If ldapsearch does not list the new accounts, then you most likely received errors during Webmin administration as well. Go back and check your work in the "Initializing the LDAP Database" section.

Authenticating Linux Clients to the OpenLDAP Server

Next, you need to find out if you can get your Linux client system, LinCli1 , to authenticate using the LDAP service on LinServ1 . To do so, you'll configure LinCli1 to request authentication from the server's LDAP database.

Earlier, you configured your server ( LinServ1 ) to use its own LDAP service for authentication. Now, you'll tell LinCli1 to use LinServ1 for LDAP lookups.

To enable a Linux client to authenticate via LDAP:

While on LinCli1 , from the Applications menu, select System Settings Authentication. The "Authentication Configuration" dialog will appear.
You will default to the "User Information" tab. Check the "Enable LDAP Support" box.
Select the "Configure LDAP" button. The "LDAP Settings" dialog appears. First, select the "Use TLS to encrypt connections" check box. Then, set the LDAP Search Base DN to dc=ldap,dc=corp,dc=com and the LDAP server name to linserv1.corp.com .
Click the "OK" button to return to the "Authentication Configuration" dialog.
Select the "Authentication" tab and check the "Enable LDAP Support" box. Then click the "Configure LDAP" button. The "LDAP settings" dialog appears, as shown in Figure 2.11. Again, select the "Use TLS to encrypt connections" check box and set the LDAP Search Base DN to dc=ldap,dc=corp,dc=com and the LDAP server name to linserv1.corp.com .
Click "OK" to close each dialog to complete the task.

Figure 2.11: Be sure to configure the "LDAP Settings" dialog twice once for the "User Information" tab, and once here, on the "Authentication" tab.

Next, since you've opted for a properly secured LDAP server, you'll need to tell your Linux client to definitely use encryption. As previously stated, there are two possible locations client LDAP programs might look: /etc/ldap.conf and /etc/openldap/ldap.conf .

In the section "Leveraging LDAP Authentication While Logging onto the Server," you used a symbolic link to make one file point toward the other, thus eliminating the problem. Do that same thing again here on the LinCli1 client.

To create a symbolic link on your client, type the following commands:

 mv /etc/openldap/ldap.conf /etc/openldap/ldap.conf.orig ln -s /etc/ldap.conf /etc/openldap/ldap.conf

Now make sure /etc/ldap.conf contains the following settings in the order shown:

 host linserv1.corp.com uri ldaps://linserv1.corp.com base dc=ldap,dc=corp,dc=com pam_password md5 tls_checkpeer yes tls_cacert /etc/openldap/cacert.pem

Tip

You might want to look through the whole /etc/ldap.conf file. The file should be mostly comments. However, if even one stray line is uncommented, you will be unsuccessful . In other words, triple-check ldap.conf and ensure the only uncommented lines are the ones you add, and make sure it looks like our example here.

If you need a refresher of what each setting in /etc/ldap.conf means, see the section "Leveraging LDAP Authentication While Logging onto the Server.

" Finally, you'll need to install the CA certificate for your own Certification Authority on the client. To do so, just copy the file /etc/openldap/cacert.pem from LinServ1 to LinCli1 , installing it in the same place on LinCli1 .Why do you copy the CA certificate, and not the LDAP server's certificate? As explained earlier, the value of a Certification Authority is that a single CA certificate can be used to validate many server certificates.

When a client connects to the LDAP server, the LDAP server presents its certificate. The client verifies the signature on the SSL certificate using the public key in cacert.pem .

The scp command is a convenient way to copy a file from one Linux system to another. The syntax is very similar to cp , with the addition of a simple syntax to specify the username and hostname on each end; usually, of course, one end is a local file or path in which to put that file.

First, you'll need to open up the SSH port on the firewall. That's because scp is built "on top" of SSH, the secure shell often used for remote access to the shell prompt. This is simpler for SSH than for some services because there is a convenient check box for it. From the Applications menu, select System Settings Security Level. On the "Firewall Options" tab, in the "Trusted Services" list box, check "SSH." Then click "OK" to put the change into effect.

You need to copy a file from the server to the client (while logged in at the client), so execute this command as root on LinCli1 :

 scp root@linserv1.corp.com:/etc/openldap/cacert.pem /etc/openldap

Here's the breakdown of the command:

The source filename is the first parameter. You need to tell scp the credentials of the username on the source server: username@server . The colon marks the end of the hostname and the beginning of the directory name to which the file should be copied, in this case, /etc/openldap/cacert.pem .
The destination filename is then given, in this case, /etc/openldap .

You will be prompted for the root password on linserv1.corp.com , which we have set to p@ssw0rd in the examples.

Tip	scp can be used to copy files in either direction. scp also supports the -r option, which allows directories and their contents to be copied recursively. In general, most options of cp behave the same way in scp . Convenient, isn't it?

When the file copying operation is complete, make sure the permissions and ownership of the file are correct on the receiving end by executing the following commands as root on LinCli1 :

 chmod a+r,o+rw /etc/openldap/cacert.pem chown ldap /etc/openldap/cacert.pem

The chmod command permits all users to read the certificate file ( a+r ). You allow this because you want applications on the client to start LDAP conversations with the server in order to verify passwords as needed. The chown command, as previously explained, grants ownership of a file to a particular user, in this case to the ldap user.

Finally, as before, verify your configuration using the getent command:

 getent passwd

If all goes as expected, you'll see a list of usernames that ends in nurse1, nurse2, doctor1 , and doctor2 .

Note

If you don't see these new users listed, double-check your settings and make sure you created the symbolic link between /etc/ldap.conf and /etc/openldap/ldap.conf correctly. If you still have no joy, check the firewall settings on the server and verify that getent passwd still works there. (You did test it on the server the first time, right?)

Now, the final step: ensuring that home directories will be created for LDAP users the first time they log into this particular client.

Earlier, we said that there are three typical ways users log on and interact with the system: the shell, encrypted shell (via SSH), and the GNOME interface, Therefore, you need to tell each of these authentication mechanisms how to create home directories. The line you'll add is:

 session     required      pam_mkhomedir.so skel=/etc/skel umask=0077

Simply append the preceding line to the following three files:

/etc/pam.d/login
/etc/pam.d/sshd
/etc/pam.d/gdm

Again, each file control policies for how clients log on to the Linux machine. The /etc/pam.d/login is for plain-text console and serial logins, /etc/pam.d/sshd is for SSH-encrypted shell logins, and /etc/pam.d/gdm is how most users graphically log on via the Fedora GNOME desktop.

That's it! You're ready to try an actual LDAP login. The computer must be restarted to thoroughly reinitialize the authentication interfaces with the new pam settings. Once finally rebooted, try logging in with the username nurse1 and the password p@ssw0rd . You should receive a message notifying you that a home directory has been created for this account, and then your desktop should appear as normal. That's ityou've achieved Linux-to-Linux LDAP bliss!

If Logins from Linux Clients Don't Work

Here are a handful of things to try if you are unable to get your Linux clients to authenticate to your Linux LDAP server:

Try the ldapsearch -x command on LinCli1 and LinServ1 . Do you see the doctor and nurse accounts on one machine but not another? If so, review your /etc/ldap.conf on the computer that isn't working.
Ensure the firewall settings on the server correctly pass ports 389 and 636 through as described in the "Firewall Passthrough" section earlier.
Double-check your entries in the Authentication tool (which you found inside in the "System Settings" submenu) and make sure your /etc/ldap.conf changes are kosher. Sometimes the Authentication tool will overwrite portions of this file and append unwanted material to the end.
Reboot the Linux client again. It can't hurt.

Authenticating Windows to OpenLDAP via SSL

If you want to have Windows clients use your Linux OpenLDAP directory, you can allow it. But out of the box, Windows doesn't natively "speak" plain LDAP; it speaks NTLM to old-school Domain Controllers and Kerberos to an Active Directory Domain Controller.

We've already discussed how to inject additional (or alternate) methods of authentication into the interactive logon process via pGina, and pGina has a plug-in module for LDAP.

On your test Windows client, be sure you have pGina installed as specified earlier. Once installed, there are two main steps to having Windows authenticate to OpenLDAP:

Introduce the CA certificate to Windows so that your Certification Authority and all certificates you choose to sign with it can be recognized. This is required before you can communicate with the OpenLDAP server via SSL.
Configure pGina to communicate to your OpenLDAP server via SSL.

Importing the CA Certificate to Your Windows Clients

First, you'll need to copy the SSL certificate from the Linux server. Since SSH is already installed on the Linux server, we suggest that you use a user-friendly Windows scp (secure copy) client, such as winscp (available from winscp.sourceforge.net ), to copy the file from /etc/openldap/cacert.pem on LinServ1 to the desktop of your Windows client system.

Once you have the public certificate copied to the Windows client, you're almost there. The certificate is just a text file and should look something like this (although it's cut short here to save space):

The file coming from Linux is cacert.pem . Of course, things are different in the Windows world, so you must rename the file to cacert.cer (it's the .cer part of the name that's important). You can see the certificate placed on the Windows desktop in Figure 2.12.

Figure 2.12: After you double-click the "cacert.cer" file, you can install the certificate. Just follow the instructions in the text carefully.

Once you double-click "cacert.cer," you'll open the certificate. In the "General" tab of the Certificate, click "Install Certificate." This will open the "Certificate Import Wizard" as also shown in Figure 2.12

Now you just have to tell Windows where to store the certificate. Don't just blast on through, accepting all the defaults here. There are particular steps you must take to put the certificate in the right place. To install the certificate on your XP system:

At the "Welcome to the Certificate Import Wizard" screen, click "Next."
Select "Place all certificates in the following store" (do not select "Automatically select the certificate store").
Click "Browse."
Check the "Show physical stores" check box.
Drill down to "Trusted Root Certification Authorities" and then highlight "Local Computer," as shown in Figure 2.13. Click "OK."
At the Certificate Store screen, select "Next."
At the final page of the Wizard, select "Finish."

Figure 2.13: Click the "Show physical stores" check, then drill down to "Local Computer."

You have now introduced the certificate to Windows.

To Configure pGina to Authenticate to OpenLDAP via SSL

Be sure you're logged in as a local administrator. To configure pGina to perform encrypted LDAP logins:

Download and install the required plug-in(s). In this example, we downloaded the LDAP plug-in (not the LDAP Groups plug-in) from here: http://pgina.xpasystems.com/plugins/LDAPauth.php .
Select the pGina configuration tool by selecting Start Programs pGina Configuration Tool.
Select the "Plugin" tab. Click the "Browse" button and select " LDAPauth_plus.dll " (which was installed in step 1 in c:\pGina\plugins\LDAPauth ). Once selected, the Plugin Path will confirm your selection, as shown in Figure 2.14.
On the "Plugin" tab, select the "Configure" button to open the "LDAPAuth" screen. Here are the settings you'll need to choose:
- LDAP Method Click "MultiMap Mode."
- LDAP Server Enter the name of the server, linserv1.corp.com .
- Prepend Type uid= as shown in Figure 2.14. Every user's DN (distinguished name) will start with uid= .
- Use SSL Because your server is set up to accept secure communications via SSL certificates, ensure this is checked. Leaving it unchecked will result in a failure to authenticate.
- Contexts For now, all your LDAP users are stored in the users container. Enter the full path to the users container: ou=users,dc=ldap,dc=corp,dc=com and then click "Add Context." The context will be added in the big open box as shown in Figure 2.14.
Click "OK" to close pGina's LDAPAuth screen. Click "OK" to close pGina's configuration.
Reboot your Windows XP machine (logging off isn't enough).

Figure 2.14: pGina is using LDAPAuth plug-in; the LDAP server and context are added, as well as checking "Use SSL."

Next time you press Ctrl+Alt+Del, you should be able to log in with one of the newly created LDAP users, such as doctor2 , with a password of p@ssw0rd .

If it doesn't work, here are some things to try and/or revisit :

From the XP machine, check to make sure you can ping linserv1.corp.com . Without DNS resolution, you won't get very far. You might have to add an A record entry into the DNS server. Alternatively, you can use a static hosts file entry.
Make sure you followed the instructions for installing the certificate exactly as specified. Again, when installing the certificate, you didn't just take the defaults, you had to make some choices.
Did you check the "Use SSL" check box as shown in Figure 2.14? Again, your server requires all traffic to be encrypted. It simply won't accept unencrypted traffic.
Are you allowing ports 636 and 389 to flow outward? Windows firewall doesn't restrict outbound communication, but if you're using a third-party Windows firewall, make sure you're not somehow squelching these required outbound ports.
Some advanced help in troubleshooting the certificate is available on the pGina website at http://pgina.xpasystems.com/plugins/LDAPauth.php , specifically in the section "How do I know if my LDAP server's SSL certificate is correctly recognized on my computer?"
See the earlier section "Troubleshooting pGina" for three more tips that might additionally help.

Checkout: Using OpenLDAP for Your Authentication

In this previous section, you just set up your Linux machine to be an OpenLDAP server. You authenticated both Linux Clients and Windows Clients to OpenLDAP.

Here's a quick rundown of how you did it.

To configure your Linux OpenLDAP Server:

If you're using the firewall, you adjusted the firewall settings to allow TCP ports 389 (unencrypted LDAP traffic) and 636 (encrypted LDAP traffic) through.
You created a Certification Authority, generated a private SSL certificate (to store on the server), and created a public certificate (to store on the workstations).
You configured the OpenLDAP server configuration file ( slapd.conf ) and told it what certificates to use, that you want to use encryption, and the name of the root user and the LDAP directory ( ldap.corp.com ).
You used the slappasswd to generate a password hash for the OpenLDAP root user. Then you added that password hash into the slapd.conf file. This helped you get OpenLDAP started without any real users yet.
You told the server to start using LDAP when you log on directly to it. First, you used the graphical "Authentication Configuration" dialog to specify that you want to start using LDAP.
Then you did a little trick using symbolic links to fool Linux into thinking there were two LDAP client configuration files (when, in reality, you were centralizing on one).
You configured the server's LDAP client via the ldap.conf file. You told the server to use the LDAP server to authenticate you (naturally); you also told it what kind of password encryption you'll use and where the private certificate is.
You started the LDAP server and ensured it launches at every reboot. You did that with chkconfig --add ldap and service ldap start , respectively.
You created your first organization ( linserv1.corp.com ) and two OUs: Users and Groups . You did this by hand with an LDIF text file. You then used ldapadd to import the file and create the objects.
You instructed Webmin where to place users and groups in the two OUs you created for OpenLDAP. You used Webmin to create some initial users and groups. Webmin isn't the ideal tool for the long run, but for initial testing it'll do. (Better tools are phpLDAPAdmin and LDAP Administrator).

To configure your Linux Client to use OpenLDAP:

You used the graphical "Authentication Configuration" to specify the LDAP server and base DN.
You did a little trick using symbolic links to fool Linux into thinking there was only one LDAP configuration file (when, in reality, there were two).
You configured the client's LDAP settings via the ldap.conf file. You told it to use the LDAP server to authenticate you; you also told it what kind of password encryption you'll use and where the private certificate is.
You copied the private cert from the server to the client.
You changed the three usual login methods to authenticate to your LDAP repository. These three usual methods are the shell, the encrypted SSH shell, and the graphical GNOME interface.

To configure your Windows client to use OpenLDAP:

You loaded pGina on your Windows client.
You loaded the pGina LDAP plug-in.
You configured the pGina LDAP plug-in by telling it the LDAP server name and the correct base DN, and specifying that it use SSL encryption.