Autenticazione centralizzata utilizzando OpenLDAP

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Centralized authentication using OpenLDAP and the translation is 8% complete.

Other languages:
English • ‎español • ‎français • ‎italiano • ‎日本語 • ‎한국어 • ‎polski • ‎русский • ‎中文 • ‎中文(中国大陆)‎

Questa guida introduce le basi del protocollo LDAP e mostra come utilizzare OpenLDAP per l'autenticazione in un gruppo di computer.

Getting started with OpenLDAP

Cos'è LDAP?

LDAP significa Lightweight Directory Access Protocol (Protocollo Leggero di Accesso a Directory). Basato su X.500, comprende la maggior parte delle sue funzioni principali, ma manca delle funzioni più "esoteriche" che X.500 ha. Ora, cos'è X.500 e che c'entra con LDAP?

X.500 è un modello di Servizi di Directory, secondo i principi OSI. Contiene le definizioni dei namespace ed i protocolli per interrogare ed aggiornare i directory. Tuttavia, X.500 è stato riscontrato essere eccessivo in molte situazioni. Da qui deriva l'LDAP. Come X.500, fornisce un modello dati/namespace per le directory ed un protocollo. Ma LDAP è progettato per girare direttamente sullo stack TCP/IP. Vedete pure LDAP come una versione "dimagrita" di X.500.

Non capisco. Cosa si intende con directory?

Un server di directory (traducibile letteralmente come "elenco") è un database specializzato progettato per interrogazioni frequenti ed aggiornamenti non frequenti. A differenza dei DB generalizzati, non contengono supporto transazionale o funzionalità di roll-back. Questi server di directory sono facilmente replicati per incrementarne la disponibilità e l'affidabilità. Quando le directory sono replicate, è permessa un'inconsistenza temporanea a patto che vengano sincronizzate in seguito.

Come sono strutturate le informazioni?

Tutte le informazioni in un directory sono strutturate in maniera gerarchica

CODE Organisational structure for GenFic, a Fictional Gentoo community
dc:         org
dc:        genfic         ## (Organisation)
          /      \
ou:   People   servers    ## (Organisational Units)
      /    \     ..
uid: ..   John            ## (OU-specific data)

Dato che non importerete i dati con questo modo "ASCII-Art", ogni nodo in quest'albero deve essere definito. Per definire questi nodi, LDAP utilizza uno schema. Buona parte dei server LDAP (incluso OpenLDAP) contengono un certo numero di schemi predefiniti (e generalmente riconosciuti), come per esempio "inetOrgPerson", o uno schema utilizzato frequentemente per definire utenti in macchine Unix/Linux, chiamato "posixAccount". Da notare che esistono tool grafici per amministrare LDAP facilmente: si veda Working with OpenLDAP per una lista non esaustiva.

Agli utenti interessati si consiglia la lettura della Guida all'amministrazione di OpenLDAP (inglese).

So... what can it be used for?

LDAP can be used for various things. This document focuses on centralised user management, keeping all user accounts in a single LDAP location (which doesn't mean that it's housed on a single server, LDAP supports high availability and redundancy), yet other goals can be achieved using LDAP as well.

  • Public Key Infrastructure
  • Shared Calendar
  • Shared Addressbook
  • Storage for DHCP, DNS, ...
  • System Class Configuration Directives (keeping track of several server configurations)
  • Centralised Authentication (PosixAccount)
  • ...

OpenLDAP server setup

Common notes

The domain is an example in this guide. You will of course want to change this. However, make sure that the top node is an official top level domain (net, com, cc, be, ...).

Let's first emerge OpenLDAP. Ensure the USE flags berkdb, crypt, gnutls, ipv6, sasl, ssl, syslog, -minimal and tcpd are used.

root #emerge --ask openldap

OpenLDAP supports two authentication mechanisms:

  1. standard user-password (in LDAP terms user means binddn) named SIMPLE
  2. proxying authentication requests to SASL (Simple Authentication and Security Layer)

