Hoe u de aanmeldingsactiviteit van gebruikers in Active Directory kunt volgen (zonder gek te worden)
Weten wanneer en waar gebruikers inloggen is cruciaal, vooral als u vreemde accountproblemen probeert op te lossen of gewoon de activiteit in de gaten wilt houden. Het probleem is dat Active Directory niet zomaar een eenvoudige geschiedenis van elke login bijhoudt, zoals een bewakingscamera. U moet beleidsregels en scripts instellen om de benodigde informatie te verkrijgen, en zelfs dan kan het lastig zijn om alles samen te voegen. Deze handleiding helpt u hierbij – van het configureren van auditbeleid tot het ophalen van logboeken met PowerShell. Het doel? Een zo compleet mogelijk beeld van de gebruikersactiviteit in de loop van de tijd, inclusief inlogtijden, bronmachines en zelfs de authenticatiemethoden die ze hebben gebruikt. Als u zich ooit hebt afgevraagd “Wanneer heeft deze gebruiker voor het laatst ingelogd?” of “Van welke machine kwam hij/zij?” en slechts een handvol verdachte logboekvermeldingen hebt gevonden, dan is dit echt een uitkomst. Door alles goed in te stellen, kunt u nuttige informatie uit de logboeken van uw domeincontrollers halen, zonder handmatig honderden gebeurtenissen te hoeven doorzoeken. Ja, het is best een gedoe om alles te synchroniseren, maar het is de moeite waard als je die complete loggeschiedenis in je scripts ziet.
Hoe krijg ik een duidelijk overzicht van gebruikersaanmeldingen in Active Directory?
Configureer het beleid voor gebruikersaanmeldingscontrole in Active Directory.
Allereerst moet je Windows vertellen dat het alle aanmeldingsgebeurtenissen daadwerkelijk moet *registreren* in plaats van ze te negeren. Want, zoals je van Windows gewend bent, maakt het extra ingewikkeld. Je moet een auditbeleid instellen in Groepsbeleidsbeheer.- Open GPMC.msc (de GPO-beheerconsole voor domeinen).- Maak een nieuw GPO aan (bijvoorbeeld “Gebruikersaanmeldingscontrole”) en koppel dit aan de root van je domein – niet aan het standaardbeleid. Dat is veiliger, geloof me.- Navigeer naar: Computerconfiguratie → Beleid → Windows-instellingen → Beveiligingsinstellingen → Geavanceerde auditbeleidsconfiguratie → Auditbeleid → Aanmelden/Afmelden.- Schakel zowel Aanmeldingscontrole als Overige aanmeldings-/afmeldingsgebeurtenissen controleren in; zorg ervoor dat je Geslaagd en eventueel Mislukt aanvinkt. Waarom? Omdat je elke succesvolle aanmelding wilt registreren, maar mislukte aanmeldingen kunnen ook wijzen op misbruikte referenties of brute-force-aanvallen.- Ga ook naar Accountaanmelding → Kerberos-verificatieservice controleren en schakel Succes in. Kerberos-gebeurtenissen zijn goud waard, vooral om aanmeldingen te achterhalen die niet altijd worden geregistreerd in de standaard aanmeldingsgebeurtenissen.- Sla het groepsbeleidsobject (GPO) op en implementeer het vervolgens met gpupdate /force op uw domeincontrollers om het proces te versnellen. Het kan een paar minuten duren voordat deze instellingen zijn doorgevoerd, maar zodra dat is gebeurd, genereert elke succesvolle gebruikersaanmelding een gebeurtenis-ID 4624 in het beveiligingslogboek. De details omvatten welke gebruiker, vanaf welke locatie en wat voor soort aanmelding (lokaal, netwerk, extern, enz.).Let op: het veld Aanmeldingstype geeft aan of het lokaal, via het netwerk, via externe RDP of iets anders is. Bijvoorbeeld: – Type 2 — lokale aanmelding op de desktop.- Type 3 — netwerk-/aanmelding op een gedeelde map.- Type 10 — interactieve aanmelding op afstand, zoals RDP.- Type 7 — sessie ontgrendelen na vergrendelscherm. Als je nog meer inzicht wilt, helpt het volgen van gebeurtenis-ID 4768 (Kerberos Ticket Granting Ticket-verzoeken) ook bij het opsporen van aanmeldingen die achter de schermen plaatsvinden – handig voor auditdoeleinden.
Aanmeldingsgegevens ophalen met PowerShell (omdat handmatig niet volstaat)
Zodra je auditlogboeken goed werken, hoe zie je dan wie er heeft ingelogd, wanneer en vanaf welke machine? PowerShell biedt uitkomst. Maar let op: het gebruik van Get-EventLog is niet bepaald snel, vooral niet als je logboeken groot zijn of je domein veel domeincontrollers heeft. In één configuratie werkt het misschien wel, maar het kan traag zijn – alsof je door stroop waadt. Daarom zweren veel mensen bij Get-WinEvent; het is sneller en flexibeler. Hier is een eenvoudig, praktijkvoorbeeld om aanmeldingsgebeurtenissen van al uw domeincontrollers voor een specifieke gebruiker van de afgelopen paar dagen op te halen: powershell # Gebruiker om te controleren $checkuser=’*jbrown*’ # vervang indien nodig # Kijk 2 dagen terug $startDate = (get-date).AddDays(-2) # Lijst met alle domeincontrollers ophalen $DCs = Get-ADDomainController -Filter * $results = foreach ($DC in $DCs) { # Zoek gebeurtenissen met ID 4624 (succesvolle aanmelding) $events = Get-WinEvent -ComputerName $DC. HostName -FilterHashtable @{LogName=’Security’;Id=4624;StartTime=$startDate} -ErrorAction SilentlyContinue foreach ($ev in $events) { # Converteer XML om gegevens te extraheren $xml = [xml]$ev. ToXml() $user = $xml. Event. EventData. Data[5].’#text’ # Doelgebruikersnaam $logonTypeCode = $xml. Event. EventData. Data[8].’#text’ # Aanmeldtype if ($user -like $checkuser) { [PSCustomObject]@{ Time = $ev. TimeCreated User = $user DC = $DC. Name LogonType = switch ($logonTypeCode) { 2 {‘Lokaal interactief’} 3 {‘Netwerk’} 7 {‘Ontgrendelen’} 10 {‘Interactief RDP op afstand’} default {‘Anders’} } SourceIP = $xml. Event. EventData. Data[18].’#text’ } } } } # Exporteer naar CSV indien nodig $results | Export-Csv -Path “C:\Logs\UserLogonHistory.csv” -NoTypeInformation Dit genereert een lijst met alle succesvolle aanmeldingen van de gebruiker, vanaf welke machine en via welke domeincontroller (DC) ze verbinding hebben gemaakt. Zo kunt u zien of iemand zich heeft aangemeld vanaf zijn of haar kantoor-pc of via een RDP-sessie. Opmerking: omdat Get-EventLog traag kan zijn, is overschakelen naar Get-WinEvent vaak beter voor grotere omgevingen. Bovendien zorgt het pushen van logboeken naar een centrale logverzamelaar (zoals Graylog of Splunk) ervoor dat alles op de lange termijn doorzoekbaar blijft.
Het monitoren van Kerberos-gebeurtenissen voor een lichtgewicht aanpak.
Wil je snel een overzicht van recente aanmeldingen, vooral als Kerberos je belangrijkste authenticatiemethode is? Gebeurtenis-ID 4768 duidt op een Kerberos-ticketverzoek. Dit is doorgaans efficiënter omdat het alle onnodige serviceaanvragen filtert. Dit script haalt bijvoorbeeld gebruikersaanmeldingsgegevens op basis van Kerberos TGT-verzoeken van de afgelopen dag: 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) { # Parseer de XML-gebeurtenisgegevens $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 Dit toont niet elke aanmelding, alleen die van Kerberos-tickets. Het is dus een snelle manier om te zien wie zich recent heeft geauthenticeerd zonder overbodige logberichten. Houd er rekening mee dat gebruikers in NTLM-only-omgevingen hier niet worden weergegeven. En onthoud dat voor het bijhouden van de lange termijn het centraliseren van logboeken en automatisering betrouwbaarder is dan het doorzoeken van lokale gebeurtenislogboeken op elke machine. Maar het is handig voor snelle ad-hoccontroles of kleinere omgevingen.— Hopelijk geeft dit een goed beeld van hoe je gebruikersaanmeldingen kunt bijhouden zonder je haren uit je hoofd te trekken. Zodra die beleidsregels zijn ingesteld en de gegevens in je scripts stromen, is het veel gemakkelijker om de antwoorden te krijgen die je nodig hebt zonder elke keer handmatig logboeken te hoeven controleren. Onthoud: een beetje voorbereiding kan veel verschil maken, vooral bij het werken met Windows-beveiligingslogboeken. Succes!