HOWTO : CentOS 6.2 OpenLDAP 2.4 Setup

This blog post will show how to install and configure OpenLDAP 2.4 on CentOS 6.2.

Goals

1. Install OpenLDAP 2.4.
2. Configure Transport Layer Security (TLS).
3. Manage users and groups in OpenLDAP.
4. Configure pam_ldap to authenticate users via OpenLDAP.
5. Use OpenLDAP as sudo's configuration repository.
6. Use OpenLDAP as automount map repository for autofs.
7. Use OpenLDAP as NFS netgroup repository again for autofs.
8. Use OpenLDAP as the Kerberos principal repository.
9. Setup OpenLDAP backup and recovery.
10. Setup OpenLDAP replication.

Goal 1 : Install OpenLDAP 2.4

Of course, the very first thing we should do is to read the fine OpenLDAP Software 2.4 Administrator's Guide :)

Start by installing CentOS 6.2. This is quite easy. Just make sure to use the MINIMAL installation to keep the number of installed rpms to a minimum. This limits the number of packges one needs to update and also limits the attack surface on the server.
Once we have the CentOS machine up and running, we need to make sure the DNS settings are ok. Both forward and reverse lookup. This is also easy with two quick commands if our machine's Fully Qualified Domain Name (FQDN) is alice.example.com :

dig alice.company.com. +short
dig -x `dig server.company.com. +short` +short

Install the required packages. We install both the krb5-server-ldap and sudo packages right now even if we will configure them later. The idea is to get all the schema definitions right from the start.

sudo yum -y install openldap-servers openldap-clients krb5-server-ldap

Create a temporary working directory. We will use this directory during our installation.

mkdir ~/ldap

The general idea is to build a startup slapd.conf(5) file and then convert it to the new cn=config setup. List all the new schema files installed on the machine and dump them to a temporary configuration file.

rpm -ql openldap-servers krb5-server-ldap | grep '\.schema$' | sed -e "/README/d" -e "s/^/include /g" | tee  -a ~/ldap/slapd.conf.temp
rpm -ql sudo | grep -i schema.openldap | sed "s/^/include /g" | tee -a ~/ldap/slapd.conf.temp

Update! The latest version of OpenLDAP installs the pmi schema. The presence of this schema causes an error when running slaptest later in this tutorial. Since most of us don't need this schema, then we will remove it right here and now by running this command :

sed -e "/pmi/d" ~/ldap/slapd.conf.temp | tee -a ~/ldap/slapd.conf.fix

Thanks to Bas van Wetten for pointing this fix.

Now let's edit this file to add several items :

• Our OpenLDAP suffix. It's normally your DNS domain name, but it doesn't have to.
• the rootdn which is our OpenLDAP admin user. Think of him as the root user of your CentOS server. Let's use cn=admin,dc=company,dc=com as our super-user.
• A password to our rootdn user specified by rootpw. Keep in mind that this user has complete control over the OpenLDAP data. So make sure to keep this password in a safe place (such as keepass or gpg or Encryptr). The slappasswd(8C) command will generate a salted SHA password for us. Record the output as we will need it soon (the example below is a fake password not used anywhere).
• The type of backend database we want and where will it be located? Let's use the Oracle Berkely Database backend and place it into /var/lib/ldap.This directory was created when we installed the openldap-servers package.
• A few Access Control List (ACL) for the various backend databases. We will build on those later on.
• Where to write the process ID and the arguments file.
• Trun on database monitoring.
• We also remove the pmi.schema as we don't need it.

Before you edit the file, record the output of the slappasswd(8C) command

slappasswd

New password: 

Re-enter new password: 

{SSHA}JGjPUbxyCn7wa/pt8YM5rzK7s/hUGncW

We can now edit the temporary configuration file. One thing to keep in mind is that the order in which the directives appear in the slapd.conf file is important. For example, you must list your database and directory before the suffix and the suffix before the rootdn and rootpw. We need to reorder the include statements for the schemas because some schemas depend on previous ones. If we don't do this reordering, we might end up with slapcat(8) errors like this one :

/etc/openldap/schema/collective.schema: line 65 attributeType: AttributeType not found: "l"
slapcat: bad configuration directory!

