Hur spårar och löser du ett låst Active Directory-konto? Ta reda på vad som händer, hur du hittar specifika händelser och hur du analyserar händelser.
Active Directory (AD) är en fantastisk tjänst. Du kan logga in från var som helst i nätverket med samma användarnamn och lösenord. Det kan inte vara enklare – det vill säga tills du glömmer att stänga en fjärrskrivbordssession, eller en mask sprider sig över nätverket, eller du glömmer att du kör en schemalagd uppgift som ditt användarkonto, eller… Ja, du förstår vad jag menar. AD är en extremt användbar produkt, och det är därför som den är så populär. Problemet är när ett konto börjar låsa sig utan någon som helst anledning. Eller så tror man det.
AD-kontoutlåsningspolicy
Många organisationer har (eller borde ha) kontoutlåsningspolicy. Denna policy är en säkerhetsåtgärd för att förhindra att obehöriga försöker gissa lösenordet kontinuerligt eller brute force ett lösenord. Kontolåsningsprinciper är vanliga i Active Directory och är en enkel metod för att bekämpa ett stort säkerhetsproblem. Försök med fel lösenord ett visst antal gånger och kontot blir oanvändbart tills en administratör manuellt aktiverar det igen. Avsikten är sann, men i vissa fall är genomförandet inte det.
I vissa situationer, särskilt när ett lösenord ändras, kan ett konto plötsligt börja bli låst konsekvent utan någon uppenbar anledning. En användare ringer till helpdesk, helpdesk återaktiverar kontot och lite senare är kontot låst igen. Det är en frustrerande upplevelse för både användaren och helpdesken. Ibland förvärras problemet av det okända ursprunget till låsningarna. Någonstans, på något sätt finns det en person, ett skript eller en process som ständigt försöker använda samma felaktiga lösenord om och om igen, men ingen vet var.
Hur spårar man då upp dessa irriterande låsningar? Ett sätt är att använda ett PowerShell-skript. Men först ska vi gå igenom vad som händer när ett konto är låst.
Lösning av ett låst AD-konto
I en Windows Server 2008-miljö eller senare finns det en kort fram och tillbaka mellan klientsystemet, klientsystemets domänkontrollant och den domänkontrollant som innehar emulatorrollen Primary Domain Controller (PDC). Detta sker på följande sätt:
- När en autentisering av ett användarkonto försöks skickas autentiseringsuppgifterna upp till lämplig domänkontrollant för klientsystemets undernät.
- Om lösenordet är fel vidarebefordrar klientsystemets domänkontrollant begäran till den domänkontrollant som innehar PDC-emulatorrollen. Detta beror på att klientsystemets domänkontrollant kanske inte har det senaste lösenordet, och som en konstruktionsfunktion i Active Directory har domänkontrollanten med PDC-emulatorrollen alltid det.
- PDC-emulatorn försöker med lösenordet igen, och om det fortfarande är fel ökar PDC-emulatorn attributet badPwdCount på användarkontot.
- Ett händelse-ID 4740 genereras på PDC-emulatorn med den IP-adress i klientsystemet som initierade den ursprungliga begäran och med användarkontot.
- PDC-emulatorn informerar sedan klientsystemets domänkontrollant om att lösenordet faktiskt är fel.
- Klientsystemets domänkontrollant meddelar sedan klientsystemet att lösenordet var fel.
Var skulle det bästa stället vara att hitta källan? Svaret är i PDC-emulatorn. Anledningen till det är att varje kontolåsning registreras där i säkerhetshändelseloggen. PDC-emulatorn är en central plats som kan frågas efter alla kontolåsningshändelser.
Användning av PowerShell för att spåra källan till AD-kontolåsningar
För att fråga PDC-emulatorn använder vi PowerShells cmdlet Get-WinEvent. Detta är en extremt användbar cmdlet för att snabbt analysera en eller flera händelseloggar på en server. Vi letar efter händelse-ID 4740. Först måste vi hitta den domänkontrollant som har rollen som PDC-emulator. Ett sätt att göra detta är att använda cmdlet Get-AdDomain.
När vi väl känner till PDC-emulatorn är det bara att fråga dess säkerhetshändelselogg efter händelse-ID 4740.
Jag har ett konto som heter abertram som är utelåst. Låt oss se hur vi spårar upp den skyldige.
Vi har PDC-emulatorn nu, så låt oss fråga efter dess säkerhetslogg med ett PowerShell-skript.
## Definiera användarnamnet som är utelåst
$Username = ’abertram’
## Hitta domänkontrollantens PDCe-roll
$Pdce = (Get-AdDomain).PDCEmulator
## Skapa parametrarna som ska skickas till Get-WinEvent
$GweParams = @{
’Computername’ = $Pdce
’LogName’ = ’Security’
’FilterXPath’ = ”* and EventData=’$Username’]]]”
}## Fråga efter loggboken för säkerhetshändelser
$Events = Get-WinEvent @GweParams
Detta ger oss låsningshändelsen.
Men vi har inte det ursprungliga klientsystemet ännu. För att få fram det måste vi gräva lite djupare. Det faktiska användarnamnet ligger begravt i varje händelses Properties-värde. För att hitta användarnamnet i varje händelse kan vi helt enkelt använda den här raden:
$Events.Properties.Value
Detta hittar användarnamnet i den första händelsen och i den första instansen av Properties-värdet. Som tur är finns klientsystemet bara i den andra instansen av Properties.
$Events.Properties.Value
När du väl vet var klientsystemets namn finns är det bara att infoga det i en slinga, så har vi hittat den skyldige.
Nu är du beväpnad och redo att gå i gång nästa gång helpdesk ringer dig med det där oupphörliga AD-användarkontot som hela tiden blir utelåst.