Although the OpenLDAP default is to use SASL, the initial version of this article used only password-based authentication. With the OLC add-on the article starts to describe the use of the simplest SASL mechanism called EXTERNAL, which relies on the system authentication.

OpenLDAP has a main user called "rootdn" (Root Distinguished Name), which is hardcoded in the application. Unlike the classic Unix root user, the rootdn user still needs to be assigned with proper permissions. The rootdn user may be used only in the context of the configuration, but it can also be used in the directory definition. In that case a user can authenticate himself as rootdn with either the configuration used password and the tree (directory-based) password.

User passwords (regardless if it is for rootdn users or others) for verification purposes can be stored as cleartext or hashed. Multiple different hash algorithms are available, but usage of weak algorythms (up to MD5) is not recommended. SHA is currently considered sufficiently cryptographically secure.

In the below command, a hashed value is created for a given password; the result of this command can be used in the slapd.conf configuration file, or in the internal directory definition of a user:

root #slappasswd
New password: my-password
Re-enter new password: my-password

Legacy configuration (flat config slapd.conf)

Now edit the LDAP Server configuration in /etc/openldap/slapd.conf. The provided slapd.conf is from the original OpenLDAP source. Below is a sample configuration file one can use to replace it with to get things started.

FILE /etc/openldap/slapd.conf
include	/etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include	/etc/openldap/schema/misc.schema
pidfile  /var/run/openldap/
argsfile /var/run/openldap/slapd.args
## ## ServerID used in case of replication
serverID 0 
loglevel 0
## ## Certificate/SSL Section
TLSCipherSuite normal
TLSCACertificateFile /etc/openldap/ssl/ldap.crt
TLSCertificateFile /etc/openldap/ssl/ldap.pem
TLSCertificateKeyFile /etc/openldap/ssl/ldap.key
TLSVerifyClient never
## ## Access Controls
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to *
  by self write
  by users read
  by anonymous read
## ## Database definition
database mdb
suffix "dc=genfic,dc=org"
checkpoint 32 30
maxsize 10485760
#Note: It is important to set this to as large a value as possible,
#(relative to anticipated growth of the actual data over time)
#since growing the size later may not be practical when the system is under heavy load.
rootdn "cn=Manager,dc=genfic,dc=org"
## ## rootpwd generated earlier via slappasswd command
rootpw "{SSHA}EzP6I82DZRnW+ou6lyiXHGxSpSOw2XO4" 
directory "/var/lib/openldap-data"
index objectClass eq
## ## Synchronisation (pull from other LDAP server)
syncrepl rid=000
  retry="5 5 300 +"
index entryCSN eq
index entryUUID eq
mirrormode TRUE
overlay syncprov
syncprov-checkpoint 100 10

For a more detailed analysis of the configuration file, we suggest that you work through the OpenLDAP Administrator's Guide, although man 5 slapd.conf may be enough.

If it does not start, the first thing you must do is to check the config file. You can do it with the following command.

user $slaptest -v -d 1 -f /etc/openldap/slapd.conf

Vary the debug level (the "-d 1" above) for more info. If all goes well you will see config file testing succeeded. If there's an error, slaptest will list the line number to which it applies (of the slapd.conf file).

By default slapd writes the log events to the local4 syslog facility.

Note that since version 2.4.23, OpenLDAP default finally moved from traditional flat config files (slapd.conf) to OLC (OnLineConfiguration, also known through its cn=config structure) as default configuration method. One of benefits of using OLC is that the dynamic backend (cn=config) doesn't require restart of server after updating the configuration. Existing users can migrate to the new configuration method by invoking slaptest setting both -f and -F options. Traditionally OLC is stored in ldif backend (which keep benefits of human-readability) in the /etc/openldap/slapd.d directory. In Gentoo it is not required to convert the configuration yet, but support for the currently documented approach will be removed in the future.

Migration from slapd.conf to OLC

If you want to be able to change OpenLDAP server's configuration, you must define at least write (or normally manage) access to cn=config.

