Active Directory: как да откриете и отстраните заключени акаунти — ръководство за IT Helpdesk

Заключени акаунти в Active Directory: защо това е проблем номер едно за IT Helpdesk

Ако работите на IT Helpdesk, знаете усещането — идвате сутринта, отваряте тикет системата и... пак заключени акаунти. Потребителят звъни, казва „не мога да вляза" и очаква решение в рамките на минути. Отключването е лесната част, разбира се. Истинското предизвикателство? Да разберете защо се е заключил акаунтът — и да предотвратите повторното заключване пет минути по-късно.

Честно казано, след години работа с Active Directory, мога да кажа, че заключванията на акаунти са едновременно прост и коварен проблем. Прост — защото решението обикновено е едно щракване. Коварен — защото първопричината може да се крие в десетки различни места.

В това ръководство ще минем през целия процес: от конфигурирането на политиките за заключване през Group Policy, през диагностиката с Event Viewer и PowerShell, до работата в хибридна среда с Microsoft Entra ID. Включили сме конкретни команди, скриптове и практически съвети, които можете да приложите веднага.

Какво представлява заключването на акаунти в Active Directory

Идеята е проста. Когато потребител въведе грешна парола определен брой пъти (дефиниран от администратора), Active Directory автоматично заключва акаунта. Това е защитен механизъм срещу brute-force атаки — но честно казано, създава и доста главоболия за Helpdesk екипите.

При заключване на акаунт, домейн контролерът записва Event ID 4740 в Security лога. Този Event ID е ключът към цялата диагностика — той съдържа информация за потребителя, времето на заключването и най-важното — компютъра-източник (Caller Computer Name), от който са дошли неуспешните опити за вход. Запомнете този номер, ще го споменаваме често.

Ключови Event ID-та за заключване

• Event ID 4740 — акаунтът е заключен (записва се на домейн контролера)
• Event ID 4625 — неуспешен опит за вход (записва се на компютъра-източник)
• Event ID 4771 — неуспешна Kerberos предварителна автентикация
• Event ID 4776 — опит за NTLM валидация на идентификационни данни

Конфигуриране на политиката за заключване чрез Group Policy (GPO)

Преди да можете ефективно да диагностицирате заключвания, трябва да имате правилно конфигурирана политика. Хайде да видим как се прави.

Стъпка 1: Отворете Group Policy Management

На домейн контролера отворете Server Manager → Tools → Group Policy Management. Разгънете дървото на домейна и намерете Default Domain Policy (или създайте нов GPO, ако предпочитате — някои администратори предпочитат отделен GPO за по-добра организация).

Стъпка 2: Навигирайте до Account Lockout Policy

Щракнете с десен бутон върху GPO → Edit. Отидете на:

Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Account Lockout Policy

Стъпка 3: Конфигурирайте трите основни настройки

В Windows Server 2025 (и по-старите версии) има три основни настройки за заключване на акаунти:

• Account lockout threshold — брой неуспешни опити за вход преди заключване. Препоръчителна стойност по Microsoft Security Compliance Toolkit: 10
• Account lockout duration — колко минути акаунтът остава заключен. Препоръчителна стойност: 30 минути. Ако зададете 0, акаунтът ще се отключи само ръчно (което не е чудесна идея, освен ако нямате много конкретна причина за това)
• Reset account lockout counter after — след колко минути броячът на грешни пароли се нулира. Препоръчителна стойност: 30 минути

Нещо ново в Windows Server 2025 — има и четвърта настройка: Allow administrator account lockout, която е активирана по подразбиране. Да, правилно четете — дори вграденият Administrator акаунт вече може да бъде заключен. Това е добра промяна от гледна точка на сигурността.

Стъпка 4: Приложете политиката

Затворете редактора и изпълнете следната команда на целевите машини, за да приложите незабавно новата политика:

gpupdate /force

За да проверите дали политиката е приложена успешно:

gpresult /h C:\GPReport.html
start C:\GPReport.html

Активиране на одитиране за проследяване на заключвания

