Vue d’ensemble Verrouillage extranet et verrouillage intelligent extranet AD FS

Le verrouillage intelligent extranet (ESL) protège vos utilisateurs contre le verrouillage de compte extranet contre toute activité malveillante.

ESL permet à AD FS de faire la différence entre les tentatives de connexion à partir d’une localisation familière pour un utilisateur et les tentatives de connexion de ce qui pourrait être un attaquant. AD FS peut verrouiller les attaquants tout en permettant aux utilisateurs valides de continuer à utiliser leurs comptes. Cette distinction empêche et protège contre les attaques par déni de service et certaines classes d’attaques par pulvérisation de mot de passe sur l’utilisateur. ESL est disponible pour AD FS dans Windows Server 2016 et est intégré à AD FS dans Windows Server 2019.

ESL est disponible uniquement pour les requêtes d’authentification de nom d’utilisateur et de mot de passe qui transitent par l’extranet avec le Proxy d’application Web ou un proxy tiers. Tout proxy tiers doit prendre en charge le protocole MS-ADFSPIP à utiliser à la place du Proxy d’application Web, par exemple F5 BIG-IP Access Policy Manager. Consultez la documentation sur le proxy tiers pour déterminer si le proxy prend en charge le protocole MS-ADFSPIP.

Fonctionnalités dans AD FS 2019

Le verrouillage intelligent extranet dans AD FS 2019 ajoute les avantages suivants par rapport à AD FS 2016 :

• Seuils de verrouillage indépendants pour les emplacements familiers et inconnus. Les utilisateurs situés dans des localisations connues peuvent avoir davantage de marge d’erreur que les requêtes provenant de localisations suspectes.
• Mode audit pour le verrouillage intelligent tout en continuant à appliquer le comportement de verrouillage réversible précédent. Cette distinction vous permet d’en savoir plus sur les localisations familières de l’utilisateur, et d’être toujours protégé par la fonctionnalité de verrouillage extranet disponible à partir d’AD FS 2012 R2.

Informations de configuration

Quand ESL est activé, une nouvelle table dans la base de données Artifact, AdfsArtifactStore.AccountActivity, est créée. Un nœud est également sélectionné dans la batterie de serveurs AD FS comme nœud principal « Activité utilisateur ». Dans une configuration WID (Windows Internal Database), ce nœud est toujours le nœud principal. Dans une configuration SQL, un nœud est sélectionné pour être le nœud principal Activité utilisateur.

Pour afficher le nœud sélectionné en tant que nœud principal « Activité utilisateur », utilisez (Get-AdfsFarmInformation).FarmRoles.

Tous les nœuds secondaires contactent le nœud principal à chaque nouvelle connexion via le port 80 pour connaître la dernière valeur du nombre de mots de passe incorrects et les nouvelles valeurs de localisations familières. Les nœuds secondaires mettent également à jour le nœud principal après le traitement de la connexion.

Si le nœud secondaire ne peut pas contacter le nœud principal, il écrit les événements d’erreur dans le journal d’administration AD FS. Les authentifications continuent d’être traitées, mais AD FS écrit uniquement l’état mis à jour localement. AD FS retente de contacter le nœud principal toutes les 10 minutes. AD FS revient au nœud principal une fois celui-ci disponible.

Terminologie

• FamiliarLocation : lors d’une requête d’authentification, ESL vérifie toutes les adresses IP présentées. Ces adresses IP sont une combinaison d’adresses IP réseau, d’adresses IP transférées et de l’adresse IP x-forwarded-for facultative. Si la requête réussit, toutes les adresses IP sont ajoutées à la table Activité du compte en tant que « adresses IP familières ». Si la requête contient toutes les adresses IP présentes dans les « adresses IP familières », la requête est traitée comme une localisation « familière ».
• UnknownLocation : si une requête qui arrive a au moins une adresse IP qui n’est pas présente dans la liste FamiliarLocation existante, la requête est traitée comme une localisation « inconnue ». Cette action gère des scénarios de proxy tels que l’authentification héritée Exchange Online où les adresses Exchange Online gèrent les requêtes réussies et les requêtes ayant échoué.
• badPwdCount : valeur représentant le nombre de fois où un mot de passe incorrect a été envoyé, et où l’authentification a échoué. Pour chaque utilisateur, des compteurs distincts sont conservés pour les localisations familières et les localisations inconnues.
• UnknownLockout : valeur booléenne par utilisateur si l’utilisateur ne peut pas accéder à partir d’emplacements inconnus. Cette valeur est calculée en fonction des valeurs badPwdCountUnfamiliar et ExtranetLockoutThreshold.
• ExtranetLockoutThreshold : cette valeur détermine le nombre maximal de tentatives de mot de passe incorrect. Lorsque le seuil est atteint, AD FS rejette les requêtes provenant de l’extranet jusqu’à ce que la fenêtre d’observation soit passée.
• ExtranetObservationWindow : cette valeur détermine la durée pendant laquelle les requêtes de nom d’utilisateur et de mot de passe provenant de localisations inconnues sont verrouillées. Une fois la fenêtre passée, AD FS recommence à effectuer l’authentification par nom d’utilisateur et mot de passe à partir de localisations inconnues.
• ExtranetLockoutRequirePDC : lorsqu’il est activé, le verrouillage extranet nécessite un contrôleur de domaine principal (PDC). En cas de désactivation, le verrouillage extranet se replie vers un autre contrôleur de domaine au cas où le contrôleur de domaine principal est indisponible.
• ExtranetLockoutMode : contrôle le mode ESL, Journal uniquement ou Appliqué.
  • ADFSSmartLockoutLogOnly : ESL est activé. AD FS écrit des événements d’administration et d’audit, mais ne rejette pas les requêtes d’authentification. Ce mode est destiné à être activé pour que FamiliarLocation soit renseigné avant que ADFSSmartLockoutEnforce soit activé.
  • ADFSSmartLockoutEnforce : prise en charge complète du blocage des demandes d’authentification inconnues lorsque les seuils sont atteints.

Les adresses IPv4 et IPv6 sont prises en charge.

Anatomie d'une transaction

• Vérification avant authentification : lors d’une demande d’authentification, ESL vérifie toutes les adresses IP présentées. Ces adresses IP sont une combinaison d’adresses IP réseau, d’adresses IP transférées et de l’adresse IP x-forwarded-for facultative. Dans les journaux d’audit, ces adresses IP sont répertoriées dans le champ <IpAddress> dans l’ordre x-ms-forwarded-client-ip, x-forwarded-for, x-ms-proxy-client-ip.

  En fonction de ces adresses IP, AD FS détermine si la requête provient d’une localisation familière, puis vérifie si le badPwdCount respectif est inférieur à la limite de seuil définie ou si la dernière tentative ayant échoué s’est produite plus longtemps que la période de la fenêtre d’observation. Si l’une de ces conditions est remplie, AD FS autorise cette transaction pour un traitement et une validation des informations d’identification supplémentaires. Si les deux conditions sont false, le compte est déjà dans un état verrouillé jusqu’à ce que la fenêtre d’observation passe. Une fois la fenêtre d’observation passée, l’utilisateur est autorisé à tenter de s’authentifier. Dans Windows Server 2019, AD FS vérifie la limite de seuil appropriée selon que l’adresse IP correspond ou non à une localisation familière.

• Connexion réussie = : si la connexion réussit, les adresses IP de la requête sont ajoutées à la liste des adresses IP de localisation familière de l’utilisateur.

• Échec de la connexion : si la connexion échoue, la valeur badPwdCount est augmentée. L’utilisateur passe à un état de verrouillage si l’attaquant envoie au système plus de mots de passe incorrects que le seuil ne le permet. (badPwdCount > ExtranetLockoutThreshold)

La valeur UnknownLockout est égale à True lorsque le compte est verrouillé. Ce verrouillage signifie que le badPwdCount de l’utilisateur dépasse le seuil. Par exemple, une personne a tenté plus de mots de passe que le système ne le permet. Dans cet état, il existe deux façons pour un utilisateur valide de se connecter :

• Attendre que le temps ObservationWindow s’écoule
• Pour réinitialiser l’état de verrouillage, rétablir le badPwdCount à zéro avec Reset-ADFSAccountLockout.

Si aucune réinitialisation n’est effectuée, le compte est autorisé à effectuer une seule tentative de mot de passe sur AD pour chaque fenêtre d’observation. Après cette tentative, le compte revient à l’état verrouillé, et la fenêtre d’observation redémarre. La valeur badPwdCount nest réinitialisée automatiquement qu’après une connexion par mot de passe réussie.

Mode Journal uniquement et mode Appliquer

La table AccountActivity est renseignée à la fois en mode Journal uniquement et en mode Appliquer. Si le mode Journal uniquement est contourné et que l’ESL est déplacé directement en mode Appliquer sans la période d’attente recommandée, les adresses IP familières des utilisateurs ne sont pas connues d’AD FS. ESL se comporte alors comme ADBadPasswordCounter, bloquant potentiellement le trafic utilisateur légitime si le compte d’utilisateur fait l’objet d’une attaque par force brute active. Si le mode Journal uniquement est contourné et que l’utilisateur entre dans un état verrouillé oùUnknownLockout est égal à True et tente de se connecter avec un mot de passe correct à partir d’une adresse IP qui ne figure pas dans la liste d’adresses IP « familières », il ne peut pas se connecter. Le mode Journal uniquement est recommandé pendant trois à sept jours pour éviter ce scénario. Si des comptes sont activement attaqués, un minimum de 24 heures de mode Journal uniquement est nécessaire afin d’empêcher les verrouillages pour les utilisateurs légitimes.

Configuration du verrouillage intelligent extranet

Les sections suivantes décrivent les prérequis et les configurations pour activer ESL pour AD FS 2016.

Conditions requises pour AD FS 2016

1. Installez les mises à jour sur tous les nœuds de la batterie de serveurs.

   Tout d’abord, vérifiez que tous les serveurs AD FS Windows Server 2016 sont à jour à compter des Mises à jour Windows de juin 2018, et que la batterie de serveurs AD FS 2016 s’exécute au niveau de comportement de la batterie de serveurs 2016.

2. Vérifiez les autorisations.

   ESL nécessite que la gestion à distance de Windows soit activée sur chaque serveur AD FS.

3. Mettez à jour les autorisations de base de données d’artefacts.

   ESL nécessite que le compte de service AD FS dispose des autorisations nécessaires pour créer une table dans la base de données d’artefacts AD FS. Connectez-vous à n’importe quel serveur AD FS en tant qu’administrateur AD FS. Ensuite, accordez cette autorisation dans une fenêtre d’invite de commandes PowerShell en exécutant les commandes suivantes :

   PS C:\>$cred = Get-Credential
   PS C:\>Update-AdfsArtifactDatabasePermission -Credential $cred
   

   Note

   L’espace réservé $cred est un compte disposant d’autorisations d’administrateur AD FS. Cela doit fournir les autorisations d’écriture pour créer la table.

   Les commandes précédentes peuvent échouer en raison d’un manque d’autorisations suffisantes, car votre batterie de serveurs AD FS utilise SQL Server, et les informations d’identification fournies plus tôt n’ont pas d’autorisation d’administrateur sur votre serveur SQL Server. Dans ce cas, vous pouvez configurer manuellement les autorisations de base de données dans Base de données SQL Server lorsque vous êtes connecté à la base de données AdfsArtifactStore en exécutant la commande suivante :

   # when prompted with “Are you sure you want to perform this action?”, enter Y.
   
   [CmdletBinding(SupportsShouldProcess=$true,ConfirmImpact = 'High')]
   Param()
   
   $fileLocation = "$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config"
   
   if (-not [System.IO.File]::Exists($fileLocation))
   {
   write-error "Unable to open AD FS configuration file."
   return
   }
   
   $doc = new-object Xml
   $doc.Load($fileLocation)
   $connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString
   $connString = $connString -replace "Initial Catalog=AdfsConfigurationV[0-9]*", "Initial Catalog=AdfsArtifactStore"
   
   if ($PSCmdlet.ShouldProcess($connString, "Executing SQL command sp_addrolemember 'db_owner', 'db_genevaservice' "))
   {
   $cli = new-object System.Data.SqlClient.SqlConnection
   $cli.ConnectionString = $connString
   $cli.Open()
   
   try
   {
   
   $cmd = new-object System.Data.SqlClient.SqlCommand
   $cmd.CommandText = "sp_addrolemember 'db_owner', 'db_genevaservice'"
   $cmd.Connection = $cli
   $rowsAffected = $cmd.ExecuteNonQuery()
   if ( -1 -eq $rowsAffected )
   {
   write-host "Success"
   }
   }
   finally
   {
   $cli.CLose()
   }
   }
   

Vérifier que la journalisation d’audit de sécurité AD FS est activée

Cette fonctionnalité utilise les journaux d’audit de sécurité. L’audit doit donc être activé dans AD FS et la stratégie locale sur tous les serveurs AD FS.

Instructions relatives à la configuration

ESL utilise la propriété AD FS ExtranetLockoutEnabled. Cette propriété était auparavant utilisée pour contrôler Verrouillage logiciel extranet dans Server 2012 R2. Si ESL est activé et que vous souhaitez afficher la configuration de la propriété actuelle, exécutez Get-AdfsProperties.

Recommandations relatives à la configuration

Lors de la configuration d’ESL, suivez les bonnes pratiques pour définir des seuils :

ExtranetObservationWindow (new-timespan -Minutes 30)

ExtranetLockoutThreshold: Half of AD Threshold Value

AD value: 20, ExtranetLockoutThreshold: 10

Le verrouillage Active Directory fonctionne indépendamment d’ESL. Toutefois, si le verrouillage Active Directory est activé, sélectionnez ExtranetLockoutThreshold dans AD FS et Seuil de verrouillage de comptes dans AD.

ExtranetLockoutRequirePDC - $false

Lorsqu’il est activé, le verrouillage extranet nécessite un contrôleur de domaine principal (PDC). Lorsqu’il est désactivé et configuré comme false, le verrouillage extranet se replie sur un autre contrôleur de domaine au cas où le contrôleur de domaine n’est pas disponible.

Pour définir cette propriété, exécutez :

Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow (New-TimeSpan -Minutes 30) -ExtranetLockoutRequirePDC $false

Activer le mode Log-Only

En mode Journal uniquement, AD FS renseigne les informations de localisations familières des utilisateurs et écrit des événements d’audit de sécurité, mais ne bloque aucune requête. Ce mode est utilisé pour vérifier que le verrouillage intelligent est en cours d’exécution et pour permettre à AD FS d’« apprendre » des localisations familières pour les utilisateurs avant d’activer le mode Appliquer. À mesure qu’AD FS apprend, il stocke l’activité de connexion par utilisateur (que ce soit en mode Journal uniquement ou en mode Appliquer). Définissez le comportement de verrouillage sur Journal uniquement en exécutant l’applet de commande suivante :

Set-AdfsProperties -ExtranetLockoutMode AdfsSmartlockoutLogOnly

Le mode Journal uniquement est destiné à être un état temporaire afin que le système puisse apprendre le comportement de connexion avant d’introduire l’application du verrouillage avec le comportement de verrouillage intelligent. La durée recommandée pour le mode Journal uniquement est de trois à sept jours. Si les comptes sont activement attaqués, le mode Journal uniquement doit être exécuté pendant au moins 24 heures.

Sur AD FS 2016, si le comportement Verrouillage logiciel Extranet 2012 R2 est activé avant l’activation du verrouillage intelligent Extranet, le mode Journal uniquement désactive le comportement Verrouillage logiciel Extranet. Le verrouillage intelligent AD FS ne verrouille pas les utilisateurs en mode Journal uniquement. Toutefois, AD local peut verrouiller l’utilisateur en fonction de la configuration d’AD. Consultez les stratégies de verrouillage AD pour découvrir comment AD local peut verrouiller les utilisateurs.

Sur AD FS 2019, un autre avantage est de pouvoir activer le mode Journal uniquement pour le verrouillage intelligent tout en continuant à appliquer le comportement de verrouillage logiciel précédent à l’aide de la commande PowerShell ci-dessous :

Set-AdfsProperties -ExtranetLockoutMode 3

Pour que le nouveau mode prenne effet, redémarrez le service AD FS sur tous les nœuds de la batterie de serveurs à l’aide de cette commande :

Restart-service adfssrv

Une fois le mode configuré, vous pouvez activer le verrouillage intelligent à l’aide du paramètre EnableExtranetLockout :

Set-AdfsProperties -EnableExtranetLockout $true

Activer le mode d’application

Une fois que vous êtes à l’aise avec le seuil de verrouillage et la fenêtre d’observation, ESL peut être déplacé vers le mode «Appliquer à l’aide de l’applet de commande PSH suivante :

Set-AdfsProperties -ExtranetLockoutMode AdfsSmartLockoutEnforce

Pour que le nouveau mode prenne effet, redémarrez le service AD FS sur tous les nœuds de la batterie de serveurs à l’aide de la commande suivante.

Restart-service adfssrv

Gérer l’activité du compte d’utilisateur

AD FS fournit trois applets de commande pour gérer les données d’activité du compte. Ces applets de commande se connectent automatiquement au nœud de la batterie de serveurs qui détient le rôle principal.

Note

Vous pouvez utilisert Just Enough Administration (JEA) pour déléguer des commandes AD FS afin de réinitialiser les verrous de compte. Par exemple, vous pouvez déléguer des autorisations au personnel du support technique pour utiliser des applets de commande ESL. Pour plus d’informations, consultez Déléguer l’accès aux applets de commande Powershell AD FS à des utilisateurs non-administrateurs.

Vous pouvez remplacer ce comportement en passant le paramètre -Server.

Get-ADFSAccountActivity -UserPrincipalName

L’applet de commande se connecte automatiquement au nœud principal de la batterie à l’aide du point de terminaison REST d’activité de compte. Par conséquent, toutes les données doivent toujours être cohérentes. Lisez l’activité actuelle d’un compte d’utilisateur en exécutant la commande suivante :

Get-ADFSAccountActivity user@contoso.com

Propriétés :

• BadPwdCountFamiliar : incrémentée lorsqu’une authentification échoue à partir d’une localisation connue.
• BadPwdCountUnknown : incrémentée lorsqu’une authentification échoue à partir d’une localisation inconnue.
• LastFailedAuthFamiliar : si l’authentification a échoué à partir d’une localisation familière, LastFailedAuthFamiliar est définie sur l’heure de l’échec de l’authentification.
• LastFailedAuthUnknown : si l’authentification a échoué à partir d’une localisation inconnue, LastFailedAuthUnknown est définie sur l’heure de l’échec de l’authentification.
• FamiliarLockout : valeur booléenne qui est True si BadPwdCountFamiliar>ExtranetLockoutThreshold.
• UnknownLockout : valeur booléenne qui est True si BadPwdCountUnknown>ExtranetLockoutThreshold.
• FamiliarIPs : maximum de 20 adresses IP qui sont familières à l’utilisateur. Lorsque les 20 adresses IP sont dépassées, l’adresse IP la plus ancienne de la liste est supprimée.

Set-ADFSAccountActivity

Set-ADFSAccountActivity ajoute de nouvelles localisations familières. La liste d’adresses IP familières comporte un maximum de 20 entrées. Si le nombre de 20 entrées est dépassé, l’adresse IP la plus ancienne de la liste est supprimée.

Set-ADFSAccountActivity user@contoso.com -AdditionalFamiliarIps “1.2.3.4”

Reset-ADFSAccountLockout

Réinitialise le compteur de verrouillage d’un compte d’utilisateur pour chaque localisation familière (badPwdCountFamiliar) ou le compteur de localisations inconnues (badPwdCountUnfamiliar). Lorsque vous réinitialisez un compteur, la valeur FamiliarLockout ou FamiliarLockout est mise à jour, car le compteur de réinitialisation est inférieur au seuil.

Reset-ADFSAccountLockout user@contoso.com -Location Familiar

Reset-ADFSAccountLockout user@contoso.com -Location Unknown

Informations sur l’activité utilisateur et la journalisation des événements pour le verrouillage extranet AD FS

Les sections suivantes décrivent comment superviser la journalisation des événements, l’activité des comptes d’utilisateur et les verrouillages.

Connect Health

La méthode recommandée pour surveiller l’activité du compte d’utilisateur consiste à utiliser Connect Health. Connect Health génère des rapports téléchargeables sur les adresses IP à risque et les tentatives de mot de passe incorrectes. Chaque élément du rapport d’adresse IP risquée affiche des informations agrégées sur les échecs de connexion AD FS qui dépassent le seuil défini. Des notifications par e-mail peuvent être définies pour alerter les administrateurs avec des paramètres d’e-mail personnalisables en cas d’échec des activités de connexion AD FS. Pour plus d'informations et pour obtenir des instructions de configuration, consultez Surveiller AD FS avec Microsoft Entra Connect Health.

Événements Verrouillage intelligent extranet AD FS

Note

Pour résoudre les problèmes d’ESL, consultez Mitigating password spray attacks and account lockouts.

Pour que les événements de verrouillage intelligent extranet soient écrits, ESL doit être activé en mode Journal uniquement ou Appliquer, et l’audit de sécurité AD FS doit être activé. AD FS écrit des événements de verrouillage extranet dans le journal d’audit de sécurité lorsque :

• Un utilisateur est verrouillé, ce qui signifie que l’utilisateur atteint le seuil de verrouillage pour les tentatives de connexion infructueuses.
• AD FS reçoit une tentative de connexion pour un utilisateur qui est déjà en état de verrouillage.

En mode Journal uniquement, vous pouvez consulter le journal d’audit de sécurité pour vérifier les événements de verrouillage. Pour tout événement trouvé, vous pouvez vérifier l’état de l’utilisateur à l’aide de l’applet de commande Get-ADFSAccountActivity afin de déterminer si le verrouillage s’est produit à partir d’adresses IP familières ou non familières. Vous pouvez également utiliser l’applet de commande Get-ADFSAccountActivity pour vérifier la liste des adresses IP familières de cet utilisateur.

ID de l’événement	Description
1203	Cet événement est écrit pour chaque tentative de mot de passe incorrect. Dès que badPwdCount atteint la valeur spécifiée dans ExtranetLockoutThreshold, le compte est verrouillé sur AD FS pendant la durée spécifiée dans ExtranetObservationWindow. ID d’activité : %1 XML : %2
1210	Cet événement est écrit chaque fois qu’un utilisateur est verrouillé. ID d’activité : %1 XML : %2
557 (AD FS 2019)	Une erreur s’est produite lors de la tentative de communication avec le service rest du magasin de comptes sur le nœud %1. Si vous utilisez une batterie de serveurs WID, le nœud principal peut être hors connexion. Si vous utilisez une batterie de serveurs SQL, AD FS sélectionne automatiquement un nouveau nœud pour héberger le rôle principal du magasin d’utilisateurs.
562 (AD FS 2019)	Une erreur s’est produite lors de la communication avec le point de terminaison du magasin de comptes sur le serveur %1. Message d’exception : %2
563 (AD FS 2019)	Une erreur s’est produite lors du calcul de l’état de verrouillage extranet. En raison de la valeur du paramètre %1, l’authentification est autorisée pour cet utilisateur, et l’émission de jeton continue. Si vous utilisez une batterie de serveurs WID, le nœud principal peut être hors connexion. Si vous utilisez une batterie de serveurs SQL, AD FS sélectionne automatiquement un nouveau nœud pour héberger le rôle principal du magasin d’utilisateurs. Nom du serveur du magasin de comptes : %2 ID utilisateur : %3 Message d’exception : %4
512	Le compte de l’utilisateur suivant est verrouillé. Une tentative de connexion est autorisée en raison de la configuration du système. ID d’activité : %1 Utilisateur : %2 ADRESSE IP cliente : %3 Nombre de mots de passe incorrects : %4 Dernière tentative de mot de passe incorrect : %5
515	Le compte d’utilisateur suivant était verrouillé, et le mot de passe correct a été fourni. Ce compte peut être compromis. Données supplémentaires ID d’activité : %1 Utilisateur : %2 Adresse IP cliente : %3
516	Le compte d’utilisateur suivant a été verrouillé en raison d’un trop grand nombre de tentatives de mot de passe incorrectes. ID d’activité : %1 Utilisateur : %2 ADRESSE IP cliente : %3 Nombre de mots de passe incorrects : %4 Dernière tentative de mot de passe incorrect : %5

Forum aux questions à propos d’ESL

Une batterie de serveurs AD FS qui utilise le verrouillage intelligent extranet en mode Appliquer verra-t-elle jamais des verrous d’utilisateur malveillants ?

Si le verrouillage intelligent AD FS est défini sur le mode Appliquer, vous ne verrez jamais le compte de l’utilisateur légitime verrouillé par force brute ou par déni de service. La seule façon dont un verrouillage de compte malveillant peut empêcher un utilisateur de se connecter est si l’acteur malveillant a le mot de passe de l’utilisateur ou peut envoyer des requêtes à partir d’une adresse IP connue (familière) pour cet utilisateur.

Que se passe-t-il si ESL est activé et que l’acteur malveillant a un mot de passe utilisateur ?

L’objectif typique du scénario d’attaque par force brute est de deviner un mot de passe et de se connecter avec succès. Si un utilisateur est hameçonné ou si un mot de passe est deviné, la fonctionnalité ESL ne bloque pas l’accès, car la connexion répond aux critères de réussite du mot de passe correct et de la nouvelle adresse IP. L’adresse IP des mauvais acteurs apparaît alors comme familière. La meilleure atténuation dans ce scénario consiste à effacer l’activité de l’utilisateur dans AD FS et à exiger l’authentification multifacteur pour les utilisateurs. Vous devez installer la protection par mot de passe Microsoft Entra pour vous assurer qu'aucun mot de passe devinable n'accède dans le système.

Si mon utilisateur ne s’est jamais connecté avec succès à partir d’une adresse IP et qu’il tente de le faire à plusieurs reprises avec un mot de passe incorrect, pourra-t-il se connecter une fois qu’il aura finalement tapé son mot de passe correctement ?

Si un utilisateur soumet plusieurs mots de passe incorrects (par exemple en tapant incorrectement) et qu’à la tentative suivante il tape le mot de passe correct, il est connecté immédiatement. Cette connexion réussie efface le nombre de mots de passe incorrects et ajoute cette adresse IP à la liste FamiliarIPs. Toutefois, s’il dépasse le seuil des connexions ayant échoué à partir de la localisation inconnue, il bascule à l’état de verrouillage. Il doit alors attendre la fin de la fenêtre d’observation et se connecter avec un mot de passe valide. L’intervention de l’administrateur sera peut-être nécessaire pour réinitialiser le compte.

L’ESL fonctionne-t-il également sur intranet ?

Si les clients se connectent directement aux serveurs AD FS et non via des serveurs Proxy d’application Web, le comportement ESL ne s’applique pas.

Je vois les adresses IP Microsoft dans le champ Adresse IP du client. ESL bloque-t-il les attaques par force brute de proxy EXO ?  

ESL fonctionne bien pour empêcher Exchange Online ou d’autres scénarios d’attaque par force brute d’authentification héritées. Une authentification héritée a un « ID d’activité » de 00000000-0000-0000-0000-000000000000. Dans ces attaques, l’acteur malveillant tire parti de l’authentification de base Exchange Online (également appelée authentification héritée) afin que l’adresse IP du client apparaisse sous la forme d’une adresse IP Microsoft. Les serveurs en ligne Exchange dans le cloud délèguent par proxy la vérification de l’authentification pour le compte du client Outlook. Dans ces scénarios, l’adresse IP de l’expéditeur malveillant se trouve dans x-ms-forwarded-client-ip et l’adresse IP du serveur Microsoft Exchange Online se trouve dans la valeur x-ms-client-ip. Extranet Smart Lockout vérifie les adresses IP réseau, les adresses IP transférées, l’adresse IP x-forwarded-client-IP et la valeur x-ms-client-ip. Si la demande réussit, toutes les adresses IP sont ajoutées à la liste familière. Si une requête arrive et qu’une des adresses IP présentées ne figurent pas dans la liste familière, la requête est marquée comme étant inconnue. L’utilisateur familier peut se connecter correctement, tandis que les requêtes provenant des localisations inconnus sont bloquées.

Puis-je estimer la taille d’ADFSArtifactStore avant d’activer ESL ?

Avec ESL activé, AD FS effectue le suivi de l’activité du compte et des localisations connues pour les utilisateurs dans la base de données ADFSArtifactStore. Cette base de données est mise à l’échelle en fonction du nombre d’utilisateurs et d’emplacements connus suivis. Quand vous envisagez d’activer ESL, vous pouvez partir du principe que la taille de la base de données ADFSArtifactStore augmentera de 1 Go maximum tous les 100 000 utilisateurs. Si la batterie AD FS utilise la base de données interne Windows (WID, Windows Internal Database), la localisation par défaut des fichiers de base de données est C:\Windows\WID\Data. Pour empêcher le remplissage de ce lecteur, veillez à disposer d’au moins 5 Go de stockage gratuit avant d’activer ESL. En plus du stockage sur disque, planifiez l’augmentation de la mémoire totale de processus après l’activation d’ESL d’une valeur pouvant aller jusqu’à 1 Go de RAM pour une population de 500 000 utilisateurs ou moins.

Voir aussi

• Meilleures pratiques en matière de services de fédération Active Directory (AD FS)
• Set-AdfsProperties
• Opérations d’AD FS