Active Directory : configuration d’Azure AD Password Protection on-premise

I. Présentation

Dans ce tutoriel, nous allons voir comment configurer Azure AD Password Protection for Windows Server Active Directory, c'est-à-dire sur une infrastructure on-premise.

Cette fonctionnalité va permettre de renforcer la sécurité des mots de passe au sein de votre annuaire Active Directory, pour aller un peu plus loin que la politique de mot de passe native. Azure AD Password Protection va détecter et bloquer les mots de passe faibles ainsi que leurs variantes, mais aussi des mots de passe compromis centralisés dans une base par les équipes d'Azure. En complément, vous pouvez décider de bloquer certains termes propres à votre entreprise, en créant une sorte de dictionnaire personnalisé qui contiendra une liste de mots à bloquer.

Note : Microsoft ne donne pas d'informations sur le nombre de mots de passe contenus dans la base globale ni les sources exactes, si ce n'est qu'elle est constituée à partir des données de télémétrie d'Azure AD.

Par exemple, le mot de passe "Password123!" pourrait être accepté sur votre domaine Active Directory, car il contient 12 caractères et 4 types de caractères différents. Sur le papier, il a tout du bon mot de passe, sauf que vous le savez, c'est un mot de passe très facile à deviner et il vaut mieux ne pas l'utiliser... Grâce à Azure AD Password Protection on-premise, il va être bloqué !

Par ailleurs, si je précise le terme "it-connect" dans le dictionnaire personnalisé, le mot de passe "it-c0nnect!!!" ("o" remplacé par "0") sera bloqué, tout comme "IT-conn3ct123!". Par contre, "itconnect123!" fonctionnera. Néanmoins, certaines substitutions ne sont pas prises en compte, car si l'on bloque "securite", on peut définir "S€curite14!" comme mot de passe.

Si vous avez bien compris l'intérêt de cette solution et que ça vous plaît, vous n'avez plus qu'à lire la suite de cet article. 🙂

II. Prérequis et téléchargements

Avant de débuter l'installation et la configuration de la solution, je vous invite à prendre connaissance des prérequis ci-dessous.

A. Prérequis n°1 : les licences

Pour utiliser cette fonctionnalité sur votre infrastructure on-premise, vos utilisateurs doivent être couverts par une licence Azure AD Premium P1 ou Azure AD Premium P2. Tout en sachant que la licence P1 est intégrée aux licences EMS E3, Microsoft 365 E3, et Microsoft 365 Business Premium.

Microsoft précise que les utilisateurs de l'AD local qui ne sont pas synchronisés bénéficient également de la protection, même sans la licence, par l'intermédiaire des autres utilisateurs sous licence.

Remarque : cette option n'est pas activable par utilisateur, ce qui signifie que la protection sera appliquée à l'ensemble de vos utilisateurs.

B. Prérequis n°2 : les serveurs

Pour mettre en oeuvre Azure AD Password Protection sur votre infrastructure on-premise, il est nécessaire d'installer deux agents :

• Azure AD Password Protection Proxy :
  • A installer sur un serveur qui n'est pas contrôleur de domaine (DC ou RODC) et minimum sous Windows Server 2012
  • Ce module est installable sur le même serveur qu'Azure AD Connect sans problème
• Azure AD Password Protection DC :
  • Cet agent doit être installé sur l'ensemble des contrôleurs de domaine pour que tous les DC soient capables de contrôler les mots de passe via le service Azure. Pour tester la solution, vous pouvez installer l'agent sur un seul DC.
  • Ne pas installer cet agent sur les serveurs RODC

En complément, vous devez disposer d'un serveur Azure AD Connect en place puisque c'est nécessaire pour synchroniser les utilisateurs de l'ADDS local vers Azure AD (Tutoriel - Installation d'Azure AD Connect).

Pour que les utilisateurs soient en mesure de réinitialiser leur mot de passe en autonomie et depuis Office 365, pensez à activer le portail de réinitialisation libre-service d'Office 365.

Il est à noter également que votre domaine Active Directory doit utiliser la réplication DFSR, et non FRS (s'il s'agit d'un domaine Active Directory migré depuis une ancienne version de Windows Server, c'est possible. Je vous invite à lire ce tutoriel si besoin : Passer SYSVOL de FRS à DFSR.

Microsoft par du principe qu'un contrôleur de domaine ne doit pas accéder directement à Internet. C'est pour cette raison que cette solution, comme d'autres, s'appuie sur un agent "proxy" qui doit être installé sur un autre serveur connecté à Internet.

C. Téléchargements

Afin de télécharger les deux paquets d'installation des agents cités précédemment, utilisez ce lien officiel :

• Téléchargement - Azure AD Password Protection

D. Ressources

En complément de ce tutoriel, et puisque l'outil Azure AD Password Protection est assez vaste, je vous invite à consulter les liens ci-dessous pour obtenir des réponses à vos éventuelles interrogations :

• Microsoft Docs - Azure AD Password Protection - Déploiement de la fonctionnalité
• Microsoft Docs - Azure AD Password Protection - L'analyse des mots de passe

III. Configuration d'Azure AD Password Protection

Avant de passer à l'installation des agents, nous allons regarder la configuration du côté d'Azure. Connectez-vous sur le portail Azure et accédez à la section "Méthodes d'authentification". Ensuite, sur la gauche cliquez sur "Protection par mot de passe".

Au sein de cette section, on va s'intéresser à 3 options particulièrement :

• Mots de passe interdits personnalisés - Appliquer la liste personnalisée : en cliquant sur "Oui", cela vous donne la possibilité d'indiquer des termes à bloquer, ce qui est l'occasion de spécifier le nom de votre entreprise pour empêcher qu'il soit utilisé dans des mots de passe. En indiquant un terme, le système générera automatiquement des variantes (par exemple, remplacer le "a" par "@") pour les bloquer aussi.
• Activer la protection par mot de passe sur Windows Server Active Directory : veillez à ce que cette option soit sur "Oui", car cela permet d'activer la fonction que l'on souhaite mettre en place.
• Mode : choisissez le mode "Audit" dans un premier temps pour tester la solution, cela va générer des logs mais les mots de passe interdits ne seront pas bloqués. À la fin du déploiement, il faudra passer le mode sur "Appliqué".

Cliquez sur le bouton "Enregistrer" une fois que c'est fait, et passez à la suite.

IV. Azure AD Password Protection : installation du rôle proxy

Commençons par installer le rôle proxy sur notre serveur. Pour ma part, c'est sur un serveur sous Windows Server 2022 en mode "Core", mais bien sûr vous pouvez l'installer sur un serveur avec une interface graphique.

Exécutez l'installeur "AzureADPasswordProtectionProxySetup.msi" et suivez l'assistant : quelques clics vont suffire.

Suite à cette installation, un nouveau service nommé "Azure AD Password Protection Proxy" sera ajouté sur votre serveur. Grâce à la commande ci-dessous, vous pouvez vérifier qu'il est bien cours d'exécution (running).

Get-Service AzureADPasswordProtectionProxy | fl

Désormais, il faut connecter ce nouveau service avec notre Azure AD. pour cela, on va utiliser le cmdlet "Register-AzureADPasswordProtectionProxy" et spécifier un compte administrateur global. Ce qui donne :

Register-AzureADPasswordProtectionProxy -AccountUpn "[email protected]"

Cette commande va permettre de vous authentifier et d'interconnecter les deux éléments. Si vous utilisez un serveur en mode "Core", il faudra réaliser l'authentification avec un code périphérique (code à valider depuis un navigateur avec une autre machine), en ajoutant l'option "-AuthenticateUsingDeviceCode" comme ceci :

Register-AzureADPasswordProtectionProxy -AccountUpn "[email protected]" -AuthenticateUsingDeviceCode

Ensuite, nous devons enregistrer la forêt Active Directory avec Azure AD. Pour cette action, il y a un cmdlet dédié également et qui se nomme "Register-AzureADPasswordProtectionForest". Il suffit de l'utiliser comme le cmdlet précédent, ce qui donne :

Register-AzureADPasswordProtectionForest -AccountUpn "[email protected]"

Là encore, si vous avez un serveur mode "Core", il faudra spécifier le paramètre additionnel, comme ceci :

Register-AzureADPasswordProtectionForest -AccountUpn "[email protected]" -AuthenticateUsingDeviceCode

Notre serveur "proxy" est prêt, nous pouvons passer à la suite.

V. Azure AD Password Protection : installation de l'agent AD

Cette fois-ci, sur votre contrôleur de domaine, exécutez l'installeur "AzureADPasswordProtectionDCAgentSetup.msi" pour installer le deuxième agent. L'installation n'est pas plus compliquée, quelques clics et le tour est joué.

À la fin c'est un peu différent : cliquez sur "Yes" afin de redémarrer le serveur dès maintenant. Cette étape est indispensable, car les DLL de filtrage de mots de passe ne sont chargées qu'au démarrage.

Puisque vous allez devoir installer l'agent sur l'ensemble de vos contrôleurs de domaine et que Microsoft fournit un package MSI, vous pouvez le déployer par GPO (Tutoriel - Déployer un logiciel au format MSI par GPO). Voici également la ligne de commande pour l'installer en mode silencieux :

msiexec.exe /i AzureADPasswordProtectionDCAgentSetup.msi /quiet /qn /norestart

Quand votre serveur aura redémarré, je vous invite à saisir la commande ci-dessous pour voir que le nom de votre tenant apparaît bien au niveau de la propriété "AzureTenant".

Get-AzureADPasswordProtectionDCAgent

Au sein du partage SYSVOL de votre domaine, vous pouvez retrouver un dossier nommé "AzureADPasswordProtection". A l'intérieur, l'agent va stocker les informations liées à votre politique de mot de passe Azure AD. Ces informations sont synchronisées à intervalle régulier et répliquées sur tous les contrôleurs de domaine puisqu'elles sont stockées dans SYSVOL.

La solution Azure AD Password Protection on-premise est désormais en place, nous n'avons plus qu'à tester.

VI. Tester la solution Azure AD Password Protection on-premise

Sur votre contrôleur de domaine où l'agent est installé, je vous invite à saisir la commande suivante :

Get-AzureADPasswordProtectionSummaryReport

Elle va vous permettre d'obtenir des statistiques liées à l'activité d'Azure AD Password Protection : nombre de mots de passe rejetés, nombre de changements de mots de passe validés, etc... Au début, tout est à zéro, et puis en effectuant quelques essais, vous verrez que c'est bien incrémenté.

Vous pouvez aussi cibler un contrôleur de domaine spécifique :

Get-AzureADPasswordProtectionSummaryReport -DomainController SRV-ADDS-01

Voici un exemple :

Pour tester, c'est facile, il suffit de changer le mot de passe d'un utilisateur, que ce soit à partir de la console "Utilisateurs et ordinateurs Active Directory", du "Centre d'administration Active Directory", ou via un poste de travail directement. Ensuite, testez avec un mot de passe qui matche avec votre dictionnaire personnalisé ou qui devrait être bloqué car trop faible (malgré qu'il respecte votre politique de mot de passe).

Puisque nous sommes en mode audit, même si le mot de passe n'est pas conforme, l'utilisateur pourra le définir. Dans l'observateur d'événements, il y aura des logs pour tout tracer : changement accepté ou non. Ces journaux sont situés dans :

Journaux des applications et des services > Microsoft > AzureADPasswordProtection > DCAgent > Admin

Voici un exemple :

Il y a différents numéros ID d'événements, dont :

• 10015 : mot de passe validé, car il est conforme
• 10025 : mot de passe non conforme à la politique Azure (exemple : présent dans votre dictionnaire personnalisé)
• 30006 : état de la politique synchronisée, notamment le mode (audit ou appliqué)
• 30009 : mot de passe rejeté, car il est présent dans la liste globale des mots de passe Azure
• Tous les ID sont visibles sur cette page : Microsoft Docs

Si vos tests sont concluants et que vous souhaitez passer en production cette fonctionnalité de sécurité, il ne vous reste plus qu'à passer sur le mode "Appliqué" sur l'interface d'Azure.

Florian BURNEL Co-founder of IT-Connect

Ingénieur système et réseau, cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.

See Full Bio