Qu’est-ce que la protection des mots de passe Entra ID ?
La protection des mots de passe Entra ID évalue les nouveaux mots de passe à partir des termes interdits de la liste globale de Microsoft et, lorsqu’elle est configurée, de la liste personnalisée de l’organisation. L’examen opérationnel pose trois questions distinctes : les termes propres à l’organisation sont-ils couverts, les changements sur site sont-ils réellement bloqués et l’expiration des mots de passe impose-t-elle encore des changements périodiques ?
Microsoft indique que la liste globale cloud est automatique et impossible à désactiver. L’absence de liste personnalisée ne signifie donc pas que le tenant ne dispose d’aucune protection des mots de passe. Elle signifie que l’organisation n’a pas ajouté son propre vocabulaire au socle de protection. La validation intervient lors des changements et réinitialisations de mots de passe. Microsoft Learn : concepts de protection des mots de passe.
Considérez cet examen du contrôle en complément de l’audit de sécurité Microsoft Entra ID, qui explique comment vérifier les contrôles d’accès applicables, les rôles privilégiés, la confiance accordée aux applications et les identités externes. Une stratégie de mots de passe ne suffit pas à répondre à ces questions plus larges.
Fonctionnement : pourquoi la liste globale ne suffit pas
Microsoft construit sa liste globale à partir de la télémétrie de sécurité Entra. La liste personnalisée ajoute des termes locaux : marques, produits, lieux d’implantation du siège et abréviations internes. Les deux listes fonctionnent ensemble ; la liste personnalisée ne remplace pas le socle global. Microsoft Learn : mots de passe interdits personnalisés.
Ne supposez pas que tout mot de passe contenant un terme de la liste sera refusé. L’algorithme d’évaluation normalise la saisie, vérifie les variantes et attribue un score au mot de passe obtenu ; un mot de passe suffisamment robuste peut contenir un terme interdit et rester accepté. Lisez l’algorithme d’évaluation documenté avant de concevoir les tests de validation.
Cette distinction change la manière de construire une liste personnalisée utile. Examinez le vocabulaire de l’organisation au lieu d’importer une énorme collection de mots de passe complets. Vérifiez si les marques actuelles, les noms des sociétés acquises, les familles de produits et les abréviations significatives localement sont représentés. Reliez les cas de test aux termes configurés afin de pouvoir examiner un refus plutôt que de simplement le présumer.
L’article sur le password spraying explique l’attaque : un petit ensemble de tentatives réparties sur de nombreux comptes. Ce guide examine la configuration qui réduit les choix de mots de passe prévisibles avant ces tentatives. Il ne considère pas un constat relatif à la stratégie de mots de passe comme la preuve d’un password spraying.
Le piège de l’expiration
Les recommandations de Microsoft sur les stratégies de mots de passe déconseillent l’expiration périodique pour les comptes exclusivement cloud et recommandent des mots de passe qui n’expirent pas. Les mêmes recommandations insistent sur l’unicité des mots de passe, l’inscription à la MFA et la protection des identités. La suppression de l’expiration programmée accompagne ces contrôles ; elle ne justifie pas d’ignorer une compromission suspectée.
Le constat contre-intuitif est l’expiration activée, plutôt que l’expiration désactivée. Examinez pourquoi une obligation de changement fondée sur l’âge existe, à quelle population d’identités elle s’applique et si une exigence contraignante empêche sa suppression. Distinguez toute exception de ce type du socle cloud recommandé. Ne déclarez pas une contrainte métier documentée comme corrigée au seul motif que la recommandation par défaut diffère.
Les valeurs par défaut ne prouvent pas l’état de votre tenant
La page sur les stratégies de mots de passe Entra indique que l’âge maximal par défaut actuel correspond à une absence d’expiration, mais que les tenants créés avant 2021 avaient une valeur par défaut de 90 jours. Elle décrit également séparément le paramètre individuel de non-expiration de l’utilisateur. L’âge du tenant et un indicateur utilisateur ne remplacent donc pas la lecture de la stratégie effective.
La procédure d’expiration Microsoft 365 s’applique aux utilisateurs exclusivement cloud. Elle exclut explicitement les utilisateurs hybrides qui utilisent la synchronisation du hachage des mots de passe, l’authentification directe ou la fédération sur site. Dans un examen hybride, identifiez l’autorité responsable des mots de passe avant de choisir la procédure de modification.
Mesurer la configuration avant de la modifier
1. Relever les paramètres du portail Password Protection
Ouvrez Entra ID > Authentication methods > Password protection. Relevez Enforce custom list, les entrées de la liste, Enable password protection on Windows Server Active Directory et le Mode sur site. Ces observations sont distinctes. L’activation de l’option Windows Server ne vous indique pas si les agents ont reçu une stratégie ni si tous les contrôleurs prévus sont couverts.
La page Microsoft sur l’exploitation sur site indique que le mode Audit accepte les mots de passe qui seraient refusés tout en enregistrant le résultat ; Enforced refuse les mots de passe non sécurisés. Régler l’option Windows Server sur No arrête la validation dans les agents DC déployés. Ces paramètres concernent AD DS ; il ne s’agit pas d’un commutateur désactivant la liste globale cloud automatique.
2. Lire l’exception d’expiration de l’utilisateur cloud
Avec Microsoft Graph PowerShell installé et connecté au tenant visé avec au moins le rôle User Administrator, comme l’exige la procédure citée, utilisez la commande suivante, reproduite sans modification depuis la procédure Microsoft de vérification de l’expiration :
Get-MgUser -All -Property UserPrincipalName, PasswordPolicies | Select-Object UserPrincipalName, @{N="PasswordNeverExpires";E={$_.PasswordPolicies -contains "DisablePasswordExpiration"}}
-All demande tous les utilisateurs ; -Property récupère explicitement les propriétés utilisées par l’expression. Interprétez le résultat dans le bon sens : PasswordNeverExpires=True signifie que l’indicateur de désactivation est présent. False signifie que cet indicateur n’a pas été trouvé ; cela ne démontre pas, à lui seul, un âge maximal de domaine fini.
Associez cet inventaire à Microsoft 365 admin center > Settings > Org Settings > Security and Privacy > Password expiration policy pour la population cloud concernée. Relevez le périmètre des domaines et les exceptions individuelles. La procédure avertit que les nouveaux domaines managés, ou ceux convertis depuis la fédération, nécessitent de réappliquer la stratégie de l’organisation pour mettre à jour tous les domaines. Microsoft Learn : stratégie d’expiration.
Aucun résultat de tenant n’est présenté ici : la commande est une mesure documentée, pas l’affirmation qu’un environnement particulier a satisfait au contrôle.
Détection : vérifier l’application sur site
Utilisez le canal Admin de l’agent DC sous Applications and Services Logs > Microsoft > AzureADPasswordProtection > DCAgent > Admin. La référence de supervision Microsoft distingue les résultats suivants :
| Observation | Changement de mot de passe | Définition/réinitialisation du mot de passe | Interprétation |
|---|---|---|---|
| Refus par la stratégie personnalisée | 10016 et 30002 | 10017 et 30003 | Le mot de passe soumis a été refusé au regard de la stratégie du client. |
| La stratégie personnalisée refuserait en mode Audit | 10024 et 30008 | 10025 et 30007 | Le mot de passe a été accepté parce que la stratégie était en mode Audit. |
| Aucune stratégie disponible | 30001 | 30001 | Une acceptation sans stratégie de mots de passe Azure disponible nécessite une investigation. |
L’événement 30019 est une notification de l’état de la stratégie, pas un résultat émis pour chaque changement ou réinitialisation de mot de passe. Il signale que la stratégie reçue a désactivé le traitement : les mots de passe suivants sont considérés comme conformes sans validation et aucun autre événement n’est journalisé jusqu’à ce que la stratégie change.
Les paires d’événements associés partagent un CorrelationId. Examinez l’événement explicatif avec le résultat et conservez l’identité du contrôleur ainsi que l’horodatage. Ne comptez pas cette paire comme deux demandes refusées indépendantes.
Pour un récapitulatif propre à un contrôleur, Microsoft fournit cette commande sur un serveur proxy Password Protection :
Get-AzureADPasswordProtectionSummaryReport -DomainController bplrootdc2
Il s’agit du nom de contrôleur utilisé dans l’exemple Microsoft, pas d’un environnement observé ici. Remplacez-le par le contrôleur examiné. Le rapport lit les journaux Admin de l’agent via PowerShell à distance ; l’absence d’accès ou d’agents limite les éléments de preuve. N’interprétez pas un rapport vide comme un test d’application réussi.
Ces événements décrivent la validation des mots de passe, pas les attaques à la connexion. Corrélez séparément un incident à partir de la télémétrie de connexion ; un refus de la liste personnalisée ne suffit pas à identifier la personne qui tente un password spraying.
Remédiation : termes personnalisés, application AD DS et expiration (Remediation)
1. Activer et valider la liste personnalisée
Suivez le tutoriel de la liste personnalisée avec au moins le rôle Authentication Policy Administrator et une licence Entra ID P1 ou P2. Réglez Enforce custom list sur Yes, saisissez un terme par ligne et enregistrez. Les termes doivent comporter 4–16 caractères ; la liste accepte jusqu’à 1 000 termes. Les mises à jour peuvent prendre plusieurs heures.
Utilisez un compte de test non administrateur et les prérequis SSPR documentés. Testez une variante faible d’un terme configuré après propagation. Consignez l’acceptation ou le refus sans conserver le mot de passe. Si un test est accepté de manière inattendue, examinez l’application, la propagation et l’algorithme d’évaluation avant de déclarer la liste inefficace.
2. Terminer le déploiement sur site
Suivez le guide de déploiement Microsoft : installez et enregistrez le service proxy et la forêt, déployez les agents DC et tenez compte du redémarrage nécessaire au chargement du filtre de mots de passe. Les contrôleurs accessibles en écriture sont les points de validation ; les RODC transmettent les opérations sur les mots de passe et n’ont pas besoin d’agent DC.
Audit est le mode initial documenté. Profitez de cette période pour tester les processus de changement de mot de passe et la promotion/rétrogradation des contrôleurs de domaine, puis passez en mode Enforced après résolution des problèmes opérationnels. Confirmez que l’option Windows Server est Yes et enregistrez la modification selon la procédure d’exploitation. Répétez un test contrôlé de mot de passe faible et examinez ses événements de refus corrélés.
Le guide de déploiement explique également le fonctionnement avec une stratégie en cache lorsque les proxys sont indisponibles. Vérifiez la fraîcheur de la stratégie ainsi que la présence des agents : un service en fonctionnement et une capture du portail constituent des éléments de preuve différents.
3. Supprimer l’expiration cloud périodique lorsqu’elle s’applique
Pour les utilisateurs exclusivement cloud, examinez l’option recommandée de non-expiration dans le panneau d’expiration Microsoft 365. Pour l’exception d’un utilisateur individuel, Microsoft documente cette commande dans Définir un mot de passe sans expiration :
Update-MgUser -UserId <user ID> -PasswordPolicies DisablePasswordExpiration
Le paramètre fictif est copié de la documentation ; remplacez-le par l’identifiant de l’utilisateur visé. Examinez les valeurs existantes de la stratégie de mots de passe avant une mise à jour ciblée. Évitez de transformer l’exemple en modification de tout le tenant sans examen préalable et relancez ensuite l’inventaire en lecture seule.
Pour les identités hybrides, résolvez séparément la stratégie côté AD et le modèle de synchronisation. La procédure cloud ne certifie pas une modification de l’âge maximal sur site. Conservez les changements de mots de passe déclenchés par une compromission ainsi que les contrôles MFA et de risque d’identité recommandés par Microsoft.
Comment EtcSec détecte ce problème
Les implémentations des détecteurs etc-collector examinées pour cet article évaluent trois signaux de configuration :
| Identifiant du catalogue | Condition implémentée | Limite d’interprétation |
|---|---|---|
PASSWORD_PROTECTION_DISABLED | La configuration du tenant collectée comporte une valeur PasswordProtectionEnabled non nulle explicitement définie sur false. | L’absence de paramètres ne suffit pas à déclencher le constat. Rapprochez-le du portail ; il ne démontre pas que la liste globale cloud automatique de Microsoft a été désactivée. |
CUSTOM_BANNED_PASSWORDS_DISABLED | La configuration du tenant existe et CustomBannedPasswordListConfigured vaut false. | La récupération du collecteur fonctionne au mieux : false peut aussi refléter un échec de lecture des paramètres. Confirmez la réussite de la collecte et la configuration du portail ; cet indicateur seul ne vérifie pas le commutateur d’application personnalisée, la propagation de la stratégie ou la couverture des DC. |
PASSWORD_EXPIRATION_ENABLED | La valeur DomainInfo.MaxPasswordAge collectée est supérieure à zéro et inférieure à 365 jours. | Cette implémentation évalue une valeur d’âge d’un domaine AD, pas un inventaire complet des stratégies d’expiration des utilisateurs cloud. |
Utilisez ces constats pour lancer les vérifications manuelles correspondantes. L’absence de constat ne remplace pas les mesures du portail, l’inventaire Graph et la validation AD DS contrôlée décrits ci-dessus. Clôturez chaque remédiation avec des preuves issues du véritable parcours de changement de mot de passe protégé.
Explorez les pages de sécurité des identités liées à ce sujet
