Active Directory hangi problemi çözer? Workgroup, domain ve merkezi kimlik.

1. Core Mechanism / Temel mekanizma

Workgroup’ta değişiklikleri kim takip ediyor?

Domain’e katılmamış bir Windows bilgisayar kendi yerel hesaplarını yönetir. Örneğimizde IT ekibi Tunahan için WS01, WS02 ve FS01 üzerinde ayrı yerel hesaplar açmayı seçmiş olsun. Kullanıcı eklemek, parola yönetmek ve hesabı kapatmak her hesap otoritesinde ayrı iştir. Üç hesap, bu senaryonun tercihidir; her workgroup kurulumu için zorunlu bir sayı değildir.

Tunahan ekip değiştirdiğinde yalnız WS01’de bir ayarı düzeltmek, FS01’deki rapor iznini düzeltmez. Başka yönetim araçları işleri otomatikleştirebilir; workgroup mutlaka her şeyin elle yapıldığı anlamına gelmez. Buradaki fark, bu bilgisayarların ortak bir AD domain hesabına dayanıp dayanmadığıdır.

Domain neyi ortaklaştırıyor?

AD DS, kullanıcıları, grupları ve bilgisayarları ortak bir dizinde tutar. Tunahan için IYELABS domain’inde bir kullanıcı hesabı oluşturulur. Domain’e katılan WS01 ve WS02 bu domain kimliğiyle çalışabilir; FS01’in kaynak izinleri de aynı domain hesabını veya grubunu referans edebilir. Her üye bilgisayarda Tunahan’ın yeni bir yerel kopyasını oluşturmak gerekmez.

Domain Controller, kısaca DC, bu dizin ve domain doğrulama hizmetlerini çalıştıran sunucudur. “Merkezi” sözü bütün sistemin tek fiziksel sunucuya sığdığı anlamına gelmez: birden fazla DC dizin verisini replication ile paylaşabilir. Domain üyeliği de bilgisayardaki yerel hesapları ortadan kaldırmaz.

Merkezi yönetim yalnız kullanıcı listesi değildir. Bilgisayar nesneleri, grup üyelikleri ve uygun kapsamda Group Policy ile yönetilen ayarlar birlikte bir düzen kurar. Bunların nasıl işlendiğini sonraki derslerde açacağız; burada önemli olan ortak bir yönetim ve kimlik zemininin oluşmasıdır.

İşe giriş, görev değişikliği, işten ayrılış

İşe girişte domain hesabı açılır; Tunahan’ın işi için gereken gruplar ve kaynak izinleri belirlenir. Örneğin rapor okuma izni bir ekip grubuna verilmişse, Tunahan’ı o gruba almak her dosyada kullanıcı adını tek tek yazmaktan daha düzenli bir yönetim sağlar. Grup oluşturmak tek başına izin vermez; FS01’de o gruba gerekli izin de atanmalıdır.

Görev değişikliğinde eski üyelikler ve yeni erişim ihtiyaçları birlikte gözden geçirilir. İşten ayrılışta hesabı devre dışı bırakmak yeni domain doğrulamalarını engellemeye yönelik merkezi bir adımdır. Yerel hesaplar, uygulamaların kendi oturumları ve daha önce kurulmuş erişim bağlamları ayrıca ele alınır.

Bir DC’de değişen durum diğer DC’lere replication ile ulaşır. Üyelik değişikliği mevcut token’ı geriye dönük yeniden yazmaz; hesabı kapatmak da mevcut bütün session ve ticket’ları anında yok etmez. “Tek yerden yönetmek” ile “her yerde aynı anda bütün erişimleri iptal etmek” aynı iddia değildir.

Kimliği doğrulamak, dosyayı açtırmak değildir

Domain doğrulaması “Bu hesap kim?” sorusuna cevap verir. FS01’in dosya izni ise “Bu hesap ya da grupları bu raporu okuyabilir mi?” sorusunu değerlendirir. Tunahan doğru domain kimliğiyle çalışırken raporu açamayabilir; örneğin rapor grubuna üye değildir veya kaynağın izinleri bu isteğe uygun değildir.

AD bu kararları anlaşılır ve yönetilebilir bir ortak zemine taşır; her kaynağı herkese açmaz. AD yönetim yetkileri de buna göre dikkatli sınırlandırılmalıdır: çok sayıda hesabı veya üyeliği değiştirebilen bir yönetim hakkının etkisi, tek cihazdaki sıradan bir değişiklikten daha geniş olabilir.

Şimdi kimlik sorusunu ayrı aç

Bu dersten çıkarılacak temel fikir şudur: AD, çalışan ve cihaz sayısı arttıkça hesapları, üyelikleri ve policy düzenini ortak bir domain üzerinden yönetmeyi sağlar. Kaynak izni yine ayrıca tanımlanır ve değerlendirilir.

Peki WS01\tunahan, FS01\tunahan ve IYELABS\tunahan neden aynı hesap değildir? Bir insan ile hesabı, görünen ad ile SID’yi 02.01’de ayrı örneklerle ele alıyoruz. Önce bu yönetim problemini kendi cümlenle anlat; ardından kimlik karşılaştırmasına geç.

Durum ve veri akışı

1. Tunahan’ın WS01, WS02 ve FS01’de ne yapacağını belirle: çalışma, rapor okuma ve erişim yaşam döngüsü.
2. Workgroup ile domain’i seçip hesap yönetiminin hangi otoritede tutulduğunu karşılaştır.
3. Örnekte workgroup için üç ayrı yerel hesap; domain için üye cihazların kullanabildiği ortak bir domain hesabı yönetilir.
4. FS01’de rapor izni ayrıca atanır. Ortak domain hesabı veya grup, herkese otomatik READ vermez.
5. Tunahan ayrılıyor: workgroup’ta ilgili yerel hesaplar ayrı; domain’de domain hesabı merkezi olarak devre dışı bırakılır.
6. Merkezi değişiklik mevcut session/token/ticket’ları anında yok etmez. DC replication ve mevcut erişim bağlamları ayrıca değerlendirilir.

2. Exploitation / İstismar

Broken trust assumption

Bozulan varsayım: ortak domain kimliği otomatik yönetim ve kaynak erişim hakkıdır. Domain üyeliği directory delegation veya FS01 READ izni vermez.

Technical prerequisites

• Bir domain hesabı veya yönetim rolünün gerçek izinleri olması.
• Etki değerlendirmesinde hangi kullanıcı/grup/nesnelerin değiştirilebildiğinin bilinmesi.
• Kaynak erişimi için ayrıca gerekli kaynak izinlerinin bulunması.

Exploitation mechanism / İstismar mekanizması

Ortak dizindeki hesap ve üyelik değişiklikleri birden çok kaynak tarafından kullanılan kimlik düzenini etkileyebilir. Etki gerçek delegation ve kaynak izinleriyle sınırlıdır; bir cihazdaki local admin hakkı otomatik domain yönetimi değildir.

Merkezi yönetim hakkının etki alanı

Birçok kullanıcı ve grubun yönetimi ortak bir dizinde toplandığında, bu nesneleri değiştirme yetkisi de önem kazanır. Domain’e katılmış olmak bu yönetim hakkını vermez; delegation ve ayrıcalıklı hesapların gerçek izinleri belirleyicidir.

Bir yerel hesabı ele geçirmek ile domain yönetimi üzerinde yetki elde etmek aynı sonuç değildir. Etkiyi cihaz, hesap otoritesi ve değiştirilmesine izin verilen nesneler üzerinden sınırla. Kimlik ve credential reuse ayrıntısını 02.01’de incele.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Telemetri üreticisi oturumun oluşturulduğu workstation veya sunucudur; kanal Security’dir.
• Audit Logon alt kategorisinde Success, 4624 başarı kayıtlarını; Failure, 4625 başarısızlık kayıtlarını destekler.
• 4624 hedef bilgisayarda oluşur. Bu artifact yalnız başarılı 4624 karşılaştırması taşır; başarısızlık sonucu veya kaynak nesne erişimi içermez.

Events and relevant fields

• 4624 / Computer + TargetDomainName + TargetUserSid: oturumun host ve hesap bağlamı; gerçek örnekleri 02.01’de ayrı oku.
• 4624: başarılı hedef oturumu; hesap kapatmanın tüm erişimleri bitirdiği veya dosyanın okunduğu sonucu değildir.

Yönetim değişikliğini sonuçla karıştırma

Önce envanteri çıkar: hangi domain hesabı, hangi yerel hesaplar, hangi gruplar ve hangi kaynak izinleri söz konusu? İşten ayrılan kullanıcı için yalnız hesap durumuna bakmak, daha önce kurulmuş bütün erişimlerin sona erdiğini göstermez.

Dizin değişikliği, başarılı oturum ve belirli bir dosyanın okunması ayrı gözlemlerdir. Bu dersteki yönetim kaydı sentetik bir karşılaştırmadır; gerçek Windows event’i değildir. 02.01’de oturum kayıtlarını hesap otoritesiyle, 15. bölümde kaynak kanıtını daha ayrıntılı okuyacaksın.

Detection logic · XPath

*[System[(EventID=4624)]] and *[EventData[Data[@Name='TargetUserName']='tunahan']]

Query assumptions

• Bu, Windows Event Log XML alanlarına yönelik çalıştırılmamış bir aday filtredir; SIEM sorgusu veya parola-tekrar tespiti değildir.
• Sonuçlar TargetUserSid, TargetDomainName ve Computer birlikte incelenerek sınıflandırılmalıdır.
• TargetDomainName biçimi ortama ve logon yoluna göre değişebilir; bilgisayar/domain envanteri olmadan kesin sınıflandırma yapılmamalıdır.
• Fixture parser’da henüz çalıştırılmadı; gerçek Windows veri kümesinde sonuç ürettiği iddia edilmez.

False positives

• Help-desk standardı nedeniyle birçok cihazda aynı adlı yerel hesap bulunabilir.
• Servis, yerleşik ve cached domain logon kayıtları yalnız ada dayalı sınıflandırmayı yanıltabilir.
• Negatif örnek: 4624 kayıtları iki hesabın aynı parolayı kullandığını göstermez.

Hardening

• Hesap açma, görev değişikliği ve işten ayrılışı aynı yaşam döngüsünde yönet.
• Kaynak izinlerini iş gereksinimine göre gruplarla düzenle; eski üyelikleri gözden geçir.
• Directory delegation ve ayrıcalıklı hesap kullanımını gerekli kapsamla sınırla.
• Domain hesabını kapatırken yerel hesapları ve mevcut session/ticket bağlamlarını ayrıca değerlendir.
• Hesap, oturum ve dosya erişimi kanıtlarını ayrı gözlemler olarak kontrol et.

Örnekler üzerinde oku / Read the examples

{
  "kind": "teaching-record",
  "synthetic": true,
  "scenario": "Tunahan joins, uses three devices, then leaves",
  "devices": [
    "WS01",
    "WS02",
    "FS01"
  ],
  "workgroup": {
    "accountAuthorities": [
      "WS01 local SAM",
      "WS02 local SAM",
      "FS01 local SAM"
    ],
    "managedAccounts": 3,
    "disableScope": "Each selected local account separately"
  },
  "domain": {
    "accountAuthority": "IYELABS AD DS",
    "managedUserAccounts": 1,
    "memberDevices": [
      "WS01",
      "WS02",
      "FS01"
    ],
    "disableScope": "Domain account; local accounts are separate"
  },
  "resource": {
    "host": "FS01",
    "requestedRight": "READ",
    "permission": "Configured separately"
  },
  "existingSessionsAndTickets": "No instantaneous revocation claimed"
}

İki yanlış kanı / Two reality checks

Sanılan: Domain’e katılınca kullanıcı hesabı her bilgisayara yerel hesap olarak kopyalanır.

Gerçekte: Domain üyeleri ortak domain principal’ını kullanabilir. Yerel hesaplar ayrı kalır; domain kullanıcı nesnesini her üye bilgisayarda yeniden oluşturmak gerekmez.

Sanılan: Domain hesabıyla doğrulanan kullanıcı domain’deki bütün kaynaklara erişir.

Gerçekte: Domain doğrulaması kimliği ve token girdilerini sağlar. Her kaynak, istenen erişimi kendi security descriptor’ı ve güvenlik bağlamıyla ayrıca kararlaştırır; başarılı logon otomatik kaynak izni değildir.

Kaynaklar / Sources

• Microsoft · Active Directory Domain Services overview
  Directory objects, integrated security, policy administration and replication; consulted 2026-10-11.
• Microsoft · Local accounts
  Giriş ve “Local accounts” bölümü: yerel hesapların cihazda tanımlanması ve yerel güvenlik bağlamı.
• Microsoft · Security Principals
  “How security principals work”, “Security identifiers” ve “Access tokens”.
• Microsoft · Credentials Processes in Windows Authentication
  “Windows credentials authentication overview”: yerel SAM ve domain/DC doğrulama yolları.
• Microsoft · 4624(S): An account was successfully logged on
  Event Description, Version 2 XML ve New Logon alan açıklamaları; Account Domain yerel hesap davranışı.
• Microsoft · Windows LAPS overview
  Giriş ve Benefits: cihaz başına benzersiz yerel yönetici parolası ve döndürme.