If we wanted a hashed version stored in our configuration file, we'd enter the text '''{SSHA}0H+zTv8o4MR4H43n03eCsvw1luG8LdB7''' in place of '''secret'' below:

+

If we wanted a hashed version stored in our configuration file, we'd enter the text '''{SSHA}0H+zTv8o4MR4H43n03eCsvw1luG8LdB7''' in place of ''secret'' below:

<pre>

<pre>

# Cleartext passwords, especially for the rootdn, should

# Cleartext passwords, especially for the rootdn, should

Line 269:

Line 269:

access to *

access to *

by * read</pre>

by * read</pre>

+

+

Once we've got this file saved, create the directory you referenced for the database store, set permissions to 0600 and chown to your openldap users (ldap/ldap if you installed OpenLDAP from ports). Lastly, go ahead and try to start slapd from it's rc.d script:

+

<pre># /usr/local/etc/rc.d/slapd start</pre>

+

Check that it's running (sockstat | grep slapd is my method). If you '''do not''' see slapd listed as running, check your log files for any errors. If you've followed my directions up to this point, you should be good to go. At this point, ''stop'' slapd with the following command:

+

<pre># /usr/local/etc/rc.d/slapd stop</pre>

+

It can't be running for our initial load of the database.

Revision as of 11:02, 8 February 2008

So, at work, we've finally got enough systems and users that we're seriously considering an OpenLDAP server for authentication, as well as for our customer/client contact lists, etc. I've never before successfully rolled out an LDAP system, and I've for certain never rolled one out that does authentication for any systems.

Hopefully, this, when finished, will lay out the entire process of installed OpenLDAP Server 2.4.6 on a FreeBSD 6.2 system. Being that FreeBSD 6.3 and 7.0 are due out in short order, I should be able to update this page and make note of any differences you may come across.

Please note, while I'm working through this, this page is a work-in-progress. That means there may be some funny looking edits, and I use these pages as scratch paper of sorts during my installation, to make certain all of the necessary notes get made.

Ecrist 12:56, 4 February 2008 (CST): With a few weeks since my initial post here, I'm going to finally finish this document. There have been quite a few things to work through and I've finally got a broader picture of what's going on.

Contents

System Overview

As we're big fans of ezjail, we're going to install an LDAP system with one master server, and one slave. All of our email clients will be pointed to the slave for read operations, with that server redirecting any writes to the master server. While OpenLDAP 2.4.x* is available, all of my testing has been done with OpenLDAP 2.3.40, so that's what this document will use.

*: 2.4.x supports a new master-master setup that we're not going to cover here. The multi-master configuration is still considered fairly experimental.

Installation

In our setup, we're going to have two OpenLDAP servers (one master, one slave). In addition, we're going to install phpldapadmin on our master server to help us get a better view of our directory structure.

To begin, we install the following ports:

net/openldap-server23

enable SASL

other defaults should be fine

www/apache22

enable LDAP

lang/php5

enable APACHE (apache module)

lang/php5-extensions

enable LDAP

enable PCRE

enable SESSION

Configuration

/etc/rc.conf

Now that we have all the ports installed, edit /etc/rc.conf and add the following line:

OpenLDAP Configuration

Now that we have openldap, php5 and apache22 installed, we need to setup our slapd.conf file. The first thing to take into consideration is the function of your directory. In our installation, we're going to use it for an address book and an authentication server. As such, we're going to need the following schemas:

core.schema

cosine.schema

inetorgperson.schema

nis.schema

You can look to ldap schemas for more information about the different types.

# Global Section
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/nis.schema

OpenLDAP uses a bit-based method for determining log level. A value of 296 gives us good verbosity for testing and initial configuration. See the man page for more information on this value.

For the rootpw, you have a couple options for entering your password. For our demonstration, we're entering a clear-text password. In a production setup, you should run the slappasswd command, and enter your password. Assuming the password is secret, the output from slappasswd would be similar to:

Our configuration is going to use TLS to encrypt the data between systems. We don't want user credentials flying around our network in clear text. See our page on OpenSSL for information on creating a root CA, and the associated certificates.

Access control lists are what defines what each authenticated or anonymous user is able to do within the directory. These should go at the end of the configuration file. Here, we have two access control lists. The first ACL states that access to the userPassword attribute, within ou=people,dc=example,dc=com is only writable by the owner, is available for authentication by anyone, and is writable by ou=admins,ou=staff,ou=people,dc=example,dc=com. The second ACL states that all fields a readable by anyone, including anonymous users.

## ACLs
#
# Restrict userPassword to be used for authentication only,
# but allow users to update their own password.
access to dn.children="ou=people,dc=example,dc=com"
attrs=userPassword
by self write
by * auth
by dn.children="ou=admins,ou=staff,ou=people,dc=example,dc=com" write
# Read access to the world.
access to *
by * read

Once we've got this file saved, create the directory you referenced for the database store, set permissions to 0600 and chown to your openldap users (ldap/ldap if you installed OpenLDAP from ports). Lastly, go ahead and try to start slapd from it's rc.d script:

# /usr/local/etc/rc.d/slapd start

Check that it's running (sockstat | grep slapd is my method). If you do not see slapd listed as running, check your log files for any errors. If you've followed my directions up to this point, you should be good to go. At this point, stop slapd with the following command: