LDAP ile nesneyi değiştirmek: işlem, sonuç ve belirsizlik

1. Core Mechanism / Temel mekanizma

03.05 aramayı, 03.06 bağlantının güvenliğini anlattı. Şimdi bu bağlantı üzerinden nesne değiştirilirken neyin tek işlem sayıldığını öğreniyoruz. Schema’ya uygunluk, yazma hakkı ve sonucu öğrenmek üç ayrı sorudur.

Arabirimler ve belirtimler

• Add yeni entry oluşturur; gerekli attribute ve parent koşulları sağlanmalıdır.
• Modify mevcut entry’nin attribute değerlerini değiştirir. changes listesi tek atomik operation’dır.
• ModifyDN RDN veya izin verilen konum değişikliği içindir; aynı işlem normal attribute replace değildir.
• Delete entry’yi siler. AD’nin sonraki deleted-object ve retention davranışı 10.02’nin konusudur.
• LDAPResult içindeki resultCode standarttır; diagnosticMessage ek açıklamadır ve boş olabilir.

İşlemin hedefini önce belirle

Ece’nin department alanını değiştirmek istiyorsun. Entry zaten varsa Modify uygundur; entry yoksa onu oluşturan Add gerekir. Aynı görünen form iki farklı operation’a dönüşebilir. DN konumu gösterir; yeniden oluşturulan aynı adlı nesne eski objectGUID’yi taşımayabilir.

Sunucu, kimliğinin doğrulanmış olmasının yanında hedefte bu işlemi yapma hakkını da değerlendirir. Schema gerekli yapıyı tarif eder; hakkın olup olmadığını belirlemez. Requested operation, target ve right ayrımını 05.05’te ayrıntılandıracağız.

Tek Modify, iki bağımsız istek

Bir Modify içinde department=Finance ve displayName=Ece A. değişiklikleri bulunabilir. Sunucu listeyi sırayla, tek atomik operation olarak işler: tamamı başarılı olur ya da hiçbir değişikliği uygulanmaz. Geçici ara durumlar yerine listenin sonunda oluşan entry schema’ya uygun olmalıdır.

Ayrı Add success ardından ayrı Modify error alırsan, önceki Add geri alınmış olmaz. Birden çok request’i bir uygulama düğmesi başlatmış olması onları transaction yapmaz. Uygulama bu farkı kullanıcıya doğru anlatmalıdır.

Yanıt kaybolunca ne biliyoruz?

Üç sonucu ayır: sunucu reddetti ve ret geldi; sunucu uyguladı ve success geldi; istemci yanıtı alamadı. Sonuncusunda iki olasılık vardır: sunucu işlemi bitirmiş olabilir veya istek uygulanmamış olabilir. Bağlantının kesilmesi ikisini birbirinden ayırmaz.

RFC 4511 §3.1 bu durumda update’in başarılı veya başarısız olduğunu varsaymamayı ister. Tekrar denemeden önce ilgili nesne, DC ve işlem bağlamını uzlaştır. Sonraki read güncel durumu gösterir; arada başka biri değiştirmişse ilk işlemin tarihçesini tek başına ispatlamaz.

Success’in kapsadığı sınır

DC-A success döndürdü diye DC-B’nin aynı değeri gördüğünü veya hedef uygulamanın cache’ini yenilediğini söyleyemezsin. Bunlar ayrı gözlemlerdir. 10.07’de değişikliğin diğer DC’ye hangi metadata ile taşındığını göreceğiz.

5136 da ayrı bir kanıt kanalıdır: uygun Directory Service Changes audit ve SACL koşullarına bağlıdır. Olay yoksa bu koşulları ve toplama kapsamını bilmeden “değişiklik yapılmadı” sonucuna gidilmez.

Durum ve veri akışı

1. İstemci hedef entry ve Modify listesini hazırlar; iki zararsız attribute değiştirilir.
2. Writable DC, hedef ve işlemin schema/yetki koşullarını değerlendirir.
3. Tek Modify listesi bütünüyle uygulanır veya bütünüyle reddedilir.
4. LDAPResult istemciye ulaşabilir; yanıt kaybolursa istemcinin sonucu belirsiz kalır.
5. İlgili nesne ve DC’deki read-back, ayrı zamanda alınmış bir durum gözlemidir.
6. Diğer replica ve audit kaydı, kendi koşullarıyla ayrıca değerlendirilir.

2. Exploitation / İstismar

Broken trust assumption

Başarılı bind’in veya görünür bir entry’nin yazma yetkisini de verdiğini varsaymak.

Technical prerequisites

• Etki iddiası için ilgili target, effective hak ve observed context belirlenmiş olmalıdır.

Exploitation mechanism / İstismar mekanizması

Risk, verilen target/attribute/right kapsamından doğar. Dar görünen bir rolün effective hakları daha geniş olabilir. Yanıt alınmayan bir işlemi kesin başarısız saymak da uygulamanın aynı değişikliği istemeden tekrar etmesine yol açabilir; iki risk aynı kontrol sınırında değildir.

Rol adı hak kapsamını söylemez

Telefon güncelleme rolünün adı yalnız iş tanımıdır. Hangi entry ve attribute üzerinde hangi inherited veya explicit hakların bulunduğunu incele. Etkiyi bu sınırdan genişletme; read ve bind başarısından domain-wide kontrol çıkarılmaz.

Belirsizliği otomatik başarısızlığa çevirme

Eksik yanıt, schema ret değildir. Önceki Add uygulanmışsa onu baştan göndermek aynı workflow’u temiz biçimde yeniden başlatmayabilir. Örnekte yalnız eğitim nesnesinin department ve displayName değerleri kullanılır.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• İsteğin messageID’si, hedef kimliği, DC ve zaman aralığıyla yanıtı uzlaştır. Sonraki state veya audit gözlemini aynı kaydın yerine koyma.

Events and relevant fields

• Olay kayıtları yalnız uygun üretim/toplama koşullarında kendi producer’ının kararını gösterir; bütün erişim zincirini kanıtlamaz.

Kanıtın kapsamını koru

İsteğin messageID’si, hedef kimliği, DC ve zaman aralığıyla yanıtı uzlaştır. Sonraki state veya audit gözlemini aynı kaydın yerine koyma.

Üretim ve toplama kapsamını bilmeden eksik olayı negatif kanıt sayma. Yeni davranışı ilgili owner’ın gözlemiyle doğrula.

Detection logic · XPath

*[System[(EventID=5136)]]

Query assumptions

• Bu seçim yalnız uygun Windows Security log’larındaki aday olayları seçer. Dersin JSON gözlem tablosu Windows event değildir.
• İsteğin messageID’si, hedef kimliği, DC ve zaman aralığıyla yanıtı uzlaştır. Sonraki state veya audit gözlemini aynı kaydın yerine koyma.

False positives

• Meşru değişiklikler, cache/context kullanımı veya geçici bağlantı sorunu aynı belirtiyi üretebilir; bu seçim saldırı kararı vermez.

Hardening

• Yazma haklarını gereken entry ve attribute kapsamına daralt; rol adını effective izin yerine kullanma.
• Eksik yanıtı unknown olarak koru; read-back ve değişiklik geçmişiyle kontrollü uzlaştırma yap.
• Directory Service Changes audit, SACL ve toplama kapsamını birlikte doğrula.

Örnekler üzerinde oku / Read the examples

{
  "kind": "teaching-record",
  "synthetic": true,
  "scenario": "N01",
  "object": "CN=Ece,OU=People,DC=example,DC=test",
  "stableObjectIdentity": "toy-object-17",
  "operation": "Modify",
  "changes": [
    {
      "attribute": "department",
      "replace": "Finance"
    },
    {
      "attribute": "displayName",
      "replace": "Ece A."
    }
  ],
  "branches": [
    {
      "serverApplied": false,
      "clientResponse": "error: objectClassViolation (65)"
    },
    {
      "serverApplied": true,
      "clientResponse": "success (0)"
    },
    {
      "serverApplied": true,
      "clientResponse": null
    }
  ]
}

İki yanlış kanı / Two reality checks

Sanılan: İki değişikliği aynı düğmeyle yaptım; ikisi de geri alınır.

Gerçekte: Tek Modify listesinin atomik olması ayrı Add ve Modify request’lerini transaction yapmaz. Her request’in sonucu ayrıdır.

Sanılan: İstemci timeout aldı; değişiklik yapılmamıştır.

Gerçekte: Yanıt kaybı sonucu belirsiz bırakır. Server state, received response ve başka DC’nin görünümü üç farklı kanıttır.

Kaynaklar / Sources

• RFC 4511 — LDAP protocol
  §3; §4.6–4.9; Appendix A LDAPResult
• MS-ADTS Add processing specifics
  §3.1.1.5.2.4, objectGUID/objectSid and generated attributes
• MS-ADTS schema modifications
  §3.1.1.2.5 Schema Modifications