Outils pour utilisateurs

Outils du site


slapd

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

Penser à installer les outils clients.

La configuration est désormais au format ldap, le fichier 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

ldapsearch -H ldap://server_domain_or_IP -x -LLL -s base -b "" namingContexts

Accès avec authentification SASL/externe

ldapsearch -H ldapi:/// -Y EXTERNAL

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:
slapcat  -f /etc/openldap/migration_schema/include.conf -F /etc/openldap/migration_schema//output/ -n0  -s "cn={10}samba,cn=schema,cn=config"
  • 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:

  1. Supprimer ensuite les 7 dernières lignes du fichiers (attributs structurels)
  2. Modifier le dn, actuellement relatif
  3. Supprimer les {X}

Créer un nouveau schéma

il “suffit” de faire un beau ldif et de l'intégrer. Par exemple:

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

Se référer 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:

EDITOR=vim ldapvi -h ldapi:/// -b cn=config -Y EXTERNAL

Loglevel

Il suffit de rajouter l'attribut olcLogLevel à l'entrée cn=config avec la valeur adéquate. sur Centos il peut être nécessaire de paramétrer et relancer syslog :

[[:vim|vim]]/etc/rsyslog.d/slapd.conf

local4.*     /var/log/ldap.log

Un script logrotate pourrait également être judicieux:

/var/log/ldap {
    missingok
    notifempty
    delaycompress
}

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:
    ldapsearch -LLLH ldapi:/// -Y EXTERNAL -b cn=monitor -s sub 1.1 
  • liste des compteurs pour un objet particulier:
    ldapsearch -H ldapi:/// -Y EXTERNAL -b cn=total,cn=Connections,cn=Monitor  -LLL '*' '+'
  • valeur d'un compteur:
    ldapsearch -H ldapi:/// -Y EXTERNAL -b cn=total,cn=Connections,cn=Monitor -s sub   monitorcounter -LLL
  • 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:

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

 ldap://adresse/dn=branche

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 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 devant réaliser des opérations d'écriture doivent pouvoir accéder au serveur maître, et rediriger les requètes de 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;

  1. d'implémenter un mécanisme d'audit (qui fait quoi):

Il suffit simplement d'inclure le ldif ci-joint

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

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:

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

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:

ldapsearch -xLLL memberof=cn=mongroup,ou=groups,dc=opendoor,dc=fr
...
ldapsearch -xLLL uid=tom memberof

ACL

Pour donner les droits sur un group POSIX (dans notre cas seul les membres du groupe biblio peuvent écrire dans la branche livres) :

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

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:
  1. BDB cache ( cache de blocs disque)
  2. slapd entry cache (cache d'entrée ldap)
  3. 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 generer_un_simple_certificat_auto_signe

ou

pkitool

Attention:

  1. 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
  2. le certificat doit être de type serveur.
  3. 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:
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

ou pour une version d'openldap >=2.4 utiliser le fichier ldif suivant: ssl.ldif

modifier /etc/sysconfig/slapd afin qu'il écoute en ldaps 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

URI ldaps://CommonName
BASE dc=example,dc=org
TLS_CACERT path_to_cacert.pem

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:

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:

576beb11 ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=con

Pour corriger le problème:

  1. installer le paquet perl-Archive-Zip
  2. copier le fichier à problème, sans les 2 1ères lignes:
    tail -n +3  "/etc/openldap/slapd.d/cn=config.ldif" > foo
  3. 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)