Comment suivre l’activité de connexion des utilisateurs dans Active Directory (sans devenir fou)
Il est crucial de savoir quand et où les utilisateurs se connectent, notamment pour résoudre des problèmes de compte inhabituels ou simplement surveiller l’activité. Le problème ? Active Directory ne conserve pas un simple historique de chaque connexion comme une caméra de surveillance. Il faut configurer des stratégies et des scripts pour obtenir les informations nécessaires, et même alors, reconstituer le puzzle peut s’avérer complexe. Ce guide est là pour vous aider à y voir plus clair, de la configuration des stratégies d’audit à l’extraction des journaux avec PowerShell. L’objectif ? Obtenir une vue d’ensemble complète de l’activité des utilisateurs au fil du temps, incluant les heures de connexion, les machines sources et même les méthodes d’authentification utilisées. Si vous vous êtes déjà demandé « Quand cet utilisateur s’est-il connecté pour la dernière fois ? » ou « De quelle machine provenait-il ? » et que vous n’avez trouvé que quelques entrées de journal suspectes, ce guide est fait pour vous. Une configuration optimale vous permettra d’extraire des informations utiles des journaux de vos contrôleurs de domaine, sans avoir à analyser manuellement des centaines d’événements. Et oui, c’est un peu pénible de tout synchroniser, mais ça vaut le coup quand on voit cet historique complet des journaux dans ses scripts.
Comment obtenir une vue d’ensemble claire des connexions utilisateur dans Active Directory
Configurer la stratégie d’audit des connexions utilisateur dans Active Directory
La première chose à faire est de configurer Windows pour qu’il enregistre tous les événements d’ouverture de session, au lieu de les ignorer. Car, comme vous le savez, Windows complique inutilement les choses. Vous devez configurer une stratégie d’audit dans la Gestion des stratégies de groupe.- Ouvrez GPMC.msc (console de gestion des objets de stratégie de groupe du domaine).- Créez un nouvel objet de stratégie de groupe (par exemple, « Audit des ouvertures de session utilisateur ») et liez-le à la racine de votre domaine, et non à la stratégie par défaut. C’est plus sûr, croyez-moi.- Accédez à : Configuration ordinateur → Stratégies → Paramètres Windows → Paramètres de sécurité → Configuration avancée des stratégies d’audit → Stratégies d’audit → Ouverture/Fermeture de session.- Activez les options Auditer les ouvertures de session et Auditer les autres événements d’ouverture/fermeture de session ; assurez-vous de cocher Succès et, éventuellement, Échec. Pourquoi ? Parce que vous souhaitez suivre chaque ouverture de session réussie, mais les échecs peuvent également indiquer une utilisation incorrecte d’identifiants ou des tentatives d’attaque par force brute. Ensuite, accédez à Ouverture de session → Audit du service d’authentification Kerberos et activez Succès. Les événements Kerberos sont précieux, notamment pour identifier les connexions qui ne sont pas toujours enregistrées dans les événements d’ouverture de session standard. Enregistrez la stratégie de groupe (GPO), puis déployez-la gpupdate /forcesur vos contrôleurs de domaine pour accélérer le processus. La propagation de ces paramètres peut prendre quelques minutes. Une fois effectuée, chaque connexion utilisateur réussie générera un événement d’ID 4624 dans le journal de sécurité. Ce journal contient des informations détaillées sur l’utilisateur, sa localisation et le type de connexion (locale, réseau, distante, etc.).À noter : le champ Type d’ouverture de session indique s’il s’agit d’une connexion locale, réseau, RDP distante ou autre. Par exemple : – Type 2 : ouverture de session locale.- Type 3 : ouverture de session réseau/dossier partagé.- Type 10 : ouverture de session interactive distante, comme RDP.- Type 7 : déverrouillage de session après le verrouillage de l’écran. Si vous souhaitez encore plus d’informations, le suivi de l’ID d’événement 4768 (demandes de tickets Kerberos) permet également de repérer les connexions qui se produisent en arrière-plan — un outil précieux pour l’audit.
Récupération des données de connexion avec PowerShell (car la méthode manuelle ne suffit pas)
Une fois vos journaux d’audit opérationnels, comment *voir* concrètement qui s’est connecté, quand et depuis quelle machine ? PowerShell à la rescousse. Mais attention : l’utilisation de PowerShell Get-EventLogn’est pas des plus rapides, surtout si vos journaux sont volumineux ou si votre domaine comporte de nombreux contrôleurs de domaine. Sur une configuration donnée, cela fonctionnera, mais l’exécution peut s’avérer fastidieuse, un peu comme patauger dans de la mélasse. C’est pourquoi beaucoup ne jurent que par PowerShellGet-WinEvent ; c’est plus rapide et plus flexible. Voici un exemple simple et concret pour obtenir les événements de connexion de tous vos contrôleurs de domaine pour un utilisateur spécifique au cours des deux derniers jours : powershell # Utilisateur à vérifier $checkuser=’*jbrown*’ # à remplacer selon les besoins # Retour en arrière de 2 jours $startDate = (get-date).AddDays(-2) # Obtenir la liste de tous les contrôleurs de domaine $DCs = Get-ADDomainController -Filter * $results = foreach ($DC in $DCs) { # Trouver les événements avec l’ID 4624 (connexion réussie) $events = Get-WinEvent -ComputerName $DC. HostName -FilterHashtable @{LogName=’Security’;Id=4624;StartTime=$startDate} -ErrorAction SilentlyContinue foreach ($ev in $events) { # Convertir le XML pour extraire les données $xml = [xml]$ev. ToXml() $user = $xml. Event. EventData. Data[5].’#text’ # Nom d’utilisateur cible $logonTypeCode = $xml. Event. EventData. Data[8].’#text’ # Type d’ouverture de session if ($user -like $checkuser) { [PSCustomObject]@{ Time = $ev. TimeCreated User = $user DC = $DC. Name LogonType = switch ($logonTypeCode) { 2 {‘Interactif local’} 3 {‘Réseau’} 7 {‘Déverrouillage’} 10 {‘Interactif distant RDP’} default {‘Autre’} } SourceIP = $xml. Event. EventData. Data[18].’#text’ } } } } # Exporter au format CSV si nécessaire $results | Export-Csv -Path « C:\Logs\UserLogonHistory.csv » -NoTypeInformation Ceci génère une liste de toutes les ouvertures de session réussies pour l’utilisateur, depuis quelle machine et quel contrôleur de domaine ont été utilisés. Vous pouvez ainsi voir si une personne s’est connectée depuis son ordinateur de bureau ou via une session RDP. Remarque : Get-EventLog pouvant être lent, Get-WinEventil est souvent préférable, pour les environnements importants, de passer à . De plus, l’envoi des journaux vers un collecteur de journaux centralisé (comme Graylog ou Splunk) permet de garantir leur indexation et leur indexation à long terme.
Surveillance des événements Kerberos pour une approche légère
Vous souhaitez consulter rapidement les connexions récentes, notamment si Kerberos est votre méthode d’authentification principale ? L’ID d’événement 4768 indique une demande de ticket Kerberos. Généralement, cette méthode est plus efficace car elle filtre les requêtes d’accès aux services. Par exemple, ce script récupère les informations de connexion utilisateur à partir des requêtes Kerberos TGT de la veille : powershell $allUserHistory = @() $startDate = (Get-Date).AddDays(-1) $DCs = Get-ADDomainController -Filter * foreach ($DC in $DCs) { $events = Get-EventLog -LogName Security -InstanceID 4768 -after $startDate -ComputerName $DC. HostName foreach ($ev in $events) { # Analyser les données XML de l’événement $xml = [xml]$ev. ToXml() $user = $xml. Event. EventData. Data[0].’#text’ $ip = $xml. Event. EventData. Data[9].’#text’ $allUserHistory += [PSCustomObject]@{ UserName = $user IP = $ip Date = $ev. TimeGenerated DomainController = $DC. Name } `$allUserHistory` n’affiche pas toutes les connexions, mais uniquement celles issues des tickets Kerberos. C’est donc un moyen rapide de voir qui s’est authentifié récemment sans encombrer les journaux. Notez que les utilisateurs configurés avec NTLM uniquement n’apparaîtront pas ici. Pour un suivi à long terme, la centralisation des journaux et l’automatisation sont plus fiables que la recherche dans les journaux d’événements locaux de chaque machine. Cette méthode est toutefois pratique pour des vérifications ponctuelles ou dans des environnements de petite taille.— J’espère que cela vous donne une bonne idée de la façon de suivre les connexions des utilisateurs sans vous arracher les cheveux. Une fois ces politiques définies et les données intégrées à vos scripts, il est beaucoup plus facile d’obtenir les réponses dont vous avez besoin sans avoir à inspecter manuellement les journaux à chaque fois. Un petit conseil : une bonne préparation est essentielle, surtout lorsqu’il s’agit de journaux de sécurité Windows. Bonne chance !