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 :
- 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.
- Sync-in prépare l'identifiant LDAP (UPN ou
DOMAIN\userpour Active Directory) et tente un bind. - Sync-in recherche l'utilisateur dans l'annuaire LDAP via le filtre calculé et les attributs requis.
- Si l'authentification est valide, Sync-in synchronise le compte local ou le crée si nécessaire.
- Le rôle administrateur peut être attribué via un groupe LDAP.
- 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é viaupnSuffix(ex.user@sync-in.com).sAMAccountName: un préfixe peut être ajouté vianetbiosName(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
memberOfsi présent, - sinon via une recherche
groupOfNames(utile quandmemberOfn'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.enablePasswordAuthFallbackest 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
autoCreateUserest 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, oudisplayName, oucn. - 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.