Authentification centralisée avec OpenLDAP

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Centralized authentication using OpenLDAP and the translation is 39% 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.

Ce guide introduit les bases de LDAP et montre au lecteur comment configurer OpenLDAP pour des besoin d'authentification dans un groupe d'ordinateurs.

Attention !
L'état actuel n'amène pas à une configuration fonctionnelle. Voir Talk:Centralized_authentication_using_OpenLDAP pour les détails. Travail en cours.

Démarrer avec OpenLDAP

Qu'est-ce que LDAP ?

LDAP signifie Lightweight Directory Access Protocol (Protocole Allégé pour accès à des annuaires). Basé sur X.500 il couvre la plupart de ses fonctions primaires, mais ne possède pas ses fonctions les plus ésotériques. Maintenant, qu'est-ce que ce X.500 et pourquoi LDAP existe-t-il ?

X.500 est un modèle pour les services d'annuaires dans de concept OSI. Il comprend des définitions d'espaces de noms et les protocoles pour interroger et mettre à jour l'annuaire. Néanmoins, X.500 s'est avérer être surdimensionné dans maintes situations. C'est là qu'entre en scène LDAP. Comme X.500 il procure un modèle données/espace de noms pour l'annuaire et un protocole. Cependant, LDAP est conçu pour tourner directement au-dessus de la pile TCP/IP. Considérez LDAP comme une version allégée de X:500.

Je n'ai pas saisi. Qu'est-ce qu'un annuaire ?

Un annuaire est une base de données spécialisée conçue pour des interrogations fréquentes mais avec des mises à jour moins fréquentes. Au contraire des bases de données générales, il ne comprend pas de prise en charge des transactions ou de fonctionnalités de retour en arrière. Les annuaires sont facilement répliqués pour en augmenter la disponibilité et la fiabilité. Lorsque les annuaires sont répliqués, des incohérences temporaires sont autorisées jusqu'à ce qu'elles soient synchronisées à la fin.

Comment l'information est-elle structurée ?

Toutes les informations dans un annuaire sont organisées de manière hiérarchisée. Même plus, si vous voulez entrer des données dans un annuaire, cet annuaire doit savoir comment ranger ces informations dans un arbre. Jetons un coup d'œil à une société imaginaire et un arbre similaire à Internet :

CODE Structure de l'organisation de GenFic, une communauté Gentoo imaginaire
dc:         org
           |
dc:        genfic         ## (Organisation)
          /      \
ou:   People   servers    ## (Unités d'organisation (UO) )
      /    \     ..
uid: ..   John            ## (données spécifiques d'UO )

Comme vous n'entrez pas les données dans la base de données de cette façon ascii-artistique, chacun des nœuds d'un tel arbre doit être défini. Pour nommer de tels nœuds, LDAP utilise un schéma de nommage. La plupart des distributions LDAP (y compris OpenLDAP) contiennent déjà un certain nombre de schémas prédéfinis (et largement approuvés), tels que l'inetOrgPerson, un schéma fréquemment utilisé pour définir les utilisateurs que des machines Unix/Linux peuvent utiliser, appelés posixAccount (comptes posix). Notez qu'il existe des interfaces graphiques basées sur le web pour faciliter la gestion de LDAP : reportez-vous à travailler avec OpenLDAP pour une liste non exhaustive.

Les utilisateurs intéressés sont encouragés à lire le guide d'administration de OpenLDAP .

D'accord... Mais à quoi ça sert ?

LDAP peut être utilisé pour différentes choses. Ce document est centré sur la gestion centralisée d'utilisateurs, en conservant tous les comptes utilisateur dans un emplacement LDAP unique (ce qui ne veut pas dire qu'il est hébergé sur un serveur unique, LDAP prenant en charge une haute disponibilité et la redondance), bien que d'autres objectifs peuvent être atteints en utilisant LDAP également.

  • Infrastructure de clés publiques
  • Calendrier partagé
  • Carnet d'adresses partagé
  • Espace de stockage pour DHCP, DNS, ...
  • Directives de configuration des classes système (conserver la trace de la configuration de plusieurs serveurs)
  • Authentification centralisée (PosixAccount)
  • ...

Configurer le serveur OpenLDAP

Remarques générales

Le domaine genfic.org est un exemple dans ce guide. Le domaine peut être modifié pour s'adapter au cas du lecteur. Cependant, assurez vous que le noeud racine est bien un top level domain officiel (.net, .com, .cc, .be, ...). Comme LDAP ne permet pas le chiffrement des transferts, il est nécessaire de créer des certificats TLS de serveur. C'est une pratique courant d'utiliser conjointement un serveur DNS, un certificat CN et LDAP CN. Pour cet exemple le serveur est accessible par ldpa.genfic.org seulement via ldaps://. Les certificats serveur seront exactement ceux de cet hôte, donc CN=ldap.genfic.org. Pour TLS, voir certificats et Devenez votre propre autorité de certification.

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

