Si vous utilisez Active Directory sur site, quelques centaines d'applications internes et une équipe de sécurité qui n'autorise aucun nouvel outil à écrire dans AD ou à transformer l'annuaire en base de données d'applications, la plupart des plateformes d'identité modernes vous expliqueront poliment que ce n'est pas leur fonctionnement. Nous avons eu cette conversation récemment avec un groupe européen de plusieurs milliers d'utilisateurs qui exécutait sa pile d'identité sur site. Voici comment la contrainte est réellement résolue, et pourquoi elle est beaucoup moins exotique que ce que les fournisseurs veulent bien laisser entendre.

L'exigence dont tout le monde essaie de te dissuader

Le groupe disposait déjà d'un produit de gestion d'accès. Il gérait les mots de passe à usage unique et rien d'autre, il était instable et l'équipe ne pouvait pas l'utiliser sans aide extérieure. Ils voulaient s'en sortir et ils avaient une liste claire : authentification unique (SSO) sur un grand parc d'applications via SAML et OIDC, un second facteur par TOTP et push, accès conditionnel, création de rapports d'utilisation avec exportation vers leur SIEM, un portail unique pour les utilisateurs, et la possibilité d'intégrer des sous-traitants externes via le même fournisseur d'identité plutôt que par une porte dérobée distincte.

Jusqu'à présent, ordinaire. Puis vint la partie qui décide quels fournisseurs sont encore dans la pièce.

La nouvelle couche n'était pas autorisée à écrire dans l'Active Directory ni à y stocker ses propres données opérationnelles. L'Active Directory devait rester la source faisant autorité et rester en lecture seule pour la couche RCDevs. Les utilisateurs et les groupes pouvaient être synchronisés depuis l'Active Directory vers OpenLDAP, et les mots de passe pouvaient être validés par rapport à l'Active Directory, mais l'annuaire de production lui-même ne devait pas servir de backend de stockage pour l'authentification multifactorielle (MFA), l'authentification unique (SSO), les politiques ou la configuration.

Ce n'est pas une préférence originale, et une bonne équipe ne devrait pas avoir à la défendre. Chaque endroit supplémentaire où les données d'authentification sont traitées doit être explicite, contrôlé et justifié. Garder AD comme référence faisant autorité et hors du chemin d'écriture est une décision de contrôle délibérée. Le problème est que de nombreux produits d'identité axés sur le cloud ne correspondent pas bien à cette contrainte. Leur modèle d'exploitation normal consiste à synchroniser votre répertoire sur site vers un locataire de cloud d'un fournisseur et à y exécuter l'authentification unique, l'authentification multifacteur, les politiques, l'état d'inscription, les rapports et parfois la gestion du cycle de vie. Certains peuvent laisser AD comme référence faisant autorité et éviter d'y écrire, mais le cloud du fournisseur devient toujours le plan de contrôle opérationnel de l'identité. Pour un client qui souhaite qu'AD soit en lecture seule et que les données opérationnelles d'authentification multifacteur/authentification unique restent sur site, cela ne respecte pas l'architecture qu'il essaie d'imposer. Le client en évaluait un de ceux-là en parallèle, ce qui explique en partie pourquoi l'exigence était sur la table.

Maintenez l'AD faisant autorité et hors du chemin d'écriture

La solution consiste à séparer deux questions que les fournisseurs aiment fusionner : où se trouve l'autorité sur l'identité, et ce dont la couche MFA et SSO a besoin pour fonctionner.

Active Directory (AD) reste la référence en matière d'utilisateurs et de groupes. Les comptes et les appartenances à des groupes concernés sont synchronisés vers RCDevs OpenLDAP, où la couche d'identité peut les utiliser sans transformer AD en une base de données d'application. Concrètement, AD reste la source de vérité en amont, tandis qu'OpenLDAP devient l'annuaire opérationnel pour la couche d'authentification multifactorielle (MFA) et d'authentification unique (SSO).

Lors de la connexion, le mot de passe du domaine est vérifié en se liant à son compte correspondant dans AD. Si AD valide le mot de passe, le dernier mot de passe validé est stocké sur l'objet utilisateur OpenLDAP répliqué. Il s'agit d'une mesure de résilience intentionnelle : elle permet à la couche d'authentification de continuer à fonctionner si AD devient indisponible par la suite.

Cela rend la limite claire. La validation du mot de passe provient toujours de l'AD lorsque l'AD est disponible, et le dernier mot de passe validé est conservé dans la couche OpenLDAP sur site pour assurer la continuité.

Toutes les autres informations dont les couches MFA et SSO ont besoin, notamment les secrets token, l'état d'inscription, les politiques utilisateur, les politiques de groupe, les politiques client, la configuration de l'IdP et les données de configuration RCDevs, sont également stockées dans OpenLDAP. AD reste en dehors du chemin d'écriture : il reste la source d'identité faisant autorité, mais la couche d'authentification et de SSO se trouve désormais à côté de lui plutôt qu'à l'intérieur.

C'est tout l'intérêt, et c'est une façon prise en charge d'exécuter la suite, pas une solution de contournement que nous avons improvisée. Une couche d'identité forte n'a pas à posséder votre répertoire pour le protéger.

Un fournisseur d'identité devant le domaine

