Aller au contenu principal

LDAP

Cette section décrit le mécanisme d'authentification LDAP dans Sync-in.

La configuration se fait dans environment.yaml, voir la section LDAP.


Flux d'authentification

Le flux d'authentification LDAP est le suivant :

  1. L'utilisateur saisit son identifiant (login ou email) et son mot de passe.
    • Les comptes invités (guests) et les scopes applicatifs (app passwords) passent directement par l'authentification locale.
  2. Sync-in prépare l'identifiant LDAP (UPN ou DOMAIN\user pour Active Directory) et tente un bind.
  3. Sync-in recherche l'utilisateur dans l'annuaire LDAP via le filtre calculé et les attributs requis.
  4. Si l'authentification est valide, Sync-in synchronise le compte local ou le crée si nécessaire.
  5. Le rôle administrateur peut être attribué via un groupe LDAP.
  6. En cas d'indisponibilité LDAP, un fallback local peut être autorisé (voir Break-glass).

Configuration

Exemple minimal :

auth:
provider: ldap
ldap:
servers: [ ldap://localhost:389 ]
baseDN: ou=people,dc=ldap,dc=sync-in,dc=com
attributes:
login: uid
email: mail

Attributs et normalisation

Les attributs suivants doivent être présents pour l'entrée LDAP :

  • attributes.login : utilisé pour le login local.
  • attributes.email : utilisé pour l'email local.

Le login local est normalisé : si l'identifiant est fourni au format DOMAIN\user, seul user est stocké en local.
Le champ memberOf est normalisé en liste de valeurs et de CN, ce qui permet les vérifications de groupe.
Si options.adminGroup est défini et que l'attribut memberOf ne permet pas de vérifier l'appartenance au groupe, Sync-in tente une recherche groupOfNames ciblée pour ce groupe.


Compte de service

Par défaut, Sync-in tente un bind direct avec les identifiants fournis par l'utilisateur.
Un compte de service peut être défini pour effectuer les recherches LDAP :

auth:
ldap:
serviceBindDN: cn=syncin,ou=services,dc=ldap,dc=sync-in,dc=com
serviceBindPassword: LDAPServiceBindPasswordToChange

Avec un service bind :

  • Bind initial avec le compte de service.
  • Recherche de l'utilisateur via attributes.login + baseDN (+ filter).
  • Rebind avec le DN trouvé et le mot de passe saisi.

Sans service bind :

  • Bind direct avec l'utilisateur (DN construit ou login AD).
  • Recherche de l'utilisateur LDAP pour synchroniser les attributs.

Particularités Active Directory

Si attributes.login vaut sAMAccountName ou userPrincipalName, Sync-in adapte la connexion :

  • userPrincipalName : un suffixe peut être ajouté via upnSuffix (ex. user@sync-in.com).
  • sAMAccountName : un préfixe peut être ajouté via netbiosName (ex. SYNC_IN\user).

Dans ce mode, le bind utilisateur se fait directement avec le login fourni (format UPN ou DOMAIN\user).

Le filtre de recherche est automatiquement adapté :

  • AD : (sAMAccountName=...) OR (userPrincipalName=...) OR (mail=...)
  • LDAP générique : (uid=...) OR (cn=...) OR (mail=...)

Rôles administrateurs

Si options.adminGroup est défini, Sync-in vérifie l'appartenance de l'utilisateur :

  • via memberOf si présent,
  • sinon via une recherche groupOfNames (utile quand memberOf n'est pas exposé).

Si la recherche de groupes n'est pas possible avec l'utilisateur, utilisez un compte de service.

Si options.adminGroup n'est pas défini, les comptes admin existants conservent leur rôle et ne peuvent pas être rétrogradés via LDAP.


Break-glass (fallback local)

En cas d'indisponibilité LDAP (erreur de connexion, service down), Sync-in peut autoriser une authentification locale par mot de passe :

  • Toujours autorisée pour les comptes administrateurs (break-glass), y compris en cas d'échec LDAP.
  • Pour les autres utilisateurs, autorisée uniquement si l'échec est lié à une indisponibilité LDAP et si options.enablePasswordAuthFallback est activé.

Ce mécanisme permet d'assurer la continuité d'accès administratif en cas d'indisponibilité de l'annuaire.


Synchronisation des comptes

Lors d'une connexion réussie :

  • Si l'utilisateur n'existe pas et autoCreateUser est activée, Sync-in crée un compte local.
  • Le login local est dérivé de attributes.login.
  • L'email est dérivé de attributes.email (obligatoire).
  • Les champs nom/prénom sont dérivés de givenName + sn, ou displayName, ou cn.
  • Les permissions initiales proviennent de autoCreatePermissions.

Disponibilité et erreurs

Les erreurs d'identifiants LDAP entraînent un échec de l'authentification.
Les erreurs de connectivité LDAP sont considérées comme une indisponibilité du service et peuvent activer le fallback local (voir Break-glass).
Les comptes invités et les scopes applicatifs n'utilisent pas LDAP et valident toujours via l'authentification locale.

Sécurité

Il est fortement recommandé d'utiliser LDAPS (ldaps://) ou StartTLS afin de protéger les identifiants transmis lors du bind LDAP.