AD Hesap Kilitleme Çözüm Rehberi (2026)

Neden Kullanıcı Hesapları Sürekli Kilitleniyor?

Helpdesk'te çalışıyorsanız bu sahneyi kesinlikle biliyorsunuzdur: kullanıcı arar, "hesabım kilitlendi" der, siz parolayı sıfırlarsınız, kilidi açarsınız ve tam "tamam hallettik" diyecekken — beş dakika sonra aynı kişi yeniden arar. Deja vu gibi.

Hesap kilitleme mekanizması aslında güzel bir şey; brute-force saldırılarına karşı koruma sağlıyor. Ama işler karışınca (eski önbelleğe alınmış parolalar, unutulmuş servis hesapları, arka planda çalışan uygulamalar) masum kullanıcılar da bu tuzağa düşüyor.

Bu rehberde kilitlemenin gerçek kaynağını bulup sorunu kalıcı olarak çözmenin yollarını PowerShell komutlarıyla birlikte adım adım göstereceğim. Hadi başlayalım.

Hesap Kilitlemenin En Yaygın Nedenleri

Sorunu çözmek için önce nedenini anlamak şart. Yıllardır gördüğüm en yaygın senaryolar şunlar:

Önbelleğe alınmış eski kimlik bilgileri: Kullanıcı parolasını değiştirmiş ama eski parola hâlâ Windows Credential Manager'da, tarayıcıda veya bir uygulamada kayıtlı. Her kimlik doğrulama denemesinde eski parola gönderilir ve hesap kilitlenir. Bu muhtemelen en sık karşılaştığım neden.
Servis hesapları: Windows servisleri veya zamanlanmış görevler, parolası değiştirilmiş bir hesapla çalışıyorsa her tetiklendiğinde başarısız deneme üretir. Özellikle büyük ortamlarda bu tür durumları takip etmek gerçekten zor olabiliyor.
Bağlantısı kesilmemiş RDP/Terminal oturumları: Parola değişikliğinden sonra eski bir Remote Desktop oturumu hâlâ açıksa, o oturum eski kimlik bilgileriyle bağlanmaya çalışır.
Mobil cihazlar ve Exchange ActiveSync: Kurumsal e-posta yapılandırılmış telefonlar, eski parolayla sürekli Exchange sunucusuna bağlanmaya çalışır. Kullanıcılar genellikle telefonlarındaki parola ayarını güncellemeyi unutuyor.
Drive mapping (sürücü eşleme): Ağ sürücüleri eski kimlik bilgileriyle eşlenmişse, her oturum açılışında başarısız deneme üretir.
AD çoğaltma (replication) gecikmeleri: Parola değişikliği henüz tüm Domain Controller'lara çoğaltılmamışsa, kullanıcı farklı bir DC üzerinden doğrulanırken kilitlenebilir.
Kötü niyetli aktivite: Password spraying veya brute-force saldırıları da hesap kilitlenmesine yol açar. Bu durumda güvenlik ekibini bilgilendirmek şart — bunu atlamamak lazım.

Hesap Kilitleme Politikası Nasıl Çalışır?

Active Directory'deki hesap kilitleme politikası Group Policy Management Editor üzerinden yapılandırılır. Temelde üç ayar var:

Account Lockout Threshold (Hesap Kilitleme Eşiği): Hesabın kilitlenmesi için gereken başarısız deneme sayısı. Microsoft'un güvenlik temelleri bu değeri 10 olarak öneriyor.
Account Lockout Duration (Hesap Kilitleme Süresi): Hesabın otomatik olarak açılması için beklenen süre (dakika cinsinden). 0 yaparsanız sadece yönetici açabilir — ki bu çoğu ortamda pek pratik değil.
Reset Account Lockout Counter After (Sayacı Sıfırlama Süresi): Başarısız deneme sayacının sıfırlanma süresi. Bu değer kilitleme süresinden küçük veya eşit olmalı.

Bu ayarlara şu yoldan ulaşabilirsiniz:

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

Mevcut politika ayarlarınızı PowerShell ile hızlıca görmek isterseniz:

Get-ADDefaultDomainPasswordPolicy | Select-Object LockoutDuration, LockoutObservationWindow, LockoutThreshold | Format-List

Denetim Politikasını Etkinleştirme (Audit Policy)