The example below shows how to grant manage access on OLC (cn=config database) to the system administrator (root user) by adding the proper lines at the end of the slapd.conf file:

FILE /etc/openldap/slapd.confGranting root Linux account manage rights to cn=config
database config
access to *
        by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
        by * none

Then, we invoke the slaptest utility with the -f and -F options to convert the slapd.conf file into a configuration directory (slapd.d).

root #mkdir /etc/openldap/slapd.d
root #slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
root #chown -R ldap /etc/openldap/slapd.d

Running this command will transfer and translate the configuration. After that you are expected to update the configuration using specially prepared ldif files. And only if you aren't enough familiar with them, you can first edit slapd.conf and after that re-translate the slapd.conf into slapd.d/. Don't forget to check the directory's permissions.

For more instructions read the in-line comments of the generated files.

The below line will enable the slapd.d/ configuration method.

FILE /etc/conf.d/slapd
OPTS="-F /etc/openldap/slapd.d -h 'ldaps:// ldap:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'"

Finally, create the /var/lib/openldap-data structure:

root #mkdir -p /var/lib/openldap-data
root #chown -R ldap:ldap /var/lib/openldap-data
root #chmod -R 0700 /var/lib/openldap-data

Initial setup with OLC

An initial configuration is shipped as a standard LDAP database dump, available as slapd.ldif or config.ldif.

It can be loaded (and only loaded, unlike ordinary LDAP databases) by the slapadd utility:

root #slapadd -d -1 -F /etc/openldap/slapd.d -n 0 -l /etc/openldap/config.ldif
The default configuration does not provide permissions to change the server's configuration to anybody.

If you need the right to change the configuration database, you must provide the proper permissions. The next example shows how these privileges are granted to the root system user:

FILE config-access.ldif
# {0}config, config
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to *  by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage  by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE

See man 5 slapd-config for more details.

When using OLC, never manually edit the configuration files. The directory files can be used to check the consistency of the configuration through:

root #slaptest -v -d 1 -F /etc/openldap/slapd.d

Maintaining the directory

Start slapd now that the configuration steps have been completed:

root #service slapd start

Most users will also want the OpenLDAP daemon to start automatically:

root #rc-update add slapd

It is now possible to use the directory server to authenticate users in apache/proftpd/qmail/samba.

The directory server can be managed with tools such as net-nds/phpldapadmin, app-admin/diradm and net-nds/jxplorer from the Gentoo ebuild repository, or app-misc/ldapexplorertool from the poly-c overlay available through Layman.

Server management with OLC

One of the benefits of using OLC-style configuration is that you don't need to restart the LDAP server to apply configuration changes.

Some examples of updates on the OLC-style configuration are mentioned below.

For instance, to change the location of the OLC configuration directory (needed after switching from a config file to config directory style):

FILE fix-configs.ldif
dn: cn=config
changetype: modify
delete: olcConfigFile
dn: cn=config
changetype: modify
replace: olcConfigDir
olcConfigDir: /etc/openldap/slapd.d

To change the log level used by the OpenLDAP instance:

FILE loglevel.ldif
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: stats stats2 sync

To add the syncprov overlay:

FILE add-syncprov-overlay.ldif
# Add indexes for replica to the frontend db.
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryCSN eq
add: olcDbIndex
olcDbIndex: entryUUID eq
# Load the syncprov module.
# Skip if included statically, see slapd -VVV output for details
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov
# syncrepl Provider for primary db
dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
olcSpCheckpoint: 100 10
olcSpSessionlog: 100

In order to apply the changes, run the following command:

root #ldapmodify -Y EXTERNAL -H ldapi:/// -f loglevel.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifying entry "cn=config"
On restart, the init script performs a check of the updated configuration. The ldapmodify command used above blocks only fatal errors. To get info about non-fatal errors using OLC:
root #slaptest -F /etc/openldap/slapd.d
58b7d4c2 olcThreads: value #0: warning, threads=64 larger than twice the default (2*16=32); YMMV.
config file testing succeeded

OpenLDAP logging

OpenLDAP produces numerous log events, which might not be obvious to interpret, but are necessary for debugging purposes.

As OpenLDAP by default writes the log events into the system log, it is advisable to reconfigure the system logger to direct OpenLDAP log events into a dedicated log file.

It is advisable to use the stats stats2 log level in OpenLDAP, which results in session-related information such as the following:

root #grep conn=1 /var/log/slapd.log
Mar  9 12:26:47 ldap1 slapd[95182]: conn=1 fd=14 ACCEPT from IP= (IP=
Mar  9 12:26:47 ldap1 slapd[95182]: conn=1 op=0 BIND dn="" method=128
Mar  9 12:26:47 ldap1 slapd[95182]: conn=1 op=0 RESULT tag=97 err=0 text=
Mar  9 12:26:47 ldap1 slapd[95182]: conn=1 op=1 SRCH base="ou=People,dc=genfic,dc=org" scope=1 deref=0 filter="(&(objectClass=posixAccount)(uidNumber=1001))"
Mar  9 12:26:47 ldap1 slapd[95182]: conn=1 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass shadowLastChange shadowMax shadowExpire
Mar  9 12:26:47 ldap1 slapd[95182]: conn=1 op=1 ENTRY dn="uid=larry,ou=People,dc=genfic,dc=org"
Mar  9 12:26:47 ldap1 slapd[95182]: conn=1 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=

Access management (ACLs)

The authorizations and access control mechanism used in OpenLDAP is described in the slapd.access manual page. Its base syntax is as follows:

CODE ACL syntax in OpenLDAP
access to <what> [ by <who> [ <access> ] [ <control> ] ]+

The following table shows the access levels available in OpenLDAP:

Access level Privileges Description
none 0 no access
disclose d needed for information disclosure on error
auth dx needed to authenticate (bind)
compare cdx needed to compare
search scdx needed to apply search filters
read rscdx needed to read search results
{write|add|delete} wrscdx needed to modify/rename
manage mwrscdx needed to manage

For details about the exact privilege settings, see the manual pages and official OpenLDAP documentation.

Remember that the rootdn user can read and write everything.

Config file

ACLs are parsed in the order they are set in the configuration, and are applied based on the specificity (meaning that, when an ACL rule is considered, the remainder of ACL rules is no longer checked). As such, more specific definitions should go first, before more generic ones are listed. For more information, see Access Control Evaluation.

For example:

FILE /etc/openldap/slapd.conf
access to attrs=userPassword
         by dn="cn=ldapreader,dc=genfic,dc=org" read
         by self read
         by anonymous auth
         by * none
access to dn.base="cn=Subschema" by users read
access to dn.base="" by * read

Config directory

ACLs are parsed in the order they are set in the configuration, and are applied based on the specificity (meaning that, when an ACL rule is considered, the remainder of ACL rules is no longer checked). As such, more specific definitions should go first, before more generic ones are listed. This order, when using OLC, is handled through the olcAccess directives.

For example:

FILE add_acl.ldif
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to dn.base="cn=subschema"  by users read
olcAccess: {1}to dn.base="" by * read

The following example inserts a new ACL on top, making the existing olcAccess entries to shift by one:

FILE insert_acl.ldif
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to attrs=userPassword  by dn="cn=ldapreader,dc=genfic,dc=org" read by self read by anonymous auth by * none

To delete an ACL:

FILE delete_acl.ldif
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
delete: olcAccess
olcAccess: {1}


High availability

A common high availability setup with OpenLDAP is to use replication of changes across multiple LDAP systems.

Replication within OpenLDAP is, in this guide, set up using a specific replication account ( ldapreader ) which has read rights on the primary LDAP server and which pulls in changes from the primary LDAP server to the secondary.

This setup is then mirrored, allowing the secondary LDAP server to act as a primary. Thanks to OpenLDAP's internal structure, changes are not re-applied if they are already in the LDAP structure.

Setting up replication

To setup replication, first setup a second OpenLDAP server, similarly as above. However take care that, in the configuration file:

  • The sync replication provider is pointing to the other system
  • The serverID of each OpenLDAP system is different
Using a mirrored installation means that the OpenLDAP service should be configured like a single server installation, so the serverID value on each of the nodes must be the same. Instances are identified by rid values, which must be unique.

Next, create the synchronisation account. We will create an LDIF file (the format used as data input for LDAP servers) and add it to each LDAP server:

user $slappasswd -s myreaderpassword
FILE ldapreader.ldif
dn: cn=ldapreader,dc=genfic,dc=org
userPassword: {SSHA}XvbdAv6rdskp9HgFaFL9YhGkJH3HSkiM
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: ldapreader
description: LDAP reader used for synchronization
user $ldapadd -x -W -D "cn=Manager,dc=genfic,dc=org" -f ldapreader.ldif
Password: ## enter the administrative password

Configuring the OpenLDAP client tools

Edit the LDAP Client configuration file. This file is read by ldapsearch and other ldap command line tools.

FILE /etc/openldap/ldap.confAdd the following
BASE         dc=genfic, dc=org
URI          ldap:// ldap:// ldap://

You can test the running server with the following command:

user $ldapsearch -x -D "cn=Manager,dc=genfic,dc=org" -W

If you receive an error, try adding -d 255 to increase the verbosity and solve the issue you have.

Client configuration for centralized authentication

There are numerous methods/tools that can be used for remote authentication. Some distributions also have their own easy to use configuration tool. Below there are some in no particular order. It is possible to combine local users and centrally authorized accounts at the same time. This is important because, for instance, if the LDAP server cannot be accessed one can still login as root.

  • SSSD (Single Sign-on Services Daemon). Its primary function is to provide access to identity and authentication remote resource through a common framework that can provide caching and offline support to the system. It provides PAM and NSS modules, and in the future will support D-Bus interfaces for extended user information. It also provides a better database to store local users as well as extended user data.
  • Use pam_ldap to login to the LDAP server and authenticate. Passwords are not sent over the network in clear text.
  • NSLCD (Name Service Look up Daemon). Similar to SSSD, but older.
  • NSS (Name Service Switch) using the traditional pam_unix module to fetch password hashes over the network. To permit users to update their password this has to be combined with the pam_ldap method.

The first two are demonstrated below with the minimum necessary configuration options to get working.

Client PAM configuration SSSD Method

Here is the more direct method. The three files that are required to be edited are mentioned below.

FILE /etc/sssd/sssd.conf
config_file_version = 2
services = nss, pam
domains = genfic
debug_level = 5
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
id_provider = ldap
auth_provider = ldap
ldap_search_base = dc=genfic,dc=org
ldap_tls_reqcert = never
# primary and backup ldap servers below [first server and],[second server]
ldap_uri = ldap://X.X.X.X,ldap://X.X.X.X

Add sss to the end as shown below to enable the lookup to be handed to the sssd system service. Once you have finished editing start the sssd daemon.

FILE /etc/nsswitch.confExample nsswitch.conf with SSSD support
passwd:     files sss
shadow:     files sss
group:      files sss
netgroup:   files sss
automount:  files sss
sudoers:    files sss

The last file is the most critical. Open an extra root terminal as a fallback before editing this. The lines that end with # have been added to enable remote authentication. Note the use of to support creating the user home directories.

FILE /etc/pam.d/system-authEnable pam_sss support
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required
auth        sufficient nullok try_first_pass
auth        requisite uid >= 500 quiet
auth        sufficient use_first_pass                                         #
auth        required
account     required
account     sufficient
account     sufficient uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore]                         #
account     required
password    requisite try_first_pass retry=3
password    sufficient md5 shadow nullok try_first_pass use_authtok
password    sufficient use_authtok                                            #
password    required
session     required skel=/etc/skel/ umask=0077
session     optional revoke
session     required
session     [success=1 default=ignore] service in crond quiet use_uid
session     required
session     optional                                                        #

Now try logging in from another box.

Client PAM configuration the pam_ldap module method

First, we will configure PAM to allow LDAP authorization. Install sys-auth/pam_ldap so that PAM supports LDAP authorization, and sys-auth/nss_ldap so that your system can cope with LDAP servers for additional information (used by nsswitch.conf).

root #emerge --ask pam_ldap nss_ldap

The last file is the most critical. Open a few extra root terminals as a backup before editing this. The lines that end with # have been added to enable remote authentication.

FILE /etc/pam.d/system-auth
auth       required
auth       sufficient try_first_pass likeauth nullok
auth       sufficient use_first_pass                                                    #
auth       required
account    sufficient                                                                   #
account    required
password   required difok=2 minlen=8 dcredit=2 ocredit=2 try_first_pass retry=3
password   sufficient try_first_pass use_authtok nullok md5 shadow
password   sufficient use_authtok use_first_pass                                        #
password   required
session    required
session    required
session    optional                                                                   #

Now change /etc/ldap.conf to read:

FILE /etc/ldap.conf
#base dc=padl,dc=com
base dc=genfic,dc=org
#rootbinddn uid=root,ou=People,dc=genfic,dc=org
bind_policy soft
bind_timelimit 2
ldap_version 3
nss_base_group ou=Group,dc=genfic,dc=org
nss_base_hosts ou=Hosts,dc=genfic,dc=org
nss_base_passwd ou=People,dc=genfic,dc=org
nss_base_shadow ou=People,dc=genfic,dc=org
pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_member_attribute memberuid
pam_password exop
scope one
timelimit 2
uri ldap:// ldap:// ldap://

Next, copy over the (OpenLDAP) ldap.conf file from the server to the client so the clients are aware of the LDAP environment:

root #scp ldap-server:/etc/openldap/ldap.conf /etc/openldap

Finally, configure your clients so that they check the LDAP for system accounts:

FILE /etc/nsswitch.conf
passwd:         files ldap
group:          files ldap
shadow:         files ldap

If you noticed one of the lines you pasted into your /etc/ldap.conf was commented out (the rootbinddn line): you don't need it unless you want to change a user's password as superuser. In this case you need to echo the root password to /etc/ldap.secret in plaintext. This is DANGEROUS and should be chmoded to 600. What you might want to do is keep that file blank and when you need to change someone's password that's both in the LDAP and /etc/passwd, put the pass in there for 10 seconds while changing the users password and remove it when done.

Convert file userbase to LDAP

Configuring OpenLDAP for centralized administration and management of common Linux/Unix items isn't easy, but thanks to some tools and scripts available on the Internet, migrating a system from a single-system administrative point-of-view towards an OpenLDAP-based, centralized managed system isn't hard either.

Go to and fetch the scripts there. You'll need the migration tools and the script.

Next, extract the tools and copy the script inside the extracted location:

root #mktemp -d
root #cd /tmp/tmp.zchomocO3Q
root #tar xvzf /path/to/MigrationTools.tgz
root #mv /path/to/ MigrationTools-47
root #cd MigrationTools-47

The next step now is to migrate the information of your system to OpenLDAP. The script will do this for you, after you have provided it with the information regarding your LDAP structure and environment.

At the time of writing, the tools require the following input:

Input Description Example
LDAP BaseDN The base location (root) of your tree dc=genfic,dc=org
Mail domain Domain used in e-mail addresses
Mail host FQDN of your mail server infrastructure
LDAP Root DN Administrative account information for your LDAP structure cn=Manager,dc=genfic,dc=org
LDAP Root Password Password for the administrative account, cfr earlier slappasswd command

The tool will also ask you which accounts and settings you want to migrate.

You don't need to make changes to pam.d/system-auth


We would like to thank Matt Heler for lending us his box for the purpose of this guide. Thanks also go to the cool guys in #ldap on
This page is based on a document formerly found on our main website
The following people contributed to the original document: Benjamin Coles, Sven Vermeulen (SwifT), Brandon Hale, Benny Chuang, jokey, Joshua Saddler (nightmorph)
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.