Centralized authentication using OpenLDAP

What is LDAP?[edit | edit source]

LDAP stands for Lightweight Directory Access Protocol. Based on X.500 it encompasses most of its primary functions, but lacks the more esoteric functions that X.500 has. Now what is this X.500 and why is there an LDAP?

X.500 is a model for Directory Services in the OSI concept. It contains namespace definitions and the protocols for querying and updating the directory. However, X.500 has been found to be overkill in many situations. Enter LDAP. Like X.500 it provides a data/namespace model for the directory and a protocol. However, LDAP is designed to run directly over the TCP/IP stack. See LDAP as a slim-down version of X.500.

What is a directory?[edit | edit source]

A directory is a specialized database designed for frequent queries but infrequent updates. Unlike general databases they don't contain transaction support or roll-back functionality. Directories are easily replicated to increase availability and reliability. When directories are replicated, temporary inconsistencies are allowed as long as they get synchronised eventually.

How is information structured?[edit | edit source]

All information inside a directory is structured hierarchically. Even more, to enter data inside a directory, the directory must know how to store this data inside a tree. Let's take a look at a fictional company and an Internet-like tree:

dc:         org
             |
dc:        genfic         ## (Organisation)
          /      \
ou:   People   servers    ## (Organisational Units)
      /    \     ..
uid: ..   John            ## (OU-specific data)

Since data is not fed to the database in this ASCII-art like manner, every node of such a tree must be defined. To name such nodes, LDAP uses a naming scheme. Most LDAP distributions (including OpenLDAP) already contain quite a number of predefined (and general approved) schemas, such as the inetOrgPerson, or a frequently used schema to define users which Unix/Linux boxes can use, called posixAccount. Note there are GUI web based tools to make managing LDAP painless: see Working with OpenLDAP for an non-exhaustive list.

Interested users are encouraged to read the OpenLDAP Admin Guide.

What can it be used for?[edit | edit source]

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)

• ...

Common notes[edit | edit source]

The domain genfic.org is an example in this guide. The domain can be renamed as suitable to the readers. However, make sure that the top node is an official top level domain (.net, .com, .cc, .be, etc.).

Let's first emerge OpenLDAP. Ensure the USE flags syslog, -minimal (disabled) and tcpd are used.

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, see RFC4422 for details).

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 hard coded 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 clear text or hashed. Multiple different hash algorithms are available, but usage of weak algorithms (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:

New password: my-password
Re-enter new password: my-password
{SSHA}EzP6I82DZRnW+ou6lyiXHGxSpSOw2XO4

Legacy configuration (flat config slapd.conf)[edit | edit source]

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.

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/slapd.pid
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=001
  provider=ldap://ldap2.genfic.org
  type=refreshAndPersist
  retry="5 5 300 +"
  searchbase="dc=genfic,dc=org"
  attrs="*,+"
  bindmethod="simple"
  binddn="cn=ldapreader,dc=genfic,dc=org"
  credentials="ldapsyncpass"
 
index entryCSN eq
index entryUUID eq
 
mirrormode TRUE
 
overlay syncprov
syncprov-checkpoint 100 10

For a more detailed analysis of the configuration file see the OpenLDAP Administrator's Guide found on the upstream project's documentation page, although reading man 5 slapd.conf may be enough.

If it does not start, the first step is to check the configuration file:

Vary the debug level (the -d 1 above) for more info. If all goes well a config file testing succeeded will be displayed. 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.

Migration from slapd.conf to OLC[edit | edit source]

To be able to change OpenLDAP server's configuration, 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:

database config
access to *
        by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
        by * none

Then, invoke the slaptest utility with the -f and -F options to convert the slapd.conf file into a configuration directory (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.

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

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

Initial setup with OLC[edit | edit source]

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

olcArgsFile: /run/openldap/slapd.args
olcPidFile: /run/openldap/slapd.pid

dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulepath: /usr/lib64/openldap/openldap
olcModuleload: back_mdb.so

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

When using a root account, be sure to correct ownership of the files created by root, as described below in migrate section.

For the right to change the configuration database, proper permissions must be provided. The next example shows how these privileges are granted to the root system user:

# {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:

Maintaining the directory[edit | edit source]

Start slapd now that the configuration steps have been completed:

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

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 or eselect repository.

Server management with OLC[edit | edit source]

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):

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:

dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: stats stats2 sync

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

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

58b7d4c2 olcThreads: value #0: warning, threads=64 larger than twice the default (2*16=32); YMMV.
config file testing succeeded

OpenLDAP logging[edit | edit source]

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 standalone server and stats stats2 sync in OpenLDAP cluster. In such case query results logs session-related information such as the following:

Mar  9 12:26:47 ldap1 slapd[95182]: conn=1 fd=14 ACCEPT from IP=192.168.100.9:55655 (IP=192.168.1.1:389)
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=

Most common errors in server log are err=49:

Aug 10 12:47:27 ldap-2 slapd[32920]: conn=1004 op=0 RESULT tag=97 err=49 text=

Which means «invalid credentials» (i.e. wrong password).

And err=32:

Aug 10 14:15:35 ldap-2 slapd[32966]: conn=1085 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=

Which means «No such object». Usually this error appears when binddn (user) has no permissions on requested object. So either try to do something wrong, or there is a mistake in the set ACLs.

Access management (ACLs)[edit | edit source]

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

access to <what> [ by <who> [ <access> ] [ <control> ] ]+

The following table shows the access levels available in OpenLDAP:

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

…
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
…

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

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

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

Replication[edit | edit source]

 {SSHA}XvbdAv6rdskp9HgFaFL9YhGkJH3HSkiM

dn: cn=ldapreader,dc=genfic,dc=org
userPassword: {SSHA}XvbdAv6rdskp9HgFaFL9YhGkJH3HSkiM
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: ldapreader
description: LDAP reader used for synchronization

Password: ## enter the administrative password

@(#) $OpenLDAP: slapd 2.4.44 (Feb 28 2017 10:07:46) $
	@larry:/var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44-abi_x86_64.amd64/servers/slapd

Included static overlays:
    syncprov
Included static backends:
    config
    ldif
    bdb
    hdb

#Load the syncprov module.
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

# 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

dn: cn=config
changetype: modify
add: olcServerID
olcServerID: 1

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl: 
  rid=001 
  provider=ldap://ldap-2.genfic.org 
  binddn="cn=ldapreader,dc=genfic,dc=org" 
  bindmethod=simple 
  credentials="secret" 
  searchbase="dc=genfic,dc=org" 
  type=refreshAndPersist 
  timeout=0 
  network-timeout=0 
  retry="60 +"

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcMirrorMode
olcMirrorMode: TRUE

add-replication-node2.ldif 
dn: cn=config
changetype: modify
add: olcServerID
olcServerID: 1

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncrepl
olcSyncrepl:
  rid=002
  provider=ldap://ldap-1.genfic.org
  binddn="cn=ldapreader,dc=genfic,dc=org"
  bindmethod=simple
  credentials="secret"
  searchbase="dc=genfic,dc=org"
  type=refreshAndPersist
  timeout=0
  network-timeout=0
  retry="60 +"

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcMirrorMode
olcMirrorMode: TRUE

May 14 15:39:29 ldap2 slapd[1749]: olcMirrorMode: value #0: <olcMirrorMode> database is not a shadow
May 14 15:39:29 ldap2 slapd[1749]: config error processing olcDatabase={1}mdb,cn=config: <olcMirrorMode> database is not a shadow
May 14 15:39:29 ldap2 slapd[1749]: slapd stopped.
May 14 15:39:29 ldap2 slapd[1749]: connections_destroy: nothing to destroy.

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcLimits
olcLimits: dn.exact="cn=ldapreader,dc=genfic,dc=org" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited

Performance tuning[edit | edit source]

Default daemon settings significantly limits LDAP server performance.

May 17 15:56:11 ldap2 slapd[13834]: fd=76 DENIED from unknown (192.168.210.101)
May 17 15:56:11 ldap2 slapd[13834]: warning: cannot open /etc/hosts.allow: Too many open files
May 17 15:56:11 ldap2 slapd[13834]: warning: cannot open /etc/hosts.deny: Too many open files
May 17 15:56:11 ldap2 slapd[13834]: fd=237 DENIED from unknown (192.168.77.130)
May 17 15:56:11 ldap2 slapd[13834]: warning: cannot open /etc/hosts.allow: Too many open files
May 17 15:56:11 ldap2 slapd[13834]: daemon: accept(8) failed errno=24 (Too many open files)

core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 6981
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 6981
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

nr_open:
This denotes the maximum number of file-handles a process can 
allocate. Default value is 1024*1024 (1048576) which should be
enough for most machines. Actual limit depends on RLIMIT_NOFILE
resource limit.

ldap           soft    nofile          4096
ldap           hard    nofile          8192

net.core.somaxconn = 256

## For LDAP:
net.core.somaxconn = 256

Client PAM configuration SSSD Method[edit | edit source]

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

[sssd]
config_file_version = 2
services = nss, pam
domains = genfic
debug_level = 5
  
[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
  
[domain/genfic]
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.

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 pam_mkhomedir.so to support creating the user home directories.

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_sss.so use_first_pass                                         #
auth        required      pam_deny.so
  
account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_sss.so                         #
account     required      pam_permit.so
  
password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok                                            #
password    required      pam_deny.so
  
session     required      pam_mkhomedir.so skel=/etc/skel/ umask=0077
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so                                                        #

Now try logging in from another box.

Client PAM configuration the pam_ldap module method[edit | edit source]

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).

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.

#%PAM-1.0
 
auth       required     pam_env.so
auth       sufficient   pam_unix.so try_first_pass likeauth nullok
auth       sufficient   pam_ldap.so use_first_pass                                                    #
auth       required     pam_deny.so
 
account    sufficient   pam_ldap.so                                                                   #
account    required     pam_unix.so
 
password   required     pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 try_first_pass retry=3
password   sufficient   pam_unix.so try_first_pass use_authtok nullok md5 shadow
password   sufficient   pam_ldap.so use_authtok use_first_pass                                        #
password   required     pam_deny.so
 
session    required     pam_limits.so
session    required     pam_unix.so
session    optional     pam_ldap.so                                                                   #

Now change /etc/ldap.conf to read:

#host 127.0.0.1
#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.genfic.org/ ldap://ldap1.genfic.org ldap://ldap2.genfic.org

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

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

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.

Emerge errors after conversion to LDAP[edit | edit source]

If for any reasons local user accounts (i.e. /etc/passwd /etc/shadow) or groups (i.e. /etc/group) are deleted after converting the file userbase to LDAP, errors may be encountered relating to missing user (or group) while emerging certain packages.

Example of error while emerging www-servers/apache due to missing "apache" local user account:

Installing build system files
make[1]: Leaving directory '/var/tmp/portage/www-servers/apache-2.4.41/work/httpd-2.4.41'               [ ok ]
chown: invalid user: ?apache:apache?
* ERROR: www-servers/apache-2.4.41::gentoo failed (install phase):
*   fowners failed

In such cases, a workaround involves emerging the package using FEATURES=-network-sandbox. Doing so has potential security consequences so system users should remain in local files.