Différences

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

--- ateliers:serveurmail:ldap [2018/07/01 21:07] – Some syntaxes okhin
+++ ateliers:serveurmail:ldap [2019/10/28 19:47] – Ajout du schéma de mot de passe par défaut. okhin
@@ Ligne 58: / Ligne 58: @@
 [...]
 </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 ===
@@ Ligne 99: / Ligne 106: @@
 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:\/\/\/"
 [...]
+</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:\/\/\/.
@@ Ligne 222: / Ligne 230: @@
 Il faut cependant supprimer le schéma NIS d'abord, puis activer le schéma 2307bis.
-<WRAP center round alert 60%>
+<WRAP center round alert 80%>
 Pensez à sauvegarder vos données AVANT de faire les modifications de schéma ci-dessous.
 </WRAP>
@@ Ligne 261: / Ligne 269: @@
 $ 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=schematotal 32
+$ 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
@@ Ligne 267: / Ligne 275: @@
 </code>
-<WRAP center round info 60%>
+<WRAP center round info 80%>
-Sur notre configuration, les ACL étaient définie sur un attribut shadowLastChange fourni par le schéma NIS, il a é nécessaire d'éditer le fichier contenant ls ACL avant de pouvoir redémarrer ldap (fichier situé dans ''/etc/ldap/slapd.d/cn=config/olcDatabase=\{1\}mdb.ldif'' dans notre cas)
+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>
@@ Ligne 310: / Ligne 318: @@
 <code|bash>
-$ sudo ls /etc/ldap/slapd.d/cn\=config/cn\=schema/ -ltotal 44
+$ 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
@@ Ligne 316: / Ligne 324: @@
 -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 ===
@@ Ligne 486: / Ligne 499: @@
   Enter LDAP Password:
   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 scé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>