Ето нещо, което много администратори пропускат — по подразбиране одитирането на заключвания не е активирано в Active Directory. Без него няма да видите Event ID 4740 в логовете. Изобщо. Нула резултати.

Така че нека го включим.

Чрез Group Policy

Отворете GPO за домейн контролерите (Default Domain Controllers Policy) и навигирайте до:

Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies → Account Management

Активирайте Audit User Account Management за Success и Failure.

Допълнително, за да проследявате неуспешните влизания (Event ID 4625), активирайте:

Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Audit Policies → Logon/Logoff → Audit Logon

Отново задайте Success и Failure. По-добре повече логове, отколкото по-малко — вярвайте ми по този въпрос.

Стъпка по стъпка: как да откриете източника на заключването

Добре, получили сте тикет: „Акаунтът ми пак се заключи!" Ето какво правите.

Стъпка 1: Идентифицирайте PDC Emulator

Всички заключвания на акаунти в Active Directory се обработват от домейн контролера с ролята PDC Emulator. Затова първо трябва да разберете кой е той:

# PowerShell — намиране на PDC Emulator
Get-ADDomainController -Filter * | Where-Object {
    $_.OperationMasterRoles -contains "PDCEmulator"
} | Select-Object HostName, IPv4Address, OperationMasterRoles

Стъпка 2: Проверете статуса на заключения акаунт

# Проверка дали акаунтът е заключен
Get-ADUser -Identity "потребител" -Properties LockedOut, AccountLockoutTime, BadLogonCount, LastBadPasswordAttempt |
    Select-Object Name, LockedOut, AccountLockoutTime, BadLogonCount, LastBadPasswordAttempt

Тук обръщайте внимание на BadLogonCount и LastBadPasswordAttempt — те ще ви дадат първата представа дали заключването е отскоро или е от по-рано.

Стъпка 3: Потърсете Event ID 4740 на PDC Emulator

Това е най-важната стъпка — тук ще намерите компютъра-източник на заключването:

# Търсене на Event ID 4740 за конкретен потребител
$PDC = (Get-ADDomainController -Filter * |
    Where-Object {$_.OperationMasterRoles -contains "PDCEmulator"}).HostName

$UserName = "потребител"

Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4740
    StartTime = (Get-Date).AddDays(-1)
} | Where-Object {
    $_.Properties[0].Value -eq $UserName
} | ForEach-Object {
    [PSCustomObject]@{
        Потребител      = $_.Properties[0].Value
        КомпютърИзточник = $_.Properties[1].Value
        Време           = $_.TimeCreated
        ДомейнКонтролер = $_.MachineName
    }
} | Format-Table -AutoSize

Стъпка 4: Анализирайте Event ID 4625 на компютъра-източник

След като разберете кой компютър генерира заключването, свържете се с него и потърсете Event ID 4625:

# На компютъра-източник: търсене на неуспешни влизания
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddHours(-2)
} | Select-Object TimeCreated,
    @{N='Акаунт'; E={$_.Properties[5].Value}},
    @{N='ТипВлизане'; E={$_.Properties[8].Value}},
    @{N='Процес'; E={$_.Properties[18].Value}},
    @{N='IPАдрес'; E={$_.Properties[19].Value}} |
    Format-Table -AutoSize

Обърнете внимание на полето Процес (Process Name) — то показва коя програма или услуга генерира неуспешните опити. А полето Тип влизане (Logon Type) ви казва какъв тип връзка е използвана:

• Тип 2 — интерактивно влизане (от клавиатурата)
• Тип 3 — мрежово влизане (споделена папка, принтер)
• Тип 7 — отключване на екрана
• Тип 10 — отдалечено влизане (RDP)

Тип 3 и Тип 10 са най-интересните за диагностика — обикновено там се крие проблемът.

Стъпка 5: Отключете акаунта

# Отключване на конкретен акаунт
Unlock-ADAccount -Identity "потребител"

# Проверка след отключване
Get-ADUser -Identity "потребител" -Properties LockedOut |
    Select-Object Name, LockedOut

Пълен PowerShell скрипт за диагностика на заключвания

Ето готов скрипт, който обединява всички стъпки от по-горе — можете да го запазите като Find-LockoutSource.ps1 и да го използвате ежедневно. От личен опит мога да кажа, че този скрипт спестява поне 10-15 минути на всеки тикет за заключен акаунт.

Import-Module ActiveDirectory

# Въведете потребителското име
$UserName = Read-Host "Въведете потребителско име"

# Намерете PDC Emulator
$PDC = (Get-ADDomainController -Filter * |
    Where-Object {$_.OperationMasterRoles -contains "PDCEmulator"})

Write-Host "`nPDC Emulator: $($PDC.HostName)" -ForegroundColor Cyan

# Проверете статуса на акаунта
$UserInfo = Get-ADUser -Identity $UserName -Properties LockedOut,
    AccountLockoutTime, BadLogonCount, LastBadPasswordAttempt

Write-Host "`n--- Статус на акаунта ---" -ForegroundColor Yellow
Write-Host "Заключен: $($UserInfo.LockedOut)"
Write-Host "Време на заключване: $($UserInfo.AccountLockoutTime)"
Write-Host "Брой грешни пароли: $($UserInfo.BadLogonCount)"
Write-Host "Последен грешен опит: $($UserInfo.LastBadPasswordAttempt)"

# Търсене на Event ID 4740
Write-Host "`n--- Събития за заключване (последните 24 часа) ---" -ForegroundColor Yellow

$Events = Get-WinEvent -ComputerName $PDC.HostName -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4740
    StartTime = (Get-Date).AddDays(-1)
} -ErrorAction SilentlyContinue | Where-Object {
    $_.Properties[0].Value -eq $UserName
}

if ($Events) {
    $Events | ForEach-Object {
        [PSCustomObject]@{
            Време              = $_.TimeCreated
            КомпютърИзточник   = $_.Properties[1].Value
            ДомейнКонтролер    = $_.MachineName
        }
    } | Format-Table -AutoSize
} else {
    Write-Host "Няма намерени събития за заключване в последните 24 часа." -ForegroundColor Green
}

# Опция за отключване
if ($UserInfo.LockedOut) {
    $Confirm = Read-Host "`nЖелаете ли да отключите акаунта? (да/не)"
    if ($Confirm -eq "да") {
        Unlock-ADAccount -Identity $UserName
        Write-Host "Акаунтът е отключен успешно." -ForegroundColor Green
    }
}

Най-честите причини за заключване на акаунти

Добре, намерихте компютъра-източник. Но какво точно генерира неуспешните опити? По моя опит, виновникът обикновено е някоя от следните неща.

1. Кеширани идентификационни данни

Това е причина номер едно, без съмнение. Когато потребителят смени паролата си, старата парола може да остане записана в:

• Windows Credential Manager — проверете чрез Control Panel → Credential Manager
• Планирани задачи (Scheduled Tasks) — задачи, конфигурирани да се изпълняват с потребителски акаунт
• Услуги (Services) — услуги, стартирани с потребителски акаунт вместо системен
• Свързани мрежови устройства (Mapped Drives) — трайно свързани дискове с вградени идентификационни данни

# Проверка на Credential Manager за записани идентификационни данни
cmdkey /list

# Проверка на планирани задачи с потребителски акаунт
Get-ScheduledTask | Where-Object {
    $_.Principal.UserId -like "*потребител*"
} | Select-Object TaskName, TaskPath, State

# Проверка на услуги с потребителски акаунт
Get-WmiObject Win32_Service | Where-Object {
    $_.StartName -like "*потребител*"
} | Select-Object Name, StartName, State

2. Мобилни устройства и Outlook

Класика. Ако в полето „Caller Computer Name" на Event ID 4740 виждате името на Exchange сървъра, проблемът почти сигурно е в Outlook или мобилно устройство. Телефони с остарели пароли за Exchange ActiveSync са може би най-досадният източник на заключвания, защото потребителят обикновено дори не осъзнава, че телефонът му опитва да се свърже със стара парола.

# Проверка на ActiveSync устройства за потребител (на Exchange Server)
Get-ActiveSyncDeviceStatistics -Mailbox "потребител" |
    Select-Object DeviceFriendlyName, DeviceType, LastSyncAttemptTime, Status