Kilitleme olaylarını izleyebilmeniz için denetim politikasının doğru yapılandırılmış olması lazım. Varsayılan ayarlarda hesap kilitleme olayları günlüğe kaydedilmeyebilir — bu da sizi kör bırakır.

Group Policy ile Denetim Etkinleştirme

Şu yolu izleyerek ilgili denetim politikalarını açın:

Computer Configuration → Windows Settings → Security Settings
  → Advanced Audit Policy Configuration → Audit Policies
    → Account Management → Audit User Account Management: Success, Failure
    → Logon/Logoff → Audit Account Lockout: Success, Failure

Kerberos kaynaklı kilitlemeleri de yakalamak için bu politikayı da etkinleştirin:

Account Logon → Audit Kerberos Authentication Service: Success, Failure

Değişikliği hemen uygulamak için:

gpupdate /force

Kritik Olay Kimlikleri (Event ID'ler)

Hesap kilitleme sorunlarını araştırırken üç temel Event ID'ye odaklanmanız gerekiyor:

Event ID 4740 — A user account was locked out: Ana olay budur. Domain Controller'ın Security günlüğüne yazılır ve PDC Emulator'a kopyalanır. Caller Computer Name alanı, kilitlemenin hangi bilgisayardan geldiğini gösterir. Bu alan altın değerinde.
Event ID 4771 — Kerberos pre-authentication failed: Kerberos ön kimlik doğrulamasının başarısız olduğunu bildirir. 4740 bulunamazsa alternatif kaynak olarak kullanabilirsiniz. Kaynak bilgisayarın IP adresini içerir.
Event ID 4625 — An account failed to log on: İstemci bilgisayarlarda oluşan başarısız oturum açma olayı. Failure Reason alanı nedenin detayını verir.

PowerShell ile Kilitleme Kaynağını Tespit Etme

Şimdi en kritik adıma geçiyoruz: kilitlemenin nereden geldiğini bulmak. Dürüst olmak gerekirse, PowerShell bu iş için vazgeçilmez.

Adım 1: Kilitli Hesapları Listeleme

Önce hangi hesapların kilitli olduğuna bakalım:

# Tüm kilitli hesapları listele
Search-ADAccount -LockedOut -UsersOnly | Select-Object Name, SamAccountName, LockedOut, LastLogonDate | Format-Table -AutoSize

# Belirli bir kullanıcıyı kontrol et
Get-ADUser -Identity "kullanici.adi" -Properties LockedOut, AccountLockoutTime, BadLogonCount, BadPwdCount, LastBadPasswordAttempt |
  Select-Object Name, LockedOut, AccountLockoutTime, BadLogonCount, LastBadPasswordAttempt

Adım 2: PDC Emulator Üzerinde Event 4740 Sorgulama

Event 4740 olayları PDC Emulator'da merkezi olarak toplanır. Şu komutla PDC'yi bulup sorgulayabilirsiniz:

# PDC Emulator'ı bul
$PDC = (Get-ADDomain).PDCEmulator

# Son 24 saatteki tüm kilitleme olaylarını getir
$BaslangicTarihi = (Get-Date).AddDays(-1)
Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName   = 'Security'
    ID        = 4740
    StartTime = $BaslangicTarihi
} | Select-Object TimeCreated,
    @{N='KullaniciAdi'; E={$_.Properties[0].Value}},
    @{N='KaynakBilgisayar'; E={$_.Properties[1].Value}} |
  Format-Table -AutoSize

Küçük bir performans notu: -FilterHashtable parametresi, Where-Object ile filtrelemeye kıyasla inanılmaz derecede hızlı. Kendi testlerimde Where-Object ile 13 dakika süren sorgu, -FilterHashtable ile yarım saniyede bitti. Ciddi bir fark.

Adım 3: Belirli Bir Kullanıcı İçin Kilitleme Kaynağını Bulma

Belirli bir kullanıcıyı araştırıyorsanız şu komut detaylı bir rapor çıkarır:

# Kullanıcı adını belirleyin
$KullaniciAdi = "ahmet.yilmaz"

# PDC Emulator'ı bul
$PDC = (Get-ADDomainController -Filter * |
  Where-Object {$_.OperationMasterRoles -contains "PDCEmulator"}).HostName

# Kullanıcı bilgisini al
$Kullanici = Get-ADUser -Identity $KullaniciAdi

