Formation OpenLDAP : Différence entre versions
m |
|||
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.