Outils pour utilisateurs

Outils du site


slapd

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

slapd [2017/03/29 07:02] (Version actuelle)
Ligne 1: Ligne 1:
 +
 +===== Serveur openldap =====
 +TODO
 +Voir : http://​prefetch.net/​articles/​monitoringldap.html
 +
 +
 +https://​www.digitalocean.com/​community/​tutorials/​how-to-manage-and-use-ldap-servers-with-openldap-utilities?​utm_content=how-to-manage-and-use-ldap-servers-with-openldap-utilities
 +
 +Ça s'​installa facilement à l'aide des paquets adéquats (//​openldap-servers//​ pour RH and co, //slapd// pour [[:​old:​debian|debian]]).
 +
 +Penser à installer les outils [[:​clients|clients]].
 +
 +La configuration est désormais au format ldap, le fichier [[:​slapd|slapd]].conf est désormais obsolète. Ça a le mérite de simplifier le changement de racine, de compte admin et de mot de passe après l'​installation. Il suffit de modifier les fichiers présents dans // /​etc/​openldap/​slapd.conf/​cn=config/​ // et de redémarrer le serveur.
 +
 +Ne pas oublier de créer un fichier //​DB_CONFIG//​ vide dans // /​var/​lib/​ldap/​ //.
 +
 +Ne pas oublier le paramètre de configuration //​checkpoint//​.
 +
 +Penser à dimensionner le //cache// (cachesize) correctement pour de meilleures performances.
 +
 +
 +==== Compiler openldap ====
 +
 +reprequis: gcc make libdb-devel openssl-devel cyrus-sasl-deveG
 +./configure --help
 +./configure
 +make depends
 +make
 +make install ​
 +cd /​usr/​local/​etc/​openldap
 +mkdir slapd.d
 +modifier rootPW dans slapd.conf (utiliser slappaswd pour générer un mot de
 +passe)
 +slapcat -f slapd.conf -F slapd.d -n0 -s cn=config
 +rajouter modifier
 +/​usr/​local/​etc/​openldap/​slapd.d/​cn=config/​olcDatabase={0}config.ldif:​
 +olcAccess: {0}to * by dn=cn=manager,​dc=my-domain,​dc=com manage by * none
 +olcRootDN: cn=manager,​dc=my-domain,​dc=com
 +olcRootPW: {SSHA}Z/​FiyfHMyGOjglNeqgnbymIVzBh+rJPo
 +
 +useradd ldap
 +chown ldap /​usr/​local/​var/​run
 +chown ldap.ldap /​usr/​local/​var/​openldap-data
 +lancer le service: ​
 +usr/​local/​libexec/​slapd -4 -F /​usr/​local/​etc/​openldap/​slapd.d -h ldap:/// -u
 +ldap -g ldap -d -1
 +
 +La mise au point du script d'init est laissé à titre d'​exercice
 +
 +==== Obtenir la racine de l'​arbre ====
 +<​code>​
 +ldapsearch -H ldap://​server_domain_or_IP -x -LLL -s base -b ""​ namingContexts
 +</​code>​
 +
 +==== Accès avec authentification SASL/​externe ====
 +
 +<​code>​
 +ldapsearch -H ldapi:/// -Y EXTERNAL
 +</​code>​
 +
 +==== Modifier le mot de passe root ====
 +
 +Il y a 2 comptes root, un global, et un propre à la principale base de données. Le compte et le mot de passe associé sont représentés par les attributs **olcRootDN** et **olcRootPW**. Ce dernier accepte comme valeur le retour de la commande //​slappasswd//​. Ces attributs sont renseignés :
 +  * dans //​olcDatabase={0}config.ldif//​ pour le compte global (**cn=admin,​cn=config**)
 +  * dans //​olcDatabase={1}bdb.ldif//​ pour le compte admin de la base principale.
 +
 +Il suffit de modifier la valeur de l'​attribut **olcRootPW** et de redémarrer le serveur pour prendre en compte le changement de mot de passe.
 +
 +==== Conversion de schéma ====
 +
 +La migration de la configuration fichiers plats -> base ldap ne se fait pas sans mal. Il est notamment nécessaire de convertir les anciens schémas externes, de la manière suivante:
 +
 +  * créer un fichier //​schema.list//​ recensant toutes les directives //include// du fichier //​slapd.conf//​
 +  * exécuter la commande suivante:
 +<​code>​
 +slapcat ​ -f /​etc/​openldap/​migration_schema/​include.conf -F /​etc/​openldap/​migration_schema//​output/​ -n0  -s "​cn={10}samba,​cn=schema,​cn=config"​
 +</​code>​
 +  * X correspond au n° de la ligne référençant le schéma à migrer dans le fichier //​schema.list//,​ en commençant à **0**.
 +
 +ensuite:
 +  - Supprimer ensuite les 7 dernières lignes du fichiers ​ (attributs structurels)
 +  - Modifier le dn, actuellement relatif
 +  - Supprimer les {X}
 +==== Créer un nouveau schéma ====
 +
 +il "​suffit"​ de faire un beau ldif et de l'​intégrer. Par exemple:
 +
 +<​code>​
 +dn: cn=livre,​cn=schema,​cn=config
 +objectClass:​ olcSchemaConfig
 +cn: livre
 +olcAttributeTypes:​ {0}( 1.3.6.1.4.1.42.0 NAME '​auteur'​ DESC '​auteur du livre' ​ EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX ​  ​1.3.6.1.4.1.1466.115.121.1.15{32768} )
 +olcAttributeTypes:​ {1}( 1.3.6.1.4.1.42.1 NAME '​titre'​ DESC 'titre du livre' ​ EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
 +olcAttributeTypes:​ {2}( 1.3.6.1.4.1.42.2 NAME '​parution'​ DESC 'date de parution du livre' ​ EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
 +olcObjectClasses:​ {0}( 1.3.6.1.4.1.42.2.1 NAME '​livre'​ DESC '​classe d objet livre' SUP top STRUCTURAL MUST ( titre $ auteur ) MAY ( parution ) )
 +</​code>​
 +
 +Se référer [[http://​www.zytrax.com/​books/​ldap/​apa/​types.html|ici ]] pour les types de données utilisables
 +
 +==== Supprimer un schéma personnalisé ====
 +
 +Pas possible autrement qu'en supprimant le fichier correspondant,​ **après avoir arrété le serveur**
 +==== Modifier la configuration ====
 +
 +Elle se fait en modifiant les objets de l'​arbre //​cn=config//​. On évite de toucher aux fichier de /​etc/​openlpdap/​slapd.d,​ sauf éventuellement pour attribuer un mot de passe au compte //​cn=config//​
 +
 +Le mieux est d'​installer [[phpldapadmin]] et de le configurer pour afficher les 2 bases.
 +
 +Ou alors, utiliser //ldapvi//:
 +<​code>​
 +EDITOR=vim ldapvi -h ldapi:/// -b cn=config -Y EXTERNAL
 +</​code>​
 +==== Loglevel ====
 +
 +Il //suffit// de rajouter l'​attribut //​olcLogLevel//​ à l'​entrée //​cn=config//​ avec la valeur adéquate. sur //​[[:​installationcentos|Centos]]//​ il peut être nécessaire de paramétrer et relancer //syslog// :
 +
 +<​code>​
 +[[:​vim|vim]]/​etc/​rsyslog.d/​slapd.conf
 +
 +local4.* ​    /​var/​log/​ldap.log
 +</​code>​
 +
 +
 +Un script logrotate pourrait également être judicieux:
 +<​code>​
 +/​var/​log/​ldap {
 +    missingok
 +    notifempty
 +    delaycompress
 +}
 +</​code>​
 +==== Backends ====
 +
 +Ils sont responsables des opérations de bas-niveau (accès disque) nécessaire à l'​exécution d'une requête LDAP.
 +
 +Pour plus d'​information sur un backend particulier,​ se référer à la page de man adéquate: slapd-BACKENDNAME
 +
 +=== Berkeley DB ===
 +
 +par ordre d'​antériorité
 +  * bdb
 +  * hdb
 +  * mdb (the future)
 +
 +=== back_ldap ===
 +
 +=== Monitor ===
 +info complémentaires:​ http://​www.openldap.org/​doc/​admin24/​monitoringslapd.html
 +
 +Récupération de stats sur l'​état du serveur openldap
 +  * liste des stats dispo: <​code>​ldapsearch -LLLH ldapi:/// -Y EXTERNAL -b cn=monitor -s sub 1.1 </​code>​
 +  * liste des compteurs pour un objet particulier:​ <​code>​ldapsearch -H ldapi:/// -Y EXTERNAL -b cn=total,​cn=Connections,​cn=Monitor ​ -LLL '​*'​ '​+'</​code>​
 +  * valeur d'un compteur: <​code>​ldapsearch -H ldapi:/// -Y EXTERNAL -b cn=total,​cn=Connections,​cn=Monitor -s sub   ​monitorcounter -LLL</​code>​
 +  * affichage de l'​ensemble:​
 +
 +Permet la mise en place de proxy, notamment en load-balancing
 +
 +=== back-ldif ===
 +
 +Backend basse performance. Les données sont stockées dans des fichiers texte au format LDIF
 +
 +==== Annuaires distribués ====
 +
 +biblio: ​
 +  * http://​forums.devshed.com/​ldap-programming-76/​using-openldap-as-an-ad-proxy-with-rtc-895002.html
 +  * http://​lists.arthurdejong.org/​openldap-technical/​2010/​11/​msg00084.html
 +
 +Le principe est de déléguer l'​hébergement d'une branche à un autre serveur.
 +
 +Au niveau de la branche déléguée,​ on met en place un objet de type //​extensibleObject//​ avec un attribut //red// pointant vers l'​adresse du serveur sous la forme <​code>​ ldap://​adresse/​dn=branche</​code>​
 +
 +Au niveau du serveur chargé d'​héberger la sous-branche on peut utiliser la directive //​referral//​ pour indiquer le serveur principal comme //superior knowledge//
 +=== Mot clé ===
 +  * referral
 +  * délégué
 +
 +inconvénient de la méthode: peu de [[:​clients|clients]] sont capable de //chasser les références //
 +
 +biblio: http://​www.zytrax.com/​books/​ldap/​ch8/#​ol-syncrepl-mm
 +
 +un referral consiste à déléguer la gestion d'une partie du DIT à un serveur particulier (par exemple basé sur un découpage géographique)
 +
 +Le suivi de referral peut se faire de manière automatique par le serveur (chaining) ou pas. Dans ce cas il fournit au client la référence au serveur "​suivant"​. C'est à la charge du client de "​suivre"​ ou pas cette référence.
 +
 +Exemple: http://​www.zytrax.com/​books/​ldap/​ch7/​referral-multi.png
 +
 +
 +==== Annuaires répliqués ====
 +
 +Type de réplication: ​
 +  * master (RW) -slave (RO) == provider / consummer
 +Problème de cette archi: les [[:​clients|clients]] devant réaliser des opérations d'​écriture doivent pouvoir accéder au serveur maître, et rediriger les requètes de [[:​perso:​lectures|lectures]] vers le serveur esclave.
 +
 +LE serveur maître est un SPOF
 +
 + * multi-master
 +
 +Illustration:​ http://​www.zytrax.com/​books/​ldap/​ch2/​ldap-replication.png
 +
 +Réplication basée sur syncrepl : 
 +
 +  *refresh ( consumer pull ). Asynchrone, la synchronisation est à l'​initiative du client, à des intervalles prédéfinies. L'​état de la synchronisation est connu via un "​cookie"​ de synchronisation contenant le timestamp de la dernière modification (contextCSN)
 +
 +  * refresh & persist (provider push)
 +Lors de la 1ère connexion, on procède à la synchronisation,​ puis la connexion est maintenue ouverte et tout changement est immédiatement propagé vers le consumer.
 +
 +
 +Dans tous les cas, le //​provider//​ doit implémenter l'​overlay //​syncprov//​ - voir //​replication_master.ldif//​
 +
 +Le //​consumer//​ implémente,​ lui, la directive syncrepl:
 +
 +voir //​replication_slave.ldif//​
 +
 +Réplication syncrepl multi-master
 +
 +** synchronize your clocks ​ first **
 +
 +Dans cette architecture,​ chaque serveur implémente à la fois les directives du provider (syncprov) et les directives du consumer (syncrepl).
 +
 +Chaque serveur dispose également d'un attribut olcserverid unique.
 +
 +voir //​replication_multimaster.ldif//​
 +
 +
 +==== Overlay ====
 +
 +Exe en utilisant auditlog, permettant;
 +  - d'​implémenter un mécanisme d'​audit (qui fait quoi):
 +
 +Il suffit simplement d'​inclure le ldif {{:​formation:​opg:​ldif:​add_auditlog_overlay.ldif|ci-joint}}
 +
 +<​code>​
 +dn: cn=module{0},​cn=config
 +changetype: add
 +objectClass:​ olcModuleList
 +cn: module{0}
 +olcModulePath:​ /​usr/​lib/​openldap/​
 +olcModuleLoad:​ auditlog.la
 +
 +dn: olcOverlay=auditlog,​olcDatabase={2}bdb,​cn=config
 +changetype: add
 +objectClass:​ olcOverlayConfig
 +objectClass:​ olcAuditLogConfig
 +olcOverlay: auditlog
 +olcAuditlogFile:​ /​var/​log/​ldapaudit.log
 +</​code>​
 +
 +**penser à créer le fichier de log // /​var/​log/​ldapaudit.log // et à mettre en place une règle logrotate **
 +
 +=== overlay memberof ===
 +
 +Permet à partir d'un compte utilisateur de récupérer les groupes dont il est membre.
 +
 +Rajouter les directives suivantes:
 +
 +<​code>​
 +dn: cn=module{0},​cn=config
 +changetype: add
 +objectClass:​ olcModuleList
 +cn: module{0}
 +olcModulePath:​ /​usr/​lib/​openldap/​
 +olcModuleLoad:​ memberof.la
 +
 +dn: olcOverlay=memberof,​olcDatabase={2}bdb,​cn=config
 +changetype: add
 +objectClass:​ olcConfig
 +objectClass:​ olcOverlayConfig
 +objectClass:​ olcMemberOf
 +olcOverlay: memberof
 +</​code>​
 +
 +**attention** ça ne marche que pour les nouveaux comptes et groupes !
 +
 +Par défaut les groupes doivent être des //​groupofnames//​ avec des attributs //members// renseignant les //dn// des membres du groupe.
 +
 +Il est désormais possible de faire des requètes du style:
 +<​code>​
 +ldapsearch -xLLL memberof=cn=mongroup,​ou=groups,​dc=opendoor,​dc=fr
 +...
 +ldapsearch -xLLL uid=tom memberof
 +</​code>​
 +==== ACL ====
 +
 +Pour donner les droits sur un group POSIX (dans notre cas seul les membres du groupe biblio peuvent écrire dans la branche livres) :
 +<​code>​
 +dn: olcDatabase={2}hdb,​cn=config
 +changetype: modify
 +delete: olcaccess
 +-
 +add: olcaccess
 +olcaccess: to dn.base=dc=example,​dc=fr by * read
 +-
 +add: olcaccess
 +olcaccess: to dn.sub="​ou=livres,​dc=example,​dc=fr"​ by set="​([uid=] + ([cn=biblio,​ou=groups,​dc=example,​dc=fr])/​memberuid + [,​ou=users,​dc=example,​dc=fr])/​entryDN & user" write by * read
 +-
 +add: olcaccess
 +olcaccess: to * by anonymous auth by * none
 +
 +</​code>​
 +
 +==== Performances ====
 +
 +ref: https://​mishikal.wordpress.com/​2013/​05/​16/​openldap-a-comparison-of-back-mdb-and-back-hdb-performance/​
 +
 +https://​www.vincentliefooghe.net/​content/​tuning-openldap-avec-dbconfig
 +
 +Si on peut travailler entièrement en cache, tant mieux, mais attention, qui dit
 +cache dit mémoire **volatile** !
 +
 +D'​après le guide zytrax l'​utilisation de DB_CONFIG est privilégiée par rapport à la config de slapd.
 +
 +  * 3 caches:
 +   - BDB cache ( cache de blocs disque)
 +   - slapd entry cache (cache d'​entrée ldap)
 +   - IDL (cache des index)
 +Sur des systèmes modernes, les problèmes de performances sont rares.
 +
 +  * choix du backend (bdb par défaut, hdb dans certains cas - par ex accès en écriture plus fréquents- ​
 +  * Utilisation de DBCONFIG
 +  * directives de conf ldap:
 +    * cachesize (nombre d'​entrées à maintenir en mémoire)
 +    * checkpoint
 +    * dbnosync
 +  * directives DBCONFIG
 +    * txn_checkpoint (id olccheckpoint)
 +    * set_cachesize GB MB KB  == taille fichier id2entry.bdb + 10%
 +
 +Déterminer la taille du cache et son utilisation via la commande db_stat -m :
 +  * Total cache size
 +  * Requested pages found in the cache (XX%)
 +  * Clean pages forced from the cache
 +  * Dirty pages forced from the cache
 +  * Current total page count
 +
 +En règle général la taille du cache BDB doit être égal à la somme de la taille
 +des fichiers /​var/​lib/​ldap/​*.bdb + 10%
 +
 +Pour le cache des entrées ldap, si possible le mettre aux nombres d'​entrées
 +présente dans l'​arbre ldap.
 +
 +mettre ​ IDL à 3*cachesize.
 +
 +
 +
 +==== benchmark ====
 +
 +  * loglevel: 256
 +  * olcdbcheckpoint:​ 1024 10
 +  * olcdbcachesize:​ 3000
 +  * nb entrée : 50000
 +  * backend: **hdb**
 +  * temps écoulé: 16m
 +  * 52 entries / sec
 +
 +  * loglevel: 256
 +  * olcdbcheckpoint:​ 1024 10
 +  * olcdbcachesize:​ 3000
 +  * nb entrée : 10000
 +  * backend: **mdb**
 +  * temps écoulé: 5m
 +  * 33 entries/sec
 +
 +  * loglevel: 0
 +  * olcdbcheckpoint:​ 1024 10
 +  * olcdbcachesize:​ 3000
 +  * nb entrée : 5000
 +  * backend: **mdb**
 +  * temps écoulé: 2m47
 +  * 30 entries/sec
 +
 +loglevel has no influence
 + ==== TLS /SSL  ====
 + ​=== ​ Création des certificats:​ ===
 +
 +voir [[:​openssl#​generer_un_simple_certificat_auto_signe]]
 +
 +ou
 +
 +[[:​pkitool]]
 +
 +**Attention**:​
 +  - le //Common Name// du certificat doit être le **nom** du serveur. les alias sont possible en rajoutant la variable **subjectAltName=DNS:​alias1.domain1,​DNS:​host2.domain2,​DNS:​ *.domain3** dans le fichier de configuration //​openssl.cnf//​
 +  - le certificat doit être de type **serveur**.
 +  - vérifier les permissions:​ l'​utilisateur "//​openldap//"​ doit pouvoir lire les différents fichiers pem.
 +
 + ​=== ​ Configuration du serveur: ===
 +  * Copiez le certificat, la clé associée et le certificat de l'​Autorité dans le répertoire ///​etc/​ldap/​certs///​.
 +  * Ajoutez les directives suivantes au fichier ///​etc/​ldap/​slapd.conf//:​
 +
 +<​code>​
 +TLSCACertificateFile ​   /​etc/​ldap/​certs/​cacert.pem ​    # certificat de l'​autorité
 +TLSCertificateFile ​     /​etc/​ldap/​certs/​cert.pem ​      # certificat serveur
 +TLSCertificateKeyFile ​  /​etc/​ldap/​certs/​key.pem ​       # clé associée au ca
 +
 +TLSVerifyClient ​        try
 +
 +Security ssf=128
 +olcTLSCipherSuite:​ TLSv1+RSA:​!NULL
 +</​code>​
 +
 +ou pour une version d'​openldap >=2.4 utiliser le fichier ldif suivant: {{:​formation:​opg:​ldif:​ssl.ldif}}
 +
 +<​del>​modifier // /​etc/​sysconfig/​slapd // afin qu'il écoute en **ldaps**</​del>​ inutile si on reste en TLS
 +
 +olcTLSSecurity permet de forcer l'​utilisation de ssl avec un niveau de chiffrement minimum lors de certaines (ou toutes) opérations. http://​www.zytrax.com/​books/​ldap/​ch6/#​security
 +
 +olcTLSCipherSuite oblige l'​utilisation du chiffrement
 +
 + ​=== ​ Configuration du client: ===
 +  * Copier le certificat de l'​Autorité ( cacert.pem ) dans un endroit commun.
 +  * Modifier le fichier /​etc/​ldap/​ldap.conf:​
 +
 +**Ne pas oublier de supprimer la directive TLS_CACERTDIR et de la remplacer par TLS_CACERT**
 +
 +Si besoin concaténer dans le fichier //​path_to_cacert.pem//​ les clés publiques de toutes les CA
 +
 +<​code>​
 +URI ldaps://​CommonName
 +BASE dc=example,​dc=org
 +TLS_CACERT path_to_cacert.pem
 +</​code>​
 +
 + ​==== ​ Conclusion: ====
 +Cette configuration permet la mise en place d'une connexion cryptée entre le client et le serveur ldap.
 +
 + ​==== ​ Niveau 2: Authentification de tout le monde. ====
 +Pas testé, il devrait suffir de rajouter un certificat et une clé au **client**, de modifier //​ldap.conf//​ en cons"​quence et de changer la directive //​TLSVerifiyClient//​ à "//​demand//"​ dans ///​etc/​ldap/​slapd.conf//​.
 +
 + ​==== ​ bugs et remarques diverses: ====
 +
 +[[:​openssl#​troubleshooting_ssl_issues]]
 +
 +
 +Si vous avez modifié un fichier de conf à la main malgré tous mes avertissements,​ vous obtiendrez au démarrage de slapd (ou via un //​slaptest//​) le message:
 +<​code>​
 +576beb11 ldif_read_file:​ checksum error on "/​etc/​openldap/​slapd.d/​cn=con
 +</​code>​
 +
 +Pour corriger le problème:
 +  - installer le paquet //​perl-Archive-Zip//​
 +  - copier le fichier à problème, sans les 2 1ères lignes: <​code>​tail -n +3  "/​etc/​openldap/​slapd.d/​cn=config.ldif"​ > foo</​code>​
 +  - générer le crc du fichier obtenu et reporter le dans le fichier d'​origine
 +
 +
 +# vim: set filetype=dokuwiki:​
  
slapd.txt · Dernière modification: 2017/03/29 07:02 (modification externe)