Personne n’a besoin de rappeler aux responsables informatiques le palmarès des casse-têtes qu’ils rencontrent : l’oubli de leurs mots de passe par les utilisateurs est en général en tête de liste. Et si certains éprouvent le besoin d’en avoir une preuve factuelle, ces résultats d’une étude à ce sujet ne laissent pas place au doute. Dans la même catégorie de tracas, et en seconde position en termes de fréquence et de frustration, on trouve les blocages de compte. À une époque reculée (de l’histoire de l’informatique) où les choses étaient plus simples – quand chacun n’utilisait qu’un seul terminal pour accéder au réseau –, le problème était bien plus simple à résoudre.
Le salarié bloqué appelait ou envoyait un email à son service technique interne, et ce dernier déverrouillait le compte et réinitialisait le mot de passe depuis la console Active Directory. Mais depuis sont arrivés les PC portables, les smartphones, les tablettes, le télétravail… bref, la frénésie de la vie moderne et la multiplication des types de terminaux, des modes d’utilisation, etc. De ce fait, ce qui pouvait paraître simple à résoudre au départ ne l’est plus trop.
La cause sous-jacente à la plupart des cas de blocage de compte – en dehors de l’oubli de son mot de passe par l’utilisateur –, c’est une application ou un service qui tourne en tâche de fond, sur l’un ou l’autre de ces terminaux, et qui tente de se connecter au compte avec un mot de passe périmé.
De la complexité des processus d’authentification
Combien de cas différents de tels blocages peut-on répertorier aujourd’hui ? Microsoft y consacre tout un article sur Technet, et la longue liste des réponses à cette question comprend déjà ces premières entrées :
- Les mappages de lecteurs persistants
- Les tâches planifiées
- Les sessions de connexion à un serveur
- Les comptes de service
- Tout programme mémorisant identifiants et mots de passe
Et si l’on ajoute à l’équation tous les types de nouveaux terminaux, cela multiplie encore les environnements à explorer pour détecter l’appli coupable. Sur le plan pratique, cela signifie que pour la détecter, le service informatique doit éplucher soigneusement différents journaux d’audit, souvent sur des domaines multiples.
Une politique de blocage raisonnée, oui, mais…
J’entends sans mal d’ici la communauté des administrateurs informatiques répéter en chœur que « la vraie solution à tous ces problèmes est d’instaurer une politique intelligente du blocage de compte ». Une partie d’entre eux recommande d’intervenir sur l’objet de politique des groupes (GPO) par défaut et de modifier les critères de blocage de sorte qu’ils soient plus raisonnables.
Le « Nombre de tentatives de connexion infructueuses entraînant le blocage » a tout intérêt à être fixé à une valeur bien plus élevée que trois – mettons 20 ou 30 – de telle sorte qu’un utilisateur, ou plutôt un hacker malveillant, ait besoin de s’acharner quand même un peu pour déclencher le blocage du compte. Le paramètre de « Durée de blocage du compte », avant déblocage automatique, pourrait être fixé à un délai plus pratique de dix minutes (plutôt que, souvent, 12 heures) et ne jamais être laissé à la valeur par défaut de zéro, qui correspond à une durée illimitée de blocage. Enfin, le critère plus délicat, « Réinitialiser la politique de blocage de compte après », dont le réglage par défaut est de une minute. Pour en savoir plus sur cette approche, consultez cette page.
Après consultation d’un certain nombre d’experts de Varonis, j’ai pu me faire confirmer que la personnalisation des paramètres de blocage d’Active Directory peut constituer une solution. Mais il faut être prudent, notamment concernant la force globale des mots de passe, qui doit d’abord être dûment testée. Selon ces experts, c’est si l’on a une politique de mots de passe forts en vigueur qu’il se peut que le relevage du nombre de tentatives avant blocage ait du sens ; dans le cas contraire, ce peut être un choix risqué. D’autres argumentent que le paramètre de durée de blocage doit rester à zéro pour que les utilisateurs concernés aient nécessairement un contact avec le support technique avant que leur compte soit débloqué.
Détection de l’appli dont le mot de passe est périmé
Cela dit, pour aller au fond du problème de blocage causé par la mémorisation locale de l’identifiant et du mot de passe sur différentes machines, le service informatique doit identifier l’appli ou le service en cause. Pour cela, il faut examiner les journaux d’événements des domaines concernés, soit manuellement (ce qui n’est pas recommandé), soit avec une appli spécialisée, soit avec LockoutStatus.exe, de Microsoft.
Chaque événement de blocage AD précise le nom de l’ordinateur ou l’adresse IP.
Dans cet exemple, l’événement recherché est l’Event ID 4771 sur Server 2008 ou l’Event ID 529 sur Server 2003. Lorsque cet événement de blocage de compte s’affiche, le nom de l’ordinateur client ou son adresse IP est indiqué (cf. la copie d’écran ci-dessus).
Sous Windows, au moins à partir de Windows 7, l’administrateur se connecte à distance sur la machine cliente et lance le Credential Manager pour supprimer les mots de passe périmés. On peut légitimement supposer qu’il s’agissait là de l’ordinateur secondaire de l’utilisateur, et qu’après un changement de mot de passe sur sa machine principale, cette deuxième machine a continué d’exécuter des services qui ont provoqué le blocage du compte.
Et si l’événement de blocage indique une adresse IP ?
Dans ce cas, l’administrateur doit retrouver l’adresse MAC correspondante depuis une autre machine sur le même segment de réseau, puis le fournisseur de cette adresse, par exemple en utilisant http://www.macvendorlookup.com, pour connaître le type de machine concernée. Quatre-vingt-dix-neuf fois sur cent, l’appli sur appareil iOS ou Android qui utilise le mot de passe périmé est un client mail Exchange, par exemple ActiveSync. L’utilisateur dont le compte est bloqué doit alors mettre à jour le mot de passe pour actualiser ces informations et resynchroniser tout correctement.
Michael Buckbee
Michael a travaillé en tant qu'administrateur système et développeur de logiciels pour des start-ups de la Silicon Valley, la marine américaine, et tout ce qui se trouve entre les deux.
Résoudre les blocages Active Directory : Comment détecter les applis aux ID et mots de passe périmés
Contents
Personne n’a besoin de rappeler aux responsables informatiques le palmarès des casse-têtes qu’ils rencontrent : l’oubli de leurs mots de passe par les utilisateurs est en général en tête de liste. Et si certains éprouvent le besoin d’en avoir une preuve factuelle, ces résultats d’une étude à ce sujet ne laissent pas place au doute. Dans la même catégorie de tracas, et en seconde position en termes de fréquence et de frustration, on trouve les blocages de compte. À une époque reculée (de l’histoire de l’informatique) où les choses étaient plus simples – quand chacun n’utilisait qu’un seul terminal pour accéder au réseau –, le problème était bien plus simple à résoudre.
Le salarié bloqué appelait ou envoyait un email à son service technique interne, et ce dernier déverrouillait le compte et réinitialisait le mot de passe depuis la console Active Directory. Mais depuis sont arrivés les PC portables, les smartphones, les tablettes, le télétravail… bref, la frénésie de la vie moderne et la multiplication des types de terminaux, des modes d’utilisation, etc. De ce fait, ce qui pouvait paraître simple à résoudre au départ ne l’est plus trop.
La cause sous-jacente à la plupart des cas de blocage de compte – en dehors de l’oubli de son mot de passe par l’utilisateur –, c’est une application ou un service qui tourne en tâche de fond, sur l’un ou l’autre de ces terminaux, et qui tente de se connecter au compte avec un mot de passe périmé.
De la complexité des processus d’authentification
Combien de cas différents de tels blocages peut-on répertorier aujourd’hui ? Microsoft y consacre tout un article sur Technet, et la longue liste des réponses à cette question comprend déjà ces premières entrées :
Et si l’on ajoute à l’équation tous les types de nouveaux terminaux, cela multiplie encore les environnements à explorer pour détecter l’appli coupable. Sur le plan pratique, cela signifie que pour la détecter, le service informatique doit éplucher soigneusement différents journaux d’audit, souvent sur des domaines multiples.
Une politique de blocage raisonnée, oui, mais…
J’entends sans mal d’ici la communauté des administrateurs informatiques répéter en chœur que « la vraie solution à tous ces problèmes est d’instaurer une politique intelligente du blocage de compte ». Une partie d’entre eux recommande d’intervenir sur l’objet de politique des groupes (GPO) par défaut et de modifier les critères de blocage de sorte qu’ils soient plus raisonnables.
Le « Nombre de tentatives de connexion infructueuses entraînant le blocage » a tout intérêt à être fixé à une valeur bien plus élevée que trois – mettons 20 ou 30 – de telle sorte qu’un utilisateur, ou plutôt un hacker malveillant, ait besoin de s’acharner quand même un peu pour déclencher le blocage du compte. Le paramètre de « Durée de blocage du compte », avant déblocage automatique, pourrait être fixé à un délai plus pratique de dix minutes (plutôt que, souvent, 12 heures) et ne jamais être laissé à la valeur par défaut de zéro, qui correspond à une durée illimitée de blocage. Enfin, le critère plus délicat, « Réinitialiser la politique de blocage de compte après », dont le réglage par défaut est de une minute. Pour en savoir plus sur cette approche, consultez cette page.
Après consultation d’un certain nombre d’experts de Varonis, j’ai pu me faire confirmer que la personnalisation des paramètres de blocage d’Active Directory peut constituer une solution. Mais il faut être prudent, notamment concernant la force globale des mots de passe, qui doit d’abord être dûment testée. Selon ces experts, c’est si l’on a une politique de mots de passe forts en vigueur qu’il se peut que le relevage du nombre de tentatives avant blocage ait du sens ; dans le cas contraire, ce peut être un choix risqué. D’autres argumentent que le paramètre de durée de blocage doit rester à zéro pour que les utilisateurs concernés aient nécessairement un contact avec le support technique avant que leur compte soit débloqué.
Détection de l’appli dont le mot de passe est périmé
Cela dit, pour aller au fond du problème de blocage causé par la mémorisation locale de l’identifiant et du mot de passe sur différentes machines, le service informatique doit identifier l’appli ou le service en cause. Pour cela, il faut examiner les journaux d’événements des domaines concernés, soit manuellement (ce qui n’est pas recommandé), soit avec une appli spécialisée, soit avec LockoutStatus.exe, de Microsoft.
Chaque événement de blocage AD précise le nom de l’ordinateur ou l’adresse IP.
Dans cet exemple, l’événement recherché est l’Event ID 4771 sur Server 2008 ou l’Event ID 529 sur Server 2003. Lorsque cet événement de blocage de compte s’affiche, le nom de l’ordinateur client ou son adresse IP est indiqué (cf. la copie d’écran ci-dessus).
Sous Windows, au moins à partir de Windows 7, l’administrateur se connecte à distance sur la machine cliente et lance le Credential Manager pour supprimer les mots de passe périmés. On peut légitimement supposer qu’il s’agissait là de l’ordinateur secondaire de l’utilisateur, et qu’après un changement de mot de passe sur sa machine principale, cette deuxième machine a continué d’exécuter des services qui ont provoqué le blocage du compte.
Et si l’événement de blocage indique une adresse IP ?
Dans ce cas, l’administrateur doit retrouver l’adresse MAC correspondante depuis une autre machine sur le même segment de réseau, puis le fournisseur de cette adresse, par exemple en utilisant http://www.macvendorlookup.com, pour connaître le type de machine concernée. Quatre-vingt-dix-neuf fois sur cent, l’appli sur appareil iOS ou Android qui utilise le mot de passe périmé est un client mail Exchange, par exemple ActiveSync. L’utilisateur dont le compte est bloqué doit alors mettre à jour le mot de passe pour actualiser ces informations et resynchroniser tout correctement.
Que dois-je faire maintenant ?
Vous trouverez ci-dessous trois solutions pour poursuivre vos efforts visant à réduire les risques liés aux données dans votre entreprise:
Planifiez une démonstration avec nous pour voir Varonis en action. Nous personnaliserons la session en fonction des besoins de votre organisation en matière de sécurité des données et répondrons à vos questions.
Consultez un exemple de notre évaluation des risques liés aux données et découvrez les risques qui pourraient subsister dans votre environnement. Cette évaluation est gratuite et vous montre clairement comment procéder à une remédiation automatisée.
Suivez-nous sur LinkedIn, YouTube et X (Twitter) for pour obtenir des informations sur tous les aspects de la sécurité des données, y compris la DSPM, la détection des menaces, la sécurité de l’IA et plus encore.
Essayez Varonis gratuitement.
Se déploie en quelques minutes.
Keep reading
Varonis tackles hundreds of use cases, making it the ultimate platform to stop data breaches and ensure compliance.