thÈme technique - administration systÈme -...

Normation – CC-BY-SAnormation.com

THÈME TECHNIQUE - ADMINISTRATION SYSTÈME

OpenLDAP

Astuces pour en fairel'annuaire d'entreprise idéal

Jonathan CLARKE - [email protected]

mailto:[email protected]

Normation – CC-BY-SAnormation.com 2

Qui suis-je ?

● Jonathan Clarke

● Job : Co-fondateur et directeur technique de Normation

● Métier :

– D'abord administration système, gestion d'infrastructures…

– Projets LDAP et gestion d'identités

– Maintenant un peu de tout !!

● Logiciel libre : Contributeur OpenLDAP, CFEngine, LSC, LTB...

ContactsMail : [email protected] : @jooooooon42 (ca fait 7 'o', mais c'est pas ma faute...)



Gestion des identités électroniques en entreprise

De quoi parle-t-on ?


Annuaire LDAP central


● LDAP = Lightweight Directory Access Protocol

● Standard pour communiquer avec et stocker des données dans des annuaires

● Annuaires ? Sorte de base de données objet, hierarchique...

● Bref, « LDAP, c'est compliqué... »



Source : Wikipedia


Problématique


LDAP

● Source unique de « vérité »● Origines des mises à jours multiples et variées● Point central → critique

Authentificationd'applications

Gestion des droits(administrateurs)

Création de comptes(RH)


Objectifs


● Montrer quelques fonctionnalités pas forcément connues

● Donner des exemples concrets de configuration, pour slapd.conf et cn=config

● Retours d'expériences et idées sur la gestion d'un service LDAP en production


1. De quoi parle-t-on ?2. OpenLDAP: présentation et principes3. Intégrité des données4. Architecture réseau et réplication5. Monitoring


Sommaire



OpenLDAP

● Implémentation LDAP de référence

● Open source (licence propre, de type BSD)

● Multi-plateforme

● Écrit en C

● Version majeure actuelle : 2.4

● Contributeurs :

● Créé en 1998 par Kurt Zeilenga

● Core team actuelle :

– Howard Chu, Pierangelo Maserati et Kurt Zeilenga

● Engineering team actuelle :

– 14 membres officiels

● De nombreux contributeurs occasionnels


OpenLDAP

● Un annuaire LDAP parmi d'autres...


OpenLDAP

● Contient 3 composants :

● Un serveur LDAP : slapd

– Outils d'administration côté serveur : slap*

● Des clients LDAP : ldap*

– Lecture : ldapsearch, ldapcompare

– Écriture : ldapadd, ldapmodify, ldapmodrdn, ldapdelete

– Divers : ldappasswd, ldapwhoami, ldapexop

– Utilitaire : ldapurl

● Une librairie LDAP : libldap

– Librairie standard en C


OpenLDAP : architecture du serveur

Frontend

Overlay 1 Overlay nOverlay 2 ...

Backendbdb/hdb

Backendldap/meta

Backendshell/perl

Backendldif

Backendmonitor

BackendSQL

Requête entrante


OpenLDAP : configuration

● Deux formats de configuration :

● slapd.conf – Fichier de configuration « traditionnel »

● cn=config – Base de configuration accessible via LDAP

● Comparaison :

● Édition :

– slapd.conf: éditeur texte (vim, emacs, etc)

– cn=config: client LDAP (ldapsearch/ldapmodify, Apache Directory Studio...)

● Prise en compte des changements :

– slapd.conf: redémarrage du serveur obligatoire

– cn=config: prise en compte à chaud de tous les changements

● Replication :

– slapd.conf: partage de la configuration manuelle seulement

– cn=config: synchronisation possible entre serveurs via syncrepl (clusters, haute-dispo)

● Compatibilité :

– slapd.conf: pourrait être déprécié à l'avenir

– cn=config: considéré comme standard depuis OpenLDAP 2.4



● slapd.conf – Structure et format

# comment - these options apply to every database<global configuration options>

# first database definition & configuration optionsdatabase <database 1 backend type><configuration options specific to database 1>

# subsequent database definitions & configuration optionsdatabase <database 2 backend type>

# add an overlay to database 2overlay <overlay type><configuration options specific to overlay on database 2>



● slapd.conf mappé vers cn=config

cn=config

olcDatabase={-1}frontend

# options apply to every database<global configuration options>

# first databasedatabase <database 1 type><configuration for database 1>

# subsequent databasesdatabase <database 2 type>

# add an overlay to database 2overlay <overlay type><configuration for overlay>

olcDatabase={0}config

olcDatabase={1}bdb

olcDatabase={2}hdb

olcOverlay={0]type


1. De quoi parle-t-on ?2. OpenLDAP : présentation et principes3. Intégrité des données4. Architecture réseau et réplication5. Monitoring


Sommaire



Ce qu'on veut éviter

Intégrité des données



● LDAP impose nécessaire un contrôlé des données grace à son schéma :

● ObjectClasses : définit les types d'attributs autorisés dans chaque objet

● Attributs : définit les valeurs autorisées dans un attribut

● Mais ce n'est pas toujours suffisant !

● Aller plus loin :

● Imposer l'unicité de valeurs à travers l'annuaire (UID, mail...)

● Mettre à jour les références (retirer un utilisateur supprimé de ses groupes...)

● Affiner les valeurs autorisées par attribut (liste de choix...)



● “unique” overlay

● Principe : interdire de créer des valeurs identiques à d'autres déjà existantes

● Rappel : LDAP URIs

– ldap:///[base dn]?[attributes...]?scope[?filter]

– Base DN defaults to current database baseDN

● Configuration :

– Définir une recherche par URI qui renvoie les attributs censés être uniques

● Exemples :

overlay uniqueunique_uri ldap:///?uid?sub?

dn: olcOverlay={0}unique,olcDatabase={1}bdb,cn=configobjectClass: olcOverlayConfigobjectClass: olcUniqueConfigolcUniqueURI: ldap:///ou=people,o=training?mail?sub?

ldap:///?uid?sub



● “refint” overlay

● Principe : liens entre objets (attributs de type DN) mis à jour en cas de changement de l'objet pointé

● Configuration :

– Définir les attributs dans lesquels on cherche lors des renommage ou suppression

● Exemples :

overlay refintrefint_attribute managerrefint_attribute secretary

dn: olcOverlay=refint,olcDatabase={1}bdb,cn=configobjectClass: olcOverlayConfigobjectClass: olcRefintConfigOlcRefintAttribute: managerOlcRefintAttribute: secretary



● “memberof” overlay

● Principe : lien dans les fiches personne vers les groupes dont ils sont membres

● Configuration :

– Minimum : activation + inclusion schéma

– Optionnel : changement des types de groupes, nom de l'attribut memberOf, etc...

● Exemples :

overlay memberof

dn: olcOverlay=memberof,olcDatabase={1}bdb,cn=configobjectClass: olcOverlayConfigobjectClass: olcMemberofConfig



● “constraint” overlay

● Principe :

– Impose des règles plus strictes que le schéma sur les valeurs d'attributs

● Possibilités :

– Par expression régulière (mail ~= ^[[:alnum:]][email protected]$)

– Limites de longeur (photo de 100 ko max)

– Limite de nombre de valeurs (userPassword multi-valué mais limité à 1 password)

– Par recherche de valeurs dans l'annuaire (service = un des services définis)

– Par règles de correspondance (cn = givenName + " " + sn)● Syntaxe « set » des ACL



● “constraint” overlay

● Configuration :

– Activation + définition des règles

● Exemples :

overlay constraintconstraint_attribute mail regex ^[[:alnum:]][email protected]$constraint_attribute service uri ldap:///ou=services,dc=example,dc=com?cn?sub?(objectClass=service) restrict="ldap:///ou=People,dc=example,dc=com??sub?(objectClass=person)"

dn: olcOverlay=constraint,olcDatabase={1}bdb,cn=configobjectClass: olcOverlayConfigobjectClass: olcConstraintConfigOolcConstraintAttribute: jpegPhoto size 131072olcConstraintAttribute: userPassword count 1



● Attention !

● Limitation de cette approche :

● Les overlays n'interceptent que les nouvelles opérations...

● Ils ne corrigeront pas les donneés déjà présentes dans l'annuaire !




Sommaire



Réplication

● C'est quoi la réplication ?

● Reproduire à l'identique tout ou partie du contenu d'un annuaire, de manière périodique ou en continu

● Aucune modification ni transformation des données ne peut être apportée lors d'une réplication

– Il s'agit là de synchronisation

– Pour les annuaires LDAP, voir le projet Ldap Synchronization Connector (LSC)


Réplication

● Le mécanisme historique : slurpd

● Présent jusqu'en OpenLDAP 2.3, déprécié en 2.4

● Le serveur OpenLDAP était configuré pour écrire toutes les modifications dans un journal

● Le démon slurpd tournait en parallèle et prenait chaque modification et l'appliquait à chaque esclave, grace à un compte administrateur

● Plusieurs inconvénients :

– Mécanisme fragile : désynchronisations régulières et difficiles à détecter

– Fort couplage de configuration maîtres-esclaves


Réplication

● Le mécanisme syncrepl

● Officiellement "LDAP Sync Replication"

● Syncrepl est normalisé par l'IETF : RFC 4533

● Plusieurs implémentations :

– Serveurs LDAP : OpenLDAP et ApacheDS

– Clients : outils de synchronisation, API Java UnboundID

● Fonctionnement nominal par entrée complète :

– Si un attribut a changé, l'entrée complète est répliquée

● delta-syncrepl : réplication par attribut

– Nécessite une base externe pour stocker les modifications

– Spécifique OpenLDAP

– Non-compatible avec les modes multi-maître


Réplication

● Réplication simple maître-esclave

● Réplication maître-maître

● Depuis OpenLDAP 2.4 avec syncrepl

● Aucun avantage de répartition de charge !

● Utile pour la haute disponibilité

● Aucune garantie de réplication !

● Synchronicité des changements

– Avec syncrepl, les entrées sont répliquées entièrement

– Avec syncrepl, l'entrée la plus récemment modifiée "gagne"

– Si deux changements sur une même entrée sont réalisées en "peu de temps" (avant que la réplication ait pu se faire), un changement sera perdu !

● Acceptable ou non selon le fonctionnement de votre application...


Réplication serveur-client




Sommaire



Monitoring

● Supervision à plusieurs niveaux :

● Supervision spécifique LDAP

● Supervision système standard (non spécifique LDAP)

– Indicateurs classiques du serveur :● ping● espace disque● charge● mémoire disponible● etc...

– Indicateurs système pertinents pour OpenLDAP :● Disponiblité du service LDAP (vérification simple sur port TCP 389)● Tracer l'évolution de la taille sur disque du répertoire de données● Tracer l'évolution du nombre de connexions TCP ouvertes


Monitoring


● Disponibilité du service LDAP par vérification LDAP

– Recherche simple pour valider que le serveur répond

– Recherche avec authentification pour valider le service d'authentification

– Modification d'un attribut de test sur une entrée de test pour valider le service d'écriture

– Compte du nombre d'entrées modifiées dans la dernière heure/journée pour valider les services très sollicités

– Plugins Nagios disponibles sur LTB Project :● http://ltb-project.org/wiki/documentation/nagios-plugins/check_ldap_dn● http://ltb-project.org/wiki/documentation/nagios-plugins/check_ldap_query

http://l tb-project.org

http://ltb-project.org/wiki/documentation/nagios-plugins/check_ldap_dn

http://ltb-project.org/wiki/documentation/nagios-plugins/check_ldap_query


Monitoring


● Temps de réponse du service LDAP par vérification LDAP

– Calcul du temps de réponse moyen d'une recherche simple

– Plugin Nagios disponible sur LTB Project :● http://ltb-project.org/wiki/documentation/nagios-plugins/check_ldap_time

– Plugin Cacti disponible sur LTB Project :● http://ltb-project.org/wiki/documentation/cacti-plugins/ldap_response_time

http://ltb-project.org/wiki/documentation/nagios-plugins/check_ldap_time

http://ltb-project.org/wiki/documentation/cacti-plugins/ldap_response_time


Monitoring


● État de la réplication LDAP entre plusieurs serveurs

– Validation que les serveurs esclaves ont le même niveau de synchronisation que le maître

● Adaptable au multi-maître avec des vérifications croisées

– Plugin Nagios disponible sur LTB Project :

– http://ltb-project.org/wiki/documentation/nagios-plugins/check_ldap_syncrepl_status

http://ltb-project.org/wiki/documentation/nagios-plugins/check_ldap_syncrepl_status


Monitoring


● Statistiques d'utilisation obtenues dans cn=monitor

– cn=monitor est un backend spécial qui rend accessible des statistiques sur l'utilisation et la configuration d'OpenLDAP par une interface LDAP

● Opérations effectuées (tracer dans le temps)

– Recherches, Ajouts, Modifications, Suppressions...– Plugin Cacti disponible sur LTB Project :

● http://ltb-project.org/wiki/documentation/cacti-plugins/openldap_operations

● Taille des caches BerkeleyDB (backend bdb, hdb)

http://ltb-project.org/wiki/documentation/cacti-plugins/openldap_operations


Monitoring

● Résumé supervision :

● La disponibilité du service est un minimum– Disponibilité au sens LDAP (pas que TCP) car OpenLDAP a souvent souffert

de bugs où le port TCP est ouvert mais non fonctionnel...

● Les statistiques d'utilisations (graphiques d'évolution au cours du temps) sont très utiles pour analyser et prévoir les problèmes

– Lorsqu'un incident survient,pouvoir voir l'évolutionrécente de l'usage

– Prévoir les dépassementsde capacité


Récapitulons

● Nombreuses fonctionnalités via des overlays

– Souvent simples à configurer

● Des outils hors du projet OpenLDAP

● Architecture réseau et supervision à adapter...comme pour tout service critique

http://l tb-project.org

Normation – CC-BY-SAnormation.com

Questions ?

thÈme technique - administration systÈme -...

Documents