3. Отдалечени RDP сесии

Забравени RDP сесии с остарели пароли — друг чест виновник. Ако Logon Type в Event ID 4625 е 10, това означава RDP връзка. Попитайте потребителя дали има отворени отдалечени връзки към други сървъри или работни станции.

4. VPN клиенти

VPN клиенти, които автоматично се опитват да се свържат с кеширани идентификационни данни, също причиняват заключвания. Това е особено често при Always On VPN конфигурации. Ако потребителят работи от вкъщи, това е едно от първите неща, които трябва да проверите.

5. Приложения на трети страни

ERP системи, CRM платформи, различни скриптове с вградени пароли — всичко това може да генерира заключвания при смяна на паролата. Не е рядкост да открием стар PowerShell скрипт, който някой е забравил и който продължава да работи с остаряла парола.

Инструменти за диагностика на заключвания

Microsoft Account Lockout and Management Tools (ALTools)

Microsoft предоставя безплатен набор от инструменти, специално създадени за диагностика на заключвания. Въпреки че са малко „стари" като визия, все още вършат чудесна работа:

• LockoutStatus.exe — графичен инструмент, който показва статуса на заключване на всеки домейн контролер поотделно
• EventCombMT.exe — събира Event ID 4740 от множество домейн контролери на едно място
• AcctInfo.dll — добавя допълнителни страници с информация за заключване в Active Directory Users and Computers
• ALockout.dll — проследява процеси на клиентски машини, които изпращат грешни идентификационни данни

Важно: Не използвайте ALockout.dll на сървъри с Exchange Server — може да попречи на стартирането на Exchange Store. Попадал съм на тази ситуация и не е приятна.

Използване на LockoutStatus.exe

1. Изтеглете инструмента от Microsoft Download Center
2. Стартирайте LockoutStatus.exe
3. Изберете File → Select Target
4. Въведете потребителското име (sAMAccountName) и името на домейна
5. Прегледайте резултатите — ще видите Lockout Time, Last Bad Pwd и Orig Lock за всеки домейн контролер

Хибридна среда: Active Directory + Microsoft Entra ID

Ако вашата организация използва хибридна идентичност с Microsoft Entra ID (бившият Azure AD), нещата стават малко по-сложни. Трябва да съобразите политиките за заключване между двете среди, иначе рискувате непредвидено поведение.

Microsoft Entra Smart Lockout

Entra ID има собствен механизъм за заключване — Smart Lockout. Хубавото при него е, че разпознава влизания от познати местоположения и прилага различни прагове за познати и непознати IP адреси.

Ключовото правило за хибридни среди (запомнете го):

• Задайте прага за заключване в AD DS по-висок от прага в Entra ID (например AD DS = 10-15, Entra ID = 5)
• Задайте продължителността на заключване в Entra ID по-дълга от тази в AD DS
• Така Entra ID ще блокира атаките преди да достигнат до локалния Active Directory

SyncJacking защита (ново за 2026)

Това е интересна промяна. От юни 2026 г. Microsoft Entra ID ще блокира опити за hard-match на нов потребителски обект от Active Directory към съществуващ облачен потребител с привилегировани роли. На практика, тази защита предотвратява SyncJacking атаки — опити за превземане на привилегировани облачни акаунти чрез манипулиране на атрибути в локалния AD.

Акаунти без привилегировани роли не са засегнати, така че не се притеснявайте за обикновените потребители.

Windows Server 2025: нови функции за Active Directory

Windows Server 2025 донесе значителни подобрения за Active Directory, включително ново функционално ниво — първото от времето на Windows Server 2016 (да, мина доста време):

• Allow administrator account lockout — ново GPO настройка, активирана по подразбиране, която позволява заключване на вградения Administrator акаунт
• Премахване на лимита от 64 CPU ядра — подобрена NUMA поддръжка за мащабни AD среди
• Увеличен размер на страницата на базата данни — от 8 KB на 32 KB, което подобрява производителността при множество многостойностни атрибути
• Replication Priority Boost — нова функция за приоритизиране на репликацията
• Fine-Grained Password Policies (PSO) — позволяват различни настройки за заключване на различни групи потребители, вместо единна политика за целия домейн