Une fois la question des données réglée, le reste est un travail d'intégration. Nous avons mis en place le fournisseur d'identité parlant SAML et OIDC, devant l'ensemble des applications, de sorte qu'un utilisateur s'authentifie une fois et accède aux applications auxquelles il a droit. Les passerelles VDI et d'accès à distance ont été intégrées en tant que fournisseurs de services SAML. Le second facteur a été fourni via TOTP et push, en utilisant le logiciel gratuit Application OpenOTP Token, donc il n'y avait pas de matériel par utilisateur à acheter.

Les prestataires externes étaient également représentés dans Active Directory ; ils s'authentifient donc via ce même fournisseur d'identité, avec la même authentification multifactorielle, plutôt que par un mécanisme parallèle que personne ne contrôle. RCDevs avait initialement proposé de stocker les comptes des prestataires externes dans OpenLDAP plutôt que dans Active Directory, afin de ne conserver que les comptes internes dans AD. Cependant, le client a préféré provisionner et gérer les comptes des prestataires directement depuis Active Directory, ce qui était à la fois compréhensible et entièrement pris en charge.

Les stratégies d'accès conditionnel permettent des connexions de routine sans friction, tandis que les connexions inhabituelles sont remises en question. Et comme l'ensemble fonctionne sur site, la piste d'audit et l'exportation SIEM restent au sein de leur propre environnement. Pour un groupe européen qui souhaite que ses données d'authentification restent sous son propre toit, c'est la raison de procéder ainsi.

Il fallait également résoudre un problème d'autonomie, car l'équipe n'avait pas été en mesure d'utiliser son ancien outil de manière autonome. Grâce à l'inscription en libre-service à token et à la délégation des rôles du service d'assistance, les opérations quotidiennes liées à l'authentification multifactorielle ne passent plus par un fournisseur. L'équipe peut désormais assister les utilisateurs et gérer elle-même la couche d'identité, tandis que la gestion des mots de passe Active Directory reste en dehors du périmètre du déploiement.

Un portail d'authentification unique pour plus de 200 applications internes

Une exigence ne correspondait à aucune fiche produit à l'époque. Avec plus de deux cents applications web dans le système, le groupe souhaitait que les utilisateurs accèdent à une page unique après leur connexion, voient les applications qui leur sont disponibles et en ouvrent une en un clic. Moins un écran de connexion qu'un annuaire d'applications interne, avec des droits qui varient considérablement d'une équipe à l'autre.

Cette exigence a servi de base à ce qui est aujourd’hui le portail des raccourcis d’application dans RCDevs Identity Provider 1.6.15. Le portail présente des raccourcis d'application à l'utilisateur authentifié en fonction de ses droits. Chaque raccourci est une icône qui redirige l'utilisateur vers l'URL de connexion de l'application. L'application redirige ensuite l'utilisateur vers l'IdP via SAML ou OpenID Connect. Étant donné que l'utilisateur dispose déjà d'une session authentifiée sur le portail, l'IdP achève le flux SSO et renvoie l'utilisateur vers l'application en tant qu'utilisateur authentifié.

La visibilité et l'accès suivent l'appartenance aux groupes d'annuaires, de sorte que ce que chacun voit et ouvre est géré exactement de la manière dont le groupe gouverne tout le reste.

C'est le genre de choses qui distingue une plateforme adaptable d'une plateforme fermée. L'exigence était raisonnable et proche de ce que l'IdP faisait déjà, donc l'étendre était la bonne solution, pas un “ ce n'est pas pris en charge ”.”

Mise en place de la réinitialisation de mot de passe en libre-service contre un AD en lecture seule

Au début de la POC, la principale complexité tournait autour du comportement de synchronisation, du mappage des groupes et de la résilience opérationnelle lorsque la disponibilité de l'annuaire changeait. Le mécanisme de synchronisation s'appuyant sur Active Directory comme source faisant autorité, les utilisateurs sont automatiquement maintenus dans OpenLDAP en fonction de leur présence et de leur statut dans AD. Les questions telles que quels groupes AD faisaient autorité, quels comptes d'employés et de contractuels devaient être synchronisés, et comment la plateforme devait se comporter en cas d'indisponibilité d'AD étaient le genre de considérations opérationnelles qui n'apparaissent généralement que dans un environnement de production réel plutôt que dans un environnement de démonstration.

Sur le plan opérationnel, la gestion du cycle de vie des comptes était finalement assurée par le mécanisme de synchronisation natif lui-même. Aucun script personnalisé n'était requis, car le processus de synchronisation s'exécute automatiquement toutes les heures et maintient OpenLDAP aligné sur l'état d'Active Directory.

Si vous portez la même contrainte

Les questions à poser à tout fournisseur d'identité sont courtes, et les réponses permettent de trier les outils compatibles avec l'environnement sur site de ceux qui doivent devenir votre nouveau système d'enregistrement :

• Où résident physiquement mes données utilisateur une fois votre produit en place ?
• Mon Active Directory peut-il rester faisant autorité et en lecture seule, tandis que les utilisateurs et les groupes sont synchronisés dans un répertoire local ?
• Écrivez-vous dans l'AD ou stockez-vous la configuration du produit dans l'AD ?
• Comment validez-vous les mots de passe, mettez-vous des données en cache, et où ces données sont-elles stockées exactement ?
• Cette solution est-elle entièrement sur site ? 

Nous sommes heureux d'être interrogés sur les cinq.