L'un des principaux avantages d’Azure AD Password Protection est d’aider à se défendre contre les attaques par pulvérisation de mots de passe (password spray). La plupart des attaques par pulvérisation de mots de passe ne tentent pas d'attaquer un compte individuel plus d'une fois, car un tel comportement augmente considérablement la probabilité de détection, que ce soit par verrouillage de compte ou d'autres moyens. La majorité des attaques par pulvérisation de mots de passe reposent donc sur la soumission d'un petit nombre seulement des mots de passe les plus faibles connus pour chacun des comptes d'une entreprise. Cette technique permet à l'attaquant de rechercher rapidement un compte facilement compromis tout en évitant les seuils de détection potentiels.

Azure AD Password Protection est conçu pour bloquer efficacement tous les mots de passe faibles connus qui sont susceptibles d'être utilisés lors d'attaques par pulvérisation de mots de passe, selon la base des données de télémétrie de sécurité d’Azure AD. Microsoft est au courant de sites Web tiers qui énumèrent des millions de mots de passe qui ont été compromis lors de failles de sécurité connues du public. Les produits de validation de mots de passe de tierces sont basés sur une comparaison brute par rapport à ces millions de mots de passe. Microsoft estime que de telles techniques ne sont pas le meilleur moyen d'améliorer la force globale des mots de passe étant donné les stratégies typiques utilisées par les attaquants par pulvérisation de mots de passe.

Azure AD Password Protection peut être utilisé à la fois dans Azure Active Directory mais aussi sur l’annuaire Active Directory On-Premises.

Présentation des composants

Le diagramme suivant montre comment les composants de base de la protection par mot de passe Azure AD opèrent ensemble dans un environnement Active Directory local.

 

(source : docs.microsoft.com)

 

La solution regroupe plusieurs éléments :

• Les contrôleurs de domaine en lecture/écriture qui comporte l’agent du service Azure AD Password Protection où sont écrits les stratégies de mot de passe et éventuellement répliquées aux autres contrôleurs de domaine.  C’est aussi l’agent DC qui valide les mots de passe lors des demandes de changement effectués par les utilisateurs ou administrateurs.
• Les serveurs hébergeant le proxy du service Azure AD Password Protection qui font le lien entre les contrôleurs de domaine et le service Azure AD Password Protection de manière à récupérer les stratégies de protection de mot de passe. Choisissez un ou plusieurs serveurs pour héberger le service proxy de protection par mot de passe. Chacun de ces services fournit uniquement des stratégies de mot de passe pour une forêt unique. La machine hôte doit être jointe à un domaine dans cette forêt. Les domaines racine et enfant sont tous deux pris en charge. Une connectivité réseau est nécessaire entre au moins un contrôleur de domaine dans chaque domaine de la forêt et la machine de protection de mot de passe.

 

Il n’y a pas de limitations pour gérer plusieurs forêts. Chaque forêt est configurée indépendamment comme décrit dans cet article. Chaque proxy de protection par mot de passe ne peut prendre en charge que les contrôleurs de domaine de la forêt à laquelle il est relié. Vous devez donc installer un proxy par forêt.

 

D’un point de vue sécurité, la solution répond aux grands concepts de préservation de la sécurité et de la vie privée :

• Les contrôleurs de domaine n'ont jamais à communiquer directement avec Internet.
• Aucun nouveau port réseau n'est ouvert sur les contrôleurs de domaine.
• Aucune modification de schéma Active Directory n'est nécessaire. Le service utilise le conteneur Active Directory existant et les objets de schéma serviceConnectionPoint.
• Aucun changement du niveau fonctionnel de forêt ou de domaine n'est requis.
• Le service ne crée ni n'exige de comptes dans les domaines Active Directory qu'il protège.
• Les mots de passe en texte clair de l'utilisateur ne quittent jamais le contrôleur de domaine, que ce soit pendant les opérations de validation du mot de passe ou à tout autre moment.
• Le service ne dépend pas d'autres fonctions d'Azure AD ; par exemple, la synchronisation du hachage du mot de passe d'Azure AD n'est pas liée et n'est pas nécessaire pour que la protection par mot de passe Azure AD fonctionne.
• Le déploiement incrémental est pris en charge, mais la stratégie de mot de passe n'est appliquée que lorsque l'agent de contrôleur de domaine (DC Agent) est installé sur le contrôleur de domaine utilisé pour l’opération de changement de mot de passe.

 

Processus de récupération des stratégies

Chaque instance du service Proxy d’Azure AD Password Protection s’enregistre sur les contrôleurs de domaine dans la forêt en créant un objet serviceConnectionPoint dans Active Directory.

Chaque service Agent DC d’Azure AD Password Protection crée également un objet serviceConnectionPoint dans Active Directory. Cet objet est principalement utilisé pour le reporting et le diagnostic.

Le service Agent DC est responsable d'initier le téléchargement d'une nouvelle stratégie de mots de passe à partir d'Azure AD. La première étape consiste à localiser un service proxy Azure AD Password Protection Proxy en interrogeant la forêt pour les objets proxy serviceConnectionPoint. Lorsqu'un service de proxy disponible est trouvé, l'agent DC envoie une demande de téléchargement de stratégie de mot de passe au service de proxy. Le service proxy envoie à son tour la demande à Azure AD. Le service proxy retourne ensuite la réponse au service d’agent DC.

Après que le service Agent DC reçoit une nouvelle stratégie de mot de passe d'Azure AD, le service stocke la stratégie dans un dossier dédié à la racine de son dossier sysvol domaine partagé. Le service Agent DC surveille également ce dossier au cas où des stratégies plus récentes se répliqueraient à partir d'autres services Agent DC dans le domaine.

Le service Agent DC demande toujours une nouvelle stratégie au démarrage du service. Après le démarrage du service Agent DC, il vérifie l'âge de la stratégie disponible localement toutes les heures. Si la stratégie a plus d'une heure, l’agent DC demande une nouvelle stratégie à Azure AD via le service proxy, comme décrit précédemment. Si la stratégie actuelle ne date pas de plus d'une heure, l'agent DC continue d'utiliser cette stratégie.

Chaque fois qu'une stratégie d’Azure AD Password Protection est téléchargée, cette stratégie est spécifique à un tenant. En d'autres termes, les règles de mot de passe sont toujours une combinaison de la liste globale des mots de passe bannis de Microsoft et de la liste personnalisée des mots de passe bannis dans le tenant.

L’agent DC communique avec le service proxy via RPC sur TCP. Le service proxy écoute ces appels sur un port RPC dynamique ou statique, selon la configuration. L'agent DC n'écoute jamais sur un port réseau disponible. Le service proxy n'appelle jamais le service d'agent de DC. Le service proxy ne met jamais en cache les stratégies ou tout autre état téléchargé depuis Azure.

 

Validation des mots de passe

Cette partie décrit à la fois le processus de validation de mot de passe ainsi que le fonctionnement de l’algorithme utilisé pour valider le mot de passe.

Processus de validation des mots de passe

La validation des mots de passe a lieu comme suit :

• La DLL du filtre de mot de passe de l'agent DC reçoit les demandes de validation de mot de passe utilisateur du système d'exploitation. Il les transmet au service Agent DC qui s'exécute localement sur le contrôleur de domaine.
• Le service Agent DC d’Azure AD Password Protection reçoit les demandes de validation de mot de passe de la DLL du filtre de mot de passe de DC Agent. Il les traite en utilisant la stratégie de mot de passe courante (disponible localement) et retourne le résultat : succès ou échec.

 

Le service Agent DC utilise toujours la stratégie de mot de passe la plus récente disponible localement pour évaluer le mot de passe d'un utilisateur. Azure AD Password Protection agit comme un complément aux stratégies de mot de passe d'Active Directory existantes, et non comme un remplacement. Ceci inclut toute autre DLL de filtre de mot de passe tierce qui peut être installée. Active Directory exige toujours que tous les composants de validation de mot de passe soient d'accord avant d'accepter un mot de passe.

 

Note : Si aucune stratégie de mot de passe n'est disponible sur le DC local, le mot de passe est automatiquement accepté. Lorsque cela se produit, un message d'événement est enregistré pour avertir l'administrateur

Les listes de mots de passe bannis

Il est important d'avoir de bonnes recommandations, mais même avec cela, des utilisateurs finiront par choisir des mots de passe avec un niveau de sécurité faible. Azure AD Password Protection protège l’entreprise en détectant et en bloquant les mots de passe faibles connus et leurs variantes, ainsi qu'en bloquant éventuellement les termes faibles supplémentaires spécifiques à l’entreprise.

 

Azure AD Password Protection fournit donc deux listes de mots de passe faibles :

• La liste globale des mots de passe bannis : L'équipe d'Azure AD Identity Protection analyse constamment les données de télémétrie de sécurité d'Azure AD à la recherche de mots de passe faibles ou compromis couramment utilisés, ou plus spécifiquement, les termes de base faibles qui sont souvent utilisés comme base des mots de passe faibles. Lorsque des termes aussi faibles sont trouvés, ils sont ajoutés à la liste globale des mots de passe interdits. Le contenu de la liste globale des mots de passe interdits ne repose sur aucune source de données externe. La liste mondiale des mots de passe interdits est entièrement basée sur les résultats de l'analyse et de la télémétrie de sécurité d'Azure AD.
• La liste personnalisée des mots de passe bannis : Il peut être intéressant d’améliorer encore davantage la sécurité en ajoutant des personnalisations via la liste des mots de passe bannis personnalisés. Microsoft recommande que les termes ajoutés à cette liste soient principalement axés sur des termes propres à l’entreprise, tels que :
  • Marques
  • Noms de produits
  • Lieux (par exemple, le siège social de l'entreprise)
  • Conditions internes spécifiques à l'entreprise
  • Noms d’équipe
  • Abréviations qui ont une signification spécifique pour l'entreprise.

Une fois les termes ajoutés à la liste des mots de passe bannis personnalisés, ils seront combinés avec les termes de la liste globale des mots de passe bannis lors de la validation des mots de passe.

Note : La liste lobale des mots de passe bannis par Microsoft n’est pas publiée publiquement pour ne pas informer les attaquants. Aujourd’hui cette liste comprend principalement des mots de passe et termes anglais, c’est pourquoi, il est primordial de correctement configurer la liste personnalisée des mots de passe. La liste des mots de passe personnalisés bannis est limitée à un maximum de 1000 termes.

 

Algorithme de validation des mots de passe

L’algorithme de validation des mots de passe a été conçu pour prendre en compte de nombreuses variations des mots de passe via des mécanismes de normalisation et de calcul de la difficulté.

Par exemple, si vous bannissez le terme : windows ; tous les mots de passe suivants seront bannis :

• windows18
• Windows18
• W1ndows18
• windowsTH
• W1nd0w$18
• Etc.

 

Chaque fois qu'un utilisateur change ou réinitialise son mot de passe, la complexité du nouveau mot de passe est vérifiée en le validant par rapport à la liste combinée des termes de la liste globale et de la liste personnalisée des mots de passe bannis.

Même si le mot de passe d'un utilisateur contient un mot de passe interdit, le mot de passe peut toujours être accepté si le mot de passe global est suffisamment fort sinon. Un mot de passe nouvellement configuré passera par les étapes suivantes pour évaluer sa force globale afin de déterminer s'il doit être accepté ou rejeté.

 

L’algorithme agit selon les étapes suivantes :

Etape 1 : La normalisation

Un nouveau mot de passe est d'abord soumis à un processus de normalisation. Cette technique permet de mapper un petit ensemble de mots de passe interdits à un ensemble beaucoup plus important de mots de passe potentiellement faibles.

La normalisation comporte deux parties. Tout d'abord, toutes les lettres majuscules sont remplacées par des minuscules. Deuxièmement, des substitutions de caractères communs sont effectuées, par exemple : 0 en o, 1 en l, $ en s, @ en a, etc.

Ainsi le mot de passe Micr0$0ft est normalisé en microsoft.

 

Etape 2 : Vérification si le mot de passe est considéré comme banni par les 3 moyens suivants:

L’appariement flou est utilisé sur le mot de passe normalisé pour identifier s'il contient un mot de passe trouvé sur la liste des mots de passe globaux ou personnalisés bannis. Le processus d'appariement est basé sur une différence d’un caractère. Par exemple : supposons que le mot de passe "microsoft" est interdit, et qu'un utilisateur essaie de changer son mot de passe pour un des suivants : microosft", "mircosoft" ; " microsoft1", "microsof".

Chacun des mots de passe ci-dessus ne correspond pas spécifiquement au mot de passe interdit "microsoft". Cependant, comme chaque exemple se trouve à une distance d'édition de 1 du terme interdit microsoft, ils sont tous considérés comme une correspondance avec microsoft.

 

La correspondant de la sous chaine est utilisée sur le mot de passe normalisé pour vérifier le prénom et le nom de l'utilisateur. Par exemple : supposons que nous avons un utilisateur, David, qui veut réinitialiser son mot de passe à "David123A". Après normalisation, ce mot de passe deviendrait "david123a". La correspondance des sous-chaînes indique que le mot de passe contient le prénom de l'utilisateur "David". Même si " David123A " ne figurait pas spécifiquement sur la liste des mots de passe interdits, la correspondance de sous-chaîne a trouvé "David" dans le mot de passe. Par conséquent, ce mot de passe serait rejeté.

 

Enfin le calcul du score (Score Calculation) est redoutable ! Il consiste à identifier toutes les occurrences de mots de passe bannis dans le nouveau mot de passe normalisé de l'utilisateur et déterminer un score calculé sur la base :

1. Chaque mot de passe banni qui se trouve dans le mot de passe d'un utilisateur reçoit un point.
2. Chaque caractère unique restant reçoit un point.
3. Un mot de passe doit avoir au moins cinq (5) points pour être accepté.

 

Supposons que "touch" fasse parti de la liste personnalisée. Supposons également que "microsoft" figure sur la liste globale. 

• Exemple : un utilisateur change son mot de passe en "MicrosoftTouch18".

Après normalisation, ce mot de passe devient "microsofttouch18". Le processus d'appariement trouve que ce mot de passe contient deux mots de passe interdits : microsoft et touch. Le mot de passe se voit alors attribuer un score : [microsoft] +[rhonetouch +[1] +[8] = 4 points. Comme le score de ce mot de passe est inférieur à 5 points, il sera rejeté.

• Exemple : un utilisateur change son mot de passe en "Micr0$0ftT0uch18!

Après normalisation, ce mot de passe devient "microsofttouch18!". Le processus d'appariement trouve que ce mot de passe contient deux mots de passe interdits : microsoft et touch. Ce mot de passe se voit alors attribuer un score : [microsoft] +[touch]+[1] +[8] + [!] = 5 points. Puisque ce mot de passe est d'au moins 5 points, il est accepté.

 

Cet algorithme est appliqué à chaque réinitialisation ou changement de mot de passe selon la liste globale et personnalisée.

 

Configuration des prérequis

Cette partie décrit les prérequis à mettre en œuvre pour mettre œuvre la sécurisation des mots de passe avec Azure Active Directory Password Protection.

Les prérequis suivantes s’appliquent :

• Licences :
  • Soit : Azure AD Premium (P1)
  • Soit : Enterprise Mobility + Security (EMS) E3
  • Soit : Microsoft 365 E3
• Les domaines Active Directory qui exécutent l’agent DC doivent utiliser la réplication du système de fichiers distribué (DFSR) pour la réplication sysvol.
• Le service de distribution de clés doit être activé sur tous les contrôleurs de domaine figurant dans le domaine qui exécutent Windows Server 2012.
• Tous les contrôleurs de domaine sur lesquels le service d’agent d’Azure AD Password Protection est installé doivent :
  • Exécuter Windows Server 2012 ou version ultérieure. Cette exigence n’implique pas que le domaine ou la forêt Active Directory doive également être au niveau fonctionnel du domaine ou de la forêt Windows Server 2012. Afin d’assurer une protection cohérente, il est nécessaire que tous les contrôleurs de domaine qui peuvent être utilisés pour les opérations de changement de mot de passe, soient équipés de l’agent DC et donc hébergés sur Windows Server 2012 ou plus.
  • Avoir le .NET Framework 4.5 ou plus installé
  • Avoir le Runtime C Universel

Note : Il n’est pas nécessaire d’installer l’agent sur les contrôleurs de domaine en lecture seul (RODC).

• Un ou plusieurs serveurs hébergeant le service proxy d’Azure AD Password Protection et répondant aux prérequis suivants :
  • Windows Server 2012 R2 ou plus.
  • .Net Framework 4.7+ installé
  • Runtime C Universel installé
  • Être connecté à Internet
  • Le trafic HTTP TLS 1.2 sortant doit être autorisé
• Un compte d’administrateur général pour inscrire la forêt et le service proxy de protection par mot de passe auprès d’Azure AD.
• Un compte disposant des privilèges d’administrateur de domaine Active Directory dans le domaine racine de la forêt pour inscrire la forêt Windows Server Active Directory auprès d’Azure AD.

 

Les prérequis réseaux suivants s’appliquent :

Source	Sens	Destination	Protocole
Azure AD Password Protection DC Agent	=>	Azure AD Password Protection Proxy Server	RPC (135) RPC DYNAMIC
Azure AD Password Protection Proxy Server	=>	Internet : https://login.microsoftonline.com https://enterpriseregistration.windows.net	HTTP (TCP/443)

 

Installation et Configuration du proxy Azure AD Password Protection

Cette partie décrit l’installation et la configuration du proxy Azure AD Password Protection. Pour rappel, ce rôle fait office de relais pour récupérer les stratégies de mot de passe utilisées par les contrôleurs de domaine pour valider les mots de passe soumis.

Pour rappel, voici les prérequis du serveur hébergeant ce rôle :

• Windows Server 2012 R2 ou plus.
• .Net Framework 4.7+ installé
• Runtime C Universel installé
• Être connecté à Internet
• Le trafic HTTP TLS 1.2 sortant doit être autorisé

 

Installation du proxy Azure AD Password Protection

Cette sous-partie décrit l’installation et la configuration du proxy Azure AD Password Protection.

Commencez par installer le .Net Framework 4.7+.

Une fois le Framework installé, téléchargez les sources du proxy Azure AD Password Protection. Depuis les sources, lancez l’installation du proxy en tant qu’administrateur.
La fenêtre d’installation se lance. Acceptez les termes du contrat et cliquez sur Install

 

Une fois l’installation terminée avec succès, cliquez sur Close

Vérifiez l’installation et la présence du service en lancant une invite de commande PowerShell et en exécutant :

Get-Service azureadpasswordprotectionproxy

 

L’état doit être en cours d’exécution / Running.

Note : Si vous utilisez un proxy Internet, je vous invite à consulter la documentation pour opérer sa configuration.

 

Enregistrement du proxy avec le tenant Azure AD

L’étape qui suit revient à enregistrer le proxy fraichement installé avec le tenant Azure Active Directory.
Pour ce faire, sur le serveur proxy, exécutez une invite de commande PowerShell en tant qu’administrateur.

Exécutez la commande suivante pour importer le module utilisé pour l’enregistrement :

Import-Module azureadpasswordprotection

 

Puis tapez : $get=get-credential

Renseignez les /mot de passe de l’administrateur global du tenant Azure Active Directory.

Tapez ensuite la commande :

Register-AzureADPasswordProtectionProxy -azurecredential $cred

Note : Ce mode ne fonctionne pas si une authentification à est nécessaire pour le compte utilisé. Dans ce cas, utilisez la commande :

Register-AzureADPasswordProtectionProxy -AccountUpn 'yourglobaladmin@yourtenant.onmicrosoft.com'

 

 

Enregistrement de la forêt

Vous devez initialiser la forêt Active Directory locale avec les informations d’identification nécessaires pour communiquer avec Azure. L’inscription de la forêt Active Directory est requise une seule fois au cours de la durée de vie de la forêt. Après cela, les agents du contrôleur de domaine dans la forêt effectuent automatiquement toutes les autres tâches de maintenance nécessaires.

Pour ce faire toujours sur le proxy, exécutez une invite de commande PowerShell en tant qu’administrateur.

Exécutez ensuite la commande suivante :

Register-AzureADPasswordProtectionForest -AccountUpn 'yourglobaladmin@yourtenant.onmicrosoft.com'

La forêt est maintenant enregistrée sur le proxy.

Note : La forêt ne doit être inscrite qu’une seule fois et la commande ne doit être exécutée qu’une seule fois. sont installés dans votre environnement, peu importe le serveur proxy que vous utilisez pour inscrire la forêt.

 

 

Installation de l’agent DC d’Azure AD Password Protection

Cette partie décrit l’installation de l’agent Azure AD Password Protection. Pour rappel, ce rôle s’intègre à l’annuaire et au contrôleur de domaine pour intercepter les changements de mots de passe et interroger le proxy pour savoir si la demande répond aux exigences.

 

Pour rappel, voici les prérequis du serveur hébergeant ce rôle :

• Exécuter Windows Server 2012 ou version ultérieure. Cette exigence n’implique pas que le domaine ou la forêt Active Directory doive également être au niveau fonctionnel du domaine ou de la forêt Windows Server 2012. Afin d’assurer une protection cohérente, il est nécessaire que tous les contrôleurs de domaine qui peuvent être utilisés pour les opérations de changement de mot de passe, soient équipés de l’agent DC et donc hébergés sur Windows Server 2012 ou plus.
• Avoir le .NET Framework 4.5 ou plus installé
• Avoir le Runtime C Universel

 

Note : Il n’est pas nécessaire d’installer l’agent sur les contrôleurs de domaine en lecture seul (RODC).

 

Commencez par installer le .Net Framework 4.5 via le gestionnaire de serveur (Server Manager). Une fois le Framework installé, téléchargez les sources de l’agent Azure AD Password Protection

Depuis les sources, lancez l’installation du proxy en tant qu’administrateur. Sur l’écran, acceptez le contrat de licence et cliquez sur Install :

Note : Vous pouvez installer le service d’agent DC sur une machine qui n’est pas encore un contrôleur de domaine. Dans ce cas, le service démarre et s’exécute, mais reste inactif jusqu’à ce que la machine soit promue comme contrôleur de domaine

Cliquez sur Finish :

 

La fenêtre suivante, vous invite à redémarrer le contrôleur de domaine :

Attention ! L’installation ou la désinstallation de l’agent DC, nécessite un redémarrage. Cela est dû au fait que les DLL de filtrage de mots de passe sont uniquement chargées ou déchargées par un redémarrage.

 

Vérification de l’infrastructure

Il est possible de vérifier l’infrastructure en utilisant des cmdlets PowerShell sur .

Pour ce faire connectez-vous à ce serveur et ouvrez une invite PowerShell.

Chargez le module via : Import-Module azureadpasswordprotection

 

Exécutez la commande :

Get-AzureADPasswordProtectionDCAgent

La commande doit renvoyer tous les agents de contrôleur de domaine avec :

• La version de l’agent
• La forêt et le domaine
• Le tenant Azure
• La date de dernier rechargement de la stratégie de mot de passe
• La date de dernière pulsation de l’état de santé

 

En outre, la commande Get-AzureADPasswordProtectionSummaryReport permet d’obtenir des statistiques sur l’utilisation du service par contrôleur de domaine :

 

 

 

Test d’Azure AD Password Protection

Cette partie décrit l’évaluation du service de protection des mots de passe proposé par Azure Active Directory. Nous évaluerons deux fonctionnalités :

• Le verrouillage dynamique des comptes lors des authentifications Cloud (Azure AD Smart Lockout).
• La liste des mots de passe interdits (Azure AD Banned Password). Ce test se fera en deux temps :
  • Evaluation dans un mode Audit
  • Evaluation dans un mode Appliqué bloquant les changements de mot de passe ne répondant pas aux critères.

 

 

Azure AD Smart Lockout

Tout comme sur l’annuaire Active Directory, Azure Active Directory propose un mécanisme de verrouillage/déverrouillage dynamique des mots de passe en fonction des échecs. Cette fonctionnalité ne requiert d’ailleurs pas de niveau de licence spécifique Azure Active Directory.

 

Configuration du tenant

Pour modifier la configuration du verrouillage intelligent, ouvrez le portail Azure Active Directory et naviguez dans Méthodes d’authentification (sous partie Sécurité). Cliquez ensuite sur Protection par mot de passe.

 

Modifiez les valeurs :

• Lockout Threshold étant le seuil à partir de combien de mot de passe érroné, le compte se voit verrouillé.
• Lockout duration in seconds étant le temps pendant lequel le compte sera vérrouillé.

 

Note : Il est recommandé de reporter la configuration de votre annuaire Active Directory.

 

Validation de la configuration

Pour évaluer la configuration du verrouillage intelligent des comptes, il suffit de procéder à la connexion d’un utilisateur sur les services Office 365. Nous procédons donc à la réalisation de 5 connexions infructueuses. Ceci renvoi un état de verrouillage :

Après 15 minutes, l’utilisateur peut se réauthentifier sur les services Cloud utilisant l’identité Azure Active Directory :

Azure AD Banned Password

La fonctionnalité Banned Password permet d’enrichir les stratégies de protection des mots de passe proposés par Active Directory en bannissant les mots de passe communs ou les mots de passe pouvant être facilement devinés car liés à l’image de l’entreprise.

Note : Cette fonctionnalité requiert à minima Azure AD Premium 1 (P1).

 

Configuration du tenant en mode Audit

Maintenant que les rôles nécessaires au service ont été installés dans l’infrastructure, nous pouvons procéder à la configuration de la stratégie de protection des mots de passe sur le tenant.

Pour ce faire, ouvrez le portail Azure Active Directory et naviguez dans Méthodes d’authentification (sous partie Sécurité).

Cliquez ensuite sur Protection par mot de passe.

Passez l’option Appliquer la liste personnalisée à Oui puis renseignez les mots de passe personnalisés à exclure.

Pour rappel, le service normalise les mots de passe des utilisateurs. Il n’est ainsi pas nécessaire de rentrer toutes les occurrences attendues (par exemple : password, P@ss0rd, P@$$w0rd, etc.). Vous pouvez simplement renseigner la version simple du mot de passe.  En outre, le service inclut une liste de mot de passe générique par défaut (par exemple password). Cette liste est pour l’heure centrée sur des occurrences anglophone.

 

Dans la partie Protection par mot de passe pour Windows Server Active Directory, vérifiez que la protection est activée.

Passez le mode en Audit.

Note : Nous passerons le mode en Appliqué / Enforced une fois que nous aurons validé le comportement. C’est d’ailleurs la recommandation de Microsoft pour ne pas impacter de manière trop importante vos utilisateurs.

 

Attention ! Tout changement sur la configuration (ajouts de mot de passe ou passage en mode Audit/Appliqué) peut prendre plusieurs heures pour être effectif.

 

Evaluation et Audit de la stratégie

Les événements suivants peuvent être utilisés pour évaluer l’impact de la stratégie en mode Audit :

	Modification de mot de passe (Utilisateur)	Définition de mot de passe (Administrateur
Réussite	10014	10015
Réussite à cause du mode Audit (aurait échoué avec la stratégie de mot de passe client)	10024, 30008	10025, 30007
Réussite à cause du mode Audit (aurait échoué avec la stratégie de mot de passe Microsoft)	10024, 30010	10025, 30009
Réussite à cause du mode Audit (aurait échoué avec les stratégies de mot de passe combinées Microsoft et client)	10024, 30028	10025, 30029

 

Maintenant que le tenant a été configuré en mode Audit, vous pouvez tenter de réaliser un changement de mot de passe sur une machine cliente.

Vous pouvez réaliser un essai avec l’un des mots de passe défini.

Connectez-vous en suite sur le proxy Azure AD Password Protection en utilisant des cmdlets PowerShell et chargez le module via : Import-Module azureadpasswordprotection

 

Exécutez la commande Get-AzureADPasswordProtectionSummaryReport.

 

Vous pouvez constater qu’un changement de mot de passe n’a pas répondu aux exigences.

Vous pouvez apprendre plus de détails dans les journaux d’événements du contrôleur de domaine associé en naviguant dans Journaux des applications et des services – Microsoft – AzureADPasswordProtection – DCAgent - Admin

Nous retrouvons les événements : 10024 et 30010 indiquant que le changement de mot de passe aurait dû être rejeté :

 

Configuration du tenant en mode Appliqué (Blocage)

Maintenant que nous avons testé le mode Audit, nous pouvons procéder au blocage des changements et réinitialisation de mot de passe qui ne répondent pas aux exigences.

Pour ce faire, ouvrez le portail Azure Active Directory et naviguez dans Méthodes d’authentification (sous partie Sécurité).

Cliquez ensuite sur Protection par mot de passe.

Dans la partie Protection par mot de passe pour Windows Server Active Directory, vérifiez que la protection est activée.

Passez le mode en Appliqué / Enforced.

 

Attention ! Tout changement sur la configuration (ajouts de mot de passe ou passage en mode Audit/Appliqué) peut prendre plusieurs heures pour être effectif.

 

Application de la stratégie (Blocage)

Dans cette partie, nous nous attardons un peu plus en détails sur les tests avec les scénarios suivants :

1. Evaluation du blocage du changement d’un mot de passe générique issu de la chaine de caractère password
2. Evaluation du blocage du changement d’un mot de passe issu de la liste des mots de passe personnalisés du département
3. Evaluation de l’autorisation du changement d’un mot de passe répondant aux critères et à l’algorithme malgré la source initiale du mot de passe
4. Evaluation du blocage de la réinitialisation d’un mot de passe issu de la liste des mots de passe personnalisés du Département par un administrateur via Active Directory

 

Les événéments suivants peuvent être utilisés pour évaluer l’impact de la stratégie en mode Appliqué / Enforced :

	Modification de mot de passe (Utilisateur)	Définition de mot de passe (Administrateur)
Réussite	10014	10015
Échec (à cause de la stratégie de mot de passe client)	10016, 30002	10017, 30003
Échec (à cause de la stratégie de mot de passe Microsoft)	10016, 30004	10017, 30005
Échec (à cause des stratégies de mot de passe combinées Microsoft et client)	10016, 30026	10017, 30027

 

Blocage à cause de la stratégie de mot de passe Microsoft

Cette partie vise à valider que le blocage est effectif pour les mots de passe identifiés comme communs par Microsoft. Nous testerons donc la configuration d’un mot de passe issu de la chaine de caractère : password.

Note : Il n’est pas possible de modifier la liste des mots de passe de Microsoft.

Vous pouvez réaliser cet essai sur un poste Windows 10 avec le mot de passe P@ssw0rd :

 

L’utilisateur reçoit le message : Impossible de mettre à jour le mot de passe. Le nouveau mot de passe entré ne respecte pas les spécifications de longueur, de complexité ou d'historique du domaine.

 

Vous pouvez constater qu’un changement de mot de passe n’a pas répondu aux exigences.

Vous pouvez apprendre plus de détails dans les journaux d’événéments du contrôleur de domaine associé en naviguant dans Journaux des applications et des services – Microsoft – AzureADPasswordProtection – DCAgent – Admin. Nous retrouvons les événements : 10016 et 30004 indiquant que le changement de mot de passe a été rejeté par la stratégie de mot de passe Azure :

 

Blocage à cause de la stratégie de mot de passe du Département

Cette partie vise à valider que le blocage est effectif pour les mots de passe renseignés par le Département dans la liste personnalisée. Nous testerons donc la configuration d’un mot de passe issu de la chaine de caractère : windows.

Vous pouvez réaliser cet essai sur un poste Windows 10 avec le mot de passe Wind0w$18 :

 

L’utilisateur reçoit le message : Impossible de mettre à jour le mot de passe. Le nouveau mot de passe entré ne respecte pas les spécifications de longueur, de complexité ou d'historique du domaine.

 

Vous pouvez constater qu’un changement de mot de passe n’a pas répondu aux exigences.

Vous pouvez apprendre plus de détails dans les journaux d’événéments du contrôleur de domaine associé en naviguant dans Journaux des applications et des services – Microsoft – AzureADPasswordProtection – DCAgent – Admin. Nous retrouvons les événements : 10016 et 30002 indiquant que le changement de mot de passe a été rejeté par la stratégie de mot de passe du tenant Azure 

 

 

Changement d’un mot de passe répondant aux critères et à l’algorithme malgré la source initiale du mot de passe

Cette partie vise à valider que la capacité de changement de mot de passe pour un mot de passe issu de la souche mais avec une complexité dépassant les attentes de l’algorithme (5 points de différences). Nous testerons donc la configuration d’un mot de passe issu de la chaine de caractère : windows.

Vous pouvez réaliser cet essai sur un poste Windows 10 avec le mot de passe Wind0w$T0uch123! :

 

Cette fois, l’utilisateur peut changer le mot de passe car il est jugé non commun par l’algorithme.

Vous pouvez apprendre plus de détails dans les journaux d’événéments du contrôleur de domaine associé en naviguant dans Journaux des applications et des services – Microsoft – AzureADPasswordProtection – DCAgent – Admin. Nous retrouvons l’événement 10014 indiquant que le changement de mot de passe a été autorisé

 

 

Blocage de la réinitialisation d’un mot de passe par l’administrateur

Le dernier test vise à démontrer que les stratégies s’appliquent aussi aux réinitialisations de mot de passe faites par des administrateurs via la console Active Directory. Pour ce faire, nous testerons donc la configuration d’un mot de passe issu de la chaine de caractère : password.

Nous réalisons cet essai via la console Active Directory sur l’utilisateur avec le mot de passe P@ssw0rd :

 

La console renvoi le message d’erreur :

Ce mot de passe ne correspond pas aux critères de stratégie de mot de passe. Vérifiez la longueur du mot de passe minimale, la complexité du mot de passe et l’historique des critères de mot de passe.

 

Vous pouvez constater qu’un changement de mot de passe n’a pas répondu aux exigences.

Vous pouvez apprendre plus de détails dans les journaux d’événements du contrôleur de domaine associé en naviguant dans Journaux des applications et des services – Microsoft – AzureADPasswordProtection – DCAgent – Admin. Nous retrouvons les événements : 10017 et 30005 indiquant que la réinitialisation de mot de passe a été rejetée par la stratégie de mot de passe Azure :

 

 

Supervision du service

Microsoft offre différents moyens de superviser le service Azure AD Password Protection

Les journaux d’événéments

• Sur le Proxy d’Azure AD Passsword Protection:
  • \Applications and Services Logs\Microsoft\AzureADPasswordProtection\ProxyService\Admin
  • \Applications and Services\Logs\Microsoft\AzureADPasswordProtection\ProxyService\Operational
  • \Applications and Services Logs\Microsoft\AzureADPasswordProtection\ProxyService\Trace

Composant	Plage d’identifiant d’événements
Proxy service hosting process	10000-19999
Proxy service core business logic	20000-29999
PowerShell cmdlets	30000-39999

 

• Sur l’agent DC d’Azure AD Password Protection :
  • \Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Admin permet d‘obtenir des informations sur les validations de mot de passe réalisées sur ce contrôleur de domaine et le résultat associé.

	Modification de mot de passe (Utilisateur)	Définition de mot de passe (Administrateur)
Réussite	10014	10015
Échec (à cause de la stratégie de mot de passe client)	10016, 30002	10017, 30003
Échec (à cause de la stratégie de mot de passe Microsoft)	10016, 30004	10017, 30005
Échec (à cause des stratégies de mot de passe combinées Microsoft et client)	10016, 30026	10017, 30027
Réussite à cause du mode Audit (aurait échoué avec la stratégie de mot de passe client)	10024, 30008	10025, 30007
Réussite à cause du mode Audit (aurait échoué avec la stratégie de mot de passe Microsoft)	10024, 30010	10025, 30009
Réussite à cause du mode Audit (aurait échoué avec les stratégies de mot de passe combinées Microsoft et client)	10024, 30028	10025, 30029

 

Correspondance des événéments avec le résultat de la Cmdlets Get-AzureADPasswordProtectionSummaryReport :

Propriété Get-AzureADPasswordProtectionSummaryReport	Evénément correpsondant
PasswordChangesValidated	10014
PasswordSetsValidated	10015
PasswordChangesRejected	10016
PasswordSetsRejected	10017
PasswordChangeAuditOnlyFailures	10024
PasswordSetAuditOnlyFailures	10025
PasswordChangeErrors	10012
PasswordSetErrors	10013

 

• \Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Operational permet d’obtenir des éléments sur l’agent en lui-même dont :

Composant	Plage d’identifiant d’événements
DC Agent password filter dll	10000-19999
DC agent service hosting process	20000-29999
DC agent service policy validation logic	30000-39999

 

• \Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Trace

 

Les Cmdlets PowerShell

Par import du module Azure AD Password Protection (AzureADPasswordProtection), vous obtenez les cmdlets suivantes :

• Get-AzureADPasswordProtectionSummaryReport offrant un rapport détaillé sur les validations de mot de passe réalisées par les contrôleurs de domaine.
• Get-AzureADPasswordProtectionDCAgent liste tous les agents DC et l’état associé (forêt, domaine, date de dernière mise à joru de la stratégie, etc.)
• Get-AzureADPasswordProtectionProxy liste les informations basiques sur les proxy de la forêt et d’un domaine.

 

Les compteurs de performance

L’agent DC d’Azure AD Password Protection installe les compteurs de performance suivants :

Nom du compteur	Description
Passwords processed	Ce compteur affiche le nombre total de mots de passe traités (acceptés ou refusés) depuis le dernier redémarrage.
Passwords accepted	Ce compteur affiche le nombre total de mots de passe acceptés depuis le dernier redémarrage.
Passwords rejected	Ce compteur affiche le nombre total de mots de passe qui ont été refusés depuis le dernier redémarrage.
Password filter requests in progress	Ce compteur affiche le nombre de demandes de filtre de mot de passe en cours.
Peak password filter requests	Ce compteur affiche le nombre maximum de demandes de filtre de mot de passe simultanées depuis le dernier redémarrage.
Password filter request errors	Ce compteur affiche le nombre total de demandes de filtre de mot de passe qui ont échoué en raison d'une erreur depuis le dernier redémarrage. Des erreurs peuvent se produire lorsque le service d'agent DC d'Azure AD Password Protection n'est pas exécuté.
Password filter requests/sec	Ce compteur affiche la vitesse à laquelle les mots de passe sont traités.
Password filter request processing time	Ce compteur affiche le temps moyen requis pour traiter une demande de filtre de mot de passe.
Peak password filter request processing time	Ce compteur affiche le temps de traitement des demandes de filtre de mot de passe de pointe depuis le dernier redémarrage.
Passwords accepted due to audit mode	Ce compteur affiche le nombre total de mots de passe qui auraient normalement été rejetés, mais qui ont été acceptés parce que la stratégie de mot de passe a été configurée pour être en mode audit (depuis le dernier redémarrage).

 

Ces compteurs peuvent être utilisés dans des outils de supervision de performance ou de sécurité.

Bonne sécurisation !