« Formation OpenLDAP » : différence entre les versions
imported>Jules Aucun résumé des modifications |
imported>Jules mAucun résumé des modifications |
||
Ligne 99 : | Ligne 99 : | ||
touch /var/lib/ldap/DB_MONITOR | touch /var/lib/ldap/DB_MONITOR | ||
chown ldap: /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. | Pas d'amélioration après restart du service. | ||
Ligne 123 : | Ligne 127 : | ||
30083 ? Ssl 0:00 /usr/sbin/slapd -h ldap:/// -u 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 [http://readthefuckingmanual.net/error/1256/ 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. | |||
[[Category:LDAP]] | [[Category:LDAP]] | ||
[[Category:Howto]] | [[Category:Howto]] | ||
[[Category:Linux]] | [[Category:Linux]] |
Version du 14 décembre 2010 à 14:46
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.