Hoe spoor je een vergrendeld Active Directory account op en los je het op? Ontdek wat er gebeurt, hoe u specifieke gebeurtenissen vindt en hoe u gebeurtenissen parseert.
Active Directory (AD) is een prachtige service. Je kunt je overal op het netwerk aanmelden met dezelfde gebruikersnaam en hetzelfde wachtwoord. Het kan niet eenvoudiger – dat wil zeggen, totdat je vergeet een remote desktop sessie te sluiten, of een worm verspreidt zich over het netwerk, of je vergeet dat je een geplande taak uitvoert als je gebruikersaccount, of … Nou, je snapt het wel. AD is een uiterst nuttig product; dit is waarom de adoptiegraad zo hoog is. Het probleem is wanneer een account begint te blokkeren zonder enige reden. Of dat denkt u toch.
AD Account Lockout Policies
Veel organisaties hebben een beleid voor het blokkeren van accounts (of zouden dat moeten hebben). Dit beleid is een veiligheidsmaatregel om te voorkomen dat onbevoegden voortdurend proberen het wachtwoord te raden of een wachtwoord te brute-forcen. Account lockout beleid is gemeengoed in Active Directory en bestaat uit een eenvoudige benadering van het bestrijden van een groot beveiligingsprobleem. Probeer een bepaald aantal keren het verkeerde wachtwoord, en de account is onbruikbaar totdat een beheerder hem handmatig weer inschakelt. De bedoeling is waar, maar in sommige gevallen is de uitvoering dat niet.
In sommige situaties, vooral wanneer een wachtwoord wordt gewijzigd, kan een account plotseling consequent worden geblokkeerd zonder duidelijke reden. Een gebruiker belt de helpdesk, de helpdesk schakelt de account weer in, en even later is de account weer geblokkeerd. Dit is een frustrerende ervaring voor zowel de gebruiker als de helpdesk. Soms wordt het probleem nog verergerd door de onbekende oorsprong van de lockouts. Ergens, op de een of andere manier is er een persoon, een script, of een proces voortdurend proberen hetzelfde verkeerde wachtwoord keer op keer, maar niemand weet waar.
Dus hoe kunt u opsporen deze vervelende lockouts? Een manier is door gebruik te maken van een PowerShell script. Maar laten we eerst eens bekijken wat er gebeurt wanneer een account wordt vergrendeld.
Oplossen van een vergrendeld AD-account
In een Windows Server 2008-omgeving of later, is er een kort heen en weer tussen het clientsysteem, de domeincontroller van het clientsysteem, en de domeincontroller die de Primary Domain Controller (PDC)-emulatorrol vervult. Dit gebeurt als volgt:
- Wanneer de authenticatie van een gebruikersaccount wordt geprobeerd, worden de referenties verzonden naar de juiste domeincontroller voor het subnet van het clientsysteem.
- Als het wachtwoord onjuist is, stuurt de domeincontroller van het clientsysteem het verzoek door naar de domeincontroller die de PDC-emulatorrol vervult. Dit komt omdat de domeincontroller van het clientsysteem mogelijk niet het meest actuele wachtwoord heeft, en als ontwerpkenmerk van Active Directory heeft de domeincontroller die de PDC-emulatorrol vervult, dit altijd.
- De PDC-emulator probeert het wachtwoord opnieuw, en als het nog steeds onjuist blijkt te zijn, verhoogt de PDC-emulator het kenmerk badPwdCount op de gebruikersaccount.
- Een gebeurtenis-ID 4740 wordt gegenereerd op de PDC-emulator met het IP-adres van het clientsysteem dat het oorspronkelijke verzoek heeft geïnitieerd en met de gebruikersaccount.
- De PDC-emulator informeert vervolgens de domeincontroller van het clientsysteem dat het wachtwoord inderdaad fout is.
- De domeincontroller van het clientsysteem informeert vervolgens het clientsysteem dat het wachtwoord fout was.
Waar zou de beste plaats zijn om de bron te vinden? Het antwoord is bij de PDC emulator. De reden daarvoor is dat elke account lockout daar wordt geregistreerd in het security event log. De PDC-emulator is een centrale plaats waar alle events voor accountvergrendeling kunnen worden opgevraagd.
PowerShell gebruiken om de bron van AD-accountvergrendelingen op te sporen
Om de PDC-emulator te bevragen, gebruiken we het cmdlet Get-WinEvent van PowerShell. Dit is een uiterst nuttig cmdlet om snel een of meer event logs op een server door te spitten. We zijn op zoek naar een event ID van 4740. Eerst moeten we de domeincontroller vinden die de PDC emulator rol heeft. Dit kunnen we onder andere doen met het cmdlet Get-AdDomain.
Als we eenmaal weten wie de PDC-emulator is, hoeven we alleen nog maar in het beveiligingslogboek te zoeken naar gebeurtenis-ID 4740.
Ik heb een account met de naam abertram dat is buitengesloten. Laten we eens kijken hoe we de schuldige kunnen opsporen.
We hebben nu de PDC-emulator, dus laten we het beveiligingslogboek doorzoeken met een PowerShell-script.
## Definieer de gebruikersnaam die is buitengesloten
$Username = ‘abertram’
## Zoek de PDCe rol van de domeincontroller
$Pdce = (Get-AdDomain).PDCEmulator
## Stel de parameters samen om door te geven aan Get-WinEvent
$GweParams = @{
‘Computername’ = $Pdce
‘LogName’ = ‘Security’
‘FilterXPath’ = “* en EventData=’$Username’]]”
}
## Vraag het beveiligingsgebeurtenislogboek op
$Events = Get-WinEvent @GweParams
Dit levert ons de gebeurtenis lockout op.
Maar we hebben het oorspronkelijke client-systeem nog niet. Om dat te krijgen, moeten we wat dieper graven. De werkelijke gebruikersnaam staat in de eigenschappen van elke gebeurtenis. Om de gebruikersnaam in elke gebeurtenis te vinden, kunnen we eenvoudigweg deze regel gebruiken.
$Events.Properties.Value
Dit vindt de gebruikersnaam in de eerste gebeurtenis en in de eerste instantie van de waarde Eigenschappen. Gelukkig staat het clientsysteem gewoon in de tweede instantie van Properties.
$Events.Properties.Value
Wanneer u eenmaal weet waar de naam van het clientsysteem zich bevindt, is het slechts een kwestie van invoegen in een lus, en we hebben de boosdoener gevonden.
Nu bent u gewapend en klaar om de volgende keer dat de helpdesk u belt met die onophoudelijke AD-gebruikersaccount die steeds wordt geblokkeerd, aan de slag te gaan.