Formation OpenLDAP : Différence entre versions
Ligne 516 : | Ligne 516 : | ||
# numEntries: 4 | # numEntries: 4 | ||
</pre> | </pre> | ||
+ | |||
+ | == Ajout d'entrées dans l'annuaire == | ||
+ | |||
+ | === Ajout d'utilisateurs === | ||
+ | |||
+ | Création d'un fichier LDIF pour la création des utilisateurs, qu'on ratachera à l'OU ''utilisateurs''. | ||
+ | |||
+ | Détermination des ''objectClass'': chercher quelque chose du style "account" ou "ccount" dans les schémas. | ||
+ | |||
+ | Plusieurs schémas peuvent correspondre, il faut faire un choix à cette étape. | ||
+ | |||
+ | Si on souhaite utiliser l'annuaire pour l'authentification linux, on va pouvoir choisir l'''objectClass'' '''posixAccount''' du schéma ''nis''. | ||
+ | |||
+ | '''ATTENTION:''' quand on sélectionne un objectClass, on ne peut pas n'utiliser qu'un objectClass AUXILIARY. | ||
+ | |||
+ | Ex: | ||
+ | objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' | ||
+ | DESC 'Abstraction of an account with POSIX attributes' | ||
+ | '''SUP top AUXILIARY''' | ||
+ | MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) | ||
+ | MAY ( userPassword $ loginShell $ gecos $ description ) ) | ||
+ | |||
+ | Il faut utiliser un ''objectClass'' qui soit de type '''STRUCTURAL'''. Par exemple posixGroup dans notre cas, si on ne souhaite pas mélanger les objectClass de schémas différents. | ||
+ | |||
+ | Contenu d'un bloc du LDIF: | ||
+ | <pre> | ||
+ | dn: uid=pierre,ou=utilisateurs,dc=pedrono,dc=fr | ||
+ | objectClass: posixAccount | ||
+ | objectClass: posixGroup | ||
+ | cn: Pierre Pierre | ||
+ | uid: pierre | ||
+ | uidNumber: 1000 | ||
+ | gidNumber: 100 | ||
+ | homeDirectory: /home/pierre | ||
+ | userPassword: $6$cz.MqrGuUVHz4yZG$6dOJYgmEJ8h6Tn0r.sYHPYrX.uM3xDH7xV7wTiq3OWOdtZnXXEkkVMG6inFjAyACNriflQdo.g.2Ejlig0CXR0 | ||
+ | loginShell: /bin/bash | ||
+ | description: Pierre de la compta | ||
+ | </pre> | ||
+ | |||
+ | Le fichier contenant les 4 utilisateurs créés est ''utilisateurs.ldif''. | ||
+ | |||
+ | Import des utilisateurs, on respecte la logique habituelle: | ||
+ | * arrêt du service | ||
+ | * ''slapadd'' | ||
+ | * démarrage du service | ||
+ | |||
+ | '''ATTENTION:''' une fois de plus comme on travaille en root, on crée des fichier bdb appartenant à root dans /var/lib/ldap, il ne faut donc pas oublier le ''chown ldap: /var/lib/ldap/*'' avant de démarrer le service. | ||
+ | |||
+ | /etc/init.d/slapd stop | ||
+ | slapadd -l /root/conf_ldap/utilisateurs.ldif | ||
+ | chown ldap: /var/lib/ldap/* | ||
+ | /etc/init.d/slapd start | ||
+ | |||
+ | Vérification du résultat: | ||
+ | |||
+ | <pre> | ||
+ | [root@kjh conf_ldap]# ldapsearch -x -b 'ou=utilisateurs,dc=pedrono,dc=fr' -D 'cn=Manager,dc=pedrono,dc=fr' -W | ||
+ | Enter LDAP Password: | ||
+ | # extended LDIF | ||
+ | # | ||
+ | # LDAPv3 | ||
+ | # base <ou=utilisateurs,dc=pedrono,dc=fr> with scope subtree | ||
+ | # filter: (objectclass=*) | ||
+ | # requesting: ALL | ||
+ | # | ||
+ | |||
+ | # utilisateurs, pedrono.fr | ||
+ | dn: ou=utilisateurs,dc=pedrono,dc=fr | ||
+ | objectClass: organizationalUnit | ||
+ | ou: utilisateurs | ||
+ | postalCode: 44000 | ||
+ | description: Unite organisationnelle des utilisateurs de Pedrono Organisation | ||
+ | |||
+ | # pierre, utilisateurs, pedrono.fr | ||
+ | dn: uid=pierre,ou=utilisateurs,dc=pedrono,dc=fr | ||
+ | objectClass: posixAccount | ||
+ | objectClass: posixGroup | ||
+ | cn: Pierre Pierre | ||
+ | uid: pierre | ||
+ | uidNumber: 1000 | ||
+ | gidNumber: 100 | ||
+ | homeDirectory: /home/pierre | ||
+ | userPassword:: JDYkY3ouTXFyR3VVVkh6NHlaRyQ2ZE9KWWdtRUo4aDZUbjByLnNZSFBZclgudU0 | ||
+ | zeERIN3hWN3dUaXEzT1dPZHRablhYRWtrVk1HNmluRmpBeUFDTnJpZmxRZG8uZy4yRWpsaWcwQ1hS | ||
+ | MA== | ||
+ | loginShell: /bin/bash | ||
+ | description: Pierre de la compta | ||
+ | |||
+ | # paul, utilisateurs, pedrono.fr | ||
+ | dn: uid=paul,ou=utilisateurs,dc=pedrono,dc=fr | ||
+ | objectClass: posixAccount | ||
+ | objectClass: posixGroup | ||
+ | cn: Paul Paul | ||
+ | uid: paul | ||
+ | uidNumber: 1001 | ||
+ | gidNumber: 100 | ||
+ | homeDirectory: /home/paul | ||
+ | userPassword:: JDYkY3ouTXFyR3VVVkh6NHlaRyQ2ZE9KWWdtRUo4aDZUbjByLnNZSFBZclgudU0 | ||
+ | zeERIN3hWN3dUaXEzT1dPZHRablhYRWtrVk1HNmluRmpBeUFDTnJpZmxRZG8uZy4yRWpsaWcwQ1hS | ||
+ | MA== | ||
+ | loginShell: /bin/bash | ||
+ | description: Paul de la repro | ||
+ | |||
+ | # jacques, utilisateurs, pedrono.fr | ||
+ | dn: uid=jacques,ou=utilisateurs,dc=pedrono,dc=fr | ||
+ | objectClass: posixAccount | ||
+ | objectClass: posixGroup | ||
+ | cn: Jacques Jacques | ||
+ | uid: jacques | ||
+ | uidNumber: 1002 | ||
+ | gidNumber: 100 | ||
+ | homeDirectory: /home/jacques | ||
+ | userPassword:: JDYkY3ouTXFyR3VVVkh6NHlaRyQ2ZE9KWWdtRUo4aDZUbjByLnNZSFBZclgudU0 | ||
+ | zeERIN3hWN3dUaXEzT1dPZHRablhYRWtrVk1HNmluRmpBeUFDTnJpZmxRZG8uZy4yRWpsaWcwQ1hS | ||
+ | MA== | ||
+ | loginShell: /bin/bash | ||
+ | description: Jacques du courrier | ||
+ | |||
+ | # martine, utilisateurs, pedrono.fr | ||
+ | dn: uid=martine,ou=utilisateurs,dc=pedrono,dc=fr | ||
+ | objectClass: posixAccount | ||
+ | objectClass: posixGroup | ||
+ | cn: Martine Martine | ||
+ | uid: martine | ||
+ | uidNumber: 1003 | ||
+ | gidNumber: 100 | ||
+ | homeDirectory: /home/martine | ||
+ | userPassword:: JDYkY3ouTXFyR3VVVkh6NHlaRyQ2ZE9KWWdtRUo4aDZUbjByLnNZSFBZclgudU0 | ||
+ | zeERIN3hWN3dUaXEzT1dPZHRablhYRWtrVk1HNmluRmpBeUFDTnJpZmxRZG8uZy4yRWpsaWcwQ1hS | ||
+ | MA== | ||
+ | loginShell: /bin/bash | ||
+ | description: Martine la secretaire | ||
+ | |||
+ | # search result | ||
+ | search: 2 | ||
+ | result: 0 Success | ||
+ | |||
+ | # numResponses: 6 | ||
+ | # numEntries: 5 | ||
+ | </pre> | ||
+ | |||
+ | == Manipulation des données d'annuaire à l'aide des commandes ldap* == | ||
+ | |||
+ | === ''ldapsearch'' === | ||
+ | |||
+ | On a déjà vu l'utilisation basique de ''ldapsearch'', sur tout ou partie de notre annuaire. | ||
+ | |||
+ | Cf p90 du support de cours. | ||
+ | |||
+ | Il est possible d'utiliser des filtres à ce niveau pour n'obtenir que certaines informations dans certaines conditions, ex. ci dessous on ne cherche que l'attribut ''postalCode'' de notre OU ''utilisateurs'': | ||
+ | |||
+ | <pre> | ||
+ | [root@kjh conf_ldap]# ldapsearch -x -b 'ou=utilisateurs,dc=pedrono,dc=fr' -D 'cn=Manager,dc=pedrono,dc=fr' postalCode -W | ||
+ | Enter LDAP Password: | ||
+ | # extended LDIF | ||
+ | # | ||
+ | # LDAPv3 | ||
+ | # base <ou=utilisateurs,dc=pedrono,dc=fr> with scope subtree | ||
+ | # filter: (objectclass=*) | ||
+ | # requesting: postalCode | ||
+ | # | ||
+ | |||
+ | # utilisateurs, pedrono.fr | ||
+ | dn: ou=utilisateurs,dc=pedrono,dc=fr | ||
+ | postalCode: 44000 | ||
+ | |||
+ | # search result | ||
+ | search: 2 | ||
+ | result: 0 Success | ||
+ | |||
+ | # numResponses: 2 | ||
+ | # numEntries: 1 | ||
+ | </pre> | ||
+ | |||
+ | === ''ldapmodify'' === | ||
+ | |||
+ | Permet de modifier des entités dans l'annuaire. | ||
+ | |||
+ | Cf p91 du support de cours. | ||
+ | |||
+ | |||
Version du 15 décembre 2010 à 09:19
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
Documentation spécifique d'OpenLDAP
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.
ATTENTION: il peut rester un contenu de paramétrage initial sur la conf par défaut dans /etc/openldap/splapd.d/ (cf l'étape suivante)
Tentative:
cp -r /etc/openldap/slapd.d/ /etc/openldap/slapd.d.SAVE/ rm -rf /etc/openldap/slapd.d/*
Import du LDIF
[root@kjh ~]# slapadd -f conf_ldap/organisation.ldif conf_ldap/organisation.ldif: line 2: unknown directive <dn:> outside backend info and database definitions. slapadd: bad configuration file! [root@kjh ~]#
Tentatives sans suivre la page web ci dessus: ATTENTION utilisation du mauvais switch pour la commande slapadd!!!
[root@kjh ~]# slapadd -l /root/conf_ldap/organisation.ldif bdb_monitor_db_open: monitoring disabled; configure monitor database to enable _#################### 100.00% eta none elapsed none fast! Closing DB...
A priori OK, warning sur le fait d'avoir mis en commentaire "database monitor" dans /etc/openldap/slapd.conf. Pas de réel problème, réactivation par suppression de la mise en commentaire et redémarrage du service.
[root@kjh ~]# /etc/init.d/slapd start ls: impossible d'accéder à /etc/openldap/slapd.d//cn=config/olcDatabase*.ldif: Aucun fichier ou dossier de ce type sed: can't read /etc/openldap/slapd.d//cn=config.ldif: No such file or directory Vérification des fichiers de configuration pour slapd : [AVERTISSEMENT] bdb_monitor_db_open: monitoring disabled; configure monitor database to enable config file testing succeeded Démarrage de slapd : [ OK ]
On remet donc en place l'ancien contenu de /etc/openldap/slapd.d.
[root@kjh ~]# /etc/init.d/slapd stop Arrêt de slapd : [ OK ] [root@kjh ~]# rm -rf /etc/openldap/slapd.d slapd.d/ slapd.d.SAVE/ [root@kjh ~]# rm -rf /etc/openldap/slapd.d [root@kjh ~]# mv /etc/openldap/slapd.d.SAVE/ /etc/openldap/slapd.d/ [root@kjh ~]# ls -la /etc/openldap/slapd.d/ total 16 drwx------. 3 root root 4096 14 déc. 17:21 . drwxr-xr-x. 4 root root 4096 14 déc. 17:24 .. drwx------. 3 root root 4096 14 déc. 17:21 cn=config -rw-------. 1 root root 986 14 déc. 17:21 cn=config.ldif [root@kjh ~]# /etc/init.d/slapd start /var/lib/ldap/objectClass.bdb is not owned by "ldap" [AVERTISSEMENT] Vérification des fichiers de configuration pour slapd : [ÉCHOUÉ] ldif_read_file: Permission denied for "/etc/openldap/slapd.d/cn=config.ldif" slaptest: bad configuration file!
A cette étape, problème car slapadd lancé en tant que root: les données de /var/lib/ldap appartiennent à root et non à ldap...
[root@kjh ~]# chown -R ldap: /etc/openldap/slapd.d/ [root@kjh ~]# /etc/init.d/slapd start /var/lib/ldap/objectClass.bdb is not owned by "ldap" [AVERTISSEMENT] Démarrage de slapd : [ OK ] [root@kjh ~]# chown ldap: /var/lib/ldap/* [root@kjh ~]# /etc/init.d/slapd restart Arrêt de slapd : [ OK ] Démarrage de slapd : [ OK ] [root@kjh ~]#
Vérification de l'import:
[root@kjh ~]# ldapsearch -x -b 'dc=pedrono,dc=fr' # extended LDIF # # LDAPv3 # base <dc=pedrono,dc=fr> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object # numResponses: 1
Apparement l'import s'est mal passé.
Nouvelle tentative:
[root@kjh ~]# /etc/init.d/slapd stop Arrêt de slapd : [ OK ] [root@kjh ~]# slapadd -l /root/conf_ldap/organisation.ldif slapadd: line 1: database #1 (dc=my-domain,dc=com) not configured to hold "dc=pedrono,dc=fr"; no database configured for that naming context _#################### 100.00% eta none elapsed none fast! Closing DB...
Nouveau test:
[root@kjh ~]# rm /etc/openldap/slapd.d/cn\=config.ldif rm : supprimer fichier « /etc/openldap/slapd.d/cn=config.ldif » ? y [root@kjh ~]# slapadd -l /root/conf_ldap/organisation.ldif bdb_monitor_db_open: monitoring disabled; configure monitor database to enable => bdb_tool_entry_put: id2entry_add failed: DB_KEYEXIST: Key/data pair already exists (-30995) => bdb_tool_entry_put: txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30995) slapadd: could not add entry dn="dc=pedrono,dc=fr" (line=1): txn_aborted! DB_KEYEXIST: Key/data pair already exists (-30995) _#################### 100.00% eta none elapsed none fast! Closing DB...
Cette fois slapadd nous indique qu'on a déjà créé la base et qu'on ne peut pas la recréer, il faut donc à nouveau supprimer le contenu de /var/lib/ldap:
[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 ~]# slapadd -l /root/conf_ldap/organisation.ldif bdb_monitor_db_open: monitoring disabled; configure monitor database to enable _#################### 100.00% eta none elapsed none fast! Closing DB... [root@kjh ~]# /etc/init.d/slapd start /var/lib/ldap/__db.006 is not owned by "ldap" [AVERTISSEMENT] /var/lib/ldap/__db.002 is not owned by "ldap" [AVERTISSEMENT] /var/lib/ldap/dn2id.bdb is not owned by "ldap" [AVERTISSEMENT] /var/lib/ldap/alock is not owned by "ldap" [AVERTISSEMENT] /var/lib/ldap/id2entry.bdb is not owned by "ldap" [AVERTISSEMENT] /var/lib/ldap/objectClass.bdb is not owned by "ldap" [AVERTISSEMENT] /var/lib/ldap/__db.004 is not owned by "ldap" [AVERTISSEMENT] /var/lib/ldap/__db.005 is not owned by "ldap" [AVERTISSEMENT] /var/lib/ldap/log.0000000001 is not owned by "ldap" [AVERTISSEMENT] /var/lib/ldap/__db.001 is not owned by "ldap" [AVERTISSEMENT] /var/lib/ldap/__db.003 is not owned by "ldap" [AVERTISSEMENT] sed: can't read /etc/openldap/slapd.d//cn=config.ldif: No such file or directory Vérification des fichiers de configuration pour slapd : [ÉCHOUÉ] bdb_db_open: database "dc=pedrono,dc=fr": alock package is unstable. backend_startup_one (type=bdb, suffix="dc=pedrono,dc=fr"): bi_db_open failed! (-1) slap_startup failed (test would succeed using the -u switch) d'anciens fichiers verroux peuvent être présents dans /var/[AVERTISSEMENT] [root@kjh ~]# chown ldap: /var/lib/ldap/* [root@kjh ~]# /etc/init.d/slapd start sed: can't read /etc/openldap/slapd.d//cn=config.ldif: No such file or directory Vérification des fichiers de configuration pour slapd : [AVERTISSEMENT] bdb_monitor_db_open: monitoring disabled; configure monitor database to enable config file testing succeeded Démarrage de slapd : [ OK ]
Nouveau ldapsearch:
[root@kjh ~]# ldapsearch -x -b "dc=pedrono,dc=fr" # extended LDIF # # LDAPv3 # base <dc=pedrono,dc=fr> with scope subtree # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 32 No such object # numResponses: 1
ATTENTION: à cause de nos ACL pour l'instant seul le rootdn peut interroger en s'authentifiant...
Nouveau ldapsearch:
[root@kjh ~]# ldapsearch -x -b "dc=pedrono,dc=fr" -D "cn=Manager,dc=pedrono,dc=fr" -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=pedrono,dc=fr> with scope subtree # filter: (objectclass=*) # requesting: ALL # # pedrono.fr dn: dc=pedrono,dc=fr objectClass: dcObject objectClass: organization dc: pedrono o: Pedrono Org description: Organisation Pedrono.fr # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
On a donc créé notre organisation avec les bonnes caractéristiques.
Création d'OU
On va créer 1 OU dans un nouveau fichier LDIF ou1.ldif:
dn: ou=utilisateurs,dc=pedrono,dc=fr objectClass: organizationalUnit ou: utilisateurs postalCode: 44000 description: Unite organisationnelle des utilisateurs de Pedrono Organisation
Import de ce fichier LDIF:
[root@kjh conf_ldap]# ldapadd -f ./ou1.ldif -D 'cn=Manager,dc=pedrono,dc=fr' -W Enter LDAP Password: adding new entry "ou=utilisateurs,dc=pedrono,dc=fr" [root@kjh conf_ldap]#
Test de l'import:
[root@kjh conf_ldap]# ldapsearch -x -b 'dc=pedrono,dc=fr' -D 'cn=Manager,dc=pedrono,dc=fr' -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=pedrono,dc=fr> with scope subtree # filter: (objectclass=*) # requesting: ALL # # pedrono.fr dn: dc=pedrono,dc=fr objectClass: dcObject objectClass: organization dc: pedrono o: Pedrono Org description: Organisation Pedrono.fr # utilisateurs, pedrono.fr dn: ou=utilisateurs,dc=pedrono,dc=fr objectClass: organizationalUnit ou: utilisateurs postalCode: 44000 description: Unite organisationnelle des utilisateurs de Pedrono Organisation # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2
On va donc créer 2 autres OU:
- une OU "groupes" dans ou2.ldif.
- une OU "peripheriques" dans ou3.ldif.
ou2.ldif:
dn: ou=groupes,dc=pedrono,dc=fr objectClass: organizationalUnit ou: groupes postalCode: 44000 description: Unite organisationnelle des groupes de Pedrono Organisation
ou3.ldif:
dn: ou=peripheriques,dc=pedrono,dc=fr objectClass: organizationalUnit ou: peripheriques postalCode: 44000 description: Unite organisationnelle des peripheriques de Pedrono Organisation
Import de ces nouvelles OU:
[root@kjh conf_ldap]# ldapadd -f ./ou2.ldif -D 'cn=Manager,dc=pedrono,dc=fr' -W Enter LDAP Password: adding new entry "ou=groupes,dc=pedrono,dc=fr"
[root@kjh conf_ldap]# ldapadd -f ./ou3.ldif -D 'cn=Manager,dc=pedrono,dc=fr' -W Enter LDAP Password: adding new entry "ou=peripheriques,dc=pedrono,dc=fr"
Vérification:
[root@kjh conf_ldap]# ldapsearch -x -b 'dc=pedrono,dc=fr' -D 'cn=Manager,dc=pedrono,dc=fr' -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=pedrono,dc=fr> with scope subtree # filter: (objectclass=*) # requesting: ALL # # pedrono.fr dn: dc=pedrono,dc=fr objectClass: dcObject objectClass: organization dc: pedrono o: Pedrono Org description: Organisation Pedrono.fr # utilisateurs, pedrono.fr dn: ou=utilisateurs,dc=pedrono,dc=fr objectClass: organizationalUnit ou: utilisateurs postalCode: 44000 description: Unite organisationnelle des utilisateurs de Pedrono Organisation # groupes, pedrono.fr dn: ou=groupes,dc=pedrono,dc=fr objectClass: organizationalUnit ou: groupes postalCode: 44000 description: Unite organisationnelle des groupes de Pedrono Organisation # peripheriques, pedrono.fr dn: ou=peripheriques,dc=pedrono,dc=fr objectClass: organizationalUnit ou: peripheriques postalCode: 44000 description: Unite organisationnelle des peripheriques de Pedrono Organisation # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 4
Ajout d'entrées dans l'annuaire
Ajout d'utilisateurs
Création d'un fichier LDIF pour la création des utilisateurs, qu'on ratachera à l'OU utilisateurs.
Détermination des objectClass: chercher quelque chose du style "account" ou "ccount" dans les schémas.
Plusieurs schémas peuvent correspondre, il faut faire un choix à cette étape.
Si on souhaite utiliser l'annuaire pour l'authentification linux, on va pouvoir choisir l'objectClass posixAccount du schéma nis.
ATTENTION: quand on sélectionne un objectClass, on ne peut pas n'utiliser qu'un objectClass AUXILIARY.
Ex:
objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' DESC 'Abstraction of an account with POSIX attributes' SUP top AUXILIARY MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ description ) )
Il faut utiliser un objectClass qui soit de type STRUCTURAL. Par exemple posixGroup dans notre cas, si on ne souhaite pas mélanger les objectClass de schémas différents.
Contenu d'un bloc du LDIF:
dn: uid=pierre,ou=utilisateurs,dc=pedrono,dc=fr objectClass: posixAccount objectClass: posixGroup cn: Pierre Pierre uid: pierre uidNumber: 1000 gidNumber: 100 homeDirectory: /home/pierre userPassword: $6$cz.MqrGuUVHz4yZG$6dOJYgmEJ8h6Tn0r.sYHPYrX.uM3xDH7xV7wTiq3OWOdtZnXXEkkVMG6inFjAyACNriflQdo.g.2Ejlig0CXR0 loginShell: /bin/bash description: Pierre de la compta
Le fichier contenant les 4 utilisateurs créés est utilisateurs.ldif.
Import des utilisateurs, on respecte la logique habituelle:
- arrêt du service
- slapadd
- démarrage du service
ATTENTION: une fois de plus comme on travaille en root, on crée des fichier bdb appartenant à root dans /var/lib/ldap, il ne faut donc pas oublier le chown ldap: /var/lib/ldap/* avant de démarrer le service.
/etc/init.d/slapd stop slapadd -l /root/conf_ldap/utilisateurs.ldif chown ldap: /var/lib/ldap/* /etc/init.d/slapd start
Vérification du résultat:
[root@kjh conf_ldap]# ldapsearch -x -b 'ou=utilisateurs,dc=pedrono,dc=fr' -D 'cn=Manager,dc=pedrono,dc=fr' -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=utilisateurs,dc=pedrono,dc=fr> with scope subtree # filter: (objectclass=*) # requesting: ALL # # utilisateurs, pedrono.fr dn: ou=utilisateurs,dc=pedrono,dc=fr objectClass: organizationalUnit ou: utilisateurs postalCode: 44000 description: Unite organisationnelle des utilisateurs de Pedrono Organisation # pierre, utilisateurs, pedrono.fr dn: uid=pierre,ou=utilisateurs,dc=pedrono,dc=fr objectClass: posixAccount objectClass: posixGroup cn: Pierre Pierre uid: pierre uidNumber: 1000 gidNumber: 100 homeDirectory: /home/pierre userPassword:: JDYkY3ouTXFyR3VVVkh6NHlaRyQ2ZE9KWWdtRUo4aDZUbjByLnNZSFBZclgudU0 zeERIN3hWN3dUaXEzT1dPZHRablhYRWtrVk1HNmluRmpBeUFDTnJpZmxRZG8uZy4yRWpsaWcwQ1hS MA== loginShell: /bin/bash description: Pierre de la compta # paul, utilisateurs, pedrono.fr dn: uid=paul,ou=utilisateurs,dc=pedrono,dc=fr objectClass: posixAccount objectClass: posixGroup cn: Paul Paul uid: paul uidNumber: 1001 gidNumber: 100 homeDirectory: /home/paul userPassword:: JDYkY3ouTXFyR3VVVkh6NHlaRyQ2ZE9KWWdtRUo4aDZUbjByLnNZSFBZclgudU0 zeERIN3hWN3dUaXEzT1dPZHRablhYRWtrVk1HNmluRmpBeUFDTnJpZmxRZG8uZy4yRWpsaWcwQ1hS MA== loginShell: /bin/bash description: Paul de la repro # jacques, utilisateurs, pedrono.fr dn: uid=jacques,ou=utilisateurs,dc=pedrono,dc=fr objectClass: posixAccount objectClass: posixGroup cn: Jacques Jacques uid: jacques uidNumber: 1002 gidNumber: 100 homeDirectory: /home/jacques userPassword:: JDYkY3ouTXFyR3VVVkh6NHlaRyQ2ZE9KWWdtRUo4aDZUbjByLnNZSFBZclgudU0 zeERIN3hWN3dUaXEzT1dPZHRablhYRWtrVk1HNmluRmpBeUFDTnJpZmxRZG8uZy4yRWpsaWcwQ1hS MA== loginShell: /bin/bash description: Jacques du courrier # martine, utilisateurs, pedrono.fr dn: uid=martine,ou=utilisateurs,dc=pedrono,dc=fr objectClass: posixAccount objectClass: posixGroup cn: Martine Martine uid: martine uidNumber: 1003 gidNumber: 100 homeDirectory: /home/martine userPassword:: JDYkY3ouTXFyR3VVVkh6NHlaRyQ2ZE9KWWdtRUo4aDZUbjByLnNZSFBZclgudU0 zeERIN3hWN3dUaXEzT1dPZHRablhYRWtrVk1HNmluRmpBeUFDTnJpZmxRZG8uZy4yRWpsaWcwQ1hS MA== loginShell: /bin/bash description: Martine la secretaire # search result search: 2 result: 0 Success # numResponses: 6 # numEntries: 5
Manipulation des données d'annuaire à l'aide des commandes ldap*
ldapsearch
On a déjà vu l'utilisation basique de ldapsearch, sur tout ou partie de notre annuaire.
Cf p90 du support de cours.
Il est possible d'utiliser des filtres à ce niveau pour n'obtenir que certaines informations dans certaines conditions, ex. ci dessous on ne cherche que l'attribut postalCode de notre OU utilisateurs:
[root@kjh conf_ldap]# ldapsearch -x -b 'ou=utilisateurs,dc=pedrono,dc=fr' -D 'cn=Manager,dc=pedrono,dc=fr' postalCode -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=utilisateurs,dc=pedrono,dc=fr> with scope subtree # filter: (objectclass=*) # requesting: postalCode # # utilisateurs, pedrono.fr dn: ou=utilisateurs,dc=pedrono,dc=fr postalCode: 44000 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1
ldapmodify
Permet de modifier des entités dans l'annuaire.
Cf p91 du support de cours.