vi ~/ldap/slapd.conf.fix

Test our temporary configuration to see if we made any mistakes. It should return "config file testing succeeded". If not, fix any pending errors, they should be obvious.

sudo slaptest -uf ~/ldap/slapd.conf.fix

Run slapcat to generate our cn=config data.

sudo slapcat -f ~/ldap/slapd.conf.fix -F ~/ldap -n 0

This will create the ~/ldap/cn=config.ldif file and the ~/ldap/cn=config directory. Let's test this new configuration to see if it's ok? This should also report "config file testing succeeded".

sudo slaptest -uF ~/ldap

Copy the new file and directory to the appropriate location where slapd(8) expects it and fix permissions. First we need to clear the config that was installed when we installed the openldap-servers package.

sudo mv /etc/openldap/slapd.d /etc/openldap/slapd.d.unused
sudo mkdir /etc/openldap/slapd.d
sudo cp -rp ~/ldap/cn\=config* /etc/openldap/slapd.d
sudo chown -R ldap:ldap /etc/openldap/slapd.d

Before we start slapd, we must first place a Berkley DB configuration file into /var/lib/ldap. The openldap-servers packages includes an example. If we don't have this file and we start slapd(8), it will complain with an error :

bdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (2).#012Expect poor performance for suffix "dc=company,dc=com". 

Let's use this one for now.

sudo cp `rpm -ql openldap-servers | grep DB_CONFIG` /var/lib/ldap/DB_CONFIG

Fix permissions on the /var/lib/ldap directory.

sudo chown ldap:ldap /var/lib/ldap

sudo chmod 700 /var/lib/ldap

Edit the slapd(8) system configuration file.

sudo vi /etc/sysconfig/ldap

Configure rsyslogd(8) to send slapd(8) logs into a specific log file. To do this, we only need to add three lines right after the global directives.

sudo vi /etc/rsyslog.conf

Create the new log file.

sudo touch /var/log/slapd.log

Restart rsyslogd(8) so that it knows about this new configuration.

sudo /etc/init.d/rsyslogd restart

Configure logrotate(8) to handle this new log file.

sudo vi /etc/logrotate.d/slapd

Test your logrotate(8) configuration.

sudo logrotate -df /etc/logrotate.conf

One final test of our OpenLDAP configuration before we start the daemon.

sudo slaptest -u

config file testing succeeded

Good! That means we can now start our slapd(8) daemon.

sudo /etc/init.d/slapd start

Take a look at our log file to see if all is ok?

sudo tail /var/log/slapd.log
slapd starting

Check if the appropriate TCP 389 port and the UNIX socket are active?

netstat -alnt | grep :389

tcp        0      0 0.0.0.0:389                 0.0.0.0:*                   LISTEN 
   

netstat -lA unix | grep ldap

unix  2      [ ACC ]     STREAM     LISTENING     116029 /var/run/ldapi

Configure a system-wide LDAP client configuration. This is to simplifiy our life and reduce typing later on. Don't worry about the TLS configurations for now. We will configure them later, but it doesn't hurt to have them in the file at the moment. Don't forget that in this document, the OpenLDAP server's FQDN is alice.company.com. Be sure to change it for your own.

sudo vi /etc/openldap/ldap.conf

Check if our admin user can connect?

ldapwhoami -WD cn=admin,dc=company,dc=com
Enter LDAP Password:
dn:cn=admin,dc=company,dc=com

Check if our ACLs are ok and that we can see our cn=config suffix?

ldapsearch -xLLLWD cn=admin,dc=company,dc=com -b cn=config dn
Enter LDAP Password:
dn: cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}inetorgperson,cn=schema,cn=config
dn: cn={3}collective,cn=schema,cn=config
dn: cn={4}corba,cn=schema,cn=config
dn: cn={5}duaconf,cn=schema,cn=config
dn: cn={6}openldap,cn=schema,cn=config
dn: cn={7}dyngroup,cn=schema,cn=config
dn: cn={8}java,cn=schema,cn=config
dn: cn={9}misc,cn=schema,cn=config
dn: cn={10}nis,cn=schema,cn=config
dn: cn={11}ppolicy,cn=schema,cn=config
dn: cn={12}kerberos,cn=schema,cn=config
dn: cn={13}schema,cn=schema,cn=config
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}bdb,cn=config
dn: olcDatabase={2}monitor,cn=config

