Connexion LDAP et Active Directory

Déléguez la vérification du mot de passe à votre serveur LDAP ou Active Directory, par organisation, avec filtre de recherche échappé, sémantique fail-closed et provisioning à la volée. Aucun agent à installer.

Avec une connexion LDAP configurée, les utilisateurs se connectent à Obexal avec leurs identifiants d'annuaire : Obexal vérifie le mot de passe auprès de votre serveur LDAP ou Active Directory au lieu d'un hash de mot de passe local. Aucun agent à installer dans votre réseau : Obexal se connecte directement à l'annuaire en LDAPS ou StartTLS, le serveur doit donc être joignable depuis votre déploiement Obexal. Il existe une connexion par organisation.

Le principe de l'authentification déléguée

Quand un utilisateur soumet le formulaire de mot de passe, et que le tenant a une connexion LDAP activée, Obexal effectue trois étapes auprès de l'annuaire :

Bind du compte de service : Obexal se lie avec le bindDn configuré et son mot de passe.
Recherche : l'utilisateur est cherché sous baseDn (sous-arbre entier) avec votre userFilter, où %s est remplacé par l'e-mail saisi à la connexion, échappé selon la RFC 4515 (aucune injection de filtre possible). Seuls le DN et l'attribut e-mail sont demandés. Un résultat ambigu (plus d'une entrée) est refusé. Chaque opération a un timeout de 10 secondes.
Bind utilisateur : Obexal se lie avec le DN trouvé et le mot de passe saisi par l'utilisateur. Le bind réussi est la preuve d'identité ; le mot de passe d'annuaire n'est jamais stocké, haché ni mis en cache par Obexal.

Un mot de passe vide est refusé avant même de contacter l'annuaire : sur beaucoup de serveurs (Active Directory compris), un bind vide réussit comme bind anonyme, ce qui serait sinon un contournement d'authentification.

Configurer la connexion

La configuration exige la permission tenant:manage (session console ou jeton d'API admin obx_) :

curl -sS -X PUT https://accounts.obexal.com/v1/admin/ldap \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN" -H 'Content-Type: application/json' \
  -d '{
    "enabled": true,
    "serverUrl": "ldaps://dc1.example.eu:636",
    "bindDn": "CN=svc-obexal,OU=Service Accounts,DC=example,DC=eu",
    "bindPassword": "'$LDAP_BIND_PASSWORD'",
    "baseDn": "DC=example,DC=eu",
    "userFilter": "(mail=%s)",
    "emailAttribute": "mail"
  }'
# 204

Champ	Signification
`serverUrl`	`ldaps://hôte:636` ou `ldap://hôte:389` (requis)
`startTls`	Élève une connexion `ldap://` en clair via StartTLS
`insecureSkipVerify`	Saute la vérification du certificat TLS. Développement uniquement
`bindDn`	Compte de service utilisé pour la recherche (requis)
`bindPassword`	Mot de passe du compte de service. Chiffré au repos. Vide à la mise à jour conserve l'existant ; requis à la création
`baseDn`	Base de recherche (requis)
`userFilter`	Filtre de recherche ; doit contenir `%s`, l'emplacement de l'e-mail échappé (requis)
`emailAttribute`	Attribut d'annuaire portant l'e-mail (défaut `mail`)

Pour Active Directory, un filtre comme (|(mail=%s)(userPrincipalName=%s)) retrouve l'utilisateur par adresse de boîte ou par UPN ; chaque %s reçoit l'e-mail échappé. GET /v1/admin/ldap retourne la configuration sans le bind password, et DELETE /v1/admin/ldap supprime la connexion.

Repli et comportement fail-closed

Le verdict de l'annuaire pilote strictement la suite de la connexion :

L'annuaire authentifie l'utilisateur : la connexion se poursuit (MFA, accès conditionnel).
L'utilisateur est absent de l'annuaire : Obexal se replie sur le flux de mot de passe local. C'est le seul repli, et il existe pour que les comptes purement locaux (le propriétaire de l'organisation, les admins de secours) continuent de fonctionner.
Tout le reste échoue fermé : mauvais mot de passe d'annuaire, serveur injoignable, échec TLS, résultat de recherche ambigu, ou bind password devenu indéchiffrable produisent un refus ferme, sans repli sur un mot de passe local. Un compte désactivé dans votre annuaire ne peut donc pas passer par un ancien mot de passe local. Chaque refus alimente le compteur de verrouillage du compte, comme tout échec de mot de passe.

Attention

Si votre serveur LDAP est hors service, les utilisateurs gérés par l'annuaire ne peuvent plus se connecter du tout. C'est voulu : la disponibilité ne s'échange jamais contre l'autorité de votre annuaire.

Le provisioning à la volée

Après un bind réussi, Obexal résout le compte par e-mail (pris dans l'emailAttribute de l'annuaire, ou l'e-mail saisi si cet attribut est vide) :

Un compte local avec cet e-mail existe : il est utilisé, et son e-mail est marqué vérifié (l'annuaire s'en porte garant).
Aucun compte n'existe : un compte est provisionné à la volée (JIT), avec l'e-mail déjà vérifié.

Connexions réussies, provisionnements et refus sont consignés dans le journal d'audit.

La MFA et les politiques s'appliquent toujours

L'annuaire ne remplace que le facteur primaire. Si le compte résolu a un facteur MFA actif, le défi survient après le bind, exactement comme après un mot de passe local : voir le point de passage MFA. Les règles d'accès conditionnel s'appliquent aussi. La politique de mot de passe d'Obexal ne régit pas les mots de passe d'annuaire ; ces règles vivent dans votre annuaire.

Limites, en toute honnêteté

Authentification uniquement : il n'y a pas de synchronisation d'annuaire. Groupes, attributs et états de compte ne sont pas importés, et il n'existe pas de synchronisation planifiée ; un utilisateur d'annuaire n'existe dans Obexal qu'après sa première connexion réussie. Pour synchroniser les profils, utilisez le SCIM entrant.
Une connexion LDAP par organisation.
La clé de recherche est l'adresse e-mail saisie à la connexion ; pas de connexion par identifiant court de type sAMAccountName.
Pas d'écriture de mot de passe en retour : les changements de mot de passe se font dans votre annuaire, pas dans Obexal.
Désactiver un utilisateur dans l'annuaire bloque sa connexion via l'annuaire, mais ne supprime pas son compte Obexal et ne révoque pas ses sessions existantes.