# Kilitleme olaylarını sorgula ve filtrele
Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName = 'Security'
    ID      = 4740
} -ErrorAction SilentlyContinue |
  Where-Object {$_.Properties[2].Value -match $Kullanici.SID.Value} |
  Select-Object @{N='Zaman';         E={$_.TimeCreated}},
                @{N='KullaniciAdi';   E={$_.Properties[0].Value}},
                @{N='KaynakCihaz';    E={$_.Properties[1].Value}},
                @{N='DomainController';E={$_.MachineName}} |
  Sort-Object Zaman -Descending |
  Format-Table -AutoSize

Adım 4: Event 4771 ile IP Adresi Tespiti

Bazen 4740 olayında kaynak bilgisayar adı boş gelir. Bu sinir bozucu bir durum ama çözümü var: Event 4771'i sorgulayarak kaynak IP adresine ulaşabilirsiniz.

# Kerberos ön kimlik doğrulama hatalarını sorgula
Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName   = 'Security'
    ID        = 4771
    StartTime = (Get-Date).AddHours(-4)
} | ForEach-Object {
    $xml = [xml]$_.ToXml()
    [PSCustomObject]@{
        Zaman      = $_.TimeCreated
        Kullanici  = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'TargetUserName'}).'#text'
        KaynakIP   = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'IpAddress'}).'#text'
        HataKodu   = ($xml.Event.EventData.Data | Where-Object {$_.Name -eq 'Status'}).'#text'
    }
} | Where-Object {$_.Kullanici -eq $KullaniciAdi} |
  Format-Table -AutoSize

Adım 5: Hesap Kilidini PowerShell ile Açma

Kaynağı bulduktan sonra kilidi açmak kolay kısım:

# Tek bir hesabın kilidini aç
Unlock-ADAccount -Identity "ahmet.yilmaz"

# Tüm kilitli hesapların kilidini toplu olarak aç (dikkatli kullanın!)
Search-ADAccount -LockedOut -UsersOnly | Unlock-ADAccount

# Kilitleme durumunu doğrula
Get-ADUser -Identity "ahmet.yilmaz" -Properties LockedOut | Select-Object Name, LockedOut

Kaynak Türüne Göre Çözüm Stratejileri

Kilitleme kaynağını buldunuz, güzel. Şimdi kaynağa göre doğru çözümü uygulamak gerekiyor.

Kaynak: İstemci Bilgisayar

İlgili bilgisayarda Credential Manager'ı açın (rundll32.exe keymgr.dll, KRShowKeyMgr veya Denetim Masası → Kimlik Bilgileri Yöneticisi).
Eski domain kimlik bilgilerini silin.
Tarayıcılarda ve uygulamalarda kayıtlı eski parolaları temizleyin.
Eşlenmiş ağ sürücülerini kontrol edip gerekirse yeniden bağlayın.

Kaynak: Exchange Sunucusu

Caller Computer Name alanında Exchange sunucusu görüyorsanız, sorun büyük ihtimalle Outlook veya mobil cihazlardan kaynaklanıyordur:

Exchange sunucusundaki IIS günlüklerini inceleyin.
Mobil cihaz bilgilerini PowerShell ile kontrol edin:

# Kullanıcının ActiveSync cihazlarını listele
Get-MobileDeviceStatistics -Mailbox "ahmet.yilmaz" |
  Select-Object DeviceFriendlyName, DeviceOS, LastSuccessSync, LastSyncAttemptTime |
  Format-Table -AutoSize

Kaynak: Servis Hesabı veya Zamanlanmış Görev

Bu durum özellikle sunucu ortamlarında yaygın:

Sunucuda services.msc açarak ilgili kullanıcı hesabıyla çalışan servisleri bulun.
Görev Zamanlayıcısı'nda (Task Scheduler) aynı hesapla yapılandırılmış görevleri kontrol edin.
Servis hesaplarının parolalarını güncelleyin veya (daha da iyisi) Group Managed Service Account (gMSA) kullanımına geçin.

Kaynak: RDP/Terminal Oturumu

Açık kalmış uzak masaüstü oturumlarını tespit edin:

# Sunucu üzerinde aktif oturumları listele
quser /server:SunucuAdi

Eski oturumları kapatın ve kullanıcının yeni parolayla oturum açmasını sağlayın.

Fine-Grained Password Policies (FGPP) ile Esnek Kilitleme

Varsayılan domain politikası herkese aynı kuralları uygular. Ama gerçek hayatta farklı gruplar için farklı eşikler gerekebilir — mesela yönetici hesapları için daha düşük, servis hesapları için daha yüksek bir eşik mantıklı olabilir.

Fine-Grained Password Policies (FGPP) tam da bu esnekliği sağlıyor:

Active Directory Administrative Center (ADAC) açın.
Domain → System → Password Settings Container yolunu izleyin.
Yeni bir Password Settings Object (PSO) oluşturun.
Kilitleme eşiği, süresi ve sayaç sıfırlama değerlerini belirleyin.
Politikayı ilgili kullanıcı veya güvenlik grubuna atayın.

Mevcut FGPP'leri görmek için:

Get-ADFineGrainedPasswordPolicy -Filter * |
  Select-Object Name, Precedence, LockoutThreshold, LockoutDuration, LockoutObservationWindow |
  Format-Table -AutoSize

Hibrit Ortamlarda Microsoft Entra ID Smart Lockout

Eğer kuruluşunuz Microsoft Entra ID (eski adıyla Azure AD) ile hibrit yapı kullanıyorsa, Smart Lockout özelliğini doğru yapılandırmak çok önemli. Bunu atlarsanız, bulut ve şirket içi kilitleme politikaları birbirleriyle çelişebilir.

Smart Lockout Nedir?

Smart Lockout tüm Microsoft Entra müşterileri için varsayılan olarak aktif. Bulut tarafında brute-force ve password spray saldırılarına karşı koruma sağlıyor. Varsayılan eşik Azure Public kiracılar için 10, Azure US Government için 3 başarısız deneme.

Hibrit Yapı İçin Kritik Kurallar

Pass-through authentication veya password hash sync kullanan ortamlarda şu noktalara dikkat edin:

Microsoft Entra kilitleme eşiği, şirket içi AD DS eşiğinden düşük olmalı. AD DS eşiğini Entra eşiğinin en az 2–3 katı yapın.
Microsoft Entra kilitleme süresi, şirket içi AD DS süresinden uzun olmalı. Entra süresi saniye, AD DS süresi dakika cinsinden — buna dikkat.

Örnek yapılandırma: Entra eşiği 10 ise → AD DS eşiği 20 veya 30 olsun. Entra süresi 120 saniye ise → AD DS süresi 1 dakika (60 saniye).

Smart Lockout ayarları için: Microsoft Entra admin center → Authentication methods → Password protection yolunu izleyin. Bu özelleştirme Microsoft Entra ID P1 veya üzeri lisans gerektirir.

Otomasyon: Kilitleme Bildirimi PowerShell Script'i

Hesap kilitlenmelerinden anında haberdar olmak ister misiniz? Aşağıdaki PowerShell betiğini zamanlanmış görev olarak çalıştırarak bunu otomatize edebilirsiniz. Bence her BT ekibinin bu tür bir otomasyon kurması gerekiyor.

# Kilitleme bildirimi scripti
$PDC = (Get-ADDomain).PDCEmulator
$SonKontrol = (Get-Date).AddMinutes(-15)

$KilitlemeOlaylari = Get-WinEvent -ComputerName $PDC -FilterHashtable @{
    LogName   = 'Security'
    ID        = 4740
    StartTime = $SonKontrol
} -ErrorAction SilentlyContinue