Another ACL check for SASL EXTERNAL users with both UID and GID set to 0. In this test we also test the UNIX socket (i.e. ldapi:///)

sudo ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn

SASL/EXTERNAL authentication started

SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth

SASL SSF: 0

dn: cn=config

dn: cn=schema,cn=config

dn: cn={0}core,cn=schema,cn=config

dn: cn={1}cosine,cn=schema,cn=config

dn: cn={2}inetorgperson,cn=schema,cn=config

dn: cn={3}collective,cn=schema,cn=config

dn: cn={4}corba,cn=schema,cn=config

dn: cn={5}duaconf,cn=schema,cn=config

dn: cn={6}openldap,cn=schema,cn=config

dn: cn={7}dyngroup,cn=schema,cn=config

dn: cn={8}java,cn=schema,cn=config

dn: cn={9}misc,cn=schema,cn=config

dn: cn={10}nis,cn=schema,cn=config

dn: cn={11}ppolicy,cn=schema,cn=config

dn: cn={12}kerberos,cn=schema,cn=config

dn: cn={13}schema,cn=schema,cn=config

dn: olcDatabase={-1}frontend,cn=config

dn: olcDatabase={0}config,cn=config

dn: olcDatabase={1}bdb,cn=config

dn: olcDatabase={2}monitor,cn=config

Excellent! We now have a working OpenLDAP server! The only thing left to do is make sure the daemon starts when we boot our server.

sudo chkconfig slapd on

We can now cross our first goal:

1. Install OpenLDAP 2.4.
2. Configure Transport Layer Security (TLS).
3. Manage users and groups in OpenLDAP.
4. Configure pam_ldap to authenticate users via OpenLDAP.
5. Use OpenLDAP as sudo's configuration repository.
6. Use OpenLDAP as automount map repository for autofs.
7. Use OpenLDAP as NFS netgroup repository again for autofs.
8. Use OpenLDAP as the Kerberos principal repository.
9. Setup OpenLDAP backup and recovery.
10. Setup OpenLDAP replication.

Transport Layer Security (TLS)

Using TLS is quite mandatory these days. TLS is used to provide integrity and confidentiality protections and to support LDAP authentication using the SASL EXTERNAL mechanism. TLS is defined in RFC4346.

To configure TLS, we need an SSL certificate and key. The certificate needs to be signed by a trusted Certificate Authority (CA) or self-signed if used in a lab.

In this blog post, we will show two different ways of setting up TLS :

1. Using a self-signed certificate via the openssl command.
2. Using a self-signed certificate via the CA.pl script.
3. Using a local CA via the Microsoft Certificate Authority's certuil and certreq commands.

IMPORTANT : You only need to use one of those techniques to configure TLS. Not all of them!

Self-Signed Certificate via the OpenSSL Command

UPDATE : thanks to mousematt for pointing out documentation bugs in this section!
UPDATE : see this excellent blog post on how to do self-signed certificates.

You can setup your own self-signed certificate without using the perl script. Try this :
First, change your umask value so that the new file will have user read and write permissions only.

umask 066

Then, create a self-signed Certificate Authority CA.

openssl req -newkey rsa:2048 -days 3650 -x509 -nodes -out rootca.crt

Next create a CA configuration file.

vim myca.conf

Create a few files referenced in the myca.conf file.

sudo touch /etc/pki/tls/certs/certindex
echo 000a > /tmp/serialfile
sudo mv /tmp/serialfile /etc/pki/tls/certs/serialfile
sudo chown root:root /etc/pki/tls/certs/serialfile

Move the files created with our first openssl command above.

mv privkey.pem /etc/pki/tls/certs/privkey.pem
mv rootca.crt /etc/pki/tls/certs/rootca.crt

Now create a Certificate Signing Request file (hint, that's what the .csr extension means :) Simply answer the various questions. IMHO it's best not to use a challenge password. Why? Well because if you do, then you will need to enter it every time you start the services. And if you write down the password in a wrapper script so that you don't have to enter it manually each time, then it defeats the purpose. Anyway, when prompted for the common name, enter either your machine's FQDN or a CNAME by which the service will be configured by the clients.

openssl req -newkey rsa:1024 -nodes -out alice.company.com.csr -keyout alice.company.com.key

Normally, you would then send this server.csr file to be signed by a real, trusted Certificate Authority (CA). But in our case, we do not want to pay for this service or we don't have an internal CA or it's a dev machine or we just don't care. So we self-sign it with our own CA like this :

openssl ca -batch -config ./myca.conf -notext -in alice.company.com.csr -days 730 -out alice.company.com.crt

We can then place the files in their respective locations. Just make sure you configure your OpenLDAP server with the appropriate paths to where the files are stored. Be sure to change file permissions on them.

chmod 400 alice.company.com.crt
sudo chown ldap:ldap alice.company.com.crt
sudo mv server.pem /etc/pki/tls/certs/alice.company.com.crt

chmod 400 alice.company.com.key
sudo chown ldap:ldap alice.company.com.key

sudo mv privkey.pem /etc/pki/tls/certs/alice.company.com.key

Finally, we update our OpenLDAP server's configuration to let him know where the files are located.

sudo ldapmodify -Y EXTERNAL -H ldapi:/// <<-EOF
dn: cn=config
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/pki/tls/certs/alice.company.com.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/pki/tls/certs/alice.company.com.key
-
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/pki/tls/certs/rootca.crt
EOF

Now the OpenLDAP server should work with TLS extensions. We can double-check this with the following query :

sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep -i tls

Once that works, we can get rid of the server.csr because we don't need it anymore. So just remove it.

rm alice.company.com.csr

IMPORTANT : At this point, you can go directly to « Test TLS Configuration » below.

Self-Signed Certificate via the CA.pl Script

Thanks to Ambot Lang who provided these instructions.

Optionally modify /etc/pki/tls/openssl.cnf to make your life easier by just pressing the « enter » key when you run the openssl command later. Modify each _default lines.

vi /etc/pki/tls/openssl.cnf

You will edit the _default data to something similar to this : (of course, these are from Ambot Lang, so make sure you edit those to suit your own data :) ) IMPORTANT : make sure to use your current OpenLDAP server's Fully Qualified Host Name in the Common Name value.

Country Name (2 letter code) [PH]:
State or Province Name (full name) [Mindanao]:
Locality Name (eg, city) [Aurora]:
Organization Name (eg, company) [Ambot Lang Bisdak]:
Organizational Unit Name (eg, section) [Mga Lumad]:
Common Name (eg, your name or your server's hostname) [alice.company.com]:
Email Address [root@127.0.0.1]:

Download and use Ambot's xCA.pl script  (an old script but very useful, courtesy of the authors). Place it into the ~/ldap directory.

mv ~/Downloads/xCA.pl ~/ldap

Then create the CA certificate, the server's TLS certificate and key.

cd ~/ldap
rm -Rf CA
rm -f *.pem
./xCA.pl -newca
openssl req -new -nodes -keyout alice.company.com.key -out alice.company.com.pem
./xCA.pl -sign
cp -f alice.company.com.pem /etc/pki/tls/certs
cp -f alice.company.com.key /etc/pki/tls/certs
cp -f CA/cacert.pem /etc/pki/tls/certs

Test to see if the new files work as they should?

openssl s_client -connect `hostname`:636 -showcerts -state -CAfile /etc/pki/tls/certs/cacert.pem

Fix permissions.

sudo chown ldap:ldap /etc/pki/tls/certs/alice.company.com.pem /etc/pki/tls/certs/alice.company.com.key
sudo chown root:root /etc/pki/tls/certs/cacert.pem

sudo chmod 600 /etc/pki/tls/certs/alice.company.com.key

Assuming OpenLDAP is running, add the new configuration.

sudo ldapmodify -Y EXTERNAL -H ldapi:/// <-EOF
dn: cn=config
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/pki/tls/certs/alice.company.com.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/pki/tls/certs/alice.company.com.key
-
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/pki/tls/certs/cacert.pem
EOF

Now the OpenLDAP server should work with TLS extensions. We can double-check this with the following query :

sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep -i tls

Local CA via the Microsoft Certificate Authority

To use a local CA. To have it signed, we first need to create a TLS certificate signing request and key. We will then have the certificate signing request file signed by a local CA. In this document, we use a local Windows 2003 Certification Service as the trusted CA. Simply because it was available in our production environment. If you're a systems administrator, chances are you will also have one at your site. Of course, any other CA is good, just as long as all the servers and clients agree on who's the trusted CA. One day I would very much like to give OpenCA a try.

So let's go ahead and create the Certificate Signing Request ( .csr) and associated Key ( .key). WARNING : be sure to use the real hostname here and NOT a DNS CNAME. Don't forget to edit this command with your own settings.

openssl req -newkey rsa:2048 -keyout `hostname`.key -nodes -out `hostname`.req -subj /CN=alice.company.com/O=Company/C=CA/ST=QC/L=Montreal

Upload the .req file to the CA machine.

Login to the Windows CA machine and run certuil without options to know what to use with the -config option later.

C:\Documents and Settings\drobilla\Desktop>certutil | find "Config"

  Config:                       `caserver.company.com\Company CA'

We now know that the config is `caserver.company.com\Company CA'. We can now sign the .req file with the Microsoft Certreq command.

certreq -submit -attrib "CertificateTemplate:WebServer" -config "caserver.company.com\Company CA" alice.company.com.req alice.company.com.pem

This will create the alice.company.com.pem file. Keep it handy.

While we're on the Windows CA, if we don't have a copy of the CA's certificate, now's the time to get it. We only need the lines between the BEGIN and END certificate. Copy and paste these lines into a new file called companyCA.crt with the ouput below. The file must contain both the BEGIN and END lines as well. (Note that the file below is not valid and is only there for demonstration purposes).

certutil -v -ca.cert -config "caserver.company.com\Company CA" C:\companyCA.crt

-----BEGIN CERTIFICATE-----

MIIDpjCCA1CgAwIBAgIQEzzFpHh0nbZEfMnwfsX4ZjANBgkqhkiG9w0BAQUFADCB

A1UEBhMCQ0ExDzANBgNVBAgTBlF1ZWJlYzERMA8GA1UEBxMITW9udHJlYWwxEDAO

b24gQ0EwHhcNMDYwNTI0MTQ0MTAxWhcNMTYwNTI0MTQ1MDQwWjCBlDEoMCYGCSqG

SIb3DQEJARYZYWRtaW5pc3RyYXRvckBjYXByaW9uLmNvbTELMAkGA1UEBhMCQ0Ex

DzANBgNVBAgTBlF1ZWJlYzERMA8GA1UEBxMITW9udHJlYWwxEDAOBgNVBAoTB0Nh

cHJpb24xEDAOBgNVBAsTB0NhcHJpb24xEzARBgNVBAMTCkNhcHJpb24gQ0EwXDAN

BgkqhkiG9w0BAQEFAANLADBIAkEAvFSJcicZzL06ZiH3iX74TQjjViH73bn5ax0N

Ay2vyhGwCMUw8DiGVq7xZ3n19HjDgfYJBISf6S3p6smiV6b5qwIDAQABo4IBejCC

AXYwEwYJKwYBBAGCNxQCBAYeBABDAEEwCwYDVR0PBAQDAgFGMA8GA1UdEwEB/wQF

MAMBAf8wHQYDVR0OBBYEFCxt/TUosXol3ngeFlMp/twwB8WVMIIBDgYDVR0fBIIB

BTCCAQEwgb6ggbuggbiGgbVsZGFwOi8vL0NOPUNhcHJpb24lMjBDQSxDTj1lbmNl

bGFkdXMsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZp

y2vZlenopunVBMzPz3VyYXRpb24sREM9Y2FwcmlvbixEQz1jb20/Y2VydGlmaWNh

dGVSZXZvY2F0aW9uTGLZDd9IyxnLp29IamVjdGNsYXNzPWNSTERpc3RyaWJ1dGlv

blBvaW50MD6gPKA6hjhodHRwOi8vZW5jzwXHzhvZlMnHChJpb24uY29tL0NlcnRF

bnJvbGwvQ2FwcmlvbiUyMENBLmNybDAQBgkrBgEEAYI3FQeeaWibadanbGKqhkiG

9w0BAQUFAANBAEqnFfQe8AGPA8/FJURJdgUs0Nb4qGWuGtxJXwJgo/CyS1W+Vi7x

+9/zNtsflae1Czy8O1JI6z9v9tBUKMebRSc=

-----END CERTIFICATE-----

Transfer this companyCA.crt file and the new alice.company.com.pem files to the CentOS machine.

Double-check to see if the new .pem file is good?

openssl verify -purpose sslserver -CAfile companyCA.crt alice.company.com.pem

Now place the certificate, the key and the CA certificate into the /etc/pki/tls/certs directory.

sudo mv alice.company.com.pem alice.company.com.key companyCA.crt /etc/pki/tls/certs

Fix permissions.

sudo chown ldap:ldap /etc/pki/tls/certs/alice.company.com.pem /etc/pki/tls/certs/alice.company.com.key
sudo chown root:root /etc/pki/tls/certs/companyCA.crt

sudo chmod 600 /etc/pki/tls/certs/alice.company.com.key

Check our current cn=config to see if we already have TLS configurations?

sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep -i tls
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
olcTLSVerifyClient: never

Ah ha, so we already have olcTLSVerifyClient: set to never. This is what we want, so we'll leave it as it is. To configure TLS, create an LDIF file with the following data.

vi ~/ldap/tls.ldif

Install these new configurations into our server.

sudo ldapmodify -vY EXTERNAL -H ldapi:/// -f ~/ldap/tls.ldif

Test TLS Configuration

If we query our configuration, we now have our TLS configured.

sudo ldapsearch -LLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep -i tls
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
olcTLSVerifyClient: never
olcTLSCertificateFile: /etc/pki/tls/certs/alice.company.com.pem
olcTLSCertificateKeyFile: /etc/pki/tls/certs/alice.company.com.key
olcTLSCACertificateFile: /etc/pki/tls/certs/companyCA.crt

Revist the LDAP client configuration file to enable the TLS configs.

sudo vi /etc/openldap/ldap.conf

Normally with the cn=config setup, we don't have to restart the daemon. But for TLS, I had to. Go figure?

sudo /etc/init.d/slapd restart

Test a TLS encrypted connection to our OpenLDAP server.

ldapsearch -ZxLLLWD cn=admin,dc=company,dc=com -b cn=config -s base

Notice that we didn't have to use any -H ldap://alice.company.com in the previous command. That's because it's now listed in the /etc/openldap/ldap.conf file. We also were able to trust the certificate from alice.company.com because we have the TLS_CACERT configuration in the /etc/openldap/ldap.conf file.

Ok, so far so good. We now have a TLS enabled OpenLDAP server! We can cross our second goal now.

1. Install OpenLDAP 2.4.
2. Configure Transport Layer Security (TLS).
3. Manage users and groups in OpenLDAP.
4. Configure pam_ldap to authenticate users via OpenLDAP.
5. Use OpenLDAP as sudo's configuration repository.
6. Use OpenLDAP as automount map repository for autofs.
7. Use OpenLDAP as NFS netgroup repository again for autofs.
8. Use OpenLDAP as the Kerberos principal repository.
9. Setup OpenLDAP backup and recovery.
10. Setup OpenLDAP replication.

See you at my next post!

DA+

References

• RFC 2251 - Lightweight Directory Access Protocol (v3)
• RFC 2307 - An Approach for Using LDAP as a Network Information Service
• RFC 3045 - Storing Vendor Information in the LDAP root DSE
• RFC 3672 - Subentries in the Lightweight Directory Access Protocol (LDAP)
• RFC 4510 - LDAP : Technical Specification Road Map
• RFC 4512 - LDAP : Directory Information Models
• RFC 4517 - LDAP : Syntaxes and Matching Rules
• RFC 4519 - LDAP : Schema for User Applications
• RFC 4523 - LDAP : Schema Definitions for X.509 Certificates