Parola politikası ve FGPP: Password change, reset, history ve lockout farkları.

1. Core Mechanism / Temel mekanizma

Parola change ve reset işlemleri farklı yetkilerle yürür. AD'de kendi parolasını değiştiren kullanıcı mevcut parolasını sunmalı ve kendi nesnesi üzerinde User-Change-Password hakkına sahip olmalıdır. Varsayılan ACL bu hakkı çoğunlukla sağladığı için görünür bir ek adım olmayabilir; bu, izin kontrolü yapılmadığı anlamına gelmez. Reset mevcut parolayı istemez; çağıran hedef nesnede User-Force-Change-Password (Reset Password) hakkına ihtiyaç duyar. Politika tarafında ise iki katman vardır: her domain'de tek olan Default Domain Password Policy (Group Policy'de tanımlı: uzunluk, history, min/max age, complexity, lockout) ve bunu belirli kullanıcı/gruplar için ezebilen Fine-Grained Password Policy — bir Password Settings Object (PSO, sınıf msDS-PasswordSettings). Bu dersin sınırı change/reset ayrımı, FGPP precedence/resultant ve bunların lockout ile ilişkisidir; hesap durumları (disable/lockout state) 08.01'de, parola karma saklama ayrıntıları başka yerdedir. Kritik ayrım: bir change/reset AUDIT kaydı bir işlemin yapıldığını söyler; bir kullanıcıya HANGİ politikanın uygulandığı ise ayrı bir çıkarımdır ve tek yerden (msDS-ResultantPSO) okunur.

Arabirimler ve belirtimler

• AD password change: mevcut parola ve kullanıcının kendi nesnesinde User-Change-Password hakkı birlikte gerekir. 4723 change girişimini kaydeder; domain hesabında yanlış eski parola hatasını her zaman bu event’in Failure sonucu olarak arama.
• Password reset girişimi: User-Force-Change-Password (Reset Password) control access right, Rights-GUID 00299570-246d-11d0-a768-00aa006e0529 gerekir; başka hesap için reset girişimi 4724 ile denetlenir, netice ayrıca okunur.
• Default Domain Password Policy: domain başına tek; minimum length, password history, min/max age, complexity ve Account Lockout Policy alt bölümünü içerir (Group Policy ile taşınır).
• Fine-Grained Password Policy (PSO, msDS-PasswordSettings): belirli kullanıcı/global grup için domain politikasını ezer; msDS-PasswordSettingsPrecedence, msDS-PSOAppliesTo, msDS-Lockout* alanlarını taşır.
• Resultant policy: önce kullanıcıya doğrudan uygulanan PSO’lar değerlendirilir; yoksa uygun grup PSO’ları ele alınır. Seçilen kümede sayısal msDS-PasswordSettingsPrecedence değeri en düşük olan (önceliği en yüksek) PSO kazanır. Eşitlikte objectGUID tie-break uygulanır; PSO’lar birleştirilmez.
• 4723 ve 4724 benzer Subject/Target alanları kullanır; event-specific alan kümeleri tamamen aynı değildir. Microsoft’un Version 0 örneğinde 4723 PrivilegeList taşır, 4724 örneğinde bu alan bulunmaz. EventID ile sonuç ayrı okunur; domain hesabı için ilgili DC, yerel hesap için ilgili bilgisayar incelenir.

Change ve reset: farklı yetkiler

Change işleminde mevcut parola doğrulanır, fakat bu tek başına yeterli değildir. Kullanıcının kendi AD nesnesinde User-Change-Password hakkı da olmalıdır. Bu hak varsayılan izinlerle verilmiş olabilir; etkin ACL değişikliği engelliyorsa doğru mevcut parola izin eksikliğini aşmaz.

Reset işleminde mevcut parola aranmaz. Çağıran, hedef user nesnesinde User-Force-Change-Password (Reset Password) hakkıyla yeni parola atar. Help desk'in kullanıcı parolasını bilmeden sıfırlama yapabilmesi bu ayrı yetkiye dayanır; change yapabilmek reset yetkisi vermez.

Dolayısıyla ayrım 'bilgi mi, hak mı?' değildir: change için mevcut parola ve Change Password hakkı, reset için Reset Password hakkı gerekir. 4723 change girişimini, 4724 reset girişimini gösterir; başarı veya başarısızlık sonucu ayrıca değerlendirilir. Yeni parola için geçerli politika ve diğer işlem koşulları da sağlanmalıdır.

İki politika katmanı: domain default ve FGPP

Her domain'de tek bir Default Domain Password Policy vardır; minimum uzunluk, password history, minimum/maximum age, complexity ve Account Lockout Policy'yi tanımlar. Bu, tarihsel olarak domain'deki tüm kullanıcılar için tek bir taban çizgisiydi.

Fine-Grained Password Policy (FGPP) bu tekliği kırar: bir Password Settings Object (PSO, msDS-PasswordSettings sınıfı) oluşturup belirli kullanıcı veya global gruplara (msDS-PSOAppliesTo) uygulayarak domain politikasını ezersin. Örneğin ayrıcalıklı bir yönetici grubuna 20 karakter minimum ve daha kısa max age dayatırken, sıradan kullanıcılar domain default'unda kalır.

Önemli sınır: FGPP kullanıcı ve global gruplara uygulanır, OU'lara değil. OU bazlı bir parola politikası istiyorsan bunu bir gruba çevirmen gerekir. Bu, GPO'nun OU'ya link edilme modelinden farklı bir kapsamlama mantığıdır.

Çakışma: precedence ve resultant PSO

Bir kullanıcı birden çok PSO'nun kapsamına girebilir (örneğin hem doğrudan hem bir grup üyeliği üzerinden). Bu durumda politikalar BİRLEŞTİRİLMEZ; tek bir PSO kazanır. Kazananı msDS-PasswordSettingsPrecedence belirler: sayısal olarak en DÜŞÜK precedence değeri en yüksek önceliğe sahiptir.

Kurallar bir eleme sırasıdır: kullanıcıya DOĞRUDAN uygulanan bir PSO varsa o grup PSO'larını ezer. Doğrudan PSO yoksa, uygulanan grup PSO'ları arasında en düşük precedence kazanır. Precedence eşitse, kazanan PSO nesnesinin objectGUID'i (en küçük) bir tie-break olarak kullanılır — bu deterministik ama keyfi bir kuraldır, güvenlik anlamı taşımaz.

Bu çıkarımı elle yapmak yerine sonuç doğrudan okunur: bir kullanıcının msDS-ResultantPSO nitelik değeri, o kullanıcıya fiilen uygulanan tek PSO'yu gösterir. 'Hangi politika geçerli?' sorusunun kesin yanıtı burada durur; onu birden çok PSO'yu zihinde birleştirerek tahmin etmek hatadır.

# Fine-grained password policy (PSO = msDS-PasswordSettings) ornek nitelikleri
# ADAC/PowerShell'de gorunen, msDS-PasswordSettings nesnesinin tasidigi alanlar:
msDS-PasswordSettingsPrecedence      : 10      # dusuk sayi = yuksek oncelik
msDS-PasswordReversibleEncryptionEnabled : FALSE
msDS-PasswordHistoryLength           : 24
msDS-MinimumPasswordLength           : 14
msDS-MinimumPasswordAge              : 1.00:00:00     # 1 gun
msDS-MaximumPasswordAge              : 60.00:00:00    # 60 gun
msDS-LockoutThreshold                : 10
msDS-LockoutObservationWindow        : 0:00:15:00     # 15 dakika
msDS-LockoutDuration                 : 0:00:15:00     # 15 dakika
msDS-PSOAppliesTo                    : CN=PW-Admins,OU=Groups,DC=outreason,DC=example
#
# Bir kullanicinin RESULTANT PSO'su tek bir yerde okunur: msDS-ResultantPSO
# (birden fazla PSO uygulaninca precedence en dusuk olan kazanir; esitlik durumunda
#  PSO nesnesinin objectGUID'i tie-break olur). Grup uyeliginden gelen PSO'lar
# birlestirilmez; TEK bir sonuc PSO secilir.

Lockout parolayla nasıl ilişkilenir

Account Lockout Policy parola politikasının bir alt bölümüdür ve üç değerle çalışır: lockout threshold (kaç başarısız denemede kilit), lockout duration (kilidin ne kadar süreceği) ve observation/reset window (sayacın ne kadar sürede sıfırlanacağı). FGPP kullanılıyorsa bu değerler PSO'daki msDS-Lockout* alanlarından gelir ve domain default'unu ezer.

Yanlış mevcut parola bir change denemesini başarısız kılabilir ve badPwdCount’u etkileyebilir. Bunun audit izini ayrı düşün: domain hesabında yanlış eski parola için, ilgili auditing açıksa, DC’de 4771 veya 4776 görülebilir. 4723 Failure ise yeni parolanın policy’yi karşılamadığı durumda anlamlıdır. Lockout yorumunda sayacı, observation/reset window’u ve threshold’u birlikte incele; yalnız “art arda yanlış deneme” diye özetleme.

Password history ve minimum age, change yolunda eski parolaya hızlıca dönmeyi sınırlar. Reset için aynı sonucu otomatik varsayma: kullanılan password-set interface’inin bu kontrolleri uygulayıp uygulamadığını doğrulamak gerekir. MS-ADTS’nin policy-hints kontrolü, LDAP password-set sırasında history ve age denetimini istemeye yarar. Reset validator’ının history listesini güncellemesi ise geçmişteki bir değeri reddettiğinin kanıtı değildir. Sonuç olarak üç soru ayrıdır: hangi policy seçildi, bu işlem yolu hangi kontrolleri uyguladı, işlem hangi sonuçla bitti?

Durum ve veri akışı

1. Önce işlem türünü seç: change için User-Change-Password, reset için hedefte User-Force-Change-Password hakkı ayrı değerlendirilir.
2. Change yolunda mevcut parolayı ayrıca doğrula. Doğru parola eksik hakkı tamamlamaz; reset yolu mevcut parolayı istemez.
3. Kullanıcının msDS-ResultantPSO değerini oku; PSO yoksa domain default geçerlidir. Bu örnekte tek seçilmiş policy gösterilir, PSO’lar birleştirilmez.
4. History ve minimum age kontrollerini işlem yoluyla birlikte değerlendir. Change için geçerli kontroller, kullanılan reset interface’inde ayrıca doğrulanmalıdır.
5. İşlem sonucunu ayrı oku. Bir hakkın bulunması veya policy’nin seçilmesi, parolanın gerçekten değiştiğini tek başına kanıtlamaz.
6. Kanıtı doğru yerde ara: domain hesabında yanlış eski parola için audit kapsamına göre 4771/4776; yeni parolanın policy reddi için 4723 Failure. Sayaç ve lockout durumu ayrıca incelenir.

2. Exploitation / İstismar

Broken trust assumption

Parola bilgisi ve parola değiştirme yetkisi farklıdır. Change, mevcut parolanın doğrulanmasını ve Change Password hakkını gerektirir. Reset mevcut parolayı istemez; hedefte ayrı Reset Password hakkı gerekir. Geniş delegasyon, bu yetkinin çok sayıda hesaba yayılması riskini doğurur; parola atanması da yeni logon’un başarılı olacağını tek başına kanıtlamaz. Görünürlük Audit User Account Management ve log collection’a bağlıdır. Access Denied, Failure 4724 üretmeyebilir; event yokluğunu işlem yokluğu sayma.

Technical prerequisites

• Saldırganın hedef user nesnesi üzerinde Reset Password (User-Force-Change-Password) extended right'ına doğrudan veya devralınmış bir ACE ile sahip olması; bu hak yoksa reset başarısız olur.
• Hedef hesabın enabled olması ve reset sonrası logon'u engelleyen ek bir kontrolün (smartcard-required, disabled) bulunmaması; aksi hâlde parola atansa da oturum açılamaz.
• Savunma incelemesinde, reset yolunun hangi policy kontrollerini uyguladığını doğrula. History ve minimum age’i bütün reset interface’leri için aynı zorunlu engel sayma; history’nin güncellenmesi ile geçmişteki değerin reddi ayrı davranışlardır.
• Reset girişiminin denetimde görünürlüğü, Audit User Account Management, başarı/başarısızlık sonucu ve Security log collection'a bağlıdır. Access Denied gibi her başarısız girişim mutlaka Failure 4724 üretmez; mevcut event kapsamını kontrol et.

Exploitation mechanism / İstismar mekanizması

Risk, mevcut parolayı bilmeden reset yapma yetkisinin yanlış veya fazla geniş dağıtılmasından doğar. Change de bir izin kontrolü içerir; reset ise ayrı User-Force-Change-Password hakkıyla yürür. Reset Password hakkı bir kullanıcı nesnesinin DACL'inde bir control access right ACE'siyle verilir; bu hakka sahip bir principal, hedefin mevcut parolasını bilmeden yeni bir parola atar ve ardından o kimlikle oturum açabilir. Bu bir protokol açığı değil, tasarlanmış bir delegasyon yeteneğinin yanlış/geniş dağıtılmasıdır: help desk senaryosu için makul olan hak, bir OU'nun tümüne veya ayrıcalıklı hesaplara genişletildiğinde bir account-takeover yüzeyine dönüşür. Change için mevcut parola yanında User-Change-Password hakkı aranır. Burada incelenen risk, reset delegasyonunun hangi hesapları kapsadığıdır. FGPP açısından ilgili incelik şudur: zayıf bir PSO (kısa min length, history yok) belirli bir gruba uygulanmışsa, o grup domain default'undan daha zayıf bir tabanla korunur ve resultant PSO bunu tek yerden gösterir; 'domain politikası güçlü' demek her kullanıcının güçlü politikada olduğu anlamına gelmez.

Reset hakkı: parolasız parola değiştirme

Reset Password extended right'ı, hedefin mevcut parolasını bilmeden yeni bir parola atama yeteneğidir. Bu yüzden bu hakkın kime, hangi nesneler üzerinde verildiği kritik bir yetki sorusudur. Bir OU'nun tüm user nesneleri üzerinde bu hakka sahip bir grup, pratikte o OU'daki her hesabı devralabilir. Audit görünürlüğü ayrıca doğrulanır: ilgili audit policy ve collection gerekir, Access Denied ise Failure 4724 üretmeyebilir.

Bu, change'ten temelde farklıdır: change mevcut parolayı gerektirdiği için 'zaten bilen' biriyle sınırlıdır. Reset ise saf bir yetkidir. Denetimde bu ikisini karıştırmak — 4723 ve 4724'ü aynı 'parola değişti' kutusuna koymak — reset'in ayrıcalık kullanımı sinyalini gizler.

Zayıf PSO: güçlü domain, zayıf ada

FGPP bir kullanıcı grubuna domain default'undan DAHA ZAYIF bir politika da uygulayabilir. Precedence en düşük olan PSO kazandığından, yanlış yapılandırılmış veya kötü niyetli sayısal precedence değeri düşük (önceliği yüksek) zayıf bir PSO, bir grubu domain'in genel gücünün altına indirebilir.

Bu yüzden 'parola politikamız güçlü' iddiası tek başına yetmez; her ayrıcalıklı grubun resultant PSO'su ayrıca doğrulanmalıdır. Saldırgan tarafında zayıf resultant PSO'lu bir grup, brute-force veya password spraying için daha yumuşak bir hedeftir. Sonucu tahmin etmek yerine msDS-ResultantPSO'dan okumak, bu kör noktayı kapatır.

Toplu reset ve PSO'ya yazma: kapsam ve engelleyici kontrol

Reset hakkının tehlikesi tekil değil, kapsamlıdır: bir principal bir OU'nun tüm user nesneleri üzerinde Reset Password hakkına sahipse, o OU'daki her hesabı tek tek devralabilir — mevcut parola gerekmez, yalnız yeni parola atanır. Kapsam sınırı önemlidir: bu hak yoksa reset başarısız olur ve hedef smartcard-required ya da disabled ise parola atansa da oturum açılamaz. Yani etki, 'hakkın kapsamı' × 'hedefin ek kısıtları' ile sınırlanır; olası en kötü hâl, hakkın ayrıcalıklı hesaplara veya geniş bir OU'ya yayılmış olmasıdır.

İkinci bir kapsam noktası, PSO nesnelerinin kendisidir: msDS-PasswordSettings nesnesine yazma yetkisi olan bir principal, sayısal precedence değeri düşük (önceliği yüksek) zayıf bir PSO oluşturup bir gruba (msDS-PSOAppliesTo) uygulayarak o grubun resultant policy'sini domain tabanının altına indirebilir. Bu bir parola kırma değil, politika zayıflatmadır ve ardından password spraying'i kolaylaştırır. Engelleyici kontrol iki yönlüdür: Reset Password delegasyonunu en dar nesne kümesine indir ve düzenli envanterle; Password Settings Container üzerindeki yazma yetkisini yalnız güvenilir yöneticilere ver ve beklenmedik/sayısal precedence değeri düşük (önceliği yüksek) PSO'ları avla. Böylece hem 'parolasız parola değiştirme' hem de 'politika zayıflatma' yüzeyleri kapsam olarak daraltılır.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• 4723 (change attempt) ve 4724 (başka hesap için reset attempt) benzer alan şekline sahip ama farklı yetki modelini izler. İkisini yalnızca genel 'password changed' kategorisine indirgemek, 4724'ün privilege kullanımı sinyalini ve attempt/result ayrımını kaybettirir.
• Her iki olay Audit User Account Management alt kategorisine bağlıdır ve işlemin gerçekleştiği bilgisayarda üretilir (domain hesabı için ilgili DC, yerel hesap için üye sunucu/istemci); SACL gerektirmez, bu alt kategori açık olmalıdır.
• Subject != Target ayırımı, 4724'te başka bir hesap için parola reset girişimini gösterir; olay başarı/başarısızlık sonucu ile birlikte okunmalıdır. 4723'te Subject == Target tipik self-service change desenidir.
• 'Hangi politika uygulanıyor?' sorusu bir event'ten değil, msDS-ResultantPSO niteliğinden okunur; audit log işlemin yapıldığını gösterir, uygulanan policy'yi değil.
• FGPP kapsamını incelerken tek tek PSO'ların msDS-PSOAppliesTo ve msDS-PasswordSettingsPrecedence değerleri toplu okunur; ama bir kullanıcının fiili sonucu her zaman resultant PSO'dur, PSO listesinin zihinsel birleşimi değil.

Events and relevant fields

• 4723 / SubjectUserSid == TargetSid: kendi hesabı için password change girişimiyle uyumludur. SID eşitliği tek başına parolanın değiştiğini veya eski parolanın doğrulandığını kanıtlamaz; success/failure sonucunu ve doğrulama bağlamını ayrıca incele.
• 4724 / SubjectUserSid != TargetSid: başka bir account için reset girişimi. Olayın success/failure sonucunu ayrıca okuyun; girişim kaydı tek başına parolanın değiştiğini kanıtlamaz.
• 4724 / TargetSid: sıfırlanan hesabın kalıcı kimliğidir; ayrıcalıklı hesaplar üzerindeki reset'ler öncelikli incelenir çünkü bir takeover yolu olabilir.
• Domain hesabında yanlış eski parola: ilgili auditing açıksa DC’de 4771/4776 görülebilir; bunu doğrudan 4723 Failure diye arama. 4723 Failure, yeni parolanın policy reddini gösterebilir. badPwdCount ve lockout için sayaç, zaman penceresi ve threshold ayrı kanıtlardır.
• 4724 / SubjectLogonId: reset'i yapan oturumu tanımlar; aynı Subject'in kısa sürede birçok hesabı reset etmesi (toplu reset) bir delegasyon kötüye kullanımı veya kampanya işareti olabilir.

İşlem izi ile politika sorusunu ayır

İlk soru 'ne denendi?' olmalıdır: 4723 change girişimini, 4724 başka bir hesap için reset girişimini kaydeder. Subject/Target ilişkisi bu ayrımı doğrulamaya yardım eder; event success/failure sonucunu ayrıca göstermelidir. İkinci soru 'hangi parola policy uygulanıyor?' — bunu audit event değil, msDS-ResultantPSO directory attribute yanıtlar.

Bu ayrımı korumak iki hatayı önler: reset'i (4724) sıradan bir 'parola değişti' sanıp ayrıcalık sinyalini kaçırmak, ve bir kullanıcının parola politikasını PSO listesini zihinde birleştirerek tahmin etmek. İşlem izi olaydan, politika sonucu nitelikten okunur.

İncelenen soru              Kanıt
--------------------------  -----------------------------------------
Change mi, reset mi?         4723 / 4724; sonuç ve Subject/Target bağlamı
Hangi izin gerekir?         Change: User-Change-Password + mevcut parola
                            Reset: User-Force-Change-Password
Hangi policy uygulanır?     msDS-ResultantPSO; yoksa domain default
PSO seçiminde eşitlik?      precedence, sonra objectGUID

Resultant PSO'yu tahmin etme, oku

Bir kullanıcı birden çok PSO kapsamına girdiğinde, uygulanan tek politika resultant PSO'dur ve bunu tahmin etmek yerine msDS-ResultantPSO niteliğinden okumak gerekir. Doğrudan uygulanan PSO grup PSO'larını ezer; grup PSO'ları arasında en düşük precedence kazanır; eşitlikte objectGUID tie-break olur.

Bu deterministik kural, güvenlik açısından 'öngörülebilir ama keyfi' bir tie-break içerir: objectGUID sıralaması bir güç göstergesi değildir, yalnız kararı deterministik kılar. Bu yüzden precedence eşitliğine güvenmek kırılgandır; ayrıcalıklı gruplara net ve sayısal precedence değeri düşük (önceliği yüksek) tek bir güçlü PSO atamak, çakışma belirsizliğini baştan kapatır.

Detection logic · Sigma

title: Parola reset girisimleri (4724) - baska hesap icin
status: experimental
description: >
  4724 ile baska bir hesap icin reset girisimini gozlemler; Subject/Target
  ayirimi ve success/failure sonucu ayrica yorumlanir.
logsource:
  product: windows
  service: security
detection:
  reset_attempt:
    EventID: 4724
  condition: reset_attempt
fields:
  - EventID
  - SubjectUserName
  - SubjectUserSid
  - TargetUserName
  - TargetSid
  - Keywords           # System/Keywords carries Audit Success or Audit Failure
falsepositives:
  - Yetkili help desk veya yonetici tarafindan yapilan mesru reset girisimi
level: medium

Query assumptions

• Sigma logsource windows/security kanalını varsayar; 4724 seçimi tek başına 'kötü' demez, ayrıcalık kullanımını gözlem noktasına getirir. Subject != Target çıkarımı bir backend join/alan karşılaştırması gerektirir; ham EventID filtresi bunu yapmaz.
• Bu kural hangi parola politikasının uygulandığını göremez; policy sorusu msDS-ResultantPSO'dan okunur, event'ten değil.
• 4723/4724 domain hesabı işleminde ilgili DC'de üretilir; birden çok DC varsa ve Security log'ları merkezîleştirilmemişse reset'ler eksik görülebilir.
• Bu seçim canlı bir sistemde çalıştırılmadı; yalnızca bu dersin sentetik 4723/4724 örnekleri üzerinde alanların (EventID, Subject*, Target*) seçilebilirliği doğrulandı.
• Bu bir eğitim seçimi örneğidir. Sigma parser/backend validation yapılmadı; taşınabilir, çalıştırılmış production kuralı iddiası değildir.

False positives

• Meşru help desk / yönetici reset girişimleri 4724 üretir; yüksek değerli hedef, operatör bağlamı ve hacim örüntülerine göre önceliklendir.
• Yetkili help desk'in başka bir hesap için yaptığı meşru reset de 4724 üretir; Subject != Target bu normal işlemde beklenen desendir ve tek başına kötü niyeti göstermez.
• Negatif örnek: mevcut parolayı bilen bir saldırgan reset yerine change (4723) yapar ve bu filtreye hiç düşmez; reset odaklı seçim bir kapsam sınırıdır, tüm parola-tabanlı takeover'ı kapsamaz.

Hardening

• Reset Password (User-Force-Change-Password) delegasyonunu en dar kapsamda tut; hakkı OU'nun tümüne veya ayrıcalıklı hesaplara değil, yalnız gereken help desk grubuna ve gereken nesnelere ver. Delegasyonu düzenli envanterle ve doğrula.
• Change (4723) ve reset (4724) girişimlerini denetimde ayrı kategorilerde işle; başka hesaba yönelik resetleri (Subject != Target) hedef/operatör bağlamıyla önceliklendir, tek başına malicious diye etiketleme.
• Ayrıcalıklı gruplar için güçlendirilmiş bir FGPP (yüksek min length, uygun history, makul max age, uygun lockout) uygula ve her ayrıcalıklı hesabın msDS-ResultantPSO'sunu doğrula; 'domain default güçlü' varsayımına güvenme.
• Zayıf veya beklenmedik PSO'ları avla: sayısal precedence değeri düşük (önceliği yüksek), kısa min length veya history=0 taşıyan bir PSO bir grubu domain tabanının altına indirebilir. PSO envanterini msDS-PSOAppliesTo ile birlikte gözden geçir.
• History ile minimum age’i change yolunda birlikte değerlendir. Yetkili reset araçlarında ise kullanılan interface’in history/age kontrollerini gerçekten uyguladığını ayrıca doğrula; resultant PSO’yu okumak bu uygulamayı tek başına kanıtlamaz.
• Doğrulama adımı: test account ile change ve reset girişimi yapıp 4723/4724 EventID, Subject/Target ve success/failure alanlarını incele; hedef kullanıcının resultant PSO'sunun beklenen değer olduğuna ayrıca bak. Audit User Account Management açık ve loglar toplanıyor olmalı.

Örnekler üzerinde oku / Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4723</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>13824</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T09:03:11.5540000Z" />
    <EventRecordID>91344</EventRecordID>
    <Correlation />
    <Execution ProcessID="724" ThreadID="3980" />
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">kaan</Data>
    <Data Name="TargetDomainName">OUTREASON</Data>
    <Data Name="TargetSid">S-1-5-21-3623811015-3361044348-30300820-1201</Data>
    <Data Name="SubjectUserSid">S-1-5-21-3623811015-3361044348-30300820-1201</Data>
    <Data Name="SubjectUserName">kaan</Data>
    <Data Name="SubjectDomainName">OUTREASON</Data>
    <Data Name="SubjectLogonId">0x4a2b7</Data>
  </EventData>
</Event>

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4724</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>13824</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T09:07:48.9120000Z" />
    <EventRecordID>91352</EventRecordID>
    <Correlation />
    <Execution ProcessID="724" ThreadID="3980" />
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">kaan</Data>
    <Data Name="TargetDomainName">OUTREASON</Data>
    <Data Name="TargetSid">S-1-5-21-3623811015-3361044348-30300820-1201</Data>
    <Data Name="SubjectUserSid">S-1-5-21-3623811015-3361044348-30300820-1105</Data>
    <Data Name="SubjectUserName">helpdesk.ops</Data>
    <Data Name="SubjectDomainName">OUTREASON</Data>
    <Data Name="SubjectLogonId">0x3e9f1</Data>
  </EventData>
</Event>

İki yanlış kanı / Two reality checks

Sanılan: Birinin parolasını değiştirebilmek için önce o parolayı bilmek gerekir.

Gerçekte: Hayır. Bu yalnızca 'change' (4723) için doğrudur; change mevcut parolayı gerektirir. 'Reset' (4724) ise mevcut parolayı hiç istemez: hedef user nesnesi üzerinde Reset Password (User-Force-Change-Password) extended right'ına sahip bir principal, mevcut parolayı bilmeden yeni bir parola atar. Bu yüzden bir kullanıcının parolasını 'bilmek' ile 'değiştirebilmek' iki ayrı yetenektir; ikincisi bir ACL hakkıdır ve geniş dağıtılmış bir reset delegasyonu geniş bir account-control riski doğurur.

Sanılan: Domain'in parola politikası güçlüyse, her kullanıcı o güçlü politikayla korunur.

Gerçekte: Hayır. Fine-Grained Password Policy (PSO), belirli kullanıcı veya global gruplara domain default'undan farklı — hatta daha ZAYIF — bir politika uygulayabilir ve sayısal precedence değeri düşük (önceliği yüksek) bir PSO domain tabanını ezer. Ayrıca PSO'lar birleştirilmez; bir kullanıcı birden çok PSO kapsamındaysa yalnız precedence en düşük olan (eşitlikte objectGUID tie-break) uygulanır. Bir kullanıcının fiilen hangi politikada olduğu, PSO'ları tahminle birleştirerek değil, tek yerden — msDS-ResultantPSO — okunarak bulunur.

Kaynaklar / Sources

• Microsoft · 4723(S, F) An attempt was made to change an account's password
  Event XML (Version 0); change işleminin mevcut parola gerektirmesi; Subject/Target alanları; Audit User Account Management; domain controller, üye sunucu ve istemcilerde (işlemin gerçekleştiği bilgisayarda) üretilebilir.
• Microsoft · 4724(S, F) An attempt was made to reset an account's password
  Event XML (Version 0); reset'in mevcut parola gerektirmemesi ve Reset Password hakkına bağlı olması; Subject != Target kalıbı; domain controller, üye sunucu ve istemcilerde (işlemin gerçekleştiği bilgisayarda) üretilebilir.
• Microsoft · User-Force-Change-Password extended right (AD Schema)
  CN User-Force-Change-Password, Display-Name 'Reset Password', Rights-GUID 00299570-246d-11d0-a768-00aa006e0529; 'Permits resetting a password on a user account.'
• Microsoft · Fine-grained password policies (AD DS)
  PSO (msDS-PasswordSettings) kullanıcı ve global gruplara uygulanır (OU'ya değil); precedence en düşük kazanır; eşitlikte objectGUID; sonuç msDS-ResultantPSO.
• Microsoft · Password Policy (security policy settings)
  Default Domain Password Policy bileşenleri: minimum length, password history, min/max age, complexity; domain başına tek politika.
• Microsoft · Account lockout threshold (security policy setting)
  lockout threshold/duration/observation window ilişkisi; FGPP kullanılırsa msDS-Lockout* alanlarının domain default'unu ezmesi bağlamı.
• Microsoft Open Specifications · [MS-ADTS] unicodePwd
  §3.1.1.3.1.5.1: change için mevcut parola ve User-Change-Password; reset için User-Force-Change-Password.
• Microsoft Open Specifications · General Password Policy
  §3.1.1.7.1: history/minimum-age enforcement depends on change versus password-set path.
• Microsoft Open Specifications · LDAP_SERVER_POLICY_HINTS_OID
  §3.1.1.3.4.1.27: requested history/age enforcement during password set.
• Microsoft Open Specifications · SamValidatePasswordReset
  §3.1.5.13.7.3: history update is not a history-match rejection.
• Microsoft Open Specifications · SamValidatePasswordChange
  §3.1.5.13.7.2: wrong-password counter and observation window.
• Microsoft Open Specifications · msDS-ResultantPSO
  §3.1.1.4.5.36: direct user policy first; lower numeric precedence, then objectGUID.