OpenLDAP を使用した中央集権型認証

This page is a translated version of the page Centralized authentication using OpenLDAP and the translation is 24% complete.

Outdated translations are marked like this.

Other languages:

The information in this article is probably outdated. You can help the Gentoo community by verifying and updating this article.

このガイドは LDAP の基本を説明し、コンピュータのグループ間で認証を行うために OpenLDAP をセットアップする方法を示します。

警告
現在の記事の状態は、機能する設定を提供できていません。詳細については Talk:Centralized_authentication_using_OpenLDAP を参照してください。作業は現在進行中です。

OpenLDAP 事始め

LDAPとは何ですか?

LDAPは "Lightweight Directory Access Protocol" の略です。X.500モデルに基づいておりその主要機能をカバーしていますが、X.500上では定義されているさらに難解な機能は除かれています。さて、このX.500とはどのようなものでしょうか？　なぜLDAPは規定されたのでしょうか？

X.500は、OSIの概念に基づくディレクトリサービスのモデルです。これには名前空間の定義と、ディレクトリのクエリと更新のためのプロトコルが含まれています。しかしながら、X.500は多くの場合過剰であることが判明しています。LDAPではX.500と同様にディレクトリ用のデータ・名前空間モデルとプロトコルを提供します。ただし、LDAPはTCP/IPスタックを介して直接実行されるように設計されています。よってLDAPはX.500の簡易版と言えます。

ディレクトリとは何ですか？

ディレクトリは頻繁に参照され、あまり更新されない特殊なデータベースです。一般的なデータベースとは異なり、トランザクションやロールバックはサポートされていません。ディレクトリは可用性と信頼性を高めるために容易に複製できます。ディレクトリが複製される時の一時的な不一致は、最終的に同期が取れる限り許容されます。

どのような情報構成ですか？

ディレクトリ内のすべての情報は階層構造になっています。さらに、ディレクトリにデータを入力する場合、データをツリー内に格納する方法を知っていなければなりません。架空の会社とインターネットを模したツリーを見てみましょう:

コード 架空のGentooコミュニティGenFicの組織構造

dc:         org
             |
dc:        genfic         ## (組織)
          /      \
ou:   People   servers    ## (組織単位)
      /    \     ..
uid: ..   John            ## (組織単位に属するデータ)

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?

LDAP can be used for various things. This document focuses on centralized 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)

Centralized Authentication (PosixAccount)

……

OpenLDAP サーバの設定

Common notes

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.). Since LDAP does not provide encryption in transfer it is necessary to create TLS server certificates. It is common practice to relate server DNS, certificate CN and LDAP CN. For this example the server will be reachable by ldap.genfic.org only over ldaps://. The server certificate will be for exactly this host thus CN=ldap.genfic.org. For TLS see Certificates and Certificates/Become your own CA.

USE flags for net-nds/openldap LDAP suite of application and development tools

`+berkdb`	Add support for sys-libs/db (Berkeley DB for MySQL)
`+cleartext`	Enable use of cleartext passwords
`+syslog`	Enable support for syslog
`argon2`	Enable password hashing algorithm from app-crypt/argon2
`autoca`	Automatic Certificate Authority overlay
`crypt`	Add support for encryption -- using mcrypt or gpg where applicable
`cxx`	Build support for C++ (bindings, extra libraries, code generation, ...)
`debug`	Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
`experimental`	Enable experimental backend options
`gnutls`	Prefer net-libs/gnutls as SSL/TLS provider (ineffective with USE=-ssl)
`iodbc`	Add support for iODBC library
`ipv6`	Add support for IP version 6
`kerberos`	Add kerberos support
`kinit`	Enable support for kerberos init
`minimal`	Build libraries & userspace tools only. Does not install any server code
`odbc`	Enable ODBC and SQL backend options
`overlays`	Enable contributed OpenLDAP overlays
`pbkdf2`	Enable support for pbkdf2 passwords
`perl`	Add optional support/bindings for the Perl language
`samba`	Add support for SAMBA (Windows File and Printer sharing)
`sasl`	Add support for the Simple Authentication and Security Layer
`selinux`	!!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur
`sha2`	Enable support for pw-sha2 password hashes
`smbkrb5passwd`	Enable overlay for syncing ldap, unix and lanman passwords
`ssl`	Add support for SSL/TLS connections (Secure Socket Layer / Transport Layer Security)
`static-libs`	Build static versions of dynamic libraries as well
`systemd`	Enable use of systemd-specific libraries and features like socket activation or session tracking
`tcpd`	Add support for TCP wrappers
`test`	Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently)

