PHS, PTA ou ADFS ? Trois méthodes d’authentification Azure AD hybrides expliquées

Introduction

De nombreuses entreprises disposent d’un annuaire Active Directory (AD) sur site et souhaitent utiliser les services cloud de Microsoft Azure (par exemple Microsoft 365). Pour éviter de gérer deux comptes séparés par utilisateur (un sur site et un dans le cloud), il existe des solutions d’identité hybride permettant d’utiliser les mêmes identifiants (même nom d’utilisateur et mot de passe) sur l’infrastructure locale et dans Azure AD. Microsoft Azure AD (appelé désormais Microsoft Entra ID) propose trois méthodes principales pour authentifier les utilisateurs dans un scénario hybride : PHS (Password Hash Synchronization), PTA (Pass-Through Authentication) et ADFS (Active Directory Federation Services). Chacune de ces solutions présente un fonctionnement différent, avec ses avantages, inconvénients et cas d’usage appropriés.

Cet article vise à expliquer clairement la différence entre PHS, PTA et ADFS dans un contexte Azure AD. Nous décrirons le fonctionnement général de chaque méthode, leurs avantages et inconvénients respectifs, ainsi que quelques exemples de cas d’utilisation en entreprise.

Synchronisation de hachage de mot de passe (PHS)

La synchronisation de hachage de mot de passe (en anglais Password Hash Synchronization ou PHS) est la méthode la plus simple pour intégrer l’AD local avec Azure AD. Son principe est de copier une représentation chiffrée du mot de passe de chaque utilisateur de l’AD local vers le cloud Azure AD​ learn.microsoft.com learn.microsoft.com.

.Concrètement, un outil comme Azure AD Connect extrait régulièrement le hach du mot de passe dans l’AD on-premise, et synchronise ce hach (et non le mot de passe en clair) vers Azure AD. Ainsi, lorsque l’utilisateur tente de se connecter à un service Azure (par exemple Outlook 365), Azure AD peut vérifier directement le mot de passe saisi en le comparant au hach stocké dans le cloud, sans interroger le serveur AD sur site.

Architecture de l’identité hybride avec synchronisation de hachage de mot de passe (PHS). Ici, le serveur Azure AD Connect (à droite) synchronise régulièrement les identifiants (hachs de mots de passe) de l’AD local vers Microsoft Entra ID dans le cloud. L’utilisateur s’authentifie auprès d’Azure AD qui valide le mot de passe grâce au hach synchronisé, puis accède aux applications cloud (SaaS, Microsoft 365) sans requête directe vers l’AD on-premise.​ learn.microsoft.com

Avantages : PHS est généralement apprécié pour sa simplicité. Il nécessite très peu d’infrastructure supplémentaire : une fois Azure AD Connect configuré, la synchronisation des hachs de mots de passe s’exécute automatiquement toutes les 2 minutes environ​. L’expérience utilisateur est fluide, avec la possibilité d’activer l’option SSO (Single Sign-On) transparent pour éviter les saisies répétées de mot de passe. Un avantage important est la résilience : les utilisateurs peuvent continuer à accéder aux applications cloud même si les serveurs AD locaux ou les liens réseau vers le site central sont temporairement indisponibles​. Enfin, Azure AD stocke uniquement des mots de passe chiffrés de manière non réversible, jamais en clair​, ce qui limite les risques en cas de compromission de la base Azure AD.

Inconvénients : L’inconvénient principal de PHS est qu’il introduit un léger décalage dans la propagation des changements provenant de l’annuaire local. Par exemple, si un administrateur désactive un compte utilisateur ou révoque ses accès en local, cette information n’est pas appliquée immédiatement dans Azure AD : l’utilisateur pourrait potentiellement se connecter aux applications cloud jusqu’à la prochaine synchronisation Azure AD Connect​. De même, les politiques de compte de l’AD (comme un verrouillage suite à trop d’échecs, ou des horaires de connexion restreints) ne sont pas prises en compte instantanément côté Azure AD. Sur le plan sécurité, certaines organisations peuvent être réticentes à l’idée que les hachs de mots de passe résident dans le cloud (même s’ils ne sont pas exploitables directement). Notons par ailleurs que PHS ne permet pas d’utiliser de solutions d’authentification tierces locales (par exemple un système MFA autre que celui d’Azure AD) car l’authentification est gérée dans le cloud​. Si une entreprise a des solutions maison ou externes liées à la connexion utilisateur, PHS ne pourra pas les appliquer durant le processus d’authentification.

Cas d’usage : PHS convient bien lorsque l’objectif est de faire simple et efficace. Par exemple, une PME sans exigences spécifiques de sécurité choisira PHS pour permettre à ses employés d’accéder à Microsoft 365 avec leur mot de passe habituel, sans déployer d’infrastructure supplémentaire. C’est aussi un excellent choix pour une entreprise qui débute dans l’intégration cloud et qui ne veut pas gérer de serveurs supplémentaires : Microsoft recommande PHS aux organisations dont les besoins se limitent aux applications SaaS comme Office 365​. En résumé, dès qu’aucune contrainte forte ne l’empêche (conformité, politique interne, etc.), la synchronisation de hachage est souvent la solution par défaut adoptée pour sa facilité de mise en place.

Authentification Pass-Through (PTA / « Authentification directe »)

La méthode Pass-Through Authentication (PTA), appelée aussi « authentification directe » par Microsoft, est une approche hybride où Azure AD vérifie les mots de passe en temps réel auprès de l’AD local plutôt qu’en s’appuyant sur une copie dans le cloud. Avec PTA, aucun hach de mot de passe n’est stocké dans Azure AD : à la place, on installe un ou plusieurs agents d’authentification légers sur des serveurs Windows du domaine local​. Voici comment cela fonctionne : quand un utilisateur entre ses identifiants sur la page de connexion Azure (par exemple pour Teams ou Outlook), Azure AD transmet de façon sécurisée et chiffrée ces informations à l’agent PTA on-premise. Cet agent agit comme un intermédiaire : il reçoit le nom d’utilisateur et le mot de passe (chiffré), les déchiffre localement puis les soumet au contrôleur de domaine AD comme s’il s’agissait d’une connexion classique sur site​. L’AD répond (succès, échec, compte verrouillé, etc.), et l’agent renvoie la réponse à Azure AD, qui peut alors ouvrir la session de l’utilisateur ou la refuser. Tout ce processus est transparent pour l’utilisateur, qui utilise la même interface de connexion cloud, mais en coulisse la validation du mot de passe se fait « en direct » sur le serveur AD local.

Avantages : PTA présente l’intérêt majeur de ne pas répliquer les secrets d’authentification dans le cloud. Pour des entreprises très soucieuses de la sécurité ou de la conformité, le fait qu’Azure AD ne stocke pas les hachs de mots de passe peut être un impératif. Chaque tentative de login est contrôlée par l’AD local, ce qui veut dire que toutes les politiques de sécurité locales sont appliquées immédiatement : compte désactivé ou expiré, mot de passe expiré, horaire de connexion non autorisé, etc., entraîneront un refus instantané de la connexion​. Contrairement à PHS, il n’y a pas de délai de synchronisation à attendre pour répercuter ces changements, l’AD étant consulté en temps réel. C’est donc idéal si l’on veut que la gestion des accès reste centralisée sur site. Par ailleurs, mettre en place PTA est relativement simple comparé à une fédération ADFS : il suffit d’installer l’agent (ou idéalement plusieurs agents pour la haute dispo) sur des serveurs existants, sans déployer de nouvelles bases de données ou de service web complexe. Microsoft le présente comme une solution légère : « un agent logiciel sur un ou plusieurs serveurs locaux valide directement les utilisateurs auprès de l’AD, garantissant que la vérification du mot de passe ne se produit pas dans le cloud »​

Inconvénients : Le principal inconvénient de PTA est sa dépendance vis-à-vis de l’infrastructure locale en temps réel. Si les agents d’authentification ou les contrôleurs de domaine AD deviennent indisponibles (panne réseau, serveur hors ligne), les utilisateurs ne pourront plus s’authentifier du tout sur Azure AD. En d’autres termes, pas d’authentification possible sans lien avec le site on-premise, ce qui peut poser problème pour la continuité d’activité (alors qu’en PHS, Azure AD peut continuer d’authentifier tant qu’il a le hach en stock). Il faut donc veiller à déployer PTA avec au moins deux ou trois agents répartis sur différents serveurs pour éviter un point de défaillance unique​. Un autre inconvénient est que certaines fonctionnalités avancées d’Azure AD nécessitent malgré tout PHS en complément. Par exemple, la détection des identifiants compromis (fuite de mot de passe) dans Azure AD Identity Protection requiert que les hachs de mot de passe soient synchronisés afin d’être comparés aux bases de données de mots de passe divulgués​. De même, si une organisation envisage d’utiliser Azure AD Domain Services (AAD DS) – un service émulant un domaine AD dans le cloud – PHS est obligatoire (PTA ne suffit pas). En résumé, même en mode PTA, il est fréquent que les entreprises activent PHS en secours pour bénéficier de ces fonctionnalités ou par précaution​. Enfin, comme pour PHS, l’authentification se fait via Azure AD directement pour l’utilisateur final, ce qui exclut l’utilisation de solutions d’identification tierces durant le login (impossible d’utiliser un fournisseur MFA non supporté par Azure AD par exemple, sans mettre en place une fédération).

Cas d’usage : PTA est particulièrement adapté aux entreprises qui ont des contraintes de sécurité ou de conformité fortes exigeant que les mots de passe ne « sortent » pas de l’annuaire local. Par exemple, une banque ou un organisme gouvernemental pourrait opter pour PTA afin que chaque authentification interroge l’AD on-premise, garantissant que la politique de sécurité interne (désactivation immédiate d’un compte, règles de complexité et d’expiration du mot de passe, etc.) soit scrupuleusement appliquée à chaque connexion​. C’est aussi un bon choix pour une entreprise qui dispose déjà d’une infrastructure AD robuste et qui souhaite éviter la mise en place d’ADFS tout en gardant un contrôle local sur les connexions. En pratique, PTA offre un compromis : il apporte un niveau de sécurité (contrôle total par l’AD local) proche de la fédération, tout en étant beaucoup plus simple à déployer qu’ADFS. On le retrouve ainsi dans des contextes où PHS est jugé insuffisant sur le plan de la politique d’entreprise, mais où l’on veut éviter la lourdeur d’une fédération complète.

Active Directory Federation Services (ADFS)

Les Services de fédération Active Directory (ADFS) représentent la troisième option, historique, pour l’authentification hybride Azure AD. Ici, le principe est totalement différent des deux précédents : on met en place une fédération, c’est-à-dire qu’Azure AD délègue l’authentification à un système externe de confiance – en l’occurrence un service ADFS hébergé sur site​. Concrètement, lorsque ADFS est configuré, un utilisateur qui tente de se connecter à Azure AD (par exemple au portail Office 365) sera redirigé vers le serveur ADFS de l’entreprise. Cette redirection se traduit par un changement d’URL (on passe sur une adresse HTTPS de l’organisation, typiquement https://sts.monentreprise.com ou similaire) et l’utilisateur voit apparaître la page de connexion ADFS. Il entre alors son mot de passe qui est validé directement par le contrôleur de domaine AD local, puisque ADFS est intégré à l’AD. En cas de succès, ADFS émet un jeton d’authentification (ticket sécurisé contenant l’identité de l’utilisateur) et le renvoie à Azure AD. Azure AD, faisant confiance à ADFS, accepte ce jeton et ouvre la session de l’utilisateur. Avec ADFS, Azure AD ne touche jamais aux mots de passe : tout le processus d’identification (saisie et vérification) se fait sur les serveurs de l’entreprise. Azure AD joue simplement le rôle de fournisseur de services qui consomme les assertions d’identité émises par le fournisseur d’identité fédéré (ADFS).

Schéma simplifié d’une architecture ADFS fédérée. L’utilisateur est redirigé vers le serveur ADFS de l’entreprise (via éventuellement un proxy en périmètre réseau) pour saisir ses identifiants. ADFS valide le mot de passe auprès de l’Active Directory local, puis renvoie à Azure AD un jeton attestant de l’identité. Azure AD permet alors l’accès aux applications cloud (Microsoft 365, etc.). Noter que l’authentification dépend ici entièrement des serveurs ADFS et de l’AD on-premise, avec une infrastructure à déployer en local (serveurs de fédération, proxies, etc.).​

Avantages : ADFS, bien que plus complexe, offre le plus haut niveau de contrôle et de flexibilité. Puisque l’authentification se fait sur site, une organisation peut appliquer des solutions personnalisées : par exemple, intégrer une méthode d’authentification multi-facteur tierce (carte à puce, token RSA, etc.) directement dans le processus de login ADFS​. De même, ADFS permet des configurations avancées, comme accepter des formats d’identifiant alternatifs (on peut se connecter avec DOMAIN\\username au lieu d’un UPN type email, ou encore utiliser un annuaire LDAP tiers connecté à ADFS). Pour les utilisateurs en interne sur le réseau de l’entreprise, ADFS peut procurer une expérience SSO transparente : un PC joint au domaine peut automatiquement authentifier l’utilisateur via Kerberos sans qu’il ait à ressaisir son mot de passe sur la page ADFS. Cette souplesse de configuration est souvent requise par de grandes entreprises ayant des besoins spécifiques non couverts nativement par Azure AD​. Un autre avantage indirect, pour celles qui en disposent déjà, est de réutiliser l’infrastructure existante : une entreprise ayant déjà déployé ADFS (par exemple pour d’autres applications SaaS) pourra l’étendre à Azure AD, capitalisant sur son investissement. Enfin, comme évoqué, ADFS garantit que les mots de passe ne transitent pas par le cloud (même pas de façon chiffrée) – une exigence que certaines entités considèrent comme indispensable.

Inconvénients : La contrepartie d’ADFS est sa complexité élevée. Comparé à PHS ou PTA, il nécessite de déployer et maintenir plusieurs serveurs dédiés : des serveurs ADFS en interne, souvent groupés en ferme (farm) pour la haute disponibilité, et des serveurs proxy (Web Application Proxy) en zone DMZ pour permettre aux utilisateurs externes d’accéder à ADFS​. Cela implique du temps d’installation, de la configuration réseau (ouvertures de ports, certificats SSL publics, etc.), de la maintenance (mise à jour de ces serveurs) et de la surveillance pour s’assurer que le service reste disponible et sécurisé. Le coût et l’effort d’administration sont donc beaucoup plus importants. Un autre inconvénient est que ADFS crée une dépendance forte : si votre plateforme ADFS tombe en panne (problème serveur ou base de données interne, erreur de configuration), plus aucun utilisateur ne peut se connecter aux ressources Azure AD. Sans plan de secours, cela peut interrompre l’accès aux emails, Teams, etc., pour toute l’entreprise. Il est possible de configurer un mode dégradé avec Azure AD (par exemple en activant PHS en parallèle comme secours​), mais cela ajoute encore à la complexité. De plus, déboguer des problèmes d’ADFS peut s’avérer ardu, car on jongle avec des protocoles de fédération (SAML, WS-Federation, OAuth) et des configurations de revendications qui ne sont pas triviales. En somme, ADFS a un coût d’entrée élevé en termes d’infrastructure et nécessite une expertise pour être géré correctement​. C'est pourquoi, sauf contrainte spécifique, beaucoup d’organisations évitent désormais de déployer ADFS si des alternatives plus simples suffisent.

Cas d’usage : Historiquement, ADFS était la solution privilégiée pour les grands comptes souhaitant un SSO avec Office 365 à l’époque où PHS/PTA n’existaient pas encore. Aujourd’hui, on le réserve généralement aux situations où les deux autres options ne peuvent pas répondre aux besoins. Par exemple, une entreprise qui utilise déjà un fournisseur MFA tiers (autre que Azure MFA) ou un service d’annuaire externe pourra opter pour ADFS afin de l’intégrer dans la boucle d’authentification​. De même, une organisation ayant déjà une ferme ADFS en production pour d’autres applications peut l’étendre à Azure AD plutôt que de gérer deux systèmes différents. Un autre cas d’usage est lorsqu’une entreprise a des exigences d’identification très particulières (par exemple utiliser un login non standard comme un matricule, ou s’authentifier via un dispositif physique spécifique) – ce genre de personnalisation profonde du processus de login n’est possible qu’avec une solution fédérée. Enfin, certaines entités publiques ou militaires, ayant pour règle stricte que les identifiants ne quittent jamais le périmètre interne, continueront d’utiliser ADFS par principe, malgré sa lourdeur. En résumé, ADFS est tout indiqué lorsqu’aucune solution cloud ne peut satisfaire certaines exigences métiers ou réglementaires. Mais en dehors de ces cas particuliers, les entreprises tendent de plus en plus à lui préférer des alternatives plus simples (PTA ou PHS) dès que c’est envisageable​.

Arbre de décision

https://learn.microsoft.com/fr-fr/entra/identity/hybrid/connect/choose-ad-authn

Conclusion

En synthèse, Microsoft propose plusieurs voies pour authentifier les utilisateurs dans un environnement Azure AD hybride, et le choix dépend des besoins et contraintes de l’organisation. La synchronisation de hachage (PHS) se distingue par sa facilité de déploiement et sa fiabilité : c’est souvent le choix par défaut pour une intégration rapide d’Active Directory avec Azure AD. L’authentification Pass-Through (PTA) offre un contrôle plus fin en s’appuyant sur l’annuaire local à chaque connexion, ce qui la rend appropriée si l’on doit appliquer en permanence les politiques de sécurité on-premise – sans pour autant subir la complexité d’ADFS. Enfin, ADFS reste une solution puissante mais exigeante, à envisager surtout pour des besoins avancés ou des exigences spécifiques que les deux autres méthodes ne peuvent couvrir. Comme le résume un expert, « une entreprise recherchant une implémentation simple avec peu de composants optera pour la synchronisation de mot de passe, tandis qu’une organisation très sécurisée souhaitant garder toute l’authentification en local envisagera plutôt la fédération ou le pass-through »​k21academy.com. En tant qu’étudiants, retenez que chaque méthode a ses atouts et ses limites : il n’y a pas de solution universelle, tout est affaire de compromis entre la simplicité, la sécurité et les fonctionnalités requises. En comprenant PHS, PTA et ADFS, vous serez en mesure d’appréhender les stratégies d’authentification hybrides employées dans les entreprises et les raisons qui guident leurs choix technologiques.