Ceci est une ancienne révision du document !
LDAP
LDAP est un serveur permettant de gérer des répertoires. Notre but ici et de pouvoir s'en servir pour s'identifier sur le serveur, afin de n'avoir qu'un seul endroit depuis lequel gérer les utilisatrices et les droits d'accès.
Nous connecterons donc le tour via PAM, afin de bénéficier au maximum des fonctionnalités d'Unix pour ces comptes.
Nous allons garder le schéma de données relativement simple, avec une ou Users pour les comptes, et une ou Groups pour gérer les groupes (administratrices, mais aussi plus tard, mailing lists par exemple).
Client graphique
Comme pour beaucoup de chose, il est possible de tout faire à la ligne de commande, avec les commandes du paquet ldap-utils
, mais pour ajouter beaucoup de monde, cela peut s'avérer rapidement fastidieux. Disposer d'un système graphique permet généralement de modifier facilement l'arbre du répertoire.
Sous GNU/Linux, le projet gnome propose LAT, qui s'installe avec la commande apt:
$ sudo apt install lat
.
KDE fournit un client aux fonctionnalité identique, Kldap, installable avec apt par exemple.
D'autres clients graphique existent et sont disponible pour toutes les plateformes.
Installation
Sur notre machine debian, il faut commencer par installer les paquets nécessaire pour faire tourner LDAP.
$ sudo apt install slapd ldap-utils
- ldap-utils fournit des commandes permettant de modifier un arbre LDAP (via ldapmodify par exemple).
- slapd est le nom du paquet debian pour le serveur openldap.
On conserve les choix par défaut et on donne un mot de passe au gestionnaire de l'arbre.
Pour créer le domaine dont nous aurons besoin, il faut reconfigurer slapd et garder les valeurs par défaut, sauf pour le nom de domaine (anarcha.pink dans notre cas), et le nom de l'organisation (Anarcha).
$ sudo dpkg-reconfigure slapd
Redémarrage et vérification que tout se passe bien avec systemctl.
$ sudo systemctl restart slapd $ sudo susytemctl 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 Wed 2018-06-27 17:03:09 CEST; 22min ago Docs: man:systemd-sysv-generator(8) Process: 18561 ExecStop=/etc/init.d/slapd stop (code=exited, status=0/SUCCESS) Process: 18568 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS) Tasks: 3 (limit: 4915) CGroup: /system.slice/slapd.service └─18576 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d [...]
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``.
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
Maintenant, il faut modifier la configuration de slapd afin de lui donner les valeurs nécessaires pour gérer des connexions tls. Cela se fait en utilisant ldapmodify sur l'arbre cn=config en passant via le protocole ldapi:\/\/\/ - qui est un accès par socket Unix au lieu de passer par l'interface réseau, tout en précisant que, comme il n'y a pas vraiment d'utilisateur pour le moment, nous voulons utiliser l'authentification Unix de SASL.
Toutes les commandes seront stockées dans un fichier ldif afin de pouvoir faciliter un peu l'utilisation de la ligne de commande.
- /usr/local/lin/ldap/letsencrypt.ldif
dn: cn=config add: olcTLSCipherSuite olcTLSCipherSuite: NORMAL - add: olcTLSCRLCheck olcTLSCRLCheck: none - add: olcTLSVerifyClient olcTLSVerifyClient: never - add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/letsencrypt/live/ldap.anarcha.pink/fullchain.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/letsencrypt/live/ldap.anarcha.pink/cert.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/letsencrypt/live/ldap.anarcha.pink/privkey.pem - add: olcTLSProtocolMin olcTLSProtocolMin: 3.3
Pour plus d'information sur l'utilité des clefs utilisées il faut se référer à 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``
<config|h /etc/default/slpad> […] SLAPD_SERVICES=“ldap:\/\/127.0.0.1:389\/ ldaps:\/\/\/ 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:\/\/\/.
Redémarrage et tests
Une fois ceci fait, redémarrons le service et vérifions qu'il est bien démarré.
$ sudo systemctl restart slapd $ sudo systemctl status slapd
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 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
SASL/EXTERNAL authentication started SASL username: gidNumber=1006+uidNumber=1007,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: dc=anarcha,dc=pink objectClass: top objectClass: dcObject objectClass: organization o: Anarcha dc: anarcha dn: cn=admin,dc=anarcha,dc=pink objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator
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.
$ openssl s_client --connect ldap.anarcha.pink:636 CONNECTED(00000003) depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = ldap.anarcha.pink verify return:1 --- Certificate chain 0 s:/CN=ldap.anarcha.pink i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 i:/O=Digital Signature Trust Co./CN=DST Root CA X3 --- Server certificate -----BEGIN CERTIFICATE----- [...] Certificat de ldap.anarcha.pink [...] -----END CERTIFICATE----- subject=/CN=ldap.anarcha.pink issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 3239 bytes and written 302 bytes Verification: OK --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 97D588825098C4361F4046846C5F7819F18656403B9EDB525F279CCB876AB426 Session-ID-ctx: Master-Key: 126ADE5FB2B02BF693212955F4DD151C8105A48FD9D1BECC886E63AB81065D6B9E0EB814C057DA6FF59FFF4800BA3E85 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1530115216 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: yes ---
Un SIGKILL permet de terminer la connexion.
Modifications des ACL
LDAP permet de restreindre l'accès à certains attributs, ou a des parties entières d'un arbre, en utilisant des règles de contrôle d'accès (ou ACL).
Il faut les ajouter à la base cn=config, mais attention. leur ordre est important, elles sont exécutée l'une après l'autre. Une documentation complète et touffue du fonctionnement des ACL est disponible sur le site du projet openldap.
Pour référence, voici les ACL telles que fournies après l'installation d'OpenLDAP, On utilise la commande suivante pour les voir :
$ sudo ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config olcAccess
# {0}config, config dn: olcDatabase={0}config,cn=config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break # {1}mdb, config dn: olcDatabase={1}mdb,cn=config olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to * by * read
Il y a deux bases concernées par les ACL. La première concerne cn=config et définit qui peut mdifier la base cn=config. En l'occurence, ici, on donne l'accès à root (gidNumber = 0 et uidNumber = 0), et personne d'autre n'y a accès.
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 acl commenté.
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.
Voici le fichier ldif à ajouter avec la commande ldapadd
- /usr/local/lib/ldap/organizational.ldif
dn: ou=Users,dc=anarcha,dc=pink ou: Users objectClass: organizationalUnit dn: ou=Groups,dc=anarcha,dc=pink ou: Groups objectClass: organizationalUnit
Nous utiliserons une syntaxe permettant de se connecter avec le compte admin.
$ ldapadd -xWD cn=admin,dc=anarcha,dc=pink -H ldapi:/// -f /usr/local/lib/ldap/organizational.ldif
Il aurait été possible d'exécuter la commande ainsi, évitant ainsi de devoir taper le mot de passe admin (si vous avez les droits sudo, vous pouvez exécuter les commandes ldapadd, ldapmodify, etc).
$ ldapadd -Y EXTERNAL -H ldapi:/// -f /usr/local/lib/ldap/organizational.ldif
Une recherche permet ensuite de vérifier que nos groupes ont bien été créé
$ ldapsearch -H ldapi:/// "(objectClass=organizationalUnit)" -b dc=anarcha,dc=pink
SASL/EXTERNAL authentication started SASL/EXTERNAL authentication started SASL username: gidNumber=1006+uidNumber=1007,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <dc=anarcha,dc=pink> with scope subtree # filter: (objectClass=organizationalUnit) # requesting: ALL # # Users, anarcha.pink dn: ou=Users,dc=anarcha,dc=pink ou: Users objectClass: organizationalUnit # Groups, anarcha.pink dn: ou=Groups,dc=anarcha,dc=pink ou: Groups objectClass: organizationalUnit # search result search: 3 result: 0 Success # numResponses: 3 # numEntries: 2
Nos OU ont été créées, tout va bien Nous allons pouvoir passer à la suite des opérations.
Groupe sudo
Nous allons ajouter un groupe dans l'arbre LDAP qui donnera les droits sudo aux personnes en ayant besoin, sur le même principe que le groupe sudo unix, donc avec le même gid.
Récupération du gid du groupe sudo. Il s'agît de la 3eme colonne dans la commande suivante :
$ getent group sudo sudo:x:27:some,username,here,but,i,removed,them,for,privacy
Il nous suffit ensuite de créer un groupe. La classe d'objet choisie est ``posixGroup``, elle permet d'associer un groupe à un champ gid, facilitant donc l'intégration dans unix.
- /usr/local/lib/ldap/groups.ldif
dn: cn=sudo,ou=Groups,dc=anarcha,dc=pink objectClass: top objectClass: posixGroup cn: sudo gidNumber: 27
La ligne vide en fin de fichier est importante, elle permet de dire aux commandes ldap qu'il s'agît de la fin d'une entité. On peut maintenant ajouter ce groupe à l'annuaire. En utilisant l'option -c on permet à la commande de continuer, même en cas d'erreur, ce qui s'avèrera pratique pour pouvoir ajouter d'autres groupes par la suite.
$ ldapadd -cxWD "cn=admin,dc=anarcha,dc=pink" -f groups.ldif Enter LDAP Password: adding new entry "cn=sudo,ou=Groups,dc=anarcha,dc=pink"