Outils pour utilisateurs

Outils du site


ateliers:serveurmail:ldap

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"
ateliers/serveurmail/ldap.1530132031.txt.gz · Dernière modification: 2018/06/27 22:40 de okhin