if ($KilitlemeOlaylari) {
    $Rapor = $KilitlemeOlaylari | ForEach-Object {
        [PSCustomObject]@{
            Zaman    = $_.TimeCreated
            Kullanici = $_.Properties[0].Value
            Kaynak   = $_.Properties[1].Value
        }
    } | ConvertTo-Html -Title "Hesap Kilitleme Raporu" -Head "<style>table{border-collapse:collapse}td,th{border:1px solid #ccc;padding:8px}</style>"

    Send-MailMessage -From "[email protected]" `
        -To "[email protected]" `
        -Subject "AD Hesap Kilitleme Uyarisi - $(Get-Date -Format 'dd.MM.yyyy HH:mm')" `
        -Body ($Rapor | Out-String) `
        -BodyAsHtml `
        -SmtpServer "mail.sirket.com"
}

Bu betiği Task Scheduler ile her 15 dakikada bir çalıştırın. Kilitleme olaylarını neredeyse gerçek zamanlı takip etmiş olursunuz.

Microsoft Resmi Araçları

PowerShell dışında Microsoft'un sunduğu bazı kullanışlı araçlar da var:

LockoutStatus.exe: Her Domain Controller üzerinde hesabın kilitleme durumunu ve zamanını gösteren grafik arayüzlü bir araç. Microsoft İndirme Merkezi'nden indirebilirsiniz. Hesap üzerine sağ tıklayarak doğrudan kilidi açabiliyorsunuz — pratik bir özellik.
Account Lockout and Management Tools (AlTools.exe): LockoutStatus, EventCombMT ve diğer yardımcı araçları bir arada sunan kapsamlı bir paket.
Microsoft Support and Recovery Assistant (SaRA): Office 365 ve Exchange ile ilgili kilitleme sorunlarını otomatik teşhis edebilen araç.

Kontrol Listesi: Hesap Kilitleme Sorun Giderme Adımları

Bir hesap kilitleme talebi geldiğinde şu adımları sırayla izleyin (bu listeyi bir yere kaydetmenizi tavsiye ederim):

Hesabın gerçekten kilitli olduğunu doğrulayın: Get-ADUser -Identity kullanici -Properties LockedOut
Event 4740 olaylarını PDC Emulator üzerinde sorgulayın.
Caller Computer Name alanından kaynak bilgisayarı tespit edin.
Kaynak bilgisayarda Credential Manager'ı temizleyin.
Servis hesapları ve zamanlanmış görevleri kontrol edin.
Mobil cihazlar ve Exchange bağlantılarını gözden geçirin.
Eski RDP/Terminal oturumlarını kapatın.
Hesabın kilidini açın: Unlock-ADAccount -Identity kullanici
Sorunu dokümante edin ve tekrarını önlemek için gerekli aksiyonları alın.

Sık Sorulan Sorular (SSS)

Active Directory'de hesap neden kendi kendine kilitleniyor?

En yaygın neden, kullanıcının parolasını değiştirdikten sonra eski parolanın hâlâ bir yerde kayıtlı olması. Credential Manager, tarayıcı, mobil cihaz, eşlenmiş ağ sürücüsü veya servis hesabı — hepsi suçlu olabilir. Her başarısız kimlik doğrulama denemesi sayacı artırır ve eşik aşıldığında hesap kilitlenir. Kilitleme kaynağını bulmak için Event ID 4740'ı PowerShell ile sorgulayın.

Hesap kilitleme kaynağı (source) nasıl bulunur?

PDC Emulator üzerinde Event ID 4740'ı sorgulayın. Bu olayın Caller Computer Name alanı, kilitlemenin hangi cihazdan geldiğini gösterir. PowerShell ile Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4740} komutunu kullanabilir veya Microsoft'un LockoutStatus.exe aracını tercih edebilirsiniz.

PowerShell ile kilitli hesaplar nasıl toplu olarak açılır?

Search-ADAccount -LockedOut -UsersOnly | Unlock-ADAccount komutuyla tüm kilitli hesapları açabilirsiniz. Ama dikkat — önce kilitleme nedenini araştırmadan toplu açmak sorunu çözmez, sadece erteler. Kaynak bulunmadan kilidi açarsanız beş dakika içinde aynı yere dönersiniz.

Hesap kilitleme eşiği kaç olmalıdır?

Microsoft'un güvenlik temelleri 10 başarısız deneme eşiği öneriyor. Daha düşük eşik daha güvenli ama daha fazla helpdesk talebi demek. Daha yüksek eşik kullanıcı deneyimini iyileştirir ama saldırılara daha fazla pencere tanır. Kuruluşunuzun risk profiline göre 5–15 arası bir değer belirleyin.

Microsoft Entra ID Smart Lockout ile şirket içi AD kilitleme politikası nasıl uyumlu hâle getirilir?

Hibrit ortamlarda Entra ID kilitleme eşiğini, şirket içi AD DS eşiğinin yarısından az olacak şekilde ayarlayın. Örnek olarak, AD DS eşiği 20 ise Entra eşiğini 10 yapın. Entra kilitleme süresini ise AD DS süresinden uzun tutun. Bu sayede bulut tarafındaki saldırılar şirket içi AD'ye ulaşmadan filtrelenir.