WIN – Password Policies & Event 4740

Dans ce billet, j’avais envie d’enfoncer des portes ouvertes. Premièrement parce que je trouve facile de faire un billet sur quelque chose de « simple » et deuxièmement si je me dem***e bien je peux faire de l’audit avec un titre p*te-à-clic !

Plus sérieusement et sans détour, il se trouve que ce sont les choses les plus simples dans la vie qui sont le plus souvent bâclées ou négligées. C’est pourquoi je me suis dit, et si je m’attardais un peu plus sur les politiques de mots de passe dans un environnement WINDOWS ?

Il relève de nombreux articles déjà sur le net qui traite ce sujet, mais voyez-vous encore une fois je pense aller un peu plus loin que les excellents articles déjà présents. Difficile de parler de ce que j’ai fait sans toutefois présenter les bases 🙂

Mais alors jusqu’où es-tu allé cette fois ci ?

Je suis parti de la politique classique de définition de la politique de mot de passe dans un domaine AD¹ et du traitement des événements de verrouillage de compte. Sujet traité par mon précédent mentor et qui m’a demandé un peu de recherche pour arriver à mes fins (je voulais faire ma propre solution, comprendre et maitriser le sujet).

Bref, cela sera je le pense un petit billet avec du script, des schémas et naturellement du powershell avec une pointe de désinvolture et assurément de sécurité.

Avant-Propos

Comme rédigé légèrement plus tôt, je n’ai pas la volonté de faire un article détaillé qui reprend la majorité des articles déjà présent sur le NET. Il me faut néanmoins une base de départ.

Mon mentor, dans le cadre d’une esquisse de PSSI² il y a un certain nombre d’année c’est dit qu’il serait bien d’informer l’équipe du SI interne (ou externalisé) d’un potentiel blocage, verrouillage de compte sur un AD. La première question que nous pourrions nous poser serait d’abord quel cas pourrait entrainer un verrouillage d’un compte ?

• Un dysfonctionnement de la couche 8 du modèle OSI³ :
  • Je suis méchant avec cette couche, je sais bien. Nous parlons ici (ou plutôt je parle car cela n’engage que ma responsabilité ET ma personne) du dysfonctionnement entre le siège du bureau et le clavier. Soit en un mot et un seul ? L’utilisateur bien sûr !! Mais qu’est ce que ce mec est condescendant… C’est affligeant. Généralement, le verrouillage de compte est généré par une erreur de frape lors de la saisie et dans certains cas (compte non nominatif utilisé par plusieurs collaborateurs) de la saisie d’un mauvais mot de passe.
• Une tentative de Charlie qui veut « poutrer » le compte de Bob pour récupérer le cœur d’Alice
  • On comprend assez aisément le brute force d’un intru pour s’infiltrer dans le SI⁴ est tout casser…
• Un dysfonctionnement de la couche 7 du modèle OSI :
  • Oui celle-là existe officiellement et concerne la couche applicative :). Je ne peux pas non plus raconter des conneries en permanence tout de même. Pour faire simple une application a des informations qui ne sont pas à jour (un client de messagerie qui pete un plomb par exemple).

Donc l’intérêt de notifier l’équipe interne ? S’assurer que notre utilisateur ne veut pas s’octroyer une pause-café supplémentaire ou que nous avons un petit malin dans la place qui veut nous faire passer nos prochains jours à la première place de l’enfer dans le plus beau des pandémoniums <3

Mon côté brun ténébreux qui ressort avec les vilains corbeaux de Sir Alan Edgar Poe… Alors comment faire pour déceler un verrouillage de compte et comment notifier les équipes ? Spoiler ? La suite dans les parties ci-dessous.

Prérequis

• SE : 
  • Windows Server 2k16 et version ultérieures
• Apps : 
  • Rôle ADDS
• Autres :
  • PowerShell version 5 et supérieure
  • SMTP
  • Domaine AD

Théorie

Avant de commencer, posons nous la question de comment fonctionne l’authentification dans poste dans une domaine (pour faire simple, nous restons dans une forêt avec un seul domaine).

Authentification, comment ça marche ?

En tous lieux, je dirai avec des chaussures… Ok, je sors…

Nous pourrions résumer le cycle de vie de l’authentification en 7 étapes (encore la magie du nombre 7…) l’authentification d’un utilisateur.

1. Saisie des identifiants login et mot de passe
   • Rien de bien sorcier, CONTOSO\John.Doe et mon superpassword (si tenter que le mot de passe soit bien celui attendu dans l’AD pour l’utilisateur John DOE…
2. Localisation du DC via DNS
   • Notre poste va alors à travers l’enregistrement DNS⁵ _ldap._tcp.dc._msdcs.contoso.x pour trouver un DC⁶ disponible
3. Négociation, KERBEROS ou NTLM ?
   • Deux mots protocoles qui peuvent faire peur. Je ne rentre pas dans le détail des deux protocoles. Gardons à l’esprit toutefois que KERBEROS est supérieur au protocole NTLM⁷ (d’ailleurs KERBEROS est utilisé comme protocole par défaut).
   • Cas de KERBEROS, le poste demande un TGT⁸ auprès du KDC⁹ du DC à travers une requête. Si le couple d’authentification saisie est correct le KDC retournera en réponse le TGT chiffré ainsi qu’une clé de session. Le poste à travers le TGT va demander un TGS¹⁰ afin d’accéder aux différentes ressources du SI (fichiers, imprimantes etc…).
   • Cas de NTLM, le poste va réaliser un challenge au DC en attendant une réponse.
4. Validation du compte
   • Une fois la négociation réussi (Où est-ce qu’il a appris à négocier ?), le DC va vérifier le mot de passe haché, le compte doit être actif (soit pas verrouillé, expiré ou désactivé), récupérer les groupes de sécurité de l’utilisateur ainsi que les stratégies de connexion et de mot de passe.
   • C’est marrant, c’est cette étape qui nous intéresse 🙂
5. Chargement du profil
   • Si la vérification du compte utilisateur est ok, alors c’est réussi. HIGH FIVE ! Le poste va alors charger le profil local ou selon la configuration un profil itinérant. Dans le pire des cas, un profil temporaire.
6. Application des GPO
   • Dans la logique, ensuite sont téléchargées et appliquées les GPO¹¹ utilisateurs, ordinateurs…
7. Ouverture de session
   • Hé nous voilà normalement sur notre bureau.

Bon j’avoue que la partie négociation, j’avais dit que je ne rentrerai pas dans le détail. J’effleure la technicité et croyez moi, nous pourrions aller beaucoup plus loin. Toutefois, demander à vos Admins Systèmes et Réseaux ou Techniciens Systèmes et Réseaux, je ne suis pas certains qu’ils vous expliquent clairement le cycle de vie d’authentification d’un utilisateur…

Stratégie de mot de passe

Avant de rentrer plus dans le détail de ce qui nous intéresse, il est important de parler de la stratégie de mot de passe. Cela s’est plutôt bien démocratisé car nous retrouvons sur la grande majorité des sites web à ce jour le traditionnel message :

Votre mot de passe doit répondre aux critères minimaux ci-dessous :

• 16 caractères minimum
• 1 Majuscule
• 1 Minuscule
• 1 caractère numérique
• 1 caractère spécifique

Je vous vois déjà hurler, ou vos utilisateurs vous ont gueulé dessus… Quant à la politique mis en place. Mais alors que devons nous appliquer et à qui ? L’objectif est de sécuriser les SIs sans pour autant être un vrai tyran avec ces utilisateurs. Gardons toujours à l’esprit que « Trop de sécurité tue la sécurité ». A quoi bon exiger 26 caractères pour retrouver le mot de passe sur un post-it ou AZERTY123456AZERTY123456azerty123456azerty123456$…

Pour cela, j’aime me référer à l’ANSSI¹² comme ça je peux dire haut et fort, « C’est pas moi, c’est eux qui veulent. » 🙂 Je suis courageux n’est ce pas ? 🙂

Dans le guide de Recommandation relatives à l’authentification multi-facteurs et aux mots de passe, il est recommandé d’appliquer la politique de mot de passe suivante (R20):

• Catégorie des mots de passe
• Longueur des mots de passe (Entre 9 et 11, c’est faible. Entre 12 et 14 c’est moyen. Au-delà de 15 c’est fort)
• Règles de complexité des mots de passe (le nombre de caractère utilisable)
• Délais d’expiration des mots de passe (la fréquence de renouvellement)
• Mécanisme de limitation d’essais d’authentification
• Mécanisme de contrôle de la robustesse des mots de passe
• Méthode de conservation des mots de passe
• Méthode de recouvrement d’accès en cas de perte ou de vol des mots de passe
• Mise à disposition d’un coffre-fort de mot de passe

Dans notre cas, seuls les points en vert nous intéressent. Pour définir techniquement notre GPO ou notre FGPP.

D’où tu dis que je suis un FDP ?! Gros Tarba va ! Je vais….

STOP ! En aucun cas je vous insulte ! FGPP¹³ ou Fine Grained Password Policy permettent de manière plus simple de définir plusieurs politiques de mots de passe dans une organisation selon les services et criticité de ces derniers. Croyez-moi, c’est bien plus simple que la gestion par GPO. Ca nous le verrons rapidement dans la pratique quant au déploiement.

Dans tous les cas, j’aime définir la stratégie de mot de passe « par défaut » dans la GPO (vous pouvez me jeter des petits cailloux au visage et du sable dans les yeux), Default Domain Policy : HERESIE ! BLASPHEME ! AU BUCHET ! (Oui ba c’est bien la seule chose que je modifie dans la Default Domain Policy) :

J’ouvre un aparté, dans le cas d’un poste hors domaine que nous souhaiterions durcir, il suffira de faire de même. Il faut que je pose la question de scripter cela. Aparté fermée.

J’ai donc une politique de mots de passe qui s’appliquent (sans verrouillage de compte) par défaut pour l’ensemble des utilisateurs de mon parc, de mon domaine. Néanmoins, je vais définir par FGPP une politique par groupe utilisateur.

Dans ma logique, je choisie de faire trois politiques par défaut en respectant le tiering d’administration des comptes utilisateurs.

Administrateur du domaine > Utilisateurs avec pouvoir > Utilisateur du domaine

La puissance des FGPPs résident dans la possibilité de définir une pondération sur chaque politique. Ainsi, un utilisateur peut se retrouver avec une ou plusieurs politiques liées. Les politiques ne pouvant se cumuler, la politique avec la pondération la plus forte sera minoritaire par rapport à une politique avec une pondération plus faible.

« Unbelievable » diraient nos voisins outre-manche ! Nous retrouvons les mêmes paramètres que dans notre GPO… A noter et point important, la FGPP vaut sur la GPO si cette dernière est lié à un utilisateur ou un groupe d’utilisateur.

Authentification & events

Pour bien comprendre le fonctionnement de l’authentification, nous avons vu ci-haut que tout se passe sur nos DCs. Comme le système n’est pas trop mal foutu (et qu’accessoirement l’authentification à un système relève de la plus grande criticité) tout est consigné dans les journaux d’événements de sécurité.

Elle est pas belle la vie ?

Alors la question est la suivante, qu’elle est ou plutôt qu’elles sont les événements qui nous sont important ? Microsoft est vraiment sympa car ils ont pour nous référencier les événements à surveiller…

Mon cœur cogne un truc esthétique ! Vous voyez tout ce qu’il est possible de faire en termes de sécurité et de suivi, gestion du SI ? Limite ça me fait ba**er. Je vais soumettre l’ID d’un nouveau projet au comité qui vie dans ma cafetière.

Dans notre cas, précis il y a deux événements qui nous intéressent :

• 4624 : Hérité des événements 528 et 540, je cite « L’ouverture de session d’un compte s’est correctement déroulée. »
• 4740 : Hérité de l’événements 644, je cite « Un compte d’utilisateur a été verrouillé. »

Il est important de comprendre dans l’annexe que la notion de criticité est celle qui remonte dans les journaux d’événements. Personnellement certains événements pourraient être revu à la hausse. Enfin, c’est mon opinion personnelle qui n’a de crédit que pour le type qui écrit ces mots…

C’est donc dans le déclenchement de l’évent 4740 que nous trouverons notre bonheur.

Approche

La question est comment récupérer l’information que le compte d’un utilisateur ou compte de service est verrouillé ?

Consultation des objets

Dans un premier temps, j’ai pensé à scruter l’état de chaque objet utilisateur ou ordinateur de l’AD sur un intervalle définis dans le temps.

Le professeur rend les copies, et c’est un 4/20 qui tombe… L’idée peut paraitre bien, mais c’est mauvais. Oui je vais avoir l’information des comptes verrouillés, mais cela n’est pas du tout optimisé, cela va charger pour rien le serveur et générer des lenteurs et niveau proactivité c’est un zéro pointé. Imaginons si nous étions sur un SI avec genre 2k d’objets dans l’AD ?

Consultation des évènements déclenchés

La seconde approche consiste à définir une tache planifiée qui se déclenche sur un événement déclenché. Je l’ai fait il y a peu pour contourner un dysfonctionnement non patché de MS, donc c’est faisable. Mais je n’aime pas cette méthode car elle ouvre une vieille blessure intellectuelle… Ce traumatisme tout bête me dite vous ? Comment retourner et transmettre un paramètre de l’événement déclenché dans un script powershell…

Je peux vous dire qu’en 2015 je me suis torturé l’esprit à un point ou écouter du Evanescence en slip le soir de la Saint Valentin avec un kebab douteux et de l’alcool frelaté relève du plaisir (passe encore pour le kebab et l’alcool m’enfin).

Dix ans après, je rempile sur cette problématique et spoiler je trouve la solution. Comme quoi, un informaticien c’est comme un bon vin. Plus on le garde plus c’est bon. Enfin tout dépend de l’organisation. Oups pardon, je voulais dire la cave 🙂

Vous l’aurez compris ça sera la seconde méthode qui sera utilisé. Nous retournerons alors les attributs suivants :

• Le nom du compte qui lock
• Le nom de l’ordinateur, équipement source qui a cherché à s’authentifier
• Le nom de domaine

Là où j’ai merdé, ce que j’ai choisi de prendre en temps le temps de déclenchement du script et non le temps de lock de l’event. Ce qui du coup dans une configuration spécifique fausse complétement les informations. Donc il doit y avoir une adaptation de ma part sur la première version du code…

Sécurité

Nous sommes dans le domaine ? Nous allons réaliser une tâche planifiée ? Alors la réponse elle est vite répondu mon copaing ! Nous passerons par un compte de service managé, oui un gMSA¹⁴ comme d’habitude (et dire que je ne jugeais que par les comptes de services restreint avant…).

Les droits seront mis sur le script ainsi que l’ensemble des dépendances des utilisateurs externes. Sur le répertoire en somme ? Oui c’est ça…

Structure

S’agissant d’un petit projet, je me suis demandé si je devais ou non découper ce billet en différent sous article. Au final, je ne pense pas. Il y a eu plus indigeste que ça par le passé 🙂

Topographie – Applicative

Nous retrouvons donc l’architecture classique de mes projets précédents (Etonnant non ?) 🙂

A la racine du répertoire, nous retrouvons cette fois ci UN fichier exécutable (au lieu de DEUX) :

• SS_044_WIN_AD_LOCKACCOUNT_1.0.0_Services.ps1 : Fichier pensé pour fonctionner uniquement en mode service. Il ne peut être exécuté si et seulement si un event 4740 est levé. A voir si je fais un mode debug ou pas.

La suite se déroule en 3 répertoires distincts.

• Modules : Répertoire contenant les modules powershell développé pour l’application. Aujourd’hui au nombre de deux dissociant la partie Windows Système et HTML.
• Log : Répertoire qui va contenir la ou les traces d’exécution du code si l’option est activée. Cela à son importance car il permet au petit gars qui à dev l’application dans sa cave de corriger les bugs. Le fichier ne prend pas de place et est réinitialisé à chaque lancement.
• Config : Répertoire contenant le fichier de configuration powershell. Je reviendrai plus en détail sur le contenu de ce fichier dans la partie Pratique. Contrairement aux projets DreamNebula et GreenRay, je n’ai pas développé la fonction de reconstruction, régénération du fichier de configuration. Inutile car il n’y a pas de mode manuel et il n’y a pas grand-chose dans le fichier de conf…

Topographie – Logiciel

Je me passe par fénéantise la topographie du logiciel. Il n’est pas complexe du tout… Pour faire simple, cela se résume au cycle de vie suivant :

• 0 : Entrez dans le journal d’événement de sécurité d’un événement 4740.
• 1 : Déclenchement de la tâche planifiée sur l’événement. Récupération des informations liées au verrouillage du compte utilisateur, le poste source et le domaine d’application. Ces valeurs de type strings sont passés en argument du script powershell qui est exécuté SS_044_WIN_AD_LOCKACCOUNT_1.0.0_Services.ps1.
• 2 : Le script lit la configuration, puis charge les modules. Une fois les modules chargés, le corps du mail est construit et ce dernier est envoyé par mail. Naturellement et selon les options activées, le mode debug redirigeras l’ensemble des transactions powershell dans le fichier de log dans le répertoire du même nom.

Et le code ? Il est sur GitHub. Je ne souhaite pas le présenter. Toutefois, je partagerai volontiers ces derniers avec celui qui viendra m’en exprimer le souhait. Ca sera l’occasion de papoter un peu 🙂

Pratique

Configuration

Avant de lancer le script, il est nécessaire de faire un tour vers le fichier de configuration contenu dans le répertoire config à la racine du projet. Je vais prendre le temps de décrire chacune des parties de ce fichier.

Le fichier se découpe en 1 partie et 1 sous-partie.

* Une sous-partie globale qui définit les paramètres du script et de son fonctionnement * Une sous-partie concernant l’envoie de notification SMTP15, futur feature/bug (rayer la mention inutile) à venir

Avec la compréhension du fichier de configuration, je pense que nous pouvons passer à la suite, soit déployer l’application sur le serveur.

Installation

Je passe alégrement la partie gMSA il y a un certain nombre d’article sur le net (comme déjà dit dans des billets précédents) qui traite déjà du sujet. Pour le reste, j’ai comme d’habitude renforcé la sécurité et implémenté mes propres mécanismes (la preuve en est, j’ai passé deux put**n d’heures à trouver pourquoi ma tâche ne se lançait pas…).

Là où ça se corse, c’est au niveau de la tache planifiée. Si vous êtes sur un environnement possédant l’expérience utilisateur, vous êtes sauvés. En revanche, dans mon cas sur mes serveurs CORE, je l’ai mais alors bien profond dans la cucurbitacée… Voyez vous comme quoi une chose tout insignifiante soit il peut devenir un vrai casse-tête.

Mais alors qu’elle est cette petite chose insignifiante ?

The ScheduledTask

A première vue, vous vous demandez pourquoi je parle de la tache planifiée… Il s’avère que dans la version WINDOWS Core, nous ne pouvons pas créer de tache planifiée sur un déclenchement d’événement.

En réalité, nous pouvons constater également le dysfonctionnement sur un environnement WINDOWS avec expérience utilisateur. Il suffit d’utiliser la console powershell (il suffit de revenir aux bases du RTFM¹⁶).

Donc comment faire une tache planifiée, si :

• Nous n’avons pas d’interface graphique
• Les commandes powershell ne fonctionne pas
• Les moyens de contournement comme WAC¹⁷ ne fonctionne pas (normale co**ard c’est du powershell derrière)
• La console mmc.exe en remote pas plus de chance

J’ai essayé l’exécutable schtasks mais je ne suis pas arrivé à mes fins. Vous vous voulez la vérité ? J’ai lu qu’il fallait faire une fichier XML et ajouté les champs blablablabla… Je me suis dit « No Way » je vais encore me foirer dans une balise ou je vais avoir un problème d’encodage sur des caractères à la mord moi le noeud…

J’ai donc pensé à un autre moyen (tu as surtout épluché le net et les divers forum technet oui…). Pourquoi ne pas créer la tache sur mon poste avec des paramètres que je modifierai une fois importé ? Et bien ça voyez vous, ça fonctionne.

La création de la tâche ne pose pas de problème. Je joins toutefois la petite capture pour la configuration des critères de déclenchement de l’évent.

Une fois la tache créée, exportons là et ouvrons cette dernière dans un éditeur de texte.

Oh mais dit donc, ça ne serait pas ? Hé si le voilà notre fichier XML que l’on devait construire via la commande svctasks. Et dire qu’une tache planifiée ça ressemble à ça. Vous noterez que j’ai occulté deux parties. La première partie permet de récupérer les valeurs de l’événement. Il sera nécessaire de modifier manuellement le fichier XML. Mais je reviendrai plus en détails sur ce point dans la sous partie à venir (c’est ça ma frustration décennale !). La seconde partie permet de passer les variables que contiennent les valeurs récupérées ci haut en paramètre de notre script.

Bien. Maintenant importons la tâche 🙂

> $myTask = Get-Content "PATH_WHERE_XML_FILE\myTask.xml" | Out-String
> Register-ScheduledTask -XML $myTask -TaskName "PROD_EVENT_4740" -TaskPath "\_ronelab"

Récupérer les valeurs

Comme écrit plus haut, ce point va mettre fin à une frustration longue de 10 ans. Comment retourner les valeurs levées dans un event depuis l’exécution d’une tâche planifiée…

Là j’ai lu un nombre important de documentation pour comprendre comment cela fonctionne et comment mettre en œuvre la chose surtout. Toujours dans la démarche des 3S¹⁸.

Dans les approches :

• Quel est la structure, schéma du fichier XML d’une tache planifié : Lien
• Quel est la structure la plus adapté pour un eventTrigger de type complexe : Lien
• Un exemple d’implémentation : Lien

Avec la plus grande sincérité du monde, je n’avais pas il y a 10 ans de cela la maturité intellectuelle pour assimiler cette notion. Aujourd’hui je rougis de l’imbécile que je suis et de la simplicité et évidence de son mécanisme.

Maintenant que j’ai compris (mais que je n’ai pas expliqué 🙂 Il faut bien que vous vous investissiez aussi non ? Passons à la compréhension d’un événement. Il faudra sélectionner un évent 4740 et se rendre dans la vue Detail en Friendly, mais nous pouvons aussi se la jouer XML.

Nous notons deux catégories que nous pouvons déployer :

• System : Va contenir l’ensemble des balises et valeurs propres au déclenchement de la tâche avec les propriétés de l’évent. Comme dit plus tôt, l’un des attributs qui pourrait nous intéresser est le temps où l’évent a été inscrit dans le journal. Je prenais le temps de lancement du script, mais ce dernier n’est pas la bonne source de temps. Bref, il convient alors de noter le chemin de l’attribut qui nous intéresse :
  • Event/System/TimeCreated/@SystemTime

Il est important de noter que tout part de notre événement d’où le Event en début de path. Puis le chemin /System/TimeCreated/ jusqu’à la variable qui contient notre valeur spécifiée par le @ devant SystemTime

• EventData : Va contenir l’ensemble des balises et valeurs propres à l’évènement de sécurité déclenché. Ce qui nous intéresse ce sont les attributs TargetUserName qui contient le login utilisé et verrouillé, TargetDomainName qui contient le nom de poste cible où la connexion a tenté d’être initier et le SubjectDomainName qui contient le nom de domaine cible du compte verrouillé. Soit alors les les chemins suivants :
  • Event/EventData/Data/@[Name= »TargetDomainName »]
  • Event/EventData/Data/@[Name= »SubjectDomainName »]
  • Event/EventData/Data/@[Name= »TargetUserName »]

Alors comment intégrer proprement dans notre fichier XML correspondant à notre tache planifier nos 4 paths pour récupérer les valeurs ?

Normalement, nous avons eu toutes les informations ci-haut pour réaliser l’opération 🙂

Nous avons défini nos variables qui contiennent nos données. Il suffit alors de passer nos variables en arguments de notre script. Je passe une nouvelle fois mon tour. Le passage de variable en arguments d’un script powershell c’est un basique. La modification peut être réalisé en graphique dans le TaskScheduler ou directement dans le fichier XML.

Maintenant, il ne reste plus qu’à réimporter la tache de nouveau puis de réaliser un test.

Reporting

Pour le test, rien de plus facile… J’ai choisie d’initier une connexion à l’une des ressources des domaines à partir d’un compte pour lequel la FGPP est active : * RONEALB\erwan.guillemard Depuis une instance de bureau à distance, je décide de mettre en application ma plus belle couche 8 en saisissant 5 fois mon mot de passe de manière erroné. Windows m’informe que mon compte a été verrouillé à la suite de plusieurs tentatives d’authentifications infructueuses. Quelques minutes après, je reçois le mail ci-contre.

En regardant en détail, j’ai bien les informations qui m’informe que le compte erwan.guillemard a été verrouillé à la suite d’une plusieurs tentatives de connexions depuis la machine EGWKS-RDB01 le 26/09/2025 à 20:31:40 sur le domaine RONELAB.

Toutefois et si je regarde avec précision le déclenchement de la tâche, j’ai 7 minutes de retard dans le temps affiché dans mon mail et la date d’entrée dans le journal de sécurité. Ce retard s’explique par une mauvaise prise en compte de la valeur DateTime. Je pensais que la valeur Datetime du script serait définis lors du lancement du script à la détection de l’événement. Cependant, mon SI étant très ancien, la tache met une bonne dizaine de minutes (en grossissant le trait) à se lancer. Ainsi je génère un delta ce qui n’est pas super en termes de sécurité. Il faudrait donc que je récupère la valeur DateTime présente dans l’événement.

Conclusion

Je suis content d’avoir réinventé mon propre système de notification sur le verrouillage d’un compte utilisateur dans un domaine à partir de la problématique qu’avait il y a maintenant plusieurs années un ancien collègue. Ainsi, j’ai pu combler une problématique vieille de 10 ans en relation avec les événements et les taches planifiées (dans mon projet de mémoire sur la supervision Shinken).

J’ai également constaté que les modules développés dans les projets précédents m’ont fait gagner un temps monstrueux. Cela me permet donc de me dire et de m’auto-confirmer que premièrement je ne fais pas que de la merde, secondement qu’à partir de maintenant je vais prendre un chemin différent quant à l’ensemble des problématiques qui nécessite un dev en powershell.

Le plus difficile restera je le pense de toujours garder une vision claire et qui réponde au 3S.

Si je devais être efficient, je reprendrais mes bouts de code existant concernant la création de ticket dans la solution ITSM de COMBODO (ITOP) pour générer un ticket en criticité haute pour le verrouillage d’un compte. De cette manière, le centre de service ou les équipes locales (internalisées ou externalisées) pourraient être proactives quant à tous comportements succès en relation avec l’authentification et l’accès à des ressources. Ce qui pourrait alors se résumer selon notre bon vieux William Shakespear par « Le plaisir d’un travail en guérit la peine ».

J’ai encore une fois repris une idée. Je pense qu’il serait temps que je reprenne un peu de temps pour innover. Certes, comprendre et mettre en pratique les idées de mes paires et une bonne chose mais je pense qu’il est souhaitable de vivre pleinement une nouvelle fois cette satisfaction personnelle. Mon ultime rature se limitera à « Est ce que cela valait ce billet ?« .

Je vous laisse jugez de tout ça et prendre contact si vous voulez le bout de code 🙂

Le mot de la fin :

Vous êtes surqualifié pour le poste ? Que neni, j’aime les salsifis et je sens vaguement le chou. Je vous embauche et Toper Harley reste dans la boucle. Merci, j’ai les films de programmateurs.

Erwan GUILLEMARD

Sources

• ANSSI : Guide d’authentification multi facteur et mots de passe
• WINDOWS : Authentification & Identification
• WINDOWS : Evénements à surveiller
• WINDOWS : Type Complexe EventType
• WINDOWS : KERBEROS
• WINDOWS : Svctasks
• WINDOWS : New-ScheduledTask
• WINDOWS : Register-ScheduledTask
• WINDOWS : Event & Queries

1. AD : Active Directory ↩︎
2. PSSI : Politique de Sécurité des Systèmes d’Informations ↩︎
3. OSI : Open Systems Interconnection ↩︎
4. SI : Système d’Informations ↩︎
5. DNS : Domain Name Service ↩︎
6. DC : Domain Controller ↩︎
7. NTLM : NT Lan Manager ↩︎
8. TGT : Ticket Granting Ticket ↩︎
9. KDC : Key Distribution Center ↩︎
10. TGS : Ticket Granting Server ↩︎
11. GPO : Group Policy Object ↩︎
12. ANSSI : Agence Nationale de Sécurité des Systèmes Informatiques ↩︎
13. FGPP : Fine Grained Password Policy ↩︎
14. gMSA : Group Managed Service Account ↩︎
15. SMTP : Simple Mail Transfert Protocol ↩︎
16. RTFM : Read The F*cking Manual ↩︎
17. WAC : Windows Admin Center ↩︎
18. 3S : Simple, Standard, Sécurisé ↩︎