Hvordan sporer og løser du en låst Active Directory-konto? Find ud af, hvad der sker, hvordan du finder specifikke hændelser, og hvordan du analyserer hændelser.
Active Directory (AD) er en vidunderlig tjeneste. Du kan logge på fra alle steder på netværket med det samme brugernavn og den samme adgangskode. Det kunne ikke være nemmere – det vil sige, indtil du glemmer at lukke en fjernskrivebordssession, eller en orm spreder sig over netværket, eller du glemmer, at du kører en planlagt opgave som din brugerkonto, eller… Nå, du forstår det hele. AD er et yderst nyttigt produkt; det er grunden til, at dets udbredelsesgrad er så høj. Problemet er, når en konto begynder at blive spærret uden nogen som helst grund. Eller det tror man i hvert fald.
AD-konto lockout-politikker
Mange organisationer har (eller bør have) konto lockout-politikker. Denne politik er en sikkerhedsforanstaltning for at forhindre uautoriserede parter i at forsøge at gætte adgangskoden løbende eller brute force en adgangskode. Kontolåsningspolitikker er almindelige i Active Directory og består af en simpel tilgang til bekæmpelse af et stort sikkerhedsproblem. Hvis du forsøger at indtaste den forkerte adgangskode et bestemt antal gange, er kontoen ubrugelig, indtil en administrator manuelt aktiverer den igen. Hensigten er sand, men i nogle tilfælde er implementeringen det ikke.
I nogle situationer, især når en adgangskode ændres, kan en konto pludselig begynde at blive låst konsekvent uden nogen åbenlys grund. En bruger ringer til helpdesken, helpdesken genaktiverer kontoen, og lidt senere er kontoen låst ude igen. Det er en frustrerende oplevelse for både brugeren og helpdesken. Nogle gange bliver problemet forværret af den ukendte oprindelse af spærringerne. Et eller andet sted, på en eller anden måde er der en person, et script eller en proces, der hele tiden forsøger at bruge den samme forkerte adgangskode igen og igen, men ingen ved hvor.
Så hvordan opsporer man disse irriterende lockouts? En måde er ved at bruge et PowerShell-script. Men lad os først gennemgå, hvad der sker, når en konto er låst.
Resolving A Locked AD Account
I et Windows Server 2008-miljø eller nyere miljø er der en kort frem og tilbage mellem klientsystemet, klientsystemets domænecontroller og den domænecontroller, der har rollen som Primary Domain Controller (PDC)-emulator. Dette sker på følgende måde:
- Hver gang der forsøges autentificering af en brugerkonto, sendes legitimationsoplysningerne op til den relevante domænecontroller for klientsystemets undernet.
- Hvis adgangskoden er forkert, videresender klientsystemets domænecontroller anmodningen til den domænecontroller, der har PDC-emulatorrollen. Dette skyldes, at klientsystemets domænecontroller måske ikke har den mest aktuelle adgangskode, og som en designfunktion i Active Directory har domænecontrolleren med PDC-emulatorrollen altid den.
- PDC-emulatoren prøver adgangskoden igen, og hvis den stadig viser sig at være forkert, øger PDC-emulatoren attributten badPwdCount på brugerkontoen.
- Der genereres et hændelses-ID 4740 på PDC-emulatoren med den IP-adresse på klientsystemet, der startede den oprindelige anmodning, og med brugerkontoen.
- PDC-emulatoren informerer derefter klientsystemets domænecontroller om, at adgangskoden faktisk er forkert.
- Klientsystemets domænecontroller meddeler derefter klientsystemet, at adgangskoden var forkert.
Hvor ville det være det bedste sted at finde kilden? Svaret er i PDC-emulatoren. Grunden til det er, at hver kontolåsning registreres der i sikkerhedshændelsesloggen. PDC-emulatoren er et centralt sted, hvor der kan spørges efter alle kontolåsningshændelser.
Brug af PowerShell til at opspore kilden til AD-kontolåsninger
For at forespørge PDC-emulatoren bruger vi PowerShells Get-WinEvent-cmdlet. Dette er en yderst nyttig cmdlet til hurtigt at analysere en eller flere hændelseslogfiler på en server. Vi leder efter et hændelses-ID på 4740. Først skal vi finde den domænecontroller, der har rollen som PDC-emulator. Det kan vi bl.a. gøre ved at bruge cmdletten Get-AdDomain.
Når vi kender PDC-emulatoren, er det blot et spørgsmål om at spørge dens sikkerhedshændelseslog for hændelses-ID 4740.
Jeg har en konto ved navn abertram, der er låst ude. Lad os se, hvordan vi opsporer synderen.
Vi har PDC-emulatoren nu, så lad os forespørge dens sikkerhedslog med et PowerShell-script.
### Definer det brugernavn, der er låst ude
$Username = ‘abertram’
## Find domænecontroller PDCe-rollen
$Pdce = (Get-AdDomain).PDCEmulator
### Opbyg de parametre, der skal overføres til Get-WinEvent
$GweParams = @{
‘Computername’ = $Pdce
‘LogName’ = ‘Security’
‘FilterXPath’ = “* and EventData=’$Username’]]]”
}## Søg i loggen over sikkerhedshændelser
$Events = Get-WinEvent @GweParams
Dette giver os lockout-hændelsen.
Men vi har ikke det oprindelige klientsystem endnu. For at få det skal vi grave lidt dybere. Det faktiske brugernavn er begravet i hver hændelses Properties-værdi. For at finde brugernavnet i hver enkelt hændelse kan vi blot bruge denne linje:
$Events.Properties.Value
Derved finder vi brugernavnet i den første hændelse og i den første forekomst af Properties-værdien. Heldigvis er klientsystemet bare i den anden instans af Properties.
$Events.Properties.Value
Når du ved, hvor klientsystemets navn er placeret, er det bare et spørgsmål om at indsætte det i en løkke, og så har vi fundet synderen.
Nu er du bevæbnet og klar til at gå i gang, næste gang helpdesk ringer til dig med den uophørlige AD-brugerkonto, der bliver ved med at blive låst ude.