Active Directory Federation Services : fonctionnement, déploiement et alternatives cloud
ADFS est un service de fédération qui authentifie l’utilisateur auprès de son annuaire d’entreprise et délivre un jeton signé.
- Le mot de passe n’est jamais transmis à l’application cible.
- ADFS agit comme un proxy d’authentification entre Active Directory et l’application.
- Le jeton signé transporte les revendications de l’utilisateur.
- L’application lit les revendications sans interroger directement l’annuaire.
- L’approbation fédérée établit le lien de confiance avec l’application.
- Une seule authentification ouvre toutes les applications fédérées en SSO.
Comment fonctionne Active Directory Federation Services (ADFS)
Le processus d’authentification fédérée en 5 étapes
Le mécanisme d’ADFS repose sur une approbation fédérée entre l’organisation et l’application cible. Concrètement, l’utilisateur ne transmet jamais son mot de passe à l’application : il s’authentifie auprès de son annuaire d’entreprise, qui délivre ensuite un jeton de sécurité signé contenant ses droits.
- Demande d’accès utilisateur : l’utilisateur tente d’ouvrir une application de confiance
- Redirection vers ADFS : l’application renvoie la demande au serveur de fédération
- Vérification annuaire AD : ADFS contrôle les identifiants dans Active Directory
- Émission jeton signé : un jeton contenant les revendications est généré
- Accès application accordé : l’application valide le jeton et ouvre la session
Le modèle basé sur les revendications et l’approbation fédérée
ADFS agit comme un proxy d’authentification entre Active Directory et l’application cible. Il ne se contente pas de confirmer une identité : il vérifie celle-ci via les données de l’annuaire d’entreprise, puis assemble un jeton sécurisé signé propre à chaque utilisateur.
Ce jeton transporte des revendications, c’est-à-dire des informations d’authentification comme le nom complet, l’identifiant, le téléphone ou l’email. L’application de confiance lit ces revendications sans interroger directement l’annuaire, ce qui simplifie l’intégration des services internes comme externes.
Le lien de confiance entre ADFS et l’application s’appelle une approbation fédérée (Federated Trust). Une fois établie, elle permet un SSO transparent : l’utilisateur s’authentifie une seule fois et accède à l’ensemble des applications fédérées.
Pourquoi les entreprises utilisent-elles ADFS en environnement hybride
Dans un système d’information hybride, les collaborateurs jonglent entre des applications internes hébergées sur site et des services cloud externes. ADFS répond à ce besoin en centralisant l’authentification : l’utilisateur s’identifie une seule fois auprès de son annuaire d’entreprise et accède ensuite à l’ensemble de ses ressources, sans ressaisir ses identifiants.
- Authentification unique interne et externe : un seul jeu d’identifiants pour toutes les applications fédérées.
- Réduction des coûts helpdesk : moins de réinitialisations de mots de passe, donc moins de tickets et de temps perdu.
- Applications on-premise et cloud : ADFS fait le lien entre les deux mondes via des jetons signés.
- Héritage AD et IWA : ces mécanismes, largement utilisés avant 2003, restent insuffisants pour l’authentification externe moderne.
- Pertinence si le SI est majoritairement sur site : la solution garde tout son sens quand l’infrastructure reste interne.
Un prolongement naturel d’Active Directory
Le rôle ADFS est apparu avec Windows Server 2008, à une époque où l’authentification Windows intégrée (IWA) ne couvrait pas les applications externes. Les entreprises déjà équipées d’un Active Directory ont donc adopté ADFS pour étendre leur annuaire existant sans tout reconstruire. Cette continuité explique en grande partie son adoption dans les parcs hybrides.
Un choix piloté par le contexte, pas par la mode
Pour une organisation dont les applications critiques tournent encore sur des serveurs internes, migrer vers une solution entièrement cloud implique souvent des coûts et des risques. ADFS reste alors un compromis rationnel, à condition d’accepter sa maintenance et sa complexité. Le choix dépend donc surtout de la répartition réelle entre applicatifs sur site et services distants.
Limites, risques et inconvénients d’ADFS
ADFS impose une infrastructure lourde : une licence Windows Server et un serveur dédié sont nécessaires, avec un proxy en zone exposée. La maintenance exige du personnel hautement qualifié, ce qui pèse sur le budget.
La configuration reste complexe : chaque nouvelle application ajoutée à une approbation fédérée demande du temps, et l’attribut NameID doit être correctement mappé en réponse SAML. En installation standard, la sécurité n’est pas optimale et un durcissement manuel est requis, comme le passage à SHA-256.
À découvrir aussi
Quand on durcit une infrastructure d’authentification, la vigilance sur les failles reste essentielle : un VOC en cybersécurité cartographie les vulnérabilités avant leur exploitation. Et si un service protégé refuse l’accès, mieux vaut savoir pourquoi [[débloquer challenges. cloudflare.
ADFS ne gère ni le partage de fichiers, ni les imprimantes, ni le RDP. Les coûts opérationnels et d’infrastructure sont souvent mal anticipés, ce qui pousse Microsoft à recommander une migration vers des solutions cloud.
Comment configurer et déployer Active Directory Federation Services
Étapes de déploiement et de configuration
Une fois les serveurs ADFS installés et le service de fédération créé, l’essentiel du travail consiste à relier votre fournisseur d’identité aux applications qui doivent consommer l’authentification fédérée. Chaque application est déclarée dans la console de gestion sous forme d’approbation de tiers de confiance, ce qui établit le lien de confiance entre ADFS et l’application cible.
- Configurer l’attribut NameID : obligatoire dans toute réponse SAML, il identifie l’utilisateur auprès de l’application.
- Enregistrer le fournisseur d’identités : déclarer ADFS comme IdP de l’entreprise auprès de chaque service.
- Ajouter une approbation de tiers de confiance : console AD FS, puis Relying Party Trusts et Add Relying Party Trust.
- Choisir SHA-256 : algorithme de hachage recommandé, à préférer à SHA-1 pour la signature des jetons.
- Exporter le certificat x509 : le certificat de signature de jeton doit être transmis à l’application au format PEM.
Prérequis techniques par version de Windows Server
Le rôle ADFS est apparu avec Windows Server 2008. Il est ensuite disponible sur Windows Server 2016, Windows Server 2019, Windows Server 2022 et Windows Server 2025, chaque version embarquant sa propre déclinaison du service.
Quelle que soit la version retenue, un attribut email correctement renseigné dans l’annuaire est indispensable : sans lui, ADFS ne peut pas générer de revendication exploitable par la plupart des applications. Le déploiement exige aussi du personnel qualifié, capable de gérer les certificats, les approbations et le durcissement de la configuration.
ADFS face aux solutions de gestion des identités dans le cloud
| Critère de comparaison | ADFS on-premise | Fournisseur d’identité cloud |
|---|---|---|
| Hébergement | Serveurs Windows Server dédiés | Infrastructure du fournisseur |
| Coût initial | Licence Windows Server et matériel | Abonnement mensuel par utilisateur |
| Compétences requises | Personnel hautement qualifié | Administration simplifiée |
| Authentification sans mot de passe | Non prise en charge nativement | True SSO intégré |
| Agilité d’ajout d’applications | Configuration chronophage par application | Catalogue d’applications préintégrées |
| Gestion des identités hétérogènes | Limitée à l’écosystème Microsoft | Multi-annuaires et multi-OS |
| Migration depuis ADFS | Non applicable | Outils de migration dédiés |
Le paysage de la gestion des identités a profondément évolué. Là où ADFS régnait en maître sur l’authentification fédérée en entreprise, les fournisseurs d’identité cloud (IdP) s’imposent désormais comme l’alternative la plus rentable et la plus agile. Microsoft elle-même recommande la migration vers Entra ID pour les organisations qui exploitent encore des serveurs de fédération sur site. Le constat est simple : maintenir une infrastructure ADFS revient à supporter des coûts opérationnels et matériels que le cloud élimine par nature.
Rentabilité et coûts cachés
La licence Windows Server, les serveurs dédiés, les certificats, les répartiteurs de charge et le personnel qualifié constituent une facture récurrente souvent mal anticipée. Face à cela, un fournisseur d’identité cloud fonctionne sur un modèle d’abonnement prévisible. JumpCloud propose par exemple un essai gratuit de 30 jours pour évaluer la migration sans engagement. Le calcul est rapide : moins de maintenance, moins d’expertise rare à recruter, et une suppression quasi totale des coûts d’infrastructure.
Agilité SSO et fonctionnalités modernes
ADFS reste bridé sur certains usages, notamment l’authentification sans mot de passe. Les IdP cloud proposent un True SSO qui connecte l’utilisateur sans ressaisie d’identifiants, y compris sur des environnements hétérogènes (Windows, macOS, Linux). Ajouter une application à ADFS demande une configuration manuelle fastidieuse, tandis qu’un catalogue cloud la rend opérationnelle en quelques clics. Un cas client documenté chez LastPass illustre cette scalabilité : 350 applications pour 3 500 employés gérées de manière centralisée, un volume difficilement soutenable avec une fédération on-premise traditionnelle.
Composants et éléments de conception d’Active Directory Federation Services
Une infrastructure ADFS repose sur quatre briques indissociables : Active Directory, qui stocke les informations d’identité des utilisateurs, le serveur de fédération, chargé de générer et de conserver les jetons, un serveur proxy placé entre l’annuaire et les applications externes, et Entra ID lorsque l’architecture s’étend au cloud.
À ces composants s’ajoutent des éléments de conception transverses : les certificats de signature de jetons, les répartiteurs de charge pour absorber la charge, et les approbations (federated trusts) qui lient ADFS à chaque application. Un attribut NameID doit obligatoirement figurer dans la réponse SAML.
La robustesse du modèle dépend du soin apporté à l’algorithme de hachage. Le standard recommandé reste SHA-256, plus solide que SHA-1, et le certificat x509 doit être exporté au format PEM pour être reconnu par les fournisseurs de services.