Chez DYB, nous déployons régulièrement des solutions d’authentification unifiée (SSO) pour nos clients, avec des connecteurs LDAP/Active Directory vers des applications métiers ou des portails internes.
Un comportement souvent méconnu d’Active Directory peut pourtant provoquer des bugs étranges : un utilisateur semble ne pas appartenir à un groupe, alors qu’il y est bien affecté dans l’AD.

Le cas concret

Dans Active Directory, chaque utilisateur a un groupe principal (Primary Group), défini par l’attribut primaryGroupID.
Par défaut, ce groupe est Domain Users.
Problème : ce groupe principal n’apparaît jamais dans l’attribut memberOf.

Or, la plupart des solutions d’authentification (dont Authentik, mais aussi beaucoup d’autres services compatibles LDAP) se basent sur memberOf pour déterminer les rôles et autorisations d’un utilisateur.

Résultat :

  • Si votre utilisateur a pour groupe principal un groupe sensible (ex : Admins), ce groupe ne sera pas visible côté LDAP.
  • Votre outil SSO considérera que l’utilisateur n’est pas membre du groupe, et lui retirera automatiquement les droits.
  • D’où des comportements incompréhensibles : deux comptes configurés de la même façon n’ont pas les mêmes droits dans les applications.

Exemple typique

  • Utilisateur cfleur → groupe principal = Domain Users, membre de Dyb-Developpeurs→ visible dans memberOf, tout fonctionne.
  • Utilisateur aperrot → groupe principal = Dyb-Developpeurs→ ce groupe n’apparaît pas dans memberOf, l’outil SSO ne lui attribue aucun droit, et le retire même s’il est ajouté manuellement.

Comment corriger le problème ?

La meilleure pratique est simple :

  • Laissez Domain Users comme groupe principal pour tous vos comptes.
  • Gérez vos droits via l’appartenance à des groupes secondaires, qui seront bien visibles dans memberOf.

Modifier le primaryGroupID est rarement justifié, et peut provoquer exactement ce type d’erreurs dans vos applications connectées.

À retenir

  • Le Primary Group d’un utilisateur AD n’est pas exposé dans memberOf.
  • Les solutions SSO qui se basent uniquement sur memberOf ne verront donc pas ces groupes.
  • Pour éviter les bugs d’intégration, gardez Domain Users comme groupe principal, et attribuez les droits via des groupes standards.

🔒 Chez DYB, nous accompagnons les entreprises dans la mise en place de solutions SSO robustes et sécurisées, en évitant ce type de pièges cachés.