Data provided by the Gentoo Package Database · Last update: 2024-09-12 18:37 More information about USE flags

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

root #emerge --ask openldap

OpenLDAP supports two authentication mechanisms:

Standard user-password (in LDAP terms user means binddn) named SIMPLE.
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. This is only limited to the host the server runs on.

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:

root #slappasswd

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

Legacy configuration (flat config slapd.conf)

警告
Do not use this anymore in 2021. It is also not the foundation to be transformed to LDIF with OpenLDAP tools. It will not be translated correctly.

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.

ファイル /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/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

メモ
Don't forget, the second node must use different value of rid and proper address in provider ldapuri.

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:

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

警告
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

警告
The following section is totally unusable and will be improved soon. Instead follow any decent basic LDIF based setup guide tosetup the objectClass: olcGlobal setup objectClass: moduleList, back_mdb.so or back_bdb.la, depending on USE setup objectClass: olcSchemaConfig, nis.ldif and such database config for tree, incl. reader role, denying anonymous reads and so on create a base DN/ objectclass=organization, without it tools like phpldapadmin will not work at all setup organizational units to group objectClass further, sane substructure with Person, Group import relevant Gentoo groups, e.g. wheel, audio, usb, desktop users with these will be rather limited use a tool, even only temporarily, to create one or two more users

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:

ファイル /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, 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.

ファイル /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.

警告
To include additional schemas, flat schema files should be converted into ldif format. Custom scheme must also be converted into ldif format. See openldap.ldif for more detailed description.

警告
{{{1}}}

This initial configuration 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

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

警告
The default configuration does not provide permissions to change the server's configuration to anybody.

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:

ファイル 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.

警告
This database configuration must be added between dn: olcDatabase=frontend,cn=config and dn: olcDatabase=mdb,cn=config, because each part requires the previous to exist and creates a default one if not.

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

ディレクトリを管理する

slapd を始動させましょう:

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

Server management with OLC

メモ
One of the benefits of using OLC-style configuration is that the LDAP server does not require a restart 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):

ファイル 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:

ファイル loglevel.ldif

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

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
SASL SSF: 0
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 standalone server and stats stats2 sync in OpenLDAP cluster. In such case query results logs 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=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:

ファイル /var/log/slapd.log

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:

ファイル /var/log/slapd.log

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)

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

コード 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	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:

ファイル /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:

ファイル 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:

ファイル 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:

ファイル delete_acl.ldif

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

Replication

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.

警告
For normal operation of OpenLDAP cluster upstream recommends to use the same version on all nodes.

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.

Synchronisation account

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

 {SSHA}XvbdAv6rdskp9HgFaFL9YhGkJH3HSkiM

ファイル 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

Enabling syncprov overlay

Overlay can be linked statically and dynamically. When it is built dynamically, you'll need to load module. For now in Gentoo it's usually built statically. To ensure type:

root #/usr/lib64/openldap/slapd -VVV

@(#) $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 syncprov module (optional)

To load syncprov module, use the following ldif file:

ファイル syncprov-module-load.ldif

#Load the syncprov module.
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

Setting up replication for database

Next step, mandatory for everybody, is to setup replication for database (must be done on both nodes):

ファイル syncprov-add-overlay.ldif

# 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

警告
One of poorly-documented feature of ldif-backend is that it doesn't permit file deletion. So, you can add overlay, but cannot remove it.

Final configuration

Finally, add replication's definition.

On node 1:

ファイル add-replication-node1.ldif

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

secret traditionally means the password string.

On node 2:

ファイル add-replication-node2.ldif

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

The only difference is in server's ident (rid) and provider uri.

メモ
You need to load ldap database only on one node of cluster and should not load on another. The database will be replicated automatically after adding quoted definition.

If LDAP master (mirror node with initially loaded database) is unavailable (slapd daemon not started, or 389/tcp port is blocked by a packet filter) slapd daemon on secondary node fails to start with the following error message:

root #tail -f /var/log/slapd.log

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.

Almost certainly the database will not fit into default limits. So, you will need to increase ldapreader's limits. For example:

ファイル add_replicator-limits.ldif

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

警告
Database file note: replicated database size may be significantly different with origin. In my case about 300 megabytes ldif-dump is loaded into almost 900 megabytes mdb-data file and replicated in 1.5 gigabyte mdb-data file.

Performance tuning

Default daemon settings significantly limits LDAP server performance.

Symptoms

When server load fits system limit client applications fails with different kind of timeout errors.

In server log this produces error messages like following:

ファイル /var/log/slapd.log

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)

Increasing OS limits

First, read ldap system user limits:

root #su ldap -c 'ulimit -aHS' -s '/bin/bash'

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

The first parameter, you need to increase, is the open files limit.

Maximum available value is described in Documentation/sysctl/fs.txt file of kernel documentation:

ファイル /usr/src/linux-4.9.95-gentoo/Documentation/sysctl/fs.txt

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.

PAM system limits are stored in /etc/security/limits.conf file or, optionally, in /etc/security/limits.d/ directory. Daemons, started with sys-apps/openrc init system use these parameters (see sys-apps/openrc: start-stop-daemon should use system-services PAM stack for details), so you need just to put in the file:

ファイル /etc/security/limits.conf

ldap           soft    nofile          4096
ldap           hard    nofile          8192

And restart daemon.

警告
For some unknown reasons, upstart init system together with systemd by design ignores system PAM settings i.e. /etc/security/limits.conf file. Users of systemd init in Gentoo please contact me to verify the solution.

The next limitation is sysctl's net.core.somaxconn parameter.

During run time, this value can be updated via:

root #sysctl -w net.core.somaxconn=256

net.core.somaxconn = 256

After verifying new value do not forget to fix it:

ファイル /etc/sysctl.conf

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

And, possibly, some other application-specific parameters.

Configuring the OpenLDAP client tools

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

ファイル /etc/openldap/ldap.conf以下を追加

BASE         dc=genfic, dc=org
URI          ldap://ldap.genfic.org:389/ ldap://ldap-1.genfic.org:389/ ldap://ldap-2.genfic.org:389/
TLS_REQCERT  allow
TIMELIMIT    2

Test the running server with the following command:

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

If errors are received, try adding -d 255 to increase the verbosity and solve the issue.

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

警告
Untested as of 2021

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

ファイル /etc/sssd/sssd.conf

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

ファイル /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 pam_mkhomedir.so to support creating the user home directories.

ファイル /etc/pam.d/system-authEnable pam_sss support

#%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_pwquality.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.

メモ
SSSD method could be used not only for LDAP-authentication, but also to use AD-authentication.

Client PAM configuration the pam_ldap module method

Before starting any change to the client side authentication configuration, make sure that the LDAP server can be reached and presents the correct information. The following steps assume a user Bert Ram was created in the LDAP with login name bertram. Exchange accordingly with a user from the LDAP instance. Use the manager role with caution. But at least check with the LDAP read user role and a user that will logon to the client(s) to be configured:

# Uses the manager role, prompts for Manager's password
# if you can't use the manager role change -D to reader role
ldapsearch -x uid=bertram -H ldaps://ldap.genfic.org -b "dc=genfic,dc=org" -D cn=Manager,dc=genfic,dc=org -W
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Make a member query for the initgroups with the user that will login
# tests also this user's password
ldapsearch -x '({{|}}(&(objectClass=posixAccount)(uid=bertram))({{&}}(objectClass=posixGroup)(memberUid=bertram)))'  -H ldaps://ldap.genfic.org -b "dc=genfic,dc=org" -D "cn=Bert Ram,dc=genfic,dc=org" -W

First, configure PAM to allow LDAP authorization. Install sys-auth/nss-pam-ldapd so that PAM supports LDAP authorization. Then edit /etc/pam.d/system-auth and include the relevant lines so that local login is checked first. This gives safety with at least a local root login and a local user – created during Gentoo installation. Third /etc/nsswitch.conf must be edited to check LDAP in addition to local database and files option. Finally check login on one of the terminals before restarting the client/ logging out root and/ or current user.

メモ
sys-auth/pam_ldap in combination with sys-auth/nss_ldap is an alternative. It requires a globally readable /etc/ldap.conf which is questionable with recent OpenLDAP setups that prohibit anonymous binds. A readable plain text password is as good as anonymous binds. Also code did not change for a long time and some links are dead. Nevertheless it still works. Also ldap.conf on cliet systems may collide with other services.

root #emerge --ask nss-pam-ldapd

Backup this file first. Copy to a safe place (outside /etc) in case you made changes. Make the copy read only, e.g. chmod 444 system-auth.copy. Insert one statement for pam_ldap.so in each of the blocks for auth, account, password and session.

ファイル /etc/pam.d/system-auth

#%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                                                                   #

In /etc/nsswitch.conf each line for passwd, group, shadow and initgroups needs to be prepended with ldap:

ファイル /etc/nsswitch.conf

# Many explanations in comments before...

passwd:         db files ldap
group:          db files ldap
shadow:         db files ldap
initgroups:     db [SUCCESS=continue] files ldap
gshadow:        files

# more statements afterwards

警告
If initgroups lacks ldap as source users logging in with LDAP credentials will have only their primary group. All other groups like wheel, audio, video and so on will be missing.

Now change /etc/nslcd.conf. It should contain

URI to contact LDAP server, use TLS/ ldaps:// by any means, otherwise passwords are transferred unencrypted
Base (general) to lookup DNs
Bind-DN (and secret) since anonymous binds are bad
Base per group, passwd and/ or shadow in case your LDAP tree deviates from defaults (as mentioned in the file's comments)
optional client certificates if you use mutual TLS
mapping for group membership to memberUid if you use primary group with additional groups expressed by membership

メモ
{{{1}}}

警告
Make sure that /etc/nslcd.conf is owned by nslcd and only readable by nslcd through chmod 400.

ファイル /etc/ldap.conf

#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

This is just a note and needs distinction between systemd and OpenRC, start nslcd:

root #/etc/init.d/nslcd start

If the daemon started successfully, change to one of the console terminals. Return to the graphical session by pressing Ctrl+Alt+F7. Switch to one of the 6 login consoles by pressing Ctrl+Alt+F1..F6. At the login prompt, try user bertram.

Convert file userbase to LDAP

メモ
The link is broken. Other Linux distributions provide packages and patches.

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 https://www.padl.com/OSS/MigrationTools.html and fetch the scripts there. You'll need the migration tools and the make_master.sh script.

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

root #mktemp -d

/tmp/tmp.zchomocO3Q

root #

cd /tmp/tmp.zchomocO3Q

root #

tar xvzf /path/to/MigrationTools.tgz

root #

mv /path/to/make_master.sh MigrationTools-47

root #cd MigrationTools-47

The next step now is to migrate the information of the system to OpenLDAP. The make_master.sh script will do this, after it has been provided with the information regarding the 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 the tree.	dc=genfic,dc=org
Mail domain	Domain used in e-mail addresses	genfic.org
Mail host	FQDN of the mail server infrastructure.	smtp.genfic.org
LDAP Root DN	Administrative account information for the 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 which accounts and settings to migrate.

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

トラブルシューティング

Emerge errors after conversion to LDAP

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.

謝辞

このガイドの為に環境を貸してくれた Matt heler に感謝します。また、Libera Chat IRC network の #ldap (webchat) にいる方々に感謝します。

This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Benjamin Coles, Sven Vermeulen (SwifT) , Brandon Hale, Benny Chuang, jokey,
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.