Chaque fois qu’on ajoute une nouvelle application dans un réseau, se pose la question de l’accès pour ses utilisateurs.

Bien sûr, toutes les applications peuvent gérer leur propre base de donnée des utilisateurs. Il suffit de créer des comptes pour chaque personne autorisée et ils pourront utiliser l’application (après avoir changé le mot de passe par défaut que vous avez utilisé bien sûr).

Mais à force d’installer des applications, vos utilisateurs se retrouvent avec autant de comptes qu’il faut gérer. C’est pénible pour eux (ne serait-ce que la gestion des mots de passes) et pour vous (gérer les entrées et sorties du personnel implique de créer et supprimer ces comptes).

Heureusement, toutes les applications un minimum sérieuses gèrent également une connexion avec un annuaire d’utilisateur centralisé. Habituellement avec LDAP parce qu’il marche plutôt bien et est supporté à la fois dans le monde Unix et Windows (via Active Directory).

C’est bien sûr le cas de grav (le CMS que nous utilisons) qui possède un plugin pour ça. Une fois installé et configuré, plus besoin de gérer les comptes dans grav, tout sera centralisé (dans notre AD).

Configuration du serveur

Dans les faits, j’avais d’abord installé le plugin, pour me rendre compte ensuite qu’il ne marchait pas car mon serveur n’était pas encore préparé pour le recevoir…

Module PHP LDAP

Plutôt que de réinventer la roue, les développeurs de grav se sont basés sur les fonctions déjà fournies par PHP. Ces fonctions sont regroupées dans un module spécifique, « php-ldap ».

Si votre serveur ne dispose pas déjà de ce module, il faut l’installer. Sur Ubuntu, la ligne de commande suivante vous fera l’affaire :

sudo apt-get install php-ldap

Avec lui, le module pourra effectuer les opérations LDAP dont il a besoin.

Installer le certificat racine de votre PKI

Comme vous avez fait les choses bien, votre annuaire n’écoute sûrement pas directement en LDAP mais sécurise ses communications avec TLS (en LDAPs ou via starttls).

Vous pourriez configurer le plugin de grav pour ne pas vérifier le certificat du serveur lorsqu’il s’y connectera mais ça annulerait complètement l’intérêt de TLS, un attaquant pourrait alors intercepter vos connexions.

La bonne pratique est donc de déployer votre certificat racine sur le serveur où grav fonctionne. Ainsi, lorsqu’il se connectera au serveur LDAP, il pourra vérifier que le certificat du serveur LDAP est bien signé par une autorité qu’il reconnaît.

Cette tâche est en fait simplissime, il suffit de copier votre CA dans le répertoire prévu pour ça puis de dire au système de mettre sa liste de CA à jours. En partant du principe que la CA est dans le fichier root.arsouyes.org.crt, ces deux commandes feront le travail :

sudo mv root.arsouyes.org.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

Installation du plugin

L’installation du plugin ne pose aucun problème particulier, il suffit de suivre les étapes habituelles des plugins.

En ligne de commande

Si vous préférez les invites de commandes aux interfaces graphiques, vous pouvez utiliser le gestionnaire de paquet intégré à grav. Une fois dans le répertoire où vous avez déployé grav, lancez la commande suivante :

./bin/gpm install login-ldap

Notez que si tous vos fichiers sont la propriété d’un autre utilisateur (i.e. www-data), vous devez passer par sudo pour lancer le gestionnaire avec l’identité de cet utilisateur. La commande est alors légèrement modifiée comme suit :

sudo -u www-data ./bin/gpm install login-ldap

Via l’interface graphique

Si vous préférez l’interface d’administration, vous pouvez passer par le menu « Plugins » à droite, puis le bouton « + Add » en haut, entrer le nom du plugin dans le champ de saisie puis cliquer sur le bouton « + Install ».

Vous pouvez aussi choisir de cliquer sur le lien « Login LDAP » pour voir les informations du plugin. Un autre bouton « + Install » sera disponible, vous pouvez cliquer sur celui-là aussi.

L’interface vous demande alors de confirmer, cliquez sur « ✔ Continue ».

Configuration via l’interface graphique

On peut maintenant se lancer dans la configuration du plugin. La documentation est claire, mais elle manque un peu de précisions (notamment pour l’AD). Un utilisateur était passé avant nous et avait documenté ses découvertes dans un ticket sur github mais comme il manque quelques détails, on a complété.

Avant de vous lancer, et comme ce genre de système ne tombe généralement pas en marche du premier coup, deux conseils pour vous faciliter la vie :

1. Utiliser deux navigateurs, l’un connecté avec le compte admin (et restez connecté quoi qu’il arrive), l’autre pour tester la connexion avec LDAP.
2. Désactiver la protection contre le brute force le temps des tests (sinon, grav vous bloquera au bout de 5 tentatives qui échouent). C’est dans la configuration du plugin « login », onglet « Security », passez la valeur de « Max logins count » à 0 le temps des tests.

Authentification

Rendez-vous sur la page de configuration du plugin. Pour ça, passez par le menu « Plugins » puis cliquez sur le lien « Login LDAP ».

Le premier onglet vous permet de configurer l’authentification via LDAP. Commençons par la première zone, « Server Configuration » pour les paramètres réseaux.

• Host : le nom d’hôte de votre serveur ldap, addc.arsouyes.org ou équivalent,
• Port : Comme je préfère LDAPs, 636,
• Use SSL : Yes, forcément.

Si vous préférez starttls, laissez le port à 389 et « Use SSL » à No. Par contre, vous devrez mettre « Negociate TLS » à Yes.

On poursuit avec la configuration LDAP proprement dite. Version Active Directory dans notre cas, voici les champs que nous avons du changer (les valeurs DN pour les utilisateurs et les groupes sont factices et à adapter à vos situations) :

• User DN : ça construit le nom d’utilisateur lors de la connexion à LDAP, [username]@arsouyes.org
• User Search DN : pour dire où chercher vos utilisateurs (certaines applications appellent ça base dn), OU=users,DC=arsouyes,DC=org
• Group Search DN : même chose, mais pour les groupes, OU=groups,DC=arsouyes,DC=org
• Group Query : requête pour lister les groupes d’un utilisateur, (&(cn=*)(member=[dn]))
• Group identifier : champ des groupes contenant leur nom que grav récupèrera, cn
• Username Mapping : champ contenant le nom d’utilisateur, sAMAccountName

Avec ces réglages, vos utilisateurs peuvent maintenant s’authentifier via leur compte active directory. Par contre, comme ils n’ont, pour l’instant, aucun droit, la page de login leur retournera une erreur, c’est normal, on va s’en occuper dans la prochaine étape.

Droits d’accès

La documentation n’est pas très claire sur ce point parce qu’on est à la frontière entre deux systèmes :

• Grav lui-même, qui a son propre système de groupes et permissions,
• Le plugin, de son côté, qui doit faire le lien avec des utilisateurs et groupes qui sont dans un LDAP.

Pour que ça tombe en marche, vous devez donc dire au plugin comment ajouter les droits à vos utilisateurs, et pour ça, on se rend dans l’onglet « advanced » et plus particulièrement le champ « Group Access Level » pour les adapter à votre cas.

Voici une adaptation des arsouyes. webmaster est en fait le nom d’un groupe de l’Active Directory comprenant les comptes autorisés à se connecter à l’application grav en tant qu’administrateurs :

webmasters:
    admin:
        login: true
        super: true
    site:
        login: true

La documentation (qui suit le champ de saisie) le dit : ça ne concerne que les groupes LDAP. Inutile donc de tester des valeurs dans « Default Groups » en espérant que ça utilise les informations de ce champs car le groupe par défaut n’est utilisé que si votre utilisateur n’a pas de groupe dans LDAP (c’est rarement le cas) et que le groupe correspondant est défini dans grav lui-même.

Fichier de configuration

Si vous ne voulez pas passer par l’interface graphique du site pour configurer le plugin, vous pouvez directement éditer le fichier de configuration du plugin. Il se trouve dans le fichier user/config/plugins/login-ldap.yaml. Voici le notre une fois les étapes précédentes terminées (vous devriez donc l’adapter avec vos particularités) :

enabled: true
host: addc.arsouyes.org
port: 636
version: 3
ssl: true
start_tls: false
opt_referrals: false
user_dn: '[username]@arsouyes.org'
search_dn: 'OU=users,DC=arsouyes,DC=org'
group_dn: 'OU=groups,DC=arsouyes,DC=org'
group_query: '(&(cn=*)(member=[dn]))'
group_indentifier: cn
map_username: sAMAccountName
map_fullname: 'givenName lastName'
map_email: mail
map_dn: distinguishedName
save_grav_user: false
store_ldap_data: false
default_access_levels:
  groups:
    - ldap_users
  access:
    site:
      login: 'true'
    groups: "webmasters:\n    admin:\n      login: true\n      super: true\n    site:\n      login: true\n"
blacklist_ldap_fields: null

Et après ?

Maintenant, vos utilisateurs peuvent s’authentifier avec leur compte active directory sur votre application grav. Vous pouvez même utiliser les groupes dans votre AD pour gérer leur droits d’accès (en adaptant un peu plus notre exemple bien sûr).

Pour la petite histoire, lorsque nous avions testé ce plugin, en juillet 2020, nous étions tombé sur un bogue. Lorsqu’un utilisateur se déconnecte, le système plante… C’était du au plugin qui continuait de vouloir authentifier l’utilisateur (vide puisqu’il s’était déconnecté). Quelqu’un s’en est rendu compte en mars 2020 (#14) et une correction avait été développée. Elle est maintenant intégrée au plugin depuis novembre 2020.

Vous pouvez aussi bénéficier de synergie avec d’autres systèmes ; si vous versionnez le contenu du site via le plugin git-sync l’auteur du commit peut être l’utilisateur connecté. Pour peu que votre GitLab soit également connecté au LDAP, ils seront en commun 😉.