Commencez par installer OpenLDAP. Assurez-vous que les options de la variable USE, syslog, -minimal (désactivé) et tcpd sont utilisés.

root #emerge --ask net-nds/openldap

OpenLDAP prend en charge deux mécanismes d'authentification

  1. Le mot de passe utilisateur standard (dans le jargon LDAP "utilisateur" signifie "binddn") est nommé SIMPLE.
  2. Envoi de demandes d'authentification par proxy à SASL (Simple Authentication and Security Layer, voir RFC4422 pour plus de détails)

Bien que le comportement par défaut d'OpenLDAP est d'utiliser SASL, la version initiale de cet article n'utilisait qu'une authentification basée sur un mot de passe. Avec le complément OLC, l'article commence à décrire l'utilisation du mécanisme SASL le plus simple, appelé EXTERNAL, qui repose sur l'authentification du système. Ce système d'authentification est limité à l'hôte sur lequel le serveur est lancé.

OpenLDAP posède un utilisateur principal appelé "rootdn" (Root Distinguished Name), qui est en dur dans l'application. Contrairement à l'utilisateur root Unix, l'utilisateur rootdn a besoin d'avoir les bonnes permissions. L'utilisateur rootdn ne devrais être utilisé que pour la configuration, mais il peut aussi être utilisé pour définir les répertoires. Dans ce cas, un utilisateur peut s'authentifier en tant que rootdn avec le mot de passe utilisé pour la configuration et le mot de passe de l'arborescence (basé sur le répertoire).

Les mots de passe utilisateurs (que ce soit pour les utilisateurs rootdn ou les autre) peuvent être stockés en clair ou hashé pour permettre leur vérification. Plusieurs système de hash sont disponibles, mais l'utilisation d'algorithmes faibles (Les algorithmes jusqu'à MD5) n'est pas recommandé. SHA est actuellement considéré comme suffisamment sécurisé.

Dans la commande suivante, une valeur hashée est créé pour un mot de passe donné; le résultat de cette commande peut être utilisé dans le fichier de configuration slapd.conf, ou dans l'entrée du répertoire d'un utilisateur :

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

Configuration historique (fichier de configuration slapd.conf plat)

Attention !
N'utilisez plus cette méthode en 2021. Ce n'est pas non plus la base à transformer en LDIF avec les outils OpenLDAP. Elle ne sera pas traduite correctement.

Éditez maintenant la configuration du serveur LDAP dans /etc/openldap/slapd.conf. Le fichier de configuration slapd.conf provient des sources originales de openLDAP. Ci-dessous, nous donnons un exemple de fichier de configuration pour le remplacer et démarrer.

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/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 hdb
suffix "dc=genfic,dc=com"
checkpoint 32 30
rootdn "cn=Manager,dc=genfic,dc=com"
## ## 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
  provider=ldap://ldap2.genfic.com
  type=refreshAndPersist
  retry="5 5 300 +"
  searchbase="dc=genfic,dc=com"
  attrs="*,+"
  bindmethod="simple"
  binddn="cn=ldapreader,dc=genfic,dc=com"
  credentials="ldapsyncpass"
 
index entryCSN eq
index entryUUID eq
 
mirrormode TRUE
 
overlay syncprov
syncprov-checkpoint 100 10
Remarque
N'oubliez pas, le second nœud doit utiliser une valeur différente pour rid et la bonne adresse dans le provider ldapuri.

Pour une analyse plus détaillée du fichier de configuration, nous vous suggérons d'utiliser de le Guide de l'administrateur de OpenLDAP project's documentation page ou alors la page de manuel man 5 slapd.conf qui peut être suffisante.

Si le programme ne démarre pas, la première étape est de vérifier le fichier de configuration.

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

Jouez sur le niveau de déverminage (le -d 1 ci-dessus) pour plus d'informations. Si tout se passe bien, vous verrez config file testing succeeded. Si une erreur s'est produite, slaptest indiquera le numéro de ligne (du fichier slapd.conf ) à laquelle elle s'applique.

Par défaut slapd écrit les journaux d'évènements dans le dispositif syslog local4.

Attention !
Notez que depuis la verison 2.4.23, la configuration par défaut OpenLDAP a finalement été changée d'un fichier de configuration plat (slapd.conf) pour une configuration OLC (OnLineConfiguration, aussi connue à travers la structure cn=config). Un des bénéfice de l'utilisation d'OLC est que la mise à jour de la configuration dans le backend dynamique (cn=config) peut se faire sans redémarer le serveur. Les utilisateurs existants peuvent migrer vers la nouvelle méthode de configuration en invoquant slaptest en utilisant à la fois les options f et -F Traditionnelemnt OLC est stocké dans un backend ldif (qui permet de conserver un format lisible par l'homme) dans le dossier /etc/openldap/slapd.d. Dans gentoo il n'est pas encore requis de convertir la configuration, mais le support pour cette approche documentée va être retiré dans le futur.