Конфигуриране на Fine-Grained Password Policy

Ако имате различни изисквания за различни отдели (например IT екипът трябва да има по-висок праг за заключване от стандартните потребители), използвайте Password Settings Objects (PSO). Ето как:

# Създаване на Fine-Grained Password Policy за IT отдела
New-ADFineGrainedPasswordPolicy -Name "IT-Lockout-Policy" `
    -Precedence 10 `
    -LockoutThreshold 15 `
    -LockoutDuration "00:15:00" `
    -LockoutObservationWindow "00:15:00" `
    -ComplexityEnabled $true `
    -MinPasswordLength 12

# Прилагане на политиката към група
Add-ADFineGrainedPasswordPolicySubject -Identity "IT-Lockout-Policy" `
    -Subjects "IT-Department"

# Проверка на ефективната политика за потребител
Get-ADUserResultantPasswordPolicy -Identity "потребител"

Най-добри практики за управление на заключвания

Преди да приключим, ето няколко съвета, които ще ви спестят много време и нерви:

• Активирайте одитиране от първия ден — сериозно, не чакайте да се случи проблем, за да откриете, че нямате логове. Това е грешка, която се прави само веднъж
• Създайте стандартна процедура — документирайте стъпките за диагностика, за да може всеки член на Helpdesk екипа да ги следва (скриптът по-горе е добро начало)
• Обучете потребителите — научете ги да актуализират паролите си навсякъде след смяна: мобилни устройства, VPN, свързани дискове. Кратък имейл с инструкции при смяна на парола прави чудеса
• Мониторинг в реално време — настройте известия при Event ID 4740, за да научавате за заключвания преди потребителят да ви се обади
• Избягвайте твърде нисък праг — стойност от 3 неуспешни опита е прекалено ниска и ще генерира излишни тикети. Microsoft препоръчва 10, и по моя опит, това е разумна стойност
• Използвайте Fine-Grained Policies — различните отдели наистина имат различни нужди
• Редовно преглеждайте услугите — проверявайте кои услуги и задачи използват потребителски акаунти и ги мигрирайте към Managed Service Accounts (gMSA) когато е възможно

Често задавани въпроси (FAQ)

Как да разбера кой компютър заключва акаунта в Active Directory?

Търсете Event ID 4740 в Security лога на PDC Emulator домейн контролера. В полето „Caller Computer Name" ще видите компютъра, от който са дошли неуспешните опити за вход. Използвайте PowerShell командата Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740} за бързо търсене.

Защо акаунтът ми се заключва отново веднага след отключване?

Най-вероятната причина е кеширани стари идентификационни данни — в Credential Manager, планирани задачи, услуги, мобилни устройства или VPN клиенти. Преди да отключите акаунта, идентифицирайте и премахнете старите пароли от всички тези местоположения. В противен случай ще отключвате същия акаунт отново след 5 минути.

Каква е препоръчителната стойност за Account Lockout Threshold?

Microsoft Security Compliance Toolkit препоръчва 10 неуспешни опита. Стойност под 5 ще генерира много фалшиви заключвания, докато стойност над 20 намалява защитата срещу brute-force атаки. За хибридни среди задайте AD DS прага по-висок от прага в Entra ID.

Как да настроя различни политики за заключване за различни групи потребители?

Използвайте Fine-Grained Password Policies (PSO) — те позволяват да зададете различни прагове и продължителности на заключване за различни групи. Създайте PSO с New-ADFineGrainedPasswordPolicy и я приложете към група с Add-ADFineGrainedPasswordPolicySubject.

Работи ли Active Directory политиката за заключване заедно с Microsoft Entra ID Smart Lockout?

Да, но трябва да ги координирате. Задайте прага в AD DS по-висок от Entra ID (например 10-15 в AD, 5 в Entra ID) и продължителността в Entra ID по-дълга от AD. Така Entra ID ще блокира атаките преди да достигнат до локалния Active Directory.