Stage 2 : Vikunja

DGA MI - Pôle Sup de La Salle

🌍 Introduction

L'activation du protocole LDAP permet de centraliser la gestion des utilisateurs de la plateforme. Une fois configuré, les collaborateurs peuvent se connecter à Vikunja avec leurs identifiants réseau habituels, sans avoir à créer de compte local.

⚙️ 1. Principe de fonctionnement

Lorsqu'un utilisateur tente de se connecter, le processus suivant s'enclenche :

Vikunja contacte le serveur LDAP via un compte "lecteur" (Bind User).
Il cherche l'utilisateur dans l'annuaire via son identifiant de connexion.
Si le mot de passe est correct, Vikunja crée ou met à jour le profil local (nom, email).
Si la synchronisation des groupes est activée, l'utilisateur est automatiquement ajouté aux Équipes Vikunja correspondantes.

Preuve d'authentification : Différenciation des comptes Locaux et LDAP

Cette vérification en ligne de commande démontre la création automatique du profil. On observe distinctement la différence entre l'utilisateur "yann" créé localement (Issuer: local) et "y.coudrais" importé depuis l'Active Directory (Issuer: ldap).

👥 2. Synchronisation des Groupes (Équipes)

Une fonctionnalité avancée de l'intégration LDAP de Vikunja est la gestion des équipes.

groupsyncenabled : Active la création automatique d'équipes basées sur vos groupes LDAP.
groupsyncfilter : Filtre pour cibler uniquement certains groupes (ex: (objectClass=group)).

Preuve de synchronisation : Active Directory vers Vikunja

1. Active Directory : Groupe avec ses membres

2. Vikunja : Équipe correspondante synchronisée

Grâce au filtre LDAP, les membres ajoutés dans le groupe de sécurité AD sont automatiquement intégrés dans l'équipe de l'application Vikunja lors de leur connexion.

🔧 3. Paramètres détaillés (config.yml)

A. Connexion et Sécurité

Paramètre	Description
enabled	Active ou désactive le module LDAP (`true` / `false`).
host	Adresse IP ou FQDN du serveur (ex: `pc.active.directory`).
port	Port de connexion (389 par défaut).
usetls	À mettre sur `false` si vous n'utilisez pas de certificat SSL sur le port 389.

B. Compte de liaison (Bind User)

binddn : Le chemin complet du compte de service (ex: CN=admsvc-vikunja,...).
bindpassword : Le mot de passe associé à ce compte.
basedn : La racine de recherche (ex: DC=domaine,DC=local).

C. Filtres et Attributs

userfilter : La règle pour trouver l'utilisateur. Pour AD, on utilise (&(objectClass=user)(sAMAccountName=%[1]s)).
username : L'identifiant (souvent sAMAccountName ou uid).
mail : L'attribut email de l'annuaire (Indispensable).

📄 4. Exemple de configuration (Active Directory)

Voici le bloc de configuration YAML complet intégré dans le fichier config.yml :

auth:
  ldap:
    enabled: true
    host: pc.active.directory
    port: 389
    usetls: false 
    verifytls: false 
    binddn: "CN=admsvc-vikunja,OU=Utilisateurs,DC=active,DC=directory"
    bindpassword: mdp_svc-compte
    basedn: "DC=active,DC=directory"
    userfilter: "(&(objectClass=user)(sAMAccountName=%[1]s))"
    attribute:
      username: sAMAccountName
      mail: mail
    groupsyncenabled: true
    groupsyncfilter: "(objectClass=group)"

Le compte de service (Bind User) dans l'Active Directory

Ce compte dédié dispose des droits de lecture sur l'annuaire pour permettre à l'application de vérifier les identifiants.

💡 5. Conseils et Bonnes Pratiques

⚠️ L'email est critique

Si un utilisateur LDAP n'a pas d'adresse mail renseignée dans l'annuaire Active Directory, la connexion échouera, car Vikunja en exige une obligatoirement dans sa base de données.

Test de connexion : Vérifiez vos accès (Bind DN et Mot de passe) avec un outil tiers avant de redémarrer le service pour gagner du temps.
Application des paramètres : Toute modification du fichier config.yml nécessite de redémarrer le conteneur avec la commande :

podman restart vikunja