Migration depuis slapd.conf vers OLC

Attention !
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:

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.

Pour plus d'instruction, reportez-vous aux commentaires en ligne des fichiers générés.

La ligne ci-dessous activera la méthode de configuration slapd.d/.

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

Pour finir, créez la structure /var/lib/openldap-data :

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

Configuration initiale avec OLC

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

Attention !
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.
Attention !
{{{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.

Attention !
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:

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.

Attention !
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

Maintenir l'annuaire

Start slapd:

root #/etc/init.d/slapd start

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

root #rc-update add slapd

Vous pouvez commencer à utiliser l'annuaire pour l'authentification des utilisateurs dans apache/proftpd/qmail/samba. Vous pouvez le gérer avec LAM (Ldap Account Manager), phpldapadmin, diradm, jxplorer, ou lat, qui procurent des interfaces de gestion conviviales.

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

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

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

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"
Attention !
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:

FILE /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:

FILE /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:

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

Attention !
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}

Réplication

Haute disponibilité

Pour configurer la réplication des changements à travers de multiples systèmes LDAP. Le réplication avec OpenLDAP est, dans ce guide, configurée en uilisant un compte dédié à la réplication ( ldapreader ) qui a des droits de lecture et écriture sur le serveur LDAP primaire et qui tire les changements du serveur primaire vers le serveur secondaire.

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.

Cette configuration est ensuite réfléchie, autorisant le serveur LDAP secondaire à fonctionner comme serveur primaire. Grâce à la structure interne d'OpenLDAP, les changements ne sont pas ré-appliqués s'ils sont déjà dans la structure LDAP.

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

Configurer la réplication

Pour configurer la réplication, commencez par configurer un deuxième serveur OpenLDAP, de façon similaire à ce qui a été décrit ci-dessus. Néanmoins, assurez-vous que dans le fichier de configuration :

  • sync replication providerpointe sur other system.
  • L'identifiant (serverID) est différent pour chacun des serveurs OpenLDAP.
Remarque
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

Créez ensuite le compte de synchronisation. Créez un fichier LDIF (le format utilisé en tant que données d'entrée pour les serveurs LDAP) et ajoutez le à chaque serveur LDAP.

user $slappasswd -s myreaderpassword
 {SSHA}XvbdAv6rdskp9HgFaFL9YhGkJH3HSkiM
FILE ldapreader.ldif
dn: cn=ldapreader,dc=genfic,dc=com
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: ## entrez le mot de passe d'administration
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
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Included static overlays:
    syncprov
Included static backends:
    config
    ldif
    bdb
    hdb
Load syncprov module (optional)

To load syncprov module, use the following ldif file:

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

FILE 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
Attention !
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:

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

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

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

FILE 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
Attention !
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:

FILE /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:

FILE /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:

FILE /etc/security/limits.conf
ldap           soft    nofile          4096
ldap           hard    nofile          8192

And restart daemon.

Attention !
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:

FILE /etc/sysctl.conf
## For LDAP:
net.core.somaxconn = 256

And, possibly, some other application-specific parameters.

Configurer les outils client d'OpenLDAP

Éditez les fichiers de configuration du client LDAP. Ce fichier est lu par ldapsearch et les autres outils en ligne de commande de ldap.

FILE /etc/openldap/ldap.confAdd the following
BASE         dc=genfic, dc=com
URI          ldap://ldap.genfic.com:389/ ldap://ldap1.genfic.com:389/ ldap://ldap2.genfic.com:389/
TLS_REQCERT  allow
TIMELIMIT    2

Nous pouvons tester le serveur en service à l'aide de la commande suivante :

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

Si vous obtenez une erreur, essayez d'ajouter -d 255 pour augmenter la verbosité et résoudre votre problème.

Configuration du client pour une authentification centralisée

Il existe de nombreuses méthodes ou de nombreux outils à utiliser pour une authentification à distance. Quelques distributions disposent également de leur propre outil convivial de configuration. Ci-dessous, nous en présentons quelques uns sans ordre particulier. Il est possible des combiner des comptes d'utilisateurs locaux et des comptes autorisés de manière centralisée en même temps. Ceci est important parce que, par exemple, si le serveur LDAP n'est pas accessible, on peut toujours se connecter en tant qu'utilisateur root.

  • SSSD (Single Sign-on Services Daemon). Son premier rôle est de fournir un accès à une identité et à une ressources distante d'authentification à travers une structure commune qui assure la mise en cache et une assistance hors ligne au système. IL fournit des modules PAM et NSS, et dans le futur prendra en charge les interfaces D-Bus pour une information utilisateur étendue. Il procure aussi une base de données meilleure pour stocker les utilisateurs locaux et des données utilisateur étendues.
  • Utilise pam_ldap pour se connecter au serveur LDAP et s'authentifier. Les mots de passe ne sont pas envoyés en clair sur le réseau.
  • NSLCD (Name Service Look up Daemon ou démon de service de recherche de nom). Similaire à SSSD, mais plus ancien.
  • NSS (Name Service Switch ou commutateur de service ). Il utilise le module pam_unix traditionnel pour aller chercher les hachages des mots de passe sur le réseau. Pour permettre aux utilisateurs de mettre leur mot de passe à jour, ceci doit être combiné avec la méthode pam_ldap.

Les deux premiers sont démontrés ci-après avec les options minimales de configuration pour que ça fonctionne.

Configuration PAM du client par la méthode SSSD

Attention !
Untested as of 2021

Voici une méthode plus directe. Les trois fichiers à éditer sont indiqués ci-dessous :

FILE /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=com
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


Ajoutez sss à la fin comme indiqué ci-dessous pour activer la recherche par le service système sssd. Une fois que vous avez terminé l'édition, démarrez le démon sssd.

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

Le dernier fichier est le plus critique. Ouvrez un terminal root supplémentaire en tant que secours avant d'éditer cela. Les lignes qui terminent avec # ont été ajoutées pour activer l'authentification à distance. Notez l'utilisation de pam_mkhomedir.so pour la prise en charge de la création des répertoire home des utilisateurs.

FILE /etc/pam.d/system-authActiver la prise en charge pam_sss
#%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     am_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                                                        #

Maintenant essayez de vous connecter depuis une autre machine.

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

Configurer le PAM client par la méthode du module pam_ldap

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

Tout d'abord, vous allez configurer PAM pour permettre l,autorisation LDAP. Installezsys-auth/pam_ldap afin que PAM prenne en charge l'autorisation LDAP, et sys-auth/nss_ldap afin que votre système puisse coopérer avec les serveurs LDAP pour une information additionnelle (utilisée par nsswitch.conf ).

Remarque
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

Le dernier fichier est le plus critique. Ouvrez quelques terminaux root en tant que secours avant d'éditer ces lignes. Les lignes en gras ont été ajoutées pour activer l'authentification à distance.

FILE /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:

FILE /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
Attention !
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.

Maintenant changez /etc/nslcd.conf. Il doit contenir :

  • 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
Remarque
{{{1}}}
Attention !
Make sure that /etc/nslcd.conf is owned by nslcd and only readable by nslcd through chmod 400.
FILE /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.

Migrer des données existantes vers ldap

Remarque
Ce lien est cassé. Les autre distributions linux fournissent des patchs et des paquets.

Configurer OpenLDAP pour une administration centralisée et la gestion d'items Linux/Unix communs n'est pas chose facile, mais grâce à quelques outils et scripts disponibles sur Internet, migrer un système conçu pour être administré en tant que système unique vers un système à gestion centralisée basé sur LDAP n'est pas difficile.

Rendez-vous sur https://www.padl.com/OSS/MigrationTools.html et recherchez-y les scripts. Vous avez besoin des outils de migration et du script make_master.sh.

Ensuite, extrayez les outils et copiez le script make_master.sh dans l'emplacement d'extraction :

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

L'étape suivante est maintenant de migrer les informations de votre système vers OpenLDAP. Le script make_master.sh le fera pour vous, après que vous lui ayez fourni l'information concernant votre structure LDAP et votre environnement.

Au moment de l'écriture, les outils ont besoin des entrées suivantes :

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

L'outil vous demandera aussi quels comptes et quelles configurations vous voulez migrer.

Attention !
Il n'est pas nécessaire de changer pam.d/system-auth

Troubleshooting

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.

Remerciements

Nous tenons à remercier Matt Heler qui nous a prêté sa machine pour réaliser ce guide. Merci aussi aux gars très compétents de #ldap (webchat) sur le réseau IRC Libera Chat.

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.

Retrieved from "https://wiki.gentoo.org/index.php?title=Centralized_authentication_using_OpenLDAP/fr&oldid=1292508"