Mise à jour : Azure AD Password Protection est devenu généralement disponible le2 avril 2019. Le service est en grande partie le même que celui que j'ai présenté dans ce billet, avec les mises à jour suivantes :
- La limite de deux procurations a été levée.
- Lors de l'enregistrement du proxy et de la forêt Active Directory, 3 modes d'authentification sont désormais disponibles. Deux d'entre eux supportent le MFA, il n'est donc pas nécessaire d'avoir un compte Global Admin sans MFA.
- L'algorithme d'évaluation des mots de passe interdits a été mis à jour. Voir "Comment les mots de passe sont-ils évalués" dans la documentation Microsoft. Remarque : cet algorithme peut être modifié à tout moment, sans préavis ni mise à jour de la documentation.
- L'octroi de licences a été simplifié : Tous les utilisateurs synchronisés avec Azure AD doivent avoir Azure AD Premium P1 ou P2. Une fois cette condition remplie, tous les utilisateurs d'Active Directory bénéficient d'une licence pour ce service.
- Les clients de la prévisualisation doivent mettre à jour leurs agents ; les agents de la prévisualisation publique cesseront de fonctionner après le 1er juillet 2019.
- Mes sources chez Microsoft me disent qu'avec un peu de communication en amont, les utilisateurs ne trouvent pas le nouveau rejet des mots de passe courants avec le message standard "Votre mot de passe ne répond pas aux exigences de complexité" aussi déroutant qu'ils le pensaient.
- Commencez à déployer !
Microsoft a enfin fourni un service qui atténue le risque de sécurité lié aux mots de passe le plus critique dans les entreprises aujourd'hui : les mots de passe courants. Nous vous conseillons de tester cette nouvelle fonctionnalité d'Active Directory dès aujourd'hui, afin de pouvoir la déployer dès qu'elle sera disponible.
Il s'agit d'un long article ; si vous n'êtes pas intéressé par la version TL;DR (et vous devriez l'être), vous pouvez passer directement à l'article suivant
- Le mot de passe courant comme vecteur d'attaque
- Architecture
- Flux d'authentification en cours d'exécution
- Processus d'évaluation des mots de passe
- Avantages de la conception
- Étapes du déploiement
- Contrôle
- Licences
- Diverses informations
Le mot de passe courant comme vecteur d'attaque
J'ai publié des articles dans ce blog et pris la parole au Cloud Identity Summit (désormais Identiverse) sur les recommandations de Microsoft et du NIST concernant la configuration de la longueur des mots de passe, de leur expiration et d'autres politiques relatives aux mots de passe, à la lumière de leurs recherches et de leur expérience sur le terrain. L'une des principales recommandations des deux organisations est l'utilisation d'une liste de mots de passe interdits, dans laquelle les mots de passe les plus simples et les plus courants ne sont pas autorisés. (Et oui, je suis ici pour vous dire que certains des mots de passe les plus courants sont "password" et "12345678". Je crains pour la race humaine).
Selon Microsoft, les attaques contre les mots de passe courants par "pulvérisation de mot de passe" ont augmenté de façon spectaculaire au cours des derniers mois. Il est extrêmement difficile de se défendre contre ces attaques à l'aide d'outils de sécurité conventionnels, car l'attaquant n'attaque pas un seul compte avec plusieurs mots de passe. Il utilise plutôt quelques mots de passe communs pour attaquer plusieurs comptes. Chaque compte ne fait l'objet que de quelques tentatives, éventuellement espacées d'un long intervalle pour éviter de déclencher des alertes. La meilleure façon de se protéger contre ces attaques est tout simplement de ne pas avoir de mots de passe communs.
La plupart des grandes entreprises utilisent une architecture d'identité hybride dans laquelle les mots de passe sont gérés dans une forêt Active Directory sur site. Et Active Directory ne dispose malheureusement pas d'une solution prête à l'emploi pour interdire les mots de passe communs. Par conséquent, la plupart des organisations ne disposaient d'aucune protection contre les mots de passe communs.
Azure AD Password Protection est un service hybride en avant-première publique qui offre une protection contre les mots de passe courants pour les comptes organisationnels Azure AD et les comptes Windows Server Active Directory sur site. Il empêche les utilisateurs et les administrateurs de modifier ou de réinitialiser leurs mots de passe en les remplaçant par des mots de passe simples et faciles à décrypter, tels que "987654321" ou "quertyjkl ;" (pour les dactylographes).
Architecture
La protection des mots de passe Azure AD comprend un composant Azure, un service proxy sur site, un service DC et enfin un filtre de mot de passe personnalisé (Figure 1) :
Les objectifs de cette architecture sont les suivants : 1) utiliser la liste globale des mots de passe interdits (GBPL) d'Azure pour protéger les comptes Azure AD contre l'utilisation de mots de passe courants ; 2) permettre aux administrateurs Azure de créer une liste personnalisée de mots de passe interdits qui complète la GBPL ; et 3) protéger les comptes Active Directory contre les mots de passe courants en fournissant un service sur site qui utilise la liste consolidée des mots de passe interdits.
Azure
Azure AD utilise depuis un certain temps une liste de mots de passe interdits générée en interne et impose également le respect de longueurs de mot de passe minimales plus importantes. Si vous entrez un mot de passe courant, il vous sera gentiment conseillé de réessayer :
Le service de protection des mots de passe (figure 3) utilise le système de renseignement sur les menaces Azure pour obtenir une vue d'ensemble des mots de passe interdits. La liste est compilée à partir des mots de passe figurant dans les listes d'informations d'identification ayant fait l'objet d'une fuite, ainsi que de l'analyse que le système de veille sur les menaces Azure effectue sur les 20 millions ( !) de tentatives de prise de contrôle de comptes qu'il détecte chaque jouri. Cette liste ne contient pas tous les mots de passe courants jamais trouvés, mais seulement les 1 000 les plus courants activement utilisés dans les attaquesi.
Pourquoi le service ne vérifie-t-il pas la présence de plus de 1000 mots de passe courants ? Cela pourrait être pratique pour Azure, mais pas pour les serveurs sur site. Lors du processus d'évaluation du mot de passe, le mot de passe de l'utilisateur est comparé non seulement aux plus de 1000 mots de passe interdits, mais aussi à des milliers de variations potentielles de chacun d'entre eux. Cela fait beaucoup de mots de passe à comparer. Si la liste de mots de passe contenait un million de mots de passe, cela pourrait représenter des milliards de variations de mots de passe à vérifier par vos DC - et ils s'arrêteraient sous la charge.
Le contrôle et la configuration de la fonction de protection par mot de passe sont gérés dans le volet Azure Active Directory du portail de gestion, dans la nouvelle section Méthodes d'authentification. Le seul élément de cette nouvelle section - mais je suis sûr qu'il va s'étoffer - est la protection par mot de passe (figure 4).
En plus de la liste globale des mots de passe interdits (GBPL) générée par Azure, la protection des mots de passe Azure AD permet de visualiser les mots de passe interdits à utiliser (TBPL) pour l'ensemble du locataire. Par exemple, une société de services financiers peut vouloir interdire des mots de passe tels que "mortgage" ou "insurance" en plus des mots de passe communs déterminés globalement par Azure. (Dans la figure, j'ai ajouté les entreprises automobiles à la liste personnalisée.) Cette liste consolidée est celle qui est utilisée dans les locaux.
Notez que le service est judicieusement configuré de telle sorte que si vous installez des composants sur site sans toucher aux contrôles Azure, le service de protection par mot de passe commencera à fonctionner immédiatement, en mode audit, en utilisant la liste globale des mots de passe interdits d'Azure.
Service proxy
L'objectif du service proxy de protection des mots de passe Azure AD est d'acquérir la BPL et de la transmettre aux DC. Agissant comme un service de relais sans état, le proxy permet aux DC d'obtenir la BPL d'Azure AD sans avoir besoin d'un accès à Internet (un point sensible dans la sécurité des entreprises). Le proxy n'interroge pas Azure AD lui-même ; il transmet simplement les demandes de BPL des DC au service Azure et transmet le BPL résultant au DC demandeur. Il n'est donc pas nécessaire que les centres de données disposent d'une connexion internet.
Le service proxy peut être installé sur n'importe quel serveur rattaché à un domaine. Dans cet aperçu, il peut être installé sur un ou deux serveurs pour assurer la tolérance aux pannes ; cette limite devrait être levée avant l'AG. Le service proxy et la forêt Active Directory doivent être enregistrés auprès d'Azure AD à l'aide du nouveau module AzureADPasswordProtection (suivre attentivement les instructions). (Une fois enregistré, le proxy s'annonce au DC avec un point de connexion de service AzureAdPasswordProtectionProxy sous l'objet ordinateur (Figure 5) :)
Agent DC
Le package de l'agent DC contient deux composants (Figure 6). Le premier est l'agent DC lui-même, qui s'exécute en tant qu'AzureADPasswordProtectionDCAgent. Le second est un filtre de mot de passe personnalisé. Examinons-les dans l'ordre inverse.
Un filtre de mot de passe AD est une DLL personnalisée qui vous permet d'étendre la fonctionnalité de base d'un contrôle de validité du mot de passe. Le filtre de mot de passe du client Azure AD Password Protection est aussi simple que possible ; tout ce qu'il fait est de transmettre la demande de mot de passe à l'agent DC et de collecter la réponse d'acceptation ou de refus de l'agent.
Comme le filtre de mot de passe fait partie intégrante du système de sécurité du DC, un effet secondaire est que le DC doit être redémarré chaque fois que l'agent DC est installé ou supprimé.
L'agent DC est le cœur du service sur site. Pendant les opérations d'exécution du DC, l'agent vérifie la validité des changements de mot de passe des utilisateurs par rapport à la politique de mot de passe. En arrière-plan, il s'assure que le DC dispose d'une copie à jour de la BPL obtenue auprès d'Azure AD. Si ce n'est pas le cas, il en obtient une, la traite pour créer une politique de mot de passe, puis la stocke sur SYSVOL à l'adresse
C:WindowsSYSVOLsysvolPolicies{4A9AB66B-4365-4C2A-996C-58ED9927332D}AzureADPasswordProtection.
La manière dont les agents DC (dans un déploiement de production, il devrait y en avoir un sur chaque DC) obtiennent et distribuent la politique de mot de passe est assez élégante:
- Un agent DC dans chaque site Active Directory se réveille environ une fois par heure pour décider si sa copie locale de la stratégie de mot de passe sur SYSVOL doit être actualisée.
- Si la politique doit être actualisée ou s'il n'y a pas encore de politique, il demandera un nouveau BPL crypté à Azure AD via le proxy, créera une politique de mot de passe à partir de celui-ci et l'enregistrera dans SYSVOL.
- SYSVOL réplique cette politique sur tous les DC du domaine via DFS-R (Figure 7).
Au maximum, un DC par site peut demander la BPL, mais il y en aura probablement beaucoup moins - à peine une fois par heure et par domaine. Pourquoi ? En raison de la réplication efficace de la politique de DFS-R via SYSVOL. Dans un réseau correctement connecté, une politique mise à jour sera répliquée dans tous les DC avant que les autres agents ne se réveillent, et ils auront donc une politique à jour et n'auront pas besoin de demander une nouvelle BPL à Azure. Cette architecture garantit également que les DC dans les environnements verrouillés obtiendront toujours la politique de mot de passe, car la réplication SYSVOL est un élément essentiel de la fonctionnalité des DC.
Flux d'authentification en cours d'exécution
L'évaluation de la politique d'interdiction des mots de passe est intégrée au processus standard d'évaluation des mots de passe AD (figure 8) :
- L'utilisateur tente de définir un nouveau mot de passe et son DC local traite la demande.
- Sur le DC, la demande est traitée par le filtre de mot de passe personnalisé qui transmet le mot de passe à l'agent DC.
- L'agent DC compare le mot de passe proposé au mot de passe du SYSVOL et l'approuve ou le rejette.
- Le succès ou l'échec est renvoyé à l'utilisateur.
Processus d'évaluation des mots de passe
Le mot de passe proposé par l'utilisateur est comparé à une liste d'environ 1000 mots et motifs ("asdf", etc.). En outre, des substitutions de caractères sont effectuées sur le mot de passe ($ pour s, majuscules/minuscules, etc.). Actuellement, un score est calculé pour chaque mot de passe dans le mannerv suivant :
Chaque caractère vaut un point, mais toute sous-chaîne correspondant à un mot/phrase/motif interdit ne vaut qu'un point au total. Le score minimum autorisé est de 5 points. Par exemple, "Spring" et "2018" sont des mots interdits, donc "Spring2018" ne vaut que 2 points et n'est pas autorisé.
"Spring2018asdfj236" se décompose de la manière suivante :
- Ressort = 1 point
- 2018 = 1 point
- asdf = 1 point
- f, j, 2, 3, 6 = 1 point chacun
Total = 8 points = PASSE
Ce processus autorise certains mots ou phrases interdits s'il y a suffisamment d'autres caractères aléatoires dans le mot de passe. Notez qu'il est également susceptible d'être modifié, car Microsoft fait évoluer ses renseignements sur les menaces à l'échelle du nuage en ce qui concerne les attaques par mot de passevi.
La politique s'appliquera à tous les utilisateurs de la forêt - il n'y a pas de porte dérobée pour les administrateurs - et s'appliquera à tous les processus de changement de mot de passevii. La vérification normale des mots de passe incorrects avec l'émulateur PDC n'est pas affectée par cette nouvelle capacité.
Avantages de la conception
Cette conception hybride présente de nombreux avantages :
- Le processus de demande et de mise à jour de la BPL est conçu pour avoir un impact extrêmement faible sur les opérations des DC. Dans un réseau bien connecté, il suffit d'un seul DC par domaine et par heure pour demander la BPL.
- Le processus de demande et de mise à jour fonctionne avec un large éventail de topologies de réseau. Les DC n'ont pas besoin d'être connectés à l'internet ; seul le proxy a besoin d'un accès à l'internet. Et si nécessaire, le proxy n'a besoin de se connecter qu'à un seul DC par domaine via RPC (et le port est configurable). La réplication de SYSVOL via DFSR garantit que la politique de mot de passe est transmise à tous les DC du domaine.
- La vérification du mot de passe passe par les processus normaux d'Active Directory et toute modification de la fonctionnalité principale d'AD est réduite au minimum. Aucune partie de l'opération n'échappe au DC ; par exemple, une tentative de changement de mot de passe n'est jamais bloquée si le DC doit interroger Azure pour obtenir un nouveau BPL. Le filtre de mots de passe proprement dit est aussi simple que possible.
- Le logiciel est conçu en mode "fail open", c'est-à-dire que si un composant n'est pas installé ou ne fonctionne pas (par exemple, l'agent DC est installé mais le proxy ne l'est pas), le mot de passe sera autorisé, mais une erreur sera consignée dans le journal des événements du DC.
- Cette architecture ouverte à l'échec permet de préinstaller l'agent DC sur un serveur que vous avez l'intention de promouvoir en DC.
- L'agent DC exécute le même code de vérification de mot de passe que le service Azure.
- Vous n'avez pas besoin de le déployer sur tous vos DC pour le tester. En fait, c'est une bonne façon de le déployer de manière incrémentale.
Étapes du déploiement
Les étapes détaillées du déploiement sont documentées ici; comme ce service est en avant-première, je m'attends à ce qu'elles soient mises à jour régulièrement. En gros, les étapes sont les suivantes
- Déterminez sur quel(s) ordinateur(s) joint(s) au domaine vous souhaitez installer le service proxy, et sur quels DC vous souhaitez faire des tests. Le proxy n'a pas besoin d'être installé sur le serveur Azure AD Connect ou sur un DC ; n'importe quel serveur membre (tel qu'un serveur qui héberge déjà des connecteurs Application Proxy) fera l'affaire. Rappelez-vous que vous ne devez pas utiliser les aperçus publics sur des serveurs de production, ou du moins contre des utilisateurs de production ; vous pouvez promouvoir et isoler un DC dans son propre site pour le tester contre des utilisateurs spécifiques.
- Assurez-vous que le service Azure AD Password Protection est configuré en mode Audit (par défaut) et ajoutez éventuellement des mots de passe personnalisés à la BPL du locataire.
- Obtenez les bits de prévisualisation pour le service proxy de stratégie de mot de passe et l'agent DC à partir du centre de téléchargement.
- Installer le service proxy de politique de mot de passe.
- Sur le serveur proxy,
a. Enregistrez le service proxy auprès d'Azure AD.
b. Enregistrez la forêt Active Directory sur site auprès d'Azure AD. - Installer le(s) agent(s) DC.
- Redémarrer les DC.
Contrôle
Pour l'instant, les informations sur l'activité du service Azure AD Password Protection doivent être collectées à partir du serveur proxy et des journaux d'événements DC. Il n'y a pas d'intégration avec Azure AD Connect Health à ce stade de l'aperçu public, ni de surveillance de l'agent proxy à partir de la lame Azure AD dans le portail proxy.
Les ID d'événements de l'ordre de 10000 sont générés par le filtre de mots de passe, tandis que les ID de l'ordre de 30000 proviennent de l'agent DC. Vous trouverez (légèrement) plus d'informations dans les messages de l'agent DC (Figure 9) :
L'agent DC dispose de ses propres compteurs de performance dans Perfmon sous Azure AD Password Protection (Figure 10) :
Vous pouvez également utiliser la cmdlet PowerShell Get-AzureADPasswordProtectionSummaryReport pour obtenir un résumé de l'activité de modification des mots de passe.
Licences
Quel type de licence Azure AD cette fonctionnalité nécessite-t-elle ? Elle se décompose de la manière suivanteerviii:
- Comptes en nuage uniquement : Protection par mot de passe Azure AD avec liste globale de mots de passe interdits : Gratuit
- Protection des mots de passe Azure AD avec liste personnalisée : Azure AD basic
- Intégration de Windows Server AD Protection des mots de passe Azure AD avec une liste globale de mots de passe interdits : Tous les utilisateurs synchronisés doivent disposer de licences Azure AD Premium P1
- Protection par mot de passe Azure AD avec liste personnalisée (ce que je décris dans ce billet) : Tous les utilisateurs synchronisés doivent avoir Azure AD Premium P1
Encore une fois, comme il s'agit d'un aperçu public, il est susceptible d'être modifié.
Diverses informations
- Il n'y a aucune relation entre les éléments sur site d'Azure AD Password Protection et Azure AD Connect. Il n'est donc pas nécessaire d'installer le proxy sur un ou plusieurs serveurs Azure AD Connect (même s'il fonctionnera parfaitement sur ces derniers).
- Comme il n'y a pas de changement du côté du client, tout mot de passe commun rejeté affichera le message d'erreur standard "le mot de passe ne répond pas aux exigences de complexité" sur le client.
- L'aperçu public nécessite un compte Global Admin dans le locataire pour configurer le composant Azure et installer le proxy sur site, et (bien sûr) un compte Domain Admin pour installer le logiciel. Mais le MFA n'est pas pris en charge initialement pour l'enregistrement, de sorte que vous devrez supprimer le MFA du compte Global Admin que vous utilisez pour installer le proxy. Ce problème sera résolu avant le GAix.
- Si vous souhaitez tester certains de vos propres mots de passe par rapport à ce que le NIST considère comme des mots de passe courants, consultez le projet NIST Bad Passwords sur Github. En plus de vous fournir un exemple de code pour créer votre propre vérificateur de mots de passe interdits côté client, vous pouvez tester les faiblesses de vos mots de passe.
Microsoft prend des mesures énergiques pour adopter ses recommandations et celles du NIST en matière de politiques de mots de passe. En interdisant les changements de mots de passe courants dans Active Directory, Azure AD Password Protection ferme une zone majeure de risque d'entreprise causée par les attaques de mots de passe. Je vous recommande vivement d'évaluer ce service afin de le déployer dès qu'il sera disponible.
L'interdiction des mots de passe courants n'est qu'une partie de votre solution de sécurité de l'identité, bien sûr. L'accès conditionnel avec contrôle MFA à vos applications d'entreprise - qu'elles soient basées sur le cloud ou sur site - en est un autre. Comme les architectures d'entreprise passent d'un modèle de sécurité basé sur le périmètre à un modèle basé sur l'identité, la sécurité des ressources de l'entreprise nécessite une approche globale qui inclut la sécurité des identités, des appareils et des données.
Ressources
ihttps://twitter.com/Alex_A_Simons/status/1009490805369655296
iihttps://twitter.com/Alex_A_Simons/status/1009500870872973312
iiihttps://twitter.com/Alex_A_Simons/status/1009923402998562816
viihttps://techcommunity.microsoft.com/t5/Azure-Active-Directory-AMA/bd-p/AzureActiveDirectoryAMA
ixhttps://twitter.com/Alex_A_Simons/status/1009490805369655296
