Cette section répond à de nombreuses questions fréquemment posées sur la Protection de mot de passe Microsoft Entra.
Questions générales
Quels conseils donner aux utilisateurs sur la façon de sélectionner un mot de passe sécurisé ?
Les conseils de Microsoft sur ce sujet se trouvent sur le lien suivant :
Conseils pour le choix du mot de passe Microsoft
La protection par mot de passe Microsoft Entra locale est-elle prise en charge sur les clouds non publics ?
La protection par mot de passe Microsoft Entra locale est prise en charge dans les clouds Azure Global et Azure Government.
Le Centre d’administration Microsoft Entra autorise la modification de la configuration spécifique locale « Protection par mot de passe pour Windows Server Active Directory » dans les clouds non pris en charge. Ces modifications persistent, mais ne prennent jamais effet. L’inscription d’agents proxys ou de forêts en local n’est pas prise en charge dans les clouds non pris en charge, ce qui entraîne l’échec de toute tentative d’inscription.
Comment puis-je appliquer des avantages de la protection par mot de passe Microsoft Entra à un sous-ensemble de mes utilisateurs locaux ?
Non pris en charge. Une fois déployée et activée, la Protection par mot de passe Microsoft Entra s’applique de la même façon à tous les utilisateurs.
Quelle est la différence entre une modification de mot de passe et une définition (ou réinitialisation) de mot de passe ?
Une modification de mot de passe survient lorsqu’un utilisateur choisit un nouveau mot de passe après avoir prouvé qu’il a connaissance de l’ancien mot de passe. Par exemple, un changement de mot de passe se produit quand un utilisateur se connecte à Windows et est invité à choisir un nouveau mot de passe.
Une définition de mot de passe (parfois appelée une réinitialisation de mot de passe) survient lorsqu’un administrateur remplace le mot de passe d’un compte par un nouveau mot de passe, par exemple à l’aide de l’outil de gestion Utilisateurs et ordinateurs Active Directory. Cette opération requiert un niveau élevé de privilèges (généralement, administrateur de domaine), et la personne qui effectue l’opération n’a généralement pas connaissance de l’ancien mot de passe. Les scénarios de support technique opèrent souvent des définitions de mot de passe, par exemple, pour aider un utilisateur qui a oublié son mot de passe. Vous rencontrez également des situations de définition de mot de passe lorsqu’un compte d’utilisateur est créé pour la première fois avec un mot de passe.
Le comportement de la stratégie de validation de mot de passe est toujours identique, qu’il s’agisse d’une modification de mot de passe ou d’une définition de mot de passe. Le service d’agent du contrôleur de domaine pour la Protection de mot de passe Microsoft Entra journalise différents événements afin de vous informer en cas de modification ou de définition de mot de passe. Voir Supervision et journalisation dans la Protection de mot de passe Microsoft Entra.
La protection par mot de passe Microsoft Entra valide-t-elle les mots de passe existants après installation ?
Non. La protection par mot de passe Microsoft Entra peut uniquement appliquer une stratégie de mot de passe à des mots de passe de texte en clair pendant une opération de définition ou de modification de mot de passe. Une fois qu’Active Directory accepte un mot de passe, seuls les hachages spécifiques au protocole d’authentification de ce mot de passe sont conservés. Le mot de passe en texte clair n’étant jamais conservé, la Protection par mot de passe Microsoft Entra ne peut pas valider les mots de passe existants.
Après le déploiement initial de la protection par mot de passe Microsoft Entra, l’ensemble des utilisateurs et des comptes commencent à utiliser un mot de passe validé par la protection par mot de passe Microsoft Entra, car leurs mots de passe existants expirent normalement au fil du temps. Si nécessaire, vous pouvez accélérer ce processus en procédant à une expiration manuelle ponctuelle des mots de passe de compte d’utilisateur.
Les comptes configurés avec l’option « Le mot de passe n’expire jamais » ne sont pas obligés de modifier leur mot de passe, sauf en cas d’expiration manuelle.
Pourquoi des événements de mot de passe rejetés sont-ils consignés en double lorsque je tente de définir un mot de passe faible à l’aide du composant logiciel enfichable Utilisateurs et ordinateurs Active Directory ?
Le composant logiciel enfichable Utilisateurs et ordinateurs Active Directory essaie d’abord de définir le nouveau mot de passe à l’aide du protocole Kerberos. En cas d’échec, le composant logiciel enfichable effectue une deuxième tentative de définition du mot de passe à l’aide d’un protocole (SAM RPC) hérité. Les protocoles spécifiques utilisés ne sont pas importants. Si le nouveau mot de passe est considéré comme faible par la Protection par mot de passe Microsoft Entra, ce comportement de logiciel enfichable se traduit par la journalisation de deux ensembles d’événements de rejet de réinitialisation de mot de passe.
Pourquoi les événements de validation de mot de passe Protection par mot de passe Microsoft Entra sont-ils journalisés avec un nom d’utilisateur vide ?
Active Directory prend en charge la possibilité de tester un mot de passe pour voir s’il satisfait aux exigences actuelles du domaine en matière de complexité des mots de passe, par exemple à l’aide de l’API NetValidatePasswordPolicy. Lorsqu’un mot de passe est validé de cette manière, les tests comprennent également une validation par des produits basés sur des DLL de filtre de mots de passe, tels que la Protection par mot de passe Microsoft Entra. Cependant, les noms d’utilisateur passés à une DLL de filtre de mot de passe donnée sont vides. Dans ce scénario, la Protection par mot de passe Microsoft Entra valide quand même le mot de passe à l’aide de la stratégie de mot de passe actuellement en vigueur et émet un message de journal des événements pour capturer le résultat. Le message du journal des événements comportera toutefois des champs de nom d’utilisateur vides.
J’ai des utilisateurs hybrides qui tentent de modifier leur mot de passe dans Microsoft Entra ID et reçoivent la réponse : « Ce mot de passe a été utilisé trop souvent dans le passé. Choisissez une chaîne plus difficile à deviner. » Dans ce cas, pourquoi ne vois-je pas une tentative de validation locale ?
Quand un utilisateur hybride modifie son mot de passe dans Microsoft Entra ID, que ce soit via Microsoft Entra SSPR, Mon compte ou un autre mécanisme de modification de mot de passe Microsoft Entra, son mot de passe est évalué par rapport aux listes de mots de passe interdits globaux et personnalisés dans le cloud. Lorsque le mot de passe atteint Active Directory via l’écriture différée du mot de passe, il est déjà validé dans Microsoft Entra ID.
Les réinitialisations et modifications de mot de passe initiées dans Microsoft Entra ID qui échouent à la validation pour les utilisateurs hybrides se trouvent dans les journaux d’audit Microsoft Entra. Consultez Dépanner la réinitialisation de mot de passe en libre-service dans Microsoft Entra ID.
L’installation de la protection par mot de passe Microsoft Entra simultanément avec d’autres produits basés sur le filtrage par mot de passe est-elle prise en charge ?
Oui. La prise en charge de plusieurs DLL de filtrage de mots de passe inscrits est une fonctionnalité Windows de base et n’est pas spécifique à la Protection de mot de passe Microsoft Entra. Toutes les DLL de filtrage de mots de passe enregistrés doivent valider un mot de passe avant de l’accepter.
Comment puis-je déployer et configurer la protection par mot de passe Microsoft Entra dans mon environnement Active Directory sans utiliser Azure ?
Non pris en charge. La Protection de mot de passe Microsoft Entra est une fonctionnalité Azure qui accepte d’être étendue à un environnement Active Directory local.
Comment puis-je modifier le contenu de la stratégie au niveau d’Active Directory ?
Non pris en charge. La stratégie ne peut être gérée qu’à partir du Centre d’administration Microsoft Entra. Consultez également la question précédente.
Pourquoi la technologie DFSR est-elle nécessaire pour la réplication sysvol ?
La technologie FRS (prédécesseur de la technologie DFSR) présente de nombreux problèmes connus et n’est pas du tout prise en charge par les versions plus récentes de Windows Server Active Directory. Aucun essai de la Protection par mot de passe Microsoft Entra n’est effectué sur les domaines configurés en FRS.
Pour plus d’informations, consultez les articles suivants :
Argumentaire en faveur de la migration de la réplication sysvol vers DFSR
Si votre domaine n’utilise pas encore DFSR, vous DEVEZ le faire migrer pour l’utiliser avant d’installer la Protection par mot de passe Microsoft Entra. Pour plus d’informations, consultez le lien suivant :
Guide de migration de la réplication SYSVOL : Réplication FRS vers DFS
Avertissement
Le logiciel de l’agent contrôleur de domaine de la Protection par mot de passe Microsoft Entra s’installe actuellement sur des contrôleurs de domaine dans les domaines qui utilisent encore FRS pour la réplication sysvol, mais ce logiciel ne fonctionne PAS correctement dans cet environnement. Des effets secondaires négatifs peuvent entraîner l’échec de la réplication des fichiers individuels et le succès apparent des procédures de restauration sysvol qui ne parviennent pas à répliquer tous les fichiers en mode silencieux. Vous devez migrer votre domaine pour utiliser DFSR dès que possible, à la fois pour ses avantages inhérents et pour débloquer le déploiement de la Protection de mot de passe Microsoft Entra. Les versions ultérieures du logiciel sont automatiquement désactivées lors de l’exécution dans un domaine qui utilise encore FRS.
De quelle quantité d’espace disque la fonctionnalité a besoin sur le partage sysvol du domaine ?
L’utilisation d’un espace précis varie en fonction de facteurs, par exemple la surcharge de chiffrement, le nombre et la longueur des jetons interdits dans la liste globale interdite de Microsoft et dans la liste personnalisée par locataire. Le contenu de ces listes est susceptible d’évoluer à l’avenir. Ainsi, la prévision pour cette fonctionnalité d’au moins cinq (5) mégaoctets d’espace sur le partage sysvol du domaine est une appréciation raisonnable.
Pourquoi un redémarrage est-il nécessaire pour installer ou mettre à niveau le logiciel de l’agent contrôleur de domaine ?
Cette exigence est due à un comportement de base de Windows.
Existe-t-il un moyen de configurer un agent contrôleur de domaine pour utiliser un serveur proxy spécifique ?
Non. Le serveur proxy étant sans état, n’importe quel serveur proxy en particulier est utilisé.
Est-il possible de déployer le service proxy de la protection par mot de passe Microsoft Entra simultanément avec d’autres services, comme Microsoft Entra Connect ?
Oui. Le service de proxy de Protection de mot de passe Microsoft Entra et Microsoft Entra Connect ne doivent jamais être en conflit direct.
Malheureusement, le logiciel proxy de la Protection par mot de passe Microsoft Entra installe une version du service du programme de mise à jour de l’agent Microsoft Entra Connect qui n’est pas compatible avec la version installée par le logiciel du proxy d’application Microsoft Entra. Cette incompatibilité peut empêcher le service de mise à jour de l’agent de contacter Azure pour effectuer les mises à jour logicielles. Il n’est pas recommandé d’installer le proxy de la Protection par mot de passe Microsoft Entra et le proxy d’application Microsoft Entra sur la même machine.
Dans quel ordre faut-il installer et inscrire les agents de contrôleur de domaine et les proxys ?
L’ordre n’a aucune importance pour l’installation de l’agent de proxy, l’installation de l’agent du contrôleur de domaine, l’inscription de la forêt et l’inscription du proxy.
Dois-je me préoccuper des performances obtenues sur mes contrôleurs de domaine avant de déployer cette fonctionnalité ?
Le service d’agent contrôleur de domaine de la protection par mot de passe Microsoft Entra ne devrait pas affecter considérablement les performances du contrôleur de domaine dans un déploiement Active Directory sain existant.
Pour la plupart des déploiements Active Directory, les opérations de modification de mot de passe représentent une petite proportion de la charge de travail globale sur un contrôleur de domaine donné. Imaginez, par exemple, un domaine Active Directory avec 10 000 comptes d’utilisateur et une stratégie MaxPasswordAge définie sur 30 jours. En moyenne, ce domaine voit 10000/30 = ~ 333 opérations de modification de mot de passe par jour, ce qui représente un nombre insignifiant d’opérations, même pour un seul contrôleur de domaine. Envisagez le pire scénario d’utilisation possible : supposez que ces quelque 333 modifications de mot de passe sur un seul contrôleur de domaine soient effectuées dans une même heure. Ce scénario peut notamment se produire lorsque beaucoup d’employés viennent tous travailler un lundi matin. Même dans ce cas, il est toujours question de ~333/60 minutes, soit six modifications de mot de passe par minute, ce qui encore une fois n’est pas une charge importante.
Par contre, si vos contrôleurs de domaine actuels s’exécutent déjà à des niveaux de performances limités (par exemple, en limite maximale par rapport au processeur, à l’espace disque, aux e/s de disque, etc.), il est conseillé d’ajouter plus de contrôleurs de domaine ou d’augmenter l’espace disque disponible avant le déploiement de cette fonctionnalité. Reportez-vous à la question précédente sur l’utilisation de l’espace disque sysvol ci-dessus.
Je veux tester la protection par mot de passe Microsoft Entra sur quelques contrôleurs de domaine seulement dans mon domaine. Est-il possible d’imposer des modifications de mot de passe utilisateur pour utiliser ces contrôleurs de domaine en particulier ?
Non. Le système d’exploitation client Windows contrôle quel contrôleur de domaine est utilisé lorsqu’un utilisateur change son mot de passe. Le contrôleur de domaine est sélectionné en fonction de facteurs, tels que des attributions de site et de sous-réseau Active Directory, une configuration réseau spécifique à l’environnement, etc. La Protection par mot de passe Microsoft Entra ne contrôle pas ces facteurs et ne peut pas influer sur la sélection du contrôleur de domaine pour changer le mot de passe d’un utilisateur.
Un moyen d’atteindre en partie cet objectif consisterait à déployer la protection par mot de passe Microsoft Entra sur tous les contrôleurs de domaine dans un site Active Directory donné. Cette approche fournit une couverture raisonnable aux clients Windows affectés à ce site et aux utilisateurs qui se connectent à ces clients et changent leurs mots de passe.
Si j’installe le service d’agent contrôleur de domaine de la protection par mot de passe Microsoft Entra sur le contrôleur de domaine principal seulement, est-ce que tous les autres contrôleurs de domaine dans le domaine sont aussi protégés ?
Nombre Quand un mot de passe utilisateur est changé sur un contrôleur de domaine donné qui n’est pas contrôleur de domaine principal, le mot de passe en texte clair n’est jamais envoyé au contrôleur de domaine principal (il s’agit d’une idée fausse répandue). Dès lors qu’un nouveau mot de passe est accepté sur un contrôleur de domaine donné, ce contrôleur de domaine utilise le mot de passe pour créer les différents hachages spécifiques au protocole d’authentification de ce mot de passe, puis conserve ces hachages dans le répertoire. Le mot de passe en texte clair n’est pas conservé. Les hachages mis à jour sont ensuite répliqués sur le contrôleur de domaine principal. Les mots de passe utilisateur peuvent, dans certains cas, être changés directement sur le contrôleur de domaine principal, encore une fois en fonction de divers facteurs, tels que la topologie du réseau et la conception du site Active Directory. (Consultez la question précédente.)
En résumé, le déploiement du service d’agent contrôleur de domaine de la protection par mot de passe Microsoft Entra sur le contrôleur de domaine principal est indispensable pour obtenir 100 % de la couverture de sécurité sur le domaine pour la fonctionnalité. Le déploiement de la fonctionnalité sur le contrôleur de domaine principal ne fournit aucun avantage de sécurité basée sur la Protection par mot de passe Microsoft Entra aux autres contrôleurs de domaine dans le domaine.
Pourquoi le verrouillage intelligent personnalisé ne fonctionne-t-il pas même après l’installation des agents dans mon environnement Active Directory local ?
Le verrouillage intelligent personnalisé est pris en charge uniquement dans Microsoft Entra ID. Les modifications apportées aux paramètres de verrouillage intelligent personnalisé dans le Centre d’Administration Microsoft Entra n’ont aucune incidence sur l’environnement Active Directory local, même avec les agents installés.
Existe-il un pack d’administration System Center Operations Manager disponible pour la protection par mot de passe Microsoft Entra ?
Nombre
Pourquoi Microsoft Entra ID refuse-t-il toujours les mots de passe faibles, même si j’ai configuré la stratégie en mode Audit ?
Le mode Audit est uniquement pris en charge dans l’environnement Active Directory local. Microsoft Entra ID est toujours implicitement en mode « appliquer » lorsqu’il évalue les mots de passe.
Mes utilisateurs voient le message d’erreur Windows classique lorsqu’un mot de passe est rejeté par la protection par mot de passe Microsoft Entra ID. Est-il possible de personnaliser ce message d’erreur afin que les utilisateurs sachent ce qui s’est réellement produit ?
Non. Le message d’erreur, affiché par les utilisateurs lorsqu’un mot de passe est rejeté par un contrôleur de domaine, est contrôlé par la machine cliente, et non par le contrôleur de domaine. Ce comportement a lieu, que ce soit lorsqu’un mot de passe est rejeté par les stratégies de mot de passe Active Directory par défaut ou par une solution basée sur un filtre de mot de passe, comme la Protection de mot de passe Microsoft Entra.
Procédures de test de mot de passe
Vous pouvez effectuer quelques tests de base sur différents mots de passe afin de valider le bon fonctionnement du logiciel et de mieux comprendre l’algorithme d’évaluation des mots de passe. Cette section décrit une méthode de test conçue pour produire des résultats reproductibles.
Pourquoi est-il nécessaire de suivre ces étapes ? Plusieurs facteurs font qu’il est difficile d’effectuer des tests contrôlés et reproductibles des mots de passe dans l’environnement Active Directory local :
- La stratégie de mot de passe est configurée et conservée dans Azure, et les copies de la stratégie sont synchronisées périodiquement par les agents DC locaux à l’aide d’un mécanisme d’interrogation. La latence inhérente à ce cycle d’interrogation peut être source de confusion. Par exemple, si vous configurez la stratégie dans Azure, mais que vous oubliez de la synchroniser avec l’agent DC, vos tests risquent de ne pas produire les résultats escomptés. L’intervalle d’interrogation est actuellement codé en dur pour se produire une fois par heure, mais attendre une heure entre deux modifications de stratégie n’est pas idéal pour un scénario de test interactif.
- Une fois qu’une nouvelle stratégie de mot de passe est synchronisée avec un contrôleur de domaine, la latence est plus importante lors de la réplication vers d’autres contrôleurs de domaine. Ces délais peuvent entraîner des résultats inattendus si vous testez un changement de mot de passe sur un contrôleur de domaine qui n’a pas encore reçu la dernière version de la stratégie.
- Le fait de tester des modifications de mot de passe via une interface utilisateur rend difficile la confiance dans vos résultats. Par exemple, il est facile de mal saisir un mot de passe non valide dans une interface utilisateur, en particulier dans la mesure où la plupart des interfaces utilisateur de mot de passe masquent les entrées utilisateur (par exemple, l’interface utilisateur Windows Ctrl+Alt+Supprimer -> Changer le mot de passe).
- Il n’est pas possible de contrôler strictement quel contrôleur de domaine est utilisé lors des tests de modification de mot de passe à partir de clients joints à un domaine. Le système d’exploitation client Windows sélectionne un contrôleur de domaine en fonction de facteurs tels que des attributions de site et de sous-réseau Active Directory, une configuration réseau spécifique à l’environnement, etc.
Afin d’éviter ces problèmes, les étapes suivantes sont basées sur le test de la réinitialisation de mot de passe par ligne de commande lors de la connexion à un contrôleur de domaine.
Avertissement
Veuillez n’utiliser ces procédures que dans un environnement de test. Lorsque le service de l’agent du contrôleur de domaine est arrêté, toutes les modifications et réinitialisations de mot de passe entrantes sont acceptées sans validation. Cela permet également d’éviter les risques accrus de connexion à un contrôleur de domaine.
Les étapes suivantes supposent que vous avez installé l’agent DC sur au moins un contrôleur de domaine, que vous avez installé au moins un proxy et que vous avez inscrit le proxy et la forêt.
À l’aide des informations d’identification d’administrateur de domaine (ou d’autres informations d’identification disposant de privilèges suffisants pour créer des comptes d’utilisateur de test et réinitialiser les mots de passe), connectez-vous au contrôleur de domaine. Assurez-vous que le contrôleur de domaine a installé le logiciel de l’agent DC et a été redémarré.
Ouvrez Observateur d’événements et accédez au journal des événements d’administration de l’agent DC.
Ouvrez une fenêtre d’invite de commandes avec élévation de privilèges.
Créez un compte de test pour tester les mots de passe.
Il existe de nombreuses façons de créer un compte d’utilisateur, mais une option de ligne de commande est proposée ici pour vous faciliter la tâche lors des cycles de tests répétitifs :
net.exe user <testuseraccountname> /add <password>Pour les besoins de la discussion ci-dessous, supposons que nous avons créé un compte de test nommé « ContosoUser », par exemple :
net.exe user ContosoUser /add <password>Connectez-vous au centre d’administration Microsoft Entra avec au moins le rôle d’Administrateur d’authentification.
Accédez à Protection > Méthodes d’authentification > Protection par mot de passe.
Modifiez la stratégie de Protection de mot de passe Microsoft Entra selon les besoins des tests que vous souhaitez effectuer. Par exemple, vous pouvez décider de configurer le mode Appliqué ou le mode Audit, ou vous pouvez décider de modifier la liste des termes interdits dans votre liste personnalisée des mots de passe interdits.
Synchronisez la nouvelle stratégie en arrêtant et en redémarrant le service de l’agent DC.
Cette étape peut être réalisée de différentes façons. Une façon serait d’utiliser la console d’administration Management des services en cliquant avec le bouton droit sur le service d’agent de contrôleur de domaine de Protection de mot de passe Microsoft Entra et en choisissant « Redémarrer ». Une autre méthode peut être utilisée à partir de la fenêtre d’invite de commandes comme suit :
net stop AzureADPasswordProtectionDCAgent && net start AzureADPasswordProtectionDCAgentConsultez l’observateur d’événements pour vérifier qu’une nouvelle stratégie a été téléchargée.
Chaque fois que le service de l’agent DC est arrêté et démarré, vous devez voir deux événements 30006 émis à la suite. Le premier événement 30006 reflète la mise en cache de la stratégie sur le disque, dans le partage sysvol. Le deuxième événement 30006 (le cas échéant) doit avoir une date de stratégie Locataire mise à jour et, si tel est le cas, il reflète le téléchargement de la stratégie à partir d’Azure. La valeur de date de la stratégie Locataire est actuellement codée pour afficher l’heure approximative à laquelle la stratégie a été téléchargée à partir d’Azure.
Si le deuxième événement 30006 n’apparaît pas, vous devez résoudre le problème avant de continuer.
Les événements 30006 se présentent comme suit :
The service is now enforcing the following Azure password policy. Enabled: 1 AuditOnly: 0 Global policy date: 2018-05-15T00:00:00.000000000Z Tenant policy date: 2018-06-10T20:15:24.432457600Z Enforce tenant policy: 1Par exemple, passer du mode Appliqué au mode Audit entraîne la modification de l’indicateur AuditOnly (la stratégie répertoriée avec AuditOnly=0 est en mode Appliqué). Les modifications apportées à la liste personnalisée des mots de passe interdits ne sont pas directement reflétées dans l’événement 30006 ci-dessus et ne sont pas enregistrées ailleurs pour des raisons de sécurité. Le téléchargement de la stratégie à partir d’Azure après cette modification inclut également la liste personnalisée des mots de passe interdits qui a été modifiée.
Effectuez un test en tentant de réinitialiser un nouveau mot de passe sur le compte d’utilisateur de test.
Cette étape peut être effectuée à partir de la fenêtre d’invite de commandes comme suit :
net.exe user ContosoUser <password>Après avoir exécuté la commande, vous pouvez obtenir plus d’informations sur le résultat de la commande en consultant l’observateur d’événements. Les résultats de la validation du mot de passe sont documentés dans la rubrique Journal des événements d’administration de l’agent DC. Vous utilisez ces événements pour valider le résultat de votre test en plus de la sortie interactive des commandes net.exe.
Essayons un exemple : tenter de définir un mot de passe qui est interdit par la liste globale de Microsoft (notez que cette liste n’est pas documentée, mais nous pouvons ici faire le test par rapport à un terme interdit connu). Cet exemple suppose que vous avez configuré la stratégie en mode Appliqué et que vous avez ajouté zéro terme à la liste personnalisée des mots de passe interdits.
net.exe user ContosoUser PassWord The password doesn't meet the password policy requirements. Check the minimum password length, password complexity, and password history requirements. More help is available by typing NET HELPMSG 2245.Conformément à la documentation, étant donné que notre test était une opération de réinitialisation de mot de passe, vous devriez voir un événement 10017 et un événement 30005 pour l’utilisateur ContosoUser.
L’événement 10017 doit se présenter comme dans l’exemple suivant :
The reset password for the specified user was rejected because it didn't comply with the current Azure password policy. For more information, please see the correlated event log message. UserName: ContosoUser FullName:L’événement 30005 doit se présenter comme dans l’exemple suivant :
The reset password for the specified user was rejected because it matched at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy. UserName: ContosoUser FullName:Essayons un autre exemple ! Nous allons maintenant tenter de définir un mot de passe qui est interdit par la liste personnalisée des mots de passe interdits alors que la stratégie est en mode Audit. Cet exemple suppose que vous avez terminé les étapes suivantes : vous avez configuré la stratégie en mode Audit, ajouté le terme « lachrymose » à la liste personnalisée des mots de passe interdits et synchronisé la nouvelle stratégie résultante avec le contrôleur de domaine en effectuant un cycle du service de l’agent DC comme décrit précédemment.
Maintenant que tout est bon, définissez une variante du mot de passe interdit :
net.exe user ContosoUser LaChRymoSE!1 The command completed successfully.N’oubliez pas que, cette fois-ci, l’opération a réussi, car la stratégie est en mode Audit. Vous devez voir un événement 10025 et un événement 30007 pour l’utilisateur ContosoUser.
L’événement 10025 doit se présenter comme dans l’exemple suivant :
The reset password for the specified user would normally have been rejected because it didn't comply with the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. Please see the correlated event log message for more details. UserName: ContosoUser FullName:L’événement 30007 doit se présenter comme dans l’exemple suivant :
The reset password for the specified user would normally be rejected because it matches at least one of the tokens present in the per-tenant banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. UserName: ContosoUser FullName:Continuez à tester les différents mots de passe de votre choix et vérifiez les résultats dans l’observateur d’événements à l’aide des procédures décrites dans les étapes précédentes. Si vous avez besoin de modifier la stratégie dans le Centre d’administration Microsoft Entra, n’oubliez pas de synchroniser la nouvelle stratégie avec l’agent contrôleur de domaine comme décrit précédemment.
Nous avons traité des procédures qui vous permettent de tester de manière contrôlée le comportement de validation des mots de passe de la capacité Protection par mot de passe Microsoft Entra. La réinitialisation des mots de passe utilisateur à partir de la ligne de commande directement sur un contrôleur de domaine peut paraître un moyen étrange d’effectuer de tels tests, mais, comme décrit précédemment, il est conçu pour produire des résultats reproductibles. Lorsque vous testez différents mots de passe, gardez l’algorithme d’évaluation des mots de passe à l’esprit, car cela peut aider à expliquer des résultats auxquels vous ne vous attendiez pas.
Avertissement
Une fois tous les tests terminés, n’oubliez pas de supprimer tous les comptes d’utilisateur créés à des fins de test !
Contenu supplémentaire
Les liens suivants ne font pas partie de la documentation principale de la Protection par mot de passe Microsoft Entra. Ils peuvent toutefois être une source utile d’informations supplémentaires sur cette fonctionnalité.
Protection par mot de passe Microsoft Entra désormais disponible au grand public !
Support de formation Premier\Unifié Microsoft disponible
Si vous souhaitez en savoir plus sur la Protection par mot de passe Microsoft Entra et sur son déploiement, vous pouvez utiliser un service proactif Microsoft. Ce service est disponible pour les clients disposant d’un contrat de support Premier ou Unifié. Le service est appelé Microsoft Entra ID : Protection de mot de passe. Pour plus d’informations, contactez votre responsable de compte Réussite clients.
Étapes suivantes
Si vous avez une question sur la protection par mot de passe Microsoft Entra locale qui serait restée sans réponse ici, adressez-nous votre question en soumettant vos commentaires ci-dessous. Merci !