Formation OpenLDAP
Installation
Recherche du package:
yum search openldap
Vérification des packages déjà installés:
rpm -qa openldap
ATTENTION on n'a que la partie cliente...
Vérification de la version de noyau
uname -a
Installation du serveur openldap
yum install openldap-servers.x86_64
ATTENTION à cette étape, on n'a pas les commandes clientes ldap*, uniquement les slap*
yum install openldap-clients.x86_64
Configuration initiale
Fichier de configuration slapd.conf
ATTENTION pb: pas de slapd.conf
updatedb locate slapd.conf less /usr/share/openldap-servers/slapd.conf.obsolete cp /usr/share/openldap-servers/slapd.conf.obsolete /etc/openldap/slapd.conf
Edition de /etc/openldap/slapd.conf
Configuration du Root DN et de l'accès Manager
database bdb
suffix "dc=pedrono,dc=fr"
rootdn "cn=Manager,dc=pedrono,dc=fr"
rootpw {SHA}C5wmJdwh7wX2rU3fR8XyA4N6oyw= (toto)
Génération du mot de passe du manager (rootdn) via slappasswd
slappasswd -h {SHA} -T ./pwdfile
ou
slappasswd -h {SHA} (fonctionnement interactif)
Le mot de passe est affichée sur la sortie standard.
Données
Les données sont dans /var/lib/ldap, mais préférer l'utilisation de slapcat pour faire ses sauvegardes en ldif.
Attention, faire des exports ldif réguliers, en particulier avant la mise à jour d'un serveur, car en cas de changement de format bdb, on peut abimer tout l'annuaire et donc devoir le réimporter.
Mise en place d'ACL
Toujours dans slapd.conf:
# On bloque tout pour tout le monde
# Tout est déjà ouvert pour le rootdn puisque pas sujet aux ACL
# On ouvre en lecture pour un eventuel futur utilisateur "admin"
access to *
by dn.exact="cn=admin,dc=pedrono,dc=fr" write
by * none
Droits sur les fichiers
ATTENTION à ce que les données appartiennent bien à ldap et non à root, sinon chown.
Démarrage du service
Mise en place de traces:
tail -f /var/log/messages &
Démarrage du service:
/etc/init.d/slapd start
Warning dans les logs:
[root@kjh openldap]# /etc/init.d/slapd start Vérification des fichiers de configuration pour slapd : [AVERTISSEMENT] bdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (2). Expect poor performance for suffix "dc=my-domain,dc=com". config file testing succeeded Démarrage de slapd : [ OK ]
Ceci est du certainement à de la mise en cache de la part d'openldap sur les fichiers de conf initiaux (cf la référence à dc=my-domain,dc=com).
Tentative:
touch /var/lib/ldap/DB_MONITOR chown ldap: /var/lib/ldap/DB_MONITOR
touch /var/lib/ldap/DB_CONFIG chown ldap: /var/lib/ldap/DB_CONFIG
Pas d'amélioration après restart du service.
Solution: suppression des données du cache:
rm -rf /etc/openldap/cacerts/
Sans effet, autre solution:
rm -rf /var/lib/ldap/*
Après restart du service disparition du warning.
Vérification du démarrage:
[root@kjh openldap]# netstat -tpln ... tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 30083/slapd ...
[root@kjh openldap]# ps fax|grep ldap 30098 pts/1 S+ 0:00 | \_ grep --color=auto ldap 30083 ? Ssl 0:00 /usr/sbin/slapd -h ldap:/// -u ldap
Création d'un domaine
Choix d'un schéma
A moins de partir d'une requête précise sur un schéma précis, le challenge est de choisir un schéma afin d'y piocher nos objectClasses.
[root@kjh openldap]# grep organization /etc/openldap/schema/*|grep objectclass /etc/openldap/schema/core.schema:objectclass ( 2.5.6.4 NAME 'organization' /etc/openldap/schema/core.schema:objectclass ( 2.5.6.5 NAME 'organizationalUnit' /etc/openldap/schema/core.schema:objectclass ( 2.5.6.7 NAME 'organizationalPerson' /etc/openldap/schema/core.schema:objectclass ( 2.5.6.8 NAME 'organizationalRole'
On souhaite créer une organisation donc on peut utiliser l'objectClass "organisation" disponible dans core.schema.
A priori nécessité d'utiliser un objectClass dcObject.
En synthèse, pour tout annuaire à mettre en place, on utilisera une base commune, cf le fichier LDIF ci dessous.
Création du fichier LDIF de création de notre organisation
Création d'un fichier entries.ldif:
dn: dc=pedrono,dc=fr objectClass: dcObject objectClass: organization dc: pedrono o: Pedrono Org description: Organisation Pedrono.fr
Import de ce fichier LDIF via la commande slapadd (initialisation de notre nouvel annuaire/organisation. ATTENTION: ceci nécessite l'arrêt du service slapd).
ATTENTION: si on souhaite modifier ce LDIF après import dans OpenLDAP, nécessité de supprimer et de recréer notre dn/annuaire.
Il est possible de gérer des LDIF de modification de notre annuaire, et de les appliquer par ldapmodify.
ATTENTION: ceci implique:
- qu'il faut historiser ses fichiers LDIF
- idéalement qu'on va gérer un script pour réappliquer tous les LDIF dans le bon ordre en cas de besoin de re création de la structure de l'annuaire.
- NB: il est possible de gérer à la base un LDIF pour l'organisation, plusieurs LDIF pour les OU, etc.
A cette étape, simple tentative de stop puis start du service avant toute entrée du LDIF. On se retrouve avec le même problème qu'au moment du lancement initial:
[root@kjh ~]# /etc/init.d/slapd start Vérification des fichiers de configuration pour slapd : [AVERTISSEMENT] bdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (2). Expect poor performance for suffix "dc=my-domain,dc=com". config file testing succeeded Démarrage de slapd : [ OK ]
Tentative de résolution de ce warning:
[root@kjh ~]# /etc/init.d/slapd stop Arrêt de slapd : [ OK ] [root@kjh ~]# rm -rf /var/lib/ldap/* [root@kjh ~]# touch /var/lib/ldap/DB_CONFIG [root@kjh ~]# chown ldap: /var/lib/ldap/DB_CONFIG [root@kjh ~]# /etc/init.d/slapd start
On a donc résolu à nouveau ce problème de warning.
cf cette page de résolution du problème
ATTENTION: une partie des problèmes peut venir de selinux => désactivation de selinux:
vi /etc/selinux/config ... SELINUX=enforcing (à modifier en disabled) ...
+ redémarrage du système ou setenforce 0 pour désactivation pour la session en cours.
