Outils pour utilisateurs

Outils du site


ateliers:serveurmail:ldap

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
ateliers:serveurmail:ldap [2018/06/28 15:09]
okhin Ajout d'un lien vers la structure de l'arbre.
ateliers:serveurmail:ldap [2019/10/28 19:48] (Version actuelle)
okhin Fixing typos
Ligne 13: Ligne 13:
 Sous GNU/Linux, le projet gnome propose LAT, qui s'installe avec la commande apt: Sous GNU/Linux, le projet gnome propose LAT, qui s'installe avec la commande apt:
  
-<code>$ sudo apt install lat</code>.+<code>$ sudo apt install lat</code>
  
 KDE fournit un client aux fonctionnalité identique, Kldap, installable avec apt par exemple. KDE fournit un client aux fonctionnalité identique, Kldap, installable avec apt par exemple.
  
 D'autres [[https://www.tldp.org/HOWTO/LDAP-HOWTO/graphicaltools.html|clients graphique]] existent et sont disponible pour toutes les plateformes. D'autres [[https://www.tldp.org/HOWTO/LDAP-HOWTO/graphicaltools.html|clients graphique]] existent et sont disponible pour toutes les plateformes.
 +
 +== Services utilisant LDAP ==
 +
 +Une rapide liste des services utilisant LDAP, afin que tout le monde puisses'y retrouver rapidement.
 +
 +  * PAM - Lisez donc la suite pour voir comment faire
 +  * [[ldap-ssh|SSH]] - afin de pouvoir stocker la clef publique ssh dans l'arbre LDAP
  
 === Installation === === Installation ===
Ligne 51: Ligne 58:
 [...] [...]
 </code> </code>
 +
 +<WRAP center round info 80%>
 +Par la suite, les modifications à l'arbre cn=config de LDAP se feront en utilisant la commande ldapmodify comme suit:
 +
 +<code>$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f[/chemin/vers/un/fichier.ldif</code>
 +</WRAP>
 +
  
 === TLS === === TLS ===
  
-Nous voulons avoir une connexion chiffrée lorsque nous nous connectons depuis l'extérieur du serveur, et cela va se faire grâce à [letsencrypt] sur le domaine ``ldap.anarcha.pink``.+Nous voulons avoir une connexion chiffrée lorsque nous nous connectons depuis l'extérieur du serveur, et cela va se faire grâce à [letsencrypt] sur le domaine ''ldap.anarcha.pink''.
  
-Il est nécessaire, pour que LDAP puisse démarrer avec TLS, que l'utilisateur ``openldap`` ait les droits d'accès en lecture aux certificats et clefs générées par letsencrypt, ne pas oublier d'ajouter l'utilisateur au groupe ``tls``.+Il est nécessaire, pour que LDAP puisse démarrer avec TLS, que l'utilisateur ''openldap'' ait les droits d'accès en lecture aux certificats et clefs générées par letsencrypt, ne pas oublier d'ajouter l'utilisateur au groupe ''tls''.
  
     $ sudo adduser openldap tls     $ sudo adduser openldap tls
Ligne 90: Ligne 104:
 Pour plus d'information sur l'utilité des clefs utilisées il faut se référer à [[http://www.zytrax.com/books/ldap/ch6/slapd-config.html|Zytrax]]. Pour plus d'information sur l'utilité des clefs utilisées il faut se référer à [[http://www.zytrax.com/books/ldap/ch6/slapd-config.html|Zytrax]].
  
-Il faut ensuite modifier les options du daemon slapd pour lui dire comment se connecter sur nos interfaces réseau en allant modifier le fichier ``/etc/default/slapd``+Il faut ensuite modifier les options du daemon slapd pour lui dire comment se connecter sur nos interfaces réseau en allant modifier le fichier ''/etc/default/slapd''
  
-<config|h /etc/default/slpad>+<code|h /etc/default/slpad>
 [...] [...]
 SLAPD_SERVICES="ldap:\/\/127.0.0.1:389\/ ldaps:\/\/\/ ldapi:\/\/\/" SLAPD_SERVICES="ldap:\/\/127.0.0.1:389\/ ldaps:\/\/\/ ldapi:\/\/\/"
 [...] [...]
 +</code>
  
 Cela force l'ouverture d'un canal en clair uniquement sur la boucle locale, et ouvre une connexion chiffrée sur l'ensemble des interfaces réseau ainsi que le fonctionnement classique par socket Unix avec ldapi:\/\/\/. Cela force l'ouverture d'un canal en clair uniquement sur la boucle locale, et ouvre une connexion chiffrée sur l'ensemble des interfaces réseau ainsi que le fonctionnement classique par socket Unix avec ldapi:\/\/\/.
Ligne 108: Ligne 123:
 == Test du fonctionnement de l'arbre == == Test du fonctionnement de l'arbre ==
  
-Une commande rapide que l'on peut utiliser est ldapsearch afin de lister l'ensemble de ce qu'il y a dans l'arbre. La commande doit fournir un résultat si tout va bien. Comme d'habitude, la [[ttps://linux.die.net/man/1/ldapsearch|page de man]] fournit l'explication de chaque option utilisée ici (//LLL// permet l'affiche dans un format compatible ldif, //H// précise l'endroit sur lequel on se connecte, //b// précise oú chercher.+Une commande rapide que l'on peut utiliser est ldapsearch afin de lister l'ensemble de ce qu'il y a dans l'arbre. La commande doit fournir un résultat si tout va bien. Comme d'habitude, la [[https://linux.die.net/man/1/ldapsearch|page de man]] fournit l'explication de chaque option utilisée ici (//LLL// permet l'affiche dans un format compatible ldif, //H// précise l'endroit sur lequel on se connecte, //b// précise oú chercher.
  
     $ ldapsearch -LLL -H ldapi:/// -b dc=anarcha,dc=pink     $ ldapsearch -LLL -H ldapi:/// -b dc=anarcha,dc=pink
Ligne 132: Ligne 147:
 == Test de la connexion TLS == == Test de la connexion TLS ==
  
-Depuis une machine distante, il est possible de vérifier que la cnnexion est chiffrée et valide. LDAP ćoute sur le port 636 pour le TLS.+Depuis une machine distante, il est possible de vérifier que la cnnexion est chiffrée et valide. LDAP éćoute sur le port 636 pour le TLS.
  
 <code|bash> <code|bash>
Ligne 194: Ligne 209:
 Un Overlay est une surcouche à la base de donnée voulue, permettant d'ajouter des fonctionnalités supplémentaires. Un Overlay est une surcouche à la base de donnée voulue, permettant d'ajouter des fonctionnalités supplémentaires.
  
-Les surcouches qui ont été configurés par ``ldapmodify`` avec les fichiers ldif supplémentaires qui sont dans ``/usrr/local/lib/ldap/overlays``.+Les surcouches qui ont été configurés par ''ldapmodify'' avec les fichiers ldif supplémentaires qui sont dans ''/usr/local/lib/ldap/overlays''.
  
-La syntaxe du DN de chaque surcouche utilise une notation avec ``{0}`` précédant le nom du module, cela nous permet d'être sûr que l'on configure la bonne surcouche.+La syntaxe du DN de chaque surcouche utilise une notation avec //{0}// précédant le nom du module, cela nous permet d'être sûr que l'on configure la bonne surcouche.
  
-Chaque surcouche doit être activé en chargeant un module, et donc en modifiant l'objet ayant le dn suivant: ``cn={0}module,cn=config``. Pour avoir une liste des paramètres disponible, il faut regarder les pages de man de chaque surcouche (``man slapo-<module>``) et regarder les [[http://www.zytrax.com/books/ldap/ape/config.html#olcoverlayconfig|schémas associés]] à chaque surcouche pour trouver le nom des attributs dans la syntaxe cn=config.+Chaque surcouche doit être activé en chargeant un module, et donc en modifiant l'objet ayant le dn suivant: ''cn={0}module,cn=config''. Pour avoir une liste des paramètres disponible, il faut regarder les pages de man de chaque surcouche (``man slapo-<module>``) et regarder les [[http://www.zytrax.com/books/ldap/ape/config.html#olcoverlayconfig|schémas associés]] à chaque surcouche pour trouver le nom des attributs dans la syntaxe //cn=config//.
  
 == Surcouches activées == == Surcouches activées ==
Ligne 205: Ligne 220:
  
 D'autres surcouches pourront être ajoutée plus tard, par exemple pour loguer certaines erreurs. D'autres surcouches pourront être ajoutée plus tard, par exemple pour loguer certaines erreurs.
 +
 +=== Remplacement du schéma NIS ===
 +Afin que [[slapo-memberOf|memberOf]] fonctionne, il faut pouvoir ajouter un groupeOfNames à un posixGroup.
 +
 +Un objet ne peut avoir qu'une seule classe structurelle. Or posixGroup et groupOfNames sont toutes les deux des classes structurelles, il n'est donc pas possible avec le schéma NIS installé par défaut de pouvoir utiliser memberof ET de disposer d'un gidNumber.
 +
 +La RFC implémentée par NIS ([[https://www.ietf.org/rfc/rfc2307.txt|RFC2307]]) a cependant reçu une proposition, mais qui n'a jamais atteint le stade final. Il y a donc un schéma - rfc2307bis - supprimant la classe structurelle de l'objet posixGroup, nous permettant donc de pouvoir avoir un gidNumber ET un attribut memberOf sur nos objets groupes.
 +
 +Il faut cependant supprimer le schéma NIS d'abord, puis activer le schéma 2307bis.
 +
 +<WRAP center round alert 80%>
 +Pensez à sauvegarder vos données AVANT de faire les modifications de schéma ci-dessous.
 +</WRAP>
 +
 +== Suppression du schéma NIS ==
 +Il n'est pas possible de faire un ldapdelete sur les schémas. la solution consiste donc à arrêter le service, supprimer le schéma de la base qui est alors composée de fichiers plats, puis de redémarrer le service.
 +
 +<code|bash>
 +$ sudo systemctl stop slapd
 +$ sudo systemctl status slapd
 +  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
 +   Loaded: loaded (/etc/init.d/slapd; generated; vendor preset: enabled)
 +   Active: inactive (dead) since Thu 2018-06-28 15:39:22 CEST; 13s ago
 +     Docs: man:systemd-sysv-generator(8)
 +  Process: 25434 ExecStop=/etc/init.d/slapd stop (code=exited, status=0/SUCCESS)
 +  Process: 24877 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS)
 +    Tasks: 0 (limit: 4915)
 +   CGroup: /system.slice/slapd.service
 +   [...]
 +</code>
 +
 +Il faut maintenant aller modifier la configuration des schémas. Elle est disponible sous ''/etc/ldap/slapd.d/cn=config/cn=schema/''
 +
 +Ce répertoire contient des fichiers ldif ordonnés (commençant par {Z}avec Z le numéro d'ordre)
 +
 +<code|bash>
 +$ sudo ls -l /etc/ldap/slapd.d/cn\=config/cn=schema
 +total 40
 +-rw------- 1 openldap openldap 15596 juin  27 16:24 cn={0}core.ldif
 +-rw------- 1 openldap openldap 11381 juin  27 16:24 cn={1}cosine.ldif
 +-rw------- 1 openldap openldap  6513 juin  27 16:24 cn={2}nis.ldif
 +-rw------- 1 openldap openldap  2875 juin  27 16:24 cn={3}inetorgperson.ldif
 +</code>
 +
 +Dans notre cas, nous avons le schéma nis auquel est attribué le numéro 2. On supprime ce fichier (**pensez à faire une sauvegarde de /etc/ldap/slap.d AVANT**). Puis on renomme les schéna ayant un ordre supérieur pour obtenir une suite numérique continue de schémas.
 +
 +<code|bash>
 +$ sudo rm /etc/ldap/slapd.d/cn\=config/cn\=schema/cn\=\{2\}nis.ldif
 +$ sudo mv /etc/ldap/slapd.d/cn\=config/cn\=schema/cn\=\{{3,2}\}inetorgperson.ldif
 +$ sudo ls -l /etc/ldap/slapd.d/cn\=config/cn=schema
 +-rw------- 1 openldap openldap 15596 juin  27 16:24 cn={0}core.ldif
 +-rw------- 1 openldap openldap 11381 juin  27 16:24 cn={1}cosine.ldif
 +-rw------- 1 openldap openldap  2875 juin  27 16:24 cn={2}inetorgperson.ldif
 +</code>
 +
 +<WRAP center round info 80%>
 +Nous supprimons (temporairement) un schéma, de fait certains éléments et attributs n'existent plus, il faut les commenter le temps d'importer le nouveau schéma qui fourniras les mêmes attributs. Dans le cas d'une debian par défaut, il y a une référence aux attributs ''shadowLastChange'' et ''memberUid'' dans le fichier ''/etc/ldap/slapd.d/cn=config/olcDatabase=\{1\}mdb.ldif'', commentez les avant de redémarrer slapd.
 +</WRAP>
 +
 +Et on redémarre le tout.
 +
 +<code|bash>
 +$ sudo systemctl start slapd
 +$ sudo systemctl status slapd
 +● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
 +   Loaded: loaded (/etc/init.d/slapd; generated; vendor preset: enabled)
 +   Active: active (running) since Thu 2018-06-28 15:58:41 CEST; 3s ago
 +     Docs: man:systemd-sysv-generator(8)
 +  Process: 25434 ExecStop=/etc/init.d/slapd stop (code=exited, status=0/SUCCESS)
 +  Process: 25576 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS)
 +    Tasks: 3 (limit: 4915)
 +   CGroup: /system.slice/slapd.service
 +           └─25582 /usr/sbin/slapd -h ldap://127.0.0.1:389/ ldaps:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d
 +</code>
 +
 +Tout [[https://www.youtube.com/watch?v=StTqXEQ2l-Y|fonctionne]].
 +
 +== Installation du schéma rfc2307bis ==
 +
 +Le remplacement du schéma NIS est disponible dans un paquet debian pour l'application gosa. On ne veut que les schémas LDAP.
 +
 +  $ sudo apt install gosa-schema
 +
 +Les nouveaux schéma du paquet sont disponibles dans /etc/ldap/schema/gosa/. Pour chaque schéma, il y a deux fichiers. Le rfc2307bis.schema contient les déclaration formelle des types LDAP fournit par le schéma, alors que le fichier rfc2307bis.ldif contiens lui la déclaration au format ldif pour installer le schéma sur nos bases.
 +
 +Cette modification se fait par root sur l'OLC cn=config
 +
 +<code|bash>
 +$ sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/gosa/rfc2307bis.ldif
 +SASL/EXTERNAL authentication started
 +SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
 +SASL SSF: 0
 +adding new entry "cn=rfc2307bis,cn=schema,cn=config"
 +</code>
 +
 +Un rapide coup d'œil à la configuration lisible dans ''/etc/ldap/slap.d/cn\=config/cn\=schema'' nous montre que le schéma rfc2307bis est bien actif.
 +
 +<code|bash>
 +$ sudo ls /etc/ldap/slapd.d/cn\=config/cn\=schema/ -l
 +-rw------- 1 openldap openldap 15596 juin  27 16:24 cn={0}core.ldif
 +-rw------- 1 openldap openldap 11381 juin  27 16:24 cn={1}cosine.ldif
 +-rw------- 1 openldap openldap  2875 juin  27 16:24 cn={2}inetorgperson.ldif
 +-rw------- 1 openldap openldap  9609 juin  28 16:07 cn={3}rfc2307bis.ldif
 +</code>
 +
 +<WRAP info center round 80%>
 +Si vous avez du commenter des entrées pour pouvoir démarrer le serveur et y ajouter le schéma NIS, arrêter le serveur, décommenter les entrées dans ''/etc/ldap/slapd.d/cn=config/olcDatabase=\{1\}mdb.ldif'' par exemple, et redémarrez le serveur.
 +</WRAP>
 +
  
 === Modifications des ACL === === Modifications des ACL ===
Ligne 232: Ligne 356:
 Sur la seconde base, on définit l'accès à des attributs spécifiques au seul utilisateur (ou lors de la phase d'authentification), ce qui concerne les champs userPassword (règle {0})et shadowLastChange (règle {1}). Enfin, nous permettons à tout le monde de pouvoir lire l'intégralité de l'arbre. Sur la seconde base, on définit l'accès à des attributs spécifiques au seul utilisateur (ou lors de la phase d'authentification), ce qui concerne les champs userPassword (règle {0})et shadowLastChange (règle {1}). Enfin, nous permettons à tout le monde de pouvoir lire l'intégralité de l'arbre.
  
-Le fichier ``/usr/local/lib/ldap/acl.ldif`` contient l'ensemble des ACL en place. Pour plus de détail sur les ACL implémentée sur anarcha voir le fichier [[ateliers:serveurmail:ldap-acl|ACL]] commenté.+Le fichier ''/usr/local/lib/ldap/acl.ldif'' contient l'ensemble des ACL en place. Pour plus de détail sur les ACL implémentée sur anarcha voir le fichier [[ateliers:serveurmail:ldap-acl|ACL]] commenté.
  
 === Peuplement des premiers items === === Peuplement des premiers items ===
  
 Vu que LDAP est un annuaire structuré, commençons par créer deux Organizational Unit (ou) qui nous servirons par la suite. Une première ou pour les utilisateurs et une seconde pour les groupes. Vu que LDAP est un annuaire structuré, commençons par créer deux Organizational Unit (ou) qui nous servirons par la suite. Une première ou pour les utilisateurs et une seconde pour les groupes.
 +
 +Nous en profitons aussi pour ajouter une OU System qui contiendra des comptes nécessaire au fonctionnement de LDAP ou pour connecter certains services à l'annuaire, au lieu de les bnder sur le rootdn.
  
 La structure de donnée de l'arbre Anarcha est détaillée dans notre [[ldap-schema|schéma]], avec notamment les attributs que l'on peut utiliser, les classes associées aux DN et autres. C'est cette page qui sert de référence pour la structure des arbres du LDAP anarcha. La structure de donnée de l'arbre Anarcha est détaillée dans notre [[ldap-schema|schéma]], avec notamment les attributs que l'on peut utiliser, les classes associées aux DN et autres. C'est cette page qui sert de référence pour la structure des arbres du LDAP anarcha.
Ligne 250: Ligne 376:
 ou: Groups ou: Groups
 objectClass: organizationalUnit objectClass: organizationalUnit
 +
 +dn: ou=System,dc=anarcha,dc=pink
 +ou: System
 +objectClass: organizationalUnit
 +
 </code> </code>
  
Ligne 283: Ligne 414:
 dn: ou=Groups,dc=anarcha,dc=pink dn: ou=Groups,dc=anarcha,dc=pink
 ou: Groups ou: Groups
 +objectClass: organizationalUnit
 +
 +# System, anarcha.pink
 +dn: ou=System,dc=anarcha,dc=pink
 +ou: System
 objectClass: organizationalUnit objectClass: organizationalUnit
  
 # search result # search result
-search: 3+search: 4
 result: 0 Success result: 0 Success
  
Ligne 294: Ligne 430:
  
 Nos OU ont été créées, tout va bien Nous allons pouvoir passer à la suite des opérations. Nos OU ont été créées, tout va bien Nous allons pouvoir passer à la suite des opérations.
 +
 +== Nobody ==
 +Afin de pouvoir créer des groupOfNames vide, nous avons besoin d'un utilisateur nobody. Il existe également comme compte Unix et, généralement, n'a pas de droits.
 +
 +Sur le même principe, nous allons donc créer un utilisateur nobody, qui héritera des mêmes uid et gid que dans /etc/passwd d'Unix.
 +
 +<code|ldif /usr/local/lib/ldap/nobody.ldif>
 +dn: uid=nobody,ou=System,dc=anarcha,dc=pink
 +uid: nobody
 +cn: nobody
 +sn: nobody
 +objectClass: top
 +objectClass: person
 +objectClass: posixAccount
 +objectClass: shadowAccount
 +loginShell: /bin/nologin
 +homeDirectory: /nonexistent
 +uidNumber: 65534
 +gidNumber: 65534
 +
 +</code>
 +
 +Il s'agît ensuite, simplement, de l'ajouter avec ldapadd.
 +
 +<code|bash>
 +$ ldapadd -xcWD cn=admin,cn=anarcha,cn=pink -f nobody.ldif
 +$ ldapsearch -xb dc=anarcha,dc=pink '(uid=nobody)'
 +# nobody, System, anarcha.pink
 +dn: uid=nobody,ou=System,dc=anarcha,dc=pink
 +uid: nobody
 +cn: nobody
 +sn: nobody
 +objectClass: top
 +objectClass: person
 +objectClass: posixAccount
 +objectClass: shadowAccount
 +loginShell: /bin/nologin
 +homeDirectory: /nonexistent
 +uidNumber: 65534
 +gidNumber: 65534
 +</code>
 +
 +Il faudra dans les [[ldap-acl|ACL]] s'assurer que cet utilisateur n'a aucun droits car il sera présent dans tous les groupes et que nous voulons que, justement, cet utilisateur n'ait aucun droit.
  
 == Groupe sudo == == Groupe sudo ==
Ligne 312: Ligne 491:
 cn: sudo cn: sudo
 gidNumber: 27 gidNumber: 27
 +member: uid=nobody,ou=System,dc=anarcha,dc=pink
  
 </code> </code>
Ligne 319: Ligne 499:
   Enter LDAP Password:     Enter LDAP Password:  
   adding new entry "cn=sudo,ou=Groups,dc=anarcha,dc=pink"   adding new entry "cn=sudo,ou=Groups,dc=anarcha,dc=pink"
 +
 +==== Mapping de comptes LDAP vers des com[tes Unix ====
 +
 +Lorsque nous utilisons les outils LDAP depuis la ligne de commande, OpenLDAP utilise le fichier ''/etc/ldap/ldap.conf'' pour fournir quelques valeurs par  défut, typiquement pour savoir oú se connecter et en tant que quel utilisateur.
 +
 +C'est à ça que nous sert, entre autres, l'utilisateur dn=system,ou=System (voir le [[ldap-schema|schéma]] et les [[ldap-acl|ACL]] pourplus de détail sur cet utilisateur).
 +
 +''ldapwhoami'' est un outil du paquet openldap nous permettant de poser une question simple au serveur LDAP: Qui suis-je ?. ''ldapwhoami'' va donc utiliser la configuration de ldap.conf pour afficher le DN de l'utilisateur exécutant cette commande. Le fichier contenant ceci :
 +<code|bash /etc/ldap/ldap.conf>
 +#
 +# LDAP Defaults
 +#
 +
 +# See ldap.conf(5) for details
 +# This file should be world readable but not world writable.
 +
 +BASE    dc=anarcha,dc=pink
 +URI     ldapi:///
 +BINDDN  dc=system,ou=System,dc=anarcha,dc=pink
 +
 +#SIZELIMIT      12
 +#TIMELIMIT      15
 +#DEREF          never
 +
 +# TLS certificates (needed for GnuTLS)
 +TLS_CACERT      /etc/ssl/certs/ca-certificates.crt
 +
 +</code>
 +
 +Cela revient à préciser les paramètres suivant sur l'ensemble des commandes ldap:
 +
 +  $ ldapsearch -H ldappi:/// -b dc=anarcha,dc=pink -D "dc=system,ou=System,dc=anarcha,dc=pink"
 +
 +Ce fichier mous permet de sensiblement réduire la liste des paramètres tapés à chaque commande. Et donc, comme nous utilison SASL, le serveur LDAP va utiliser unmécanisme approprié. Par défaut, et en absence d'un service sasl, le serveur OpenLDAP utilise le mécanise EXTERNAL.
 +
 +<code|ldif>
 +$ ldapsearch -b cn=config -s base -b "" supportedSASLMechanisms
 +SASL/EXTERNAL authentication started
 +SASL username: gidNumber=1006+uidNumber=1007,cn=peercred,cn=external,cn=auth
 +SASL SSF: 0
 +# extended LDIF
 +#
 +# LDAPv3
 +# base <> with scope baseObject
 +# filter: (objectclass=*)
 +# requesting: supportedSASLMechanisms
 +#
 +
 +#
 +dn:
 +supportedSASLMechanisms: EXTERNAL
 +
 +# search result
 +search: 3
 +result: 0 Success
 +
 +# numResponses: 2
 +# numEntries: 1
 +
 +</code>
 +
 +Ce que fait ce module //EXTERNAL// est de créer une authentification en utilisant l'UID et le GID de l'utilisateur connecté. ldapwhoami va donc, logiquement, nous dire que nous sommes un utilisateur système :
 +
 +<code|bash>
 +$ ldapwhoami
 +SASL/EXTERNAL authentication started 
 +SASL username: gidNumber=1006+uidNumber=1007,cn=peercred,cn=external,cn=auth
 +SASL SSF: 0                       
 +dn: gidNumber=1006+uidNumber=1007,cn=peercred,cn=external,cn=auth
 +</code>
 +
 +Ce qui ne correspond pas à un utilisateur dans notre nbase LDAP. A noter aussi que l'utilisateur root (uid et gid = 0) correspond à l'identification suivante, que nous retrouvons régulièrement dans les [[ldap-acl|ACL]] : 
 +
 +  gidNumber=1006+uidNumber=1007,cn=peercred,cn=external,cn=auth
 +
 +Ce que nous voulons faire, c'est associé cette authentification à une entrée de notre base LDAP. Notre [[ldap-schema|schéma]] indique que notre utilisateurs, si il à la classe ''posixAccount'' dispose d'un champ uidNumber, ce qui nous permettra d'associer notre compte Unix à un compte LDAP.
 +
 +Et LDAP fournit justement une variable permettant de mapper une authentification à un compte. En utilisant les Expressions Régulières (qui vaudraient le coup d'un atelier à part entière au Reset) et une syntaxe normalisée, les URL LDAP, il est possible d'effectuer une substitution grâce au paramètre ''olcAuthzRegexp''.
 +
 +<WRAP center round info 60%>
 +Les URL LDAP obéissent à la [[https://docs.ldap.com/specs/rfc4516.txt|RFC 4516]] et sont un moyen universel de créer des requêtes LDAP pouvant de fait fonctionner sur n'importe quel serveur LDAP, peu importe sa structure.
 +
 +Très rapidement, il s'agit d'une URI ayant cette structure là :
 +
 +  ldap://<server>:<port>/<baseDn>?<attrsList>?<scope>?<filter>
 +
 +Des informations plus détaillée sont disponibles sur le site [[https://ldap.com/ldap-urls/|ldap.com]]
 +</WRAP>
 +
 +Nous voulons, pour faire simple, que cette authentification là :
 +
 +  gidNumber=1006+uidNumber=1007,cn=peercred,cn=external,cn=auth
 +
 +Soit associé à cet utilisateur là (certains attributs ont été masqués):
 +
 +<code|ldif>
 +# okhin, Users, anarcha.pink
 +dn: uid=okhin,ou=Users,dc=anarcha,dc=pink
 +uid: okhin
 +cn: okhin
 +sn: okhin
 +objectClass: top
 +objectClass: person
 +objectClass: posixAccount
 +objectClass: shadowAccount
 +objectClass: ldapPublicKey
 +uidNumber: 1007
 +gidNumber: 1006
 +memberOf: cn=sudo,ou=Groups,dc=anarcha,dc=pink
 +</code>
 +
 +L'association va se faire par le ''gidNumber'' et on va donc commnecer par créer notre URL LDAP de destination.
 +
 +  ldap:///ou=Users,dc=anarcha,dc=pink??one?(uidNumber=\$1)
 +
 +Nous ne précisons pas de nom d'hôte ou de port, nous nous connecterons donc en localhost. Le reste de l'URL correspond aux valeurs suivantes :
 +
 +  * baseDN: **ou=Users,dc=anarcha,dc=pink** On ne veut mapper que vers les utilisateurs,, pas vers autre chose
 +  * attrsList: **<vide>** On prend tous les attributs (même si filtrer sur dn doit fonctionner)
 +  * scope: **one** On ne veut pas explorer tout l'arbre, mais seulement un niveau sous la base.
 +  * filter: **(uidNumber=\$1)** On veut que le champ uidNumber ait la valeur du premier motif trouvé dans l'expression régulière (motif qui doit donc être entre parenthèse dans l'expression)
 +
 +L'expression régulière d'analyse de l'authentification correspond à ce qu'il y à ci-dessous :
 +
 +  gidNumber=[0-9]+\+uidNumber=**([0-9}+)**,cn=peercred,cn=external,cn=auth
 +
 +Ne pas oublier d'échapper le + qui fait la jonction entre le gidNumber et l'uidNumber. Le motif renvoyé contient donc tous les chiffres composant l'uidNumber (ceux du gidNumber ne sont pas conservés). Ce qui nous permettra donc de pouvoir mapper notre authentification Unix avec un utilisateur LDAP - si celui-ci existe en base. On ajoute la modification suivante à notre ''cn=config'' :
 +
 +<code|ldif /usr/local/lib/ldap/user_maps.ldif>
 +dn: cn=config
 +changetype: modify
 +add: olcAuthzRegexp
 +olcAuthzRegexp: gidNumber=[0-9]+\+uidNumber=**([0-9}+)**,cn=peercred,cn=external,cn=auth
 +  ldap:///ou=Users,dc=anarcha,dc=pink??one?(uidNumber=$1)
 +
 +</code>
 +
 +Et on vérifie avec ldapwhoami que tout va bien :
 +
 +  $ ldapwhoami
 +  SASL/EXTERNAL authentication started
 +  SASL username: gidNumber=1006+uidNumber=1007,cn=peercred,cn=external,cn=auth
 +  SASL SSF: 0
 +  dn:uid=okhin,ou=users,dc=anarcha,dc=pink
 +
 +Et voilà, nous sommes correctement identifié par LDAP. Nous n'avons qu'à peine effleuré l'auth dans LDAP, mais pour nos besoins actuels, c'est très largement suffisant.
 +
 +== Changement du schéma de hash de mots de passe par défaut ==
 +Par défaut, lorsau'il ets demandé à LDAP de hasher un mot de passe, il le fait avec {SSHA}. C'est un bon algorithme, mais il ne nous permet pas, par exemple, d'importer directement les hashs depuis /etc/shadow par exemple. Pour se faire, il suffit de lui dire d'utiliser CRYPT en lieu et place de SSHA.
 +
 +Le ldiff suivant de ldapmodify permet de faire cela
 +
 +<code|ldif>
 +dn: cn=config
 +changetype: modify
 +replace: olcPasswordHash
 +olcPasswordHash: {CRYPT}
 +-
 +add: olcPasswordCryptSaltFormat
 +olcPasswordCryptSaltFormat: $6$%.16s
 +
 +</code>
ateliers/serveurmail/ldap.1530191358.txt.gz · Dernière modification: 2018/06/28 15:09 de okhin