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édentesRévision précédente
Prochaine révision
Révision précédente
Dernière révisionLes deux révisions suivantes
ateliers:serveurmail:ldap [2018/06/28 19:57] – Ajout d'une liste de services utilisant ldap okhinateliers:serveurmail:ldap [2019/10/28 19:47] – Ajout du schéma de mot de passe par défaut. okhin
Ligne 58: 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 97: 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 115: 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 139: 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 201: 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 222: Ligne 230:
 Il faut cependant supprimer le schéma NIS d'abord, puis activer le schéma 2307bis. 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. Pensez à sauvegarder vos données AVANT de faire les modifications de schéma ci-dessous.
 </WRAP> </WRAP>
Ligne 243: Ligne 251:
 </code> </code>
  
-Il faut maintenant aller modifier la configuration des schémas. Elle est disponible sous ``/etc/ldap/slapd.d/cn=config/cn=schema/``+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) Ce répertoire contient des fichiers ldif ordonnés (commençant par {Z}avec Z le numéro d'ordre)
Ligne 261: Ligne 269:
 $ sudo rm /etc/ldap/slapd.d/cn\=config/cn\=schema/cn\=\{2\}nis.ldif $ 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 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 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 11381 juin  27 16:24 cn={1}cosine.ldif
Ligne 267: Ligne 275:
 </code> </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émade 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 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> </WRAP>
  
Ligne 307: Ligne 315:
 </code> </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.+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> <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 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 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 -rw------- 1 openldap openldap  9609 juin  28 16:07 cn={3}rfc2307bis.ldif
 </code> </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 343: 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 ===
Ligne 486: 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 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>
ateliers/serveurmail/ldap.txt · Dernière modification : 2019/10/28 19:48 de okhin