Guide : Password Hash Sync vs PTA
By Mirko Peters · · Updated
Découvrez Password Hash Sync et PTA à travers des conseils pratiques sur la configuration, l’architecture, la sécurité, la gouvernance et les usages concrets.
Automatically translated with AI from the original post. Read the English original

Lorsque vous exploitez à la fois un Active Directory sur site et Microsoft Entra ID (anciennement Azure AD), la question à un million d’euros est : « Comment authentifier les utilisateurs en toute sécurité et sans complications, quel que soit l’endroit où ils se connectent ? » C’est là qu’interviennent Password Hash Sync (PHS) et Pass-Through Authentication (PTA). Chacun est conçu pour faire le lien entre l’environnement sur site et le cloud, mais leurs mécanismes diffèrent fortement en matière de sécurité, de conformité et de résilience.
PHS et PTA ne se contentent pas de permettre la connexion. Ils relient l’Active Directory traditionnel aux services cloud d’abord d’Entra ID, rendant possibles et gérables les espaces de travail hybrides. Le choix de la méthode influence non seulement l’expérience de connexion de vos utilisateurs, mais aussi la manière dont votre organisation se protège contre les menaces, gère sa conformité et prépare sa croissance.
Ce guide apporte des réponses concrètes aux responsables techniques comme aux décideurs orientés métier. Nous comparerons PHS et PTA face à face, en détaillant leur fonctionnement, ce qui les distingue et des conseils pour choisir la solution adaptée. Préparez-vous à un tour d’horizon complet de la configuration, des couches de sécurité, de la reprise après sinistre, de la conformité et des performances. À la fin, vous disposerez d’une feuille de route pour aligner votre stratégie d’identité sur les bonnes pratiques Microsoft, sans superflu, sans effet d’annonce ni complications inutiles. Entrons dans le vif du sujet.
Comparaison des méthodes d’authentification : Password Hash Sync et Pass-Through Authentication dans Entra ID
L’identité hybride consiste à relier votre Active Directory sur site à Microsoft Entra ID, et la méthode d’authentification choisie en est le cœur. Avec Password Hash Sync (PHS) et Pass-Through Authentication (PTA), vous disposez de deux façons distinctes de valider les utilisateurs qui se connectent à des ressources cloud. Ces approches influencent non seulement la sécurité, mais aussi les performances, la conformité et la facilité d’utilisation au quotidien. Comprendre l’objectif et le contexte de chacune des deux options vous permet de prendre la décision la plus judicieuse pour votre environnement. Dans la suite, nous détaillerons précisément le fonctionnement de PHS et de PTA, en nous concentrant sur les éléments et les flux les plus importants.
Authentification par hachage de mot de passe et PTA Azure : comment fonctionnent-ils ?
La synchronisation de hachage de mot de passe (Password Hash Sync, PHS) et Pass-Through Authentication (PTA) sont les deux options les plus répandues pour relier votre identité locale au cloud Microsoft. Toutes deux permettent aux utilisateurs de se connecter aux services cloud avec leurs identifiants AD « traditionnels », mais elles procèdent de façons assez différentes.
Avec Password Hash Sync, votre environnement configure Azure AD Connect pour exporter régulièrement vers Entra ID un hachage cryptographique unidirectionnel spécifique du mot de passe de chaque utilisateur AD activé. Il ne s’agit pas simplement du hachage brut issu de votre contrôleur de domaine, mais d’un hachage du hachage : même Microsoft ne peut pas rétro-concevoir votre mot de passe. Une fois ces hachages arrivés dans le cloud, Entra ID peut authentifier directement les utilisateurs, de manière rapide et résiliente face aux incidents sur site.
PTA, en revanche, maintient la vérification du mot de passe au sein de votre Active Directory sur site. Lorsqu’un utilisateur tente de se connecter à un service cloud Microsoft, la demande d’authentification est transmise en toute sécurité depuis Entra ID à l’un de vos agents PTA légers installés sur site. L’agent vérifie le nom d’utilisateur et le mot de passe fournis auprès de votre AD, renvoie une réponse oui/non, et Entra ID laisse entrer l’utilisateur ou le bloque.
Visualisez-le ainsi : PHS = des hachages de mots de passe stockés dans le cloud, authentification réalisée dans Azure ; PTA = aucun hachage de mot de passe dans le cloud, toutes les vérifications d’identifiants effectuées directement par vos contrôleurs de domaine sur site, via un agent. Votre choix détermine l’endroit où l’authentification se « produit » réellement et le degré de dépendance à la disponibilité de votre réseau. Ces fondations conditionnent tout, de votre posture de sécurité à la résilience en cas de sinistre en passant par l’expérience utilisateur. Pour voir comment tout cela s’intègre aux risques, à la conformité et aux opérations, consultez ce guide sur l’accès conditionnel Entra ID pour des stratégies de gouvernance de l’identité rigoureuses.
Stockage des hachages de mots de passe et flux d’authentification sécurisés
Avec PHS, une version hachée, puis hachée une nouvelle fois, du mot de passe de chaque utilisateur est chiffrée et synchronisée vers Entra ID. Ce stockage côté cloud permet à Entra ID de répondre directement aux tentatives de connexion, même si votre Active Directory sur site est injoignable.
PTA ne copie rien dans le cloud et ne stocke jamais de hachages de mots de passe dans Azure. Il utilise à la place des agents qui valident les identifiants en temps réel auprès d’Active Directory local, à chaque connexion d’un utilisateur. Le canal sécurisé garantit que les mots de passe ne circulent pas à découvert. En résumé : PHS s’appuie sur des identifiants stockés dans le cloud et hachés deux fois ; PTA applique des vérifications en temps réel à chaque demande d’authentification et conserve les identifiants en local.
Considérations de sécurité pour l’identité dans l’authentification hybride
Lorsqu’il s’agit d’identités hybrides, la sécurité ne consiste pas seulement à dresser un mur : il faut choisir les bons outils pour bloquer les attaques les plus courantes tout en préservant le bon fonctionnement quotidien de l’activité. Le choix entre PHS et PTA modifie l’emplacement des données de mot de passe, leur mode de transit et leur protection, que ce soit au repos ou en transit. Mais ce n’est pas tout : il faut aussi considérer la manière dont chaque méthode s’appuie sur des outils de défense tels que l’accès conditionnel et la protection des identités.
Les organisations sont soumises à la pression de répondre aux exigences de conformité et de suivre des menaces en constante évolution. Qu’il s’agisse du vol d’identifiants, de l’hameçonnage ou de la limitation de l’impact d’une faille, la méthode d’authentification hybride que vous choisissez joue un rôle déterminant. Vous voudrez savoir comment chaque approche résiste aux menaces, s’intègre à des défenses en couches et s’inscrit dans une architecture d’identité moderne et résiliente pour votre entreprise. Pour une approche pratique de l’équilibre entre sécurité des utilisateurs et expérience utilisateur, consultez ce guide de sécurité M365 consacré aux bonnes pratiques pour les environnements Microsoft.
Protections locales et couches de sécurité cloud
PHS et PTA reposent tous deux sur les fonctionnalités de sécurité d’Active Directory local et les étendent au cloud via Entra ID. Avec PHS, une fois les hachages dans Azure, vous pouvez ajouter des défenses propres au cloud : les stratégies d’accès conditionnel et le scoring de risque de la protection des identités s’appliquent à toutes les authentifications, ce qui facilite une application rigoureuse des stratégies.
PTA prend également en charge ces contrôles en couches du cloud mais, comme les vérifications de mot de passe sont effectuées en local, vous conservez vos protections Active Directory existantes comme première ligne de défense. Les contrôles cloud supplémentaires, comme l’accès conditionnel et l’MFA, s’appliquent toujours après l’authentification. Quelle que soit la voie choisie, combiner les protections locales avec les fonctionnalités modernes d’Entra ID permet de bâtir une pile d’identité résiliente et fondée sur la défense en profondeur. Vous souhaitez approfondir les dernières menaces cloud ? La présentation de l’attaque par consentement OAuth détaille les risques réels pour Entra ID et les moyens de s’en protéger.
Verrouillage de compte, expiration et expérience de connexion avec PHS et PTA
- Verrouillage de compte : PTA applique immédiatement le verrouillage local : plusieurs tentatives de mot de passe erronées bloquent aussitôt les connexions cloud. Avec PHS, le verrouillage n’intervient qu’à la prochaine synchronisation des hachages de mots de passe.
- Expiration du mot de passe : PTA respecte en temps réel la durée de vie des mots de passe définie dans Active Directory et exige un changement dès l’expiration du compte. PHS en hérite à la synchronisation suivante ; les utilisateurs peuvent bénéficier d’une courte période de tolérance après expiration si les hachages n’ont pas été actualisés.
- Stratégies de connexion : PTA reproduit l’ensemble des contrôles d’horaires de connexion d’Active Directory. PHS applique les modifications de stratégie après la synchronisation, ce qui provoque un bref décalage dans le cloud.
- Gestion des risques : La connexion en temps réel de PTA garantit une application stricte des stratégies, tandis que PHS sacrifie un peu d’immédiateté au profit d’une meilleure résilience et d’une disponibilité accrue.
Expérience utilisateur : ouverture de session unique et accessibilité dans Entra ID
Le bon flux d’identification ne se limite pas aux mots de passe ou aux jetons : il s’agit de permettre aux utilisateurs d’accéder à leurs ressources facilement, en toute sécurité et sans contraintes permanentes. Votre choix d’authentification hybride, PHS ou PTA, influence directement la fluidité (ou non) de l’expérience des utilisateurs finaux, en particulier dans un contexte de télétravail et d’équipes réparties.
Cette section examine comment chaque méthode permet une ouverture de session transparente, où vous pouvez attendre un accès utilisateur « configuré une fois pour toutes », et ce qui se passe en cas de défaillance, qu’il s’agisse d’une micro-coupure réseau, d’un plantage de l’agent PTA ou d’un mot de passe oublié. Nous nous concentrerons sur la simplification des connexions, la réduction des invites inutiles et la protection des accès, même en cas d’incident réseau, sans jamais perdre de vue la sécurité.
Activer l’ouverture de session unique avec PHS et PTA
- Prise en charge du SSO Kerberos : PHS et PTA peuvent tous deux utiliser Seamless SSO, qui repose sur un compte d’ordinateur (AZUREADSSOACC) dans AD et offre une véritable authentification unique aux utilisateurs sur les appareils joints au domaine.
- Déroulement de la connexion : Lorsque Seamless SSO est activé, les utilisateurs disposant d’appareils de confiance, que vous utilisiez PHS ou PTA, voient rarement une demande de mot de passe, même pour les applications cloud. Leurs identifiants AD sont utilisés en arrière-plan.
- Réduction des invites : Seamless SSO réduit considérablement le nombre de réauthentifications, ce qui permet aux utilisateurs de passer d’une application, d’un appareil ou d’un navigateur à l’autre avec un minimum d’interruptions.
- Sécurité selon les méthodes : Seamless SSO offre un niveau de sécurité identique avec PHS et PTA, mais la perception qu’en ont les utilisateurs s’améliore dans tous les cas. C’est un point clé pour une productivité élevée et moins d’appels au support.
Problèmes de connexion temporaires pour PTA et scénarios de repli vers le cloud
- Indisponibilité des agents PTA : Si tous les agents PTA deviennent hors ligne ou perdent le contact avec Entra ID, les utilisateurs ne peuvent plus s’authentifier, car aucune vérification sur site n’est possible, donc aucune connexion n’est accordée.
- Résilience de PHS : Les utilisateurs PHS peuvent continuer à se connecter, même si votre AD local est hors service, car les authentifications sont traitées dans le cloud à l’aide des hachages stockés.
- Sites distants et succursales : Pour les sites dont les liaisons sont peu fiables, PHS constitue une couche de protection : les utilisateurs peuvent continuer à travailler même en cas de baisse de connectivité.
- Stratégies de repli : Certaines organisations activent les deux méthodes (avec PHS en secours) pour gagner en résilience, ce qui permet une bascule automatique en cas de perturbation de PTA.
Déploiement et gestion des agents d’authentification
La mise en place d’une authentification hybride n’est pas une opération « qu’on configure une fois pour toutes ». PHS comme PTA impliquent des exigences opérationnelles propres, depuis le déploiement des logiciels d’agent jusqu’à la gestion des autorisations. Pour que ces systèmes fonctionnent correctement, il faut concilier l’entretien quotidien avec les exigences de sécurité et de conformité.
Pour les équipes qui déploient Password Hash Sync, les tâches principales portent sur la gestion d’Azure AD Connect : planification des synchronisations, application des mises à jour et surveillance des erreurs. Avec PTA, l’accent se déplace vers le déploiement et la supervision d’agents légers sur plusieurs serveurs locaux (pour la redondance), ainsi que vers le dépannage des problèmes réseau susceptibles de perturber le trafic d’authentification. Les autorisations, l’application des correctifs et les procédures de réponse aux incidents comptent également.
Avec la dépendance croissante aux services cloud, une gestion rigoureuse des agents garantit des connexions fiables et prépare la montée en charge sans interruption. Pour ceux qui prennent la gouvernance au sérieux, découvrez comment des contrôles tels que RBAC et l’application des stratégies jouent un rôle essentiel dans Azure, dans ce guide sur la stratégie de gouvernance d’entreprise.
Étendre les autorisations pour Azure AD Connect et les agents PTA
- Autorisations d’Azure AD Connect : Nécessite des droits d’administrateur d’entreprise pendant la configuration, puis se limite aux autorisations déléguées pour la synchronisation continue. N’utilisez jamais des privilèges supérieurs à ceux strictement nécessaires, et vérifiez-les à chaque mise à jour.
- Autorisations des agents PTA : Les agents exigent des identifiants de compte de service avec le droit « Ouvrir une session en tant que service » et des droits de lecture sur AD, mais doivent éviter les rôles étendus d’administrateur de domaine afin de réduire la surface d’attaque.
- Bonnes pratiques de délégation : Appliquez le principe du moindre privilège. N’accordez que les autorisations nécessaires, ni plus ni moins, et auditez régulièrement ces rôles pour détecter toute dérive.
- Audit de conformité : Appuyez-vous sur des outils comme Microsoft Purview Audit pour surveiller les modifications, suivre l’activité des agents et faciliter les investigations en cas de problème.
Mise en œuvre de la réinitialisation de mot de passe en écriture différée et correspondance des comptes existants
- Réinitialisation de mot de passe en écriture différée : Activez la réinitialisation de mot de passe en écriture différée via Azure AD Connect pour que les utilisateurs puissent réinitialiser leurs mots de passe dans le cloud. Ces modifications sont automatiquement renvoyées vers l’AD local, ce qui allège la charge du support.
- Libre-service utilisateur : Une fois la fonctionnalité configurée, les utilisateurs peuvent gérer la réinitialisation et la modification de leurs mots de passe depuis Office.com ou l’application Microsoft Authenticator, tout en restant productifs et conformes aux exigences.
- Stratégies de correspondance : Avant d’activer PHS ou de passer depuis PTA, vérifiez que les comptes utilisateurs sont correctement mis en correspondance entre Entra ID et AD, afin d’éviter les identités en double et les problèmes d’accès.
- Bonnes pratiques de migration : testez le writeback avec un groupe pilote, vérifiez la correspondance des identités à l’aide des attributs immutableID ou mail, et surveillez les erreurs de synchronisation et les identifiants incohérents après le lancement.
Migrer de PTA vers PHS : préparation, exécution et validation
Passer de l’authentification directe (Pass-Through Authentication) à la synchronisation des hachages de mots de passe (Password Hash Sync) ne se résume pas à actionner un interrupteur en espérant le meilleur. La migration exige une planification minutieuse, la documentation de votre environnement, la mise en cohérence des paramètres cloud et sur site, ainsi qu’une communication claire avec les utilisateurs et les parties prenantes.
Cette section vous guide à travers l’ensemble du processus : comment préparer votre locataire, valider la compatibilité avec PHS et anticiper les difficultés susceptibles de survenir lors de ce changement. L’objectif est de limiter les perturbations pour les utilisateurs, d’éviter les mauvaises surprises et de disposer d’une voie claire en cas de retour arrière nécessaire. Chaque phase comprend des points de contrôle et des bonnes pratiques pour assurer la stabilité de votre identité hybride tout au long de la transition.
Avec un plan de migration bien conçu, vous pouvez transférer la gestion de l’authentification vers le cloud, gagner en résilience, prendre en charge les sites distants et de succursales, et préparer les évolutions futures. Le changement est difficile, mais bien géré, il réduit les interventions d’urgence et vous permet de vous concentrer sur votre activité réelle.
Préparation, vue d’ensemble du locataire et évaluation de la préparation au changement
- Inventorier les paramètres existants : documentez l’ensemble des stratégies d’authentification et de mot de passe actuelles, ainsi que les détails du déploiement des agents, afin d’éviter les oublis.
- Vérifier la compatibilité cloud : assurez-vous que tous les comptes sont synchronisés et compatibles avec PHS, en faisant attention aux stratégies de mot de passe non standard ou aux schémas de chiffrement hérités.
- Planifier la communication : informez les parties prenantes, le service d’assistance et les utilisateurs des changements à venir, des impacts possibles et des nouveaux parcours de connexion.
- Élaborer un plan de retour arrière : préparez une solution de repli claire en cas de problème pendant la migration. Sachez quels événements déclenchent un retour arrière et comment revenir en arrière sans perte de service.
- Planifier pour un impact minimal : choisissez des fenêtres de maintenance à faible activité utilisateur et assurez-vous que le support est disponible pendant et après la bascule. Pour en savoir plus sur les effets de la conformité du locataire, consultez cet épisode sur la dérive de conformité.
Activer PHS, basculer la production, valider le succès et effectuer un retour arrière d’urgence
- Activer PHS dans Azure AD Connect : activez la synchronisation des hachages de mots de passe et vérifiez que les hachages commencent à se synchroniser pour tous les utilisateurs. Suivez la progression dans le tableau de bord d’Azure AD Connect et assurez-vous qu’aucune erreur n’est consignée.
- Valider la correspondance cloud : vérifiez que les identités synchronisées sont correctement mappées et que l’ouverture de session fonctionne avec PHS avant de basculer le trafic de production. Surveillez les incohérences et les comptes en double.
- Rediriger l’authentification de production : faites progressivement migrer le trafic d’authentification de PTA vers PHS, en commençant par des groupes pilotes, puis étendez-le à l’ensemble du locataire si tout se passe bien.
- Surveiller le succès et l’expérience utilisateur : suivez de près les temps de connexion, l’état des services et les retours des utilisateurs pendant et après la bascule. Réagissez rapidement aux échecs d’ouverture de session et aux erreurs inattendues.
- Désactiver les agents PTA en toute sécurité : une fois que vous êtes certain du bon fonctionnement de PHS, supprimez les agents PTA en suivant la procédure de nettoyage recommandée par Microsoft. Documentez le changement, mettez à jour vos plans de réponse aux incidents et vérifiez qu’aucune dépendance héritée ne subsiste.
- Plan de retour arrière d’urgence : si les choses tournent mal, soyez prêt à revenir à PTA en réactivant les agents et en inversant le flux de trafic. Entraînez-vous à cette procédure afin qu’un retour arrière puisse être exécuté en moins de 30 minutes si nécessaire.
Choisir la méthode d’authentification adaptée à votre identité cloud hybride
Une fois tous les éléments et flux examinés, il est temps de les confronter à vos besoins réels. Votre choix entre PHS et PTA ne relève pas seulement de la technologie : il dépend de votre profil de risque, de votre posture de conformité, de la fiabilité de votre réseau et de la charge de gestion que votre équipe peut assumer au quotidien. Le bon choix répond non seulement à vos objectifs techniques, mais aussi aux réalités métier, aux contraintes réglementaires et aux habitudes des utilisateurs.
Cette dernière section rassemble les aspects pratiques, les pièges connus et les scénarios courants afin que vous puissiez aligner en toute confiance votre plan d’identité hybride sur la méthode la mieux adaptée à vos objectifs, et changer de stratégie à mesure que votre organisation évolue.
PTA retenu à la place de PHS : quand choisir chaque approche
- Utilisez PTA si : Vous êtes soumis à des réglementations strictes interdisant de stocker sous quelque forme que ce soit un hachage de mot de passe dans le cloud, ou si vous avez besoin d’une application en temps réel des stratégies AD.
- Utilisez PHS si : Vous recherchez la résilience : les authentifications continuent de fonctionner même si l’AD local est en panne ou inaccessible (idéal pour les équipes distribuées ou en télétravail).
- PTA convient à : des environnements centralisés, très réglementés ou de grande taille, disposant d’une connectivité solide entre le cloud et le local.
- PHS convient à : des organisations qui privilégient la disponibilité, une gestion simple et une résilience « cloud first », en particulier si les agences distantes ou l’instabilité du réseau sont des préoccupations.
Questions fréquentes, authentification multifacteur et points clés
- L’authentification multifacteur (MFA) fonctionne-t-elle avec les deux méthodes ? Oui. PTA comme PHS prennent en charge l’authentification multifacteur moderne (accès conditionnel, SMS, code d’application, FIDO2, et plus encore), appliquée par Entra ID après l’authentification.
- Vais-je perdre mes stratégies locales en utilisant PHS ? Pas totalement. La plupart des changements de mot de passe, des verrouillages et des expirations sont repris après la synchronisation, mais PTA les applique en temps réel. Pour une application critique des stratégies, PTA peut être le meilleur choix.
- Que se passe-t-il si notre réseau tombe en panne ? Avec PTA, toute authentification cloud s’arrête si vos agents PTA sont injoignables. PHS continue de fonctionner (les utilisateurs peuvent toujours se connecter) grâce aux hachages stockés dans le cloud. Prévoyez votre stratégie de basculement en conséquence.
- Comment gérer le reporting de conformité et la journalisation d’audit ? PTA journalise les événements principalement sur site (sur les agents et les contrôleurs de domaine) ; PHS transfère l’essentiel de l’activité vers Entra ID, offrant une visibilité plus riche à l’échelle du cloud pour les équipes SIEM et conformité. La journalisation et la supervision dans le cloud sont plus simples pour une gouvernance globale : découvrez comment réduire le risque lié aux identités dans cet épisode sur l’accès conditionnel Entra ID.
- Point clé : PTA et PHS ont chacun leur rôle. Évaluez l’effort opérationnel, la résilience, les exigences réglementaires et l’expérience utilisateur avant de décider. N’oubliez pas de surveiller la dette liée aux identités et la prolifération des règles d’accès conditionnel : des stratégies solides et applicables sont au cœur d’une sécurité réelle, comme nous l’avons vu dans le guide ci-dessus. Si vous gérez la sécurité et la gouvernance de plateformes plus larges, consultez les pratiques de sécurité Power Platform pour découvrir des stratégies complémentaires de gestion des identités.
À écouter également
Si vous étudiez Password Hash Sync vs PTA, ces épisodes apportent un contexte pratique sur l’architecture, la sécurité, la gouvernance et la mise en œuvre :
- Microsoft AI Agent Harness – Simply Explained — Comprendre l’orchestration, les garde-fous, l’évaluation et la fiabilité des flux de travail d’IA.
- Microsoft Defender XDR – Simply Explained — Relier les décisions liées à l’identité et à l’IA à la supervision et à la réponse de sécurité.
- Microsoft Teams Governance – The Illusion of Control — Découvrir comment la gouvernance, la propriété et les stratégies réduisent le risque opérationnel.
- Azure Virtual Network – Simply Explained — Comprendre le contexte d’architecture qui sous-tend la connectivité cloud.