Kullanıcı, bilgisayar ve grup nesneleri; attributes ve schema mantığı.

1. Core Mechanism / Temel mekanizma

Schema, ormanın (forest) tamamında ortak olan Schema naming context'inde (CN=Schema,CN=Configuration,...) yaşar. Sınıf tanımları classSchema, attribute tanımları attributeSchema nesneleridir; yani schema veri deposunun içindeki nesnelerdir, derlenmiş kod değil. Bu ders schema'nın bu iki nesnesini ve bir instance'ın onlarla ilişkisini inceler. Attribute'ların bit düzeyinde replication metadata'sı, GC seçimi (isMemberOfPartialAttributeSet) ve schema genişletme prosedürü bu dersin kapsamı dışında bırakılır; ileri okuma bağlı derslere devredilir.

Arabirimler ve belirtimler

• classSchema: bir nesne türünün tanımı; objectClassCategory, subClassOf, mustContain/mayContain gibi alanları taşır.
• attributeSchema: tek bir attribute'un tanımı; lDAPDisplayName, attributeSyntax/oMSyntax, isSingleValued ve schemaIDGUID alanlarını taşır.
• objectClass: bir instance'ın multi-valued attribute'u; structural/abstract superclass zincirini ve varsa dynamic auxiliary class'ları listeler.
• objectCategory: instance'ın tek değerli attribute'u; sınıfın veya bir superclass'ının distinguished name'ini tutar ve aramada kullanılır.
• mustContain / mayContain (+ systemMustContain / systemMayContain): sınıfın zorunlu ve isteğe bağlı attribute kümesi.
• attributeSyntax + oMSyntax: bir attribute'un değerinin türü (Unicode string, integer, SID, DN vb.) ve karşılaştırma kuralı.
• schemaIDGUID: attribute veya sınıfın security descriptor'larda erişim kontrolü için kullanılan sabit kimliği.

Schema bir nesne kümesidir, sabit bir tablo değil

Bir user nesnesini oluşturduğunuzda directory, 'user diye bir şey var mı, hangi alanları olmalı' sorusunu kod içinden değil, Schema naming context'indeki classSchema nesnesinden yanıtlar. Yani schema'nın kendisi de dizinde duran nesnelerden ibarettir. Bu, schema'nın sorgulanabilir ve (uygun haklarla) genişletilebilir olmasının nedenidir.

attributeSchema nesnesi bir attribute'un kimliğini ve davranışını tanımlar: LDAP istemcilerinin okuyup yazdığı lDAPDisplayName, değerin türünü belirleyen syntax ve güvenlik tanımlayıcılarında bu attribute'a erişimi kontrol eden schemaIDGUID. Yani 'department' ya da 'servicePrincipalName' birer serbest metin değil, schema'da karşılığı olan tanımlı alanlardır.

Structural tür sabit, objectCategory aramayı kolaylaştırır

Bir instance'ın objectClass attribute'u çok değerlidir ve nesnenin structural/abstract superclass zincirini içerir. Bir user nesnesinde bu zincir top, person, organizationalPerson ve user değerlerini içerir. Sınıf tanımına statically linked auxiliary sınıflar bu instance değerinde listelenmez; Windows Server 2003 ve sonrasında bir dynamic auxiliary class tek bir nesneye eklenip çıkarılabilir ve objectClass değerlerinde görünür. Bu ekleme nesnenin structural sınıfını değiştirmez; structuralObjectClass bu sınıfı ve inheritance zincirini gösterir.

objectCategory tek değerlidir, indekslenmiştir ve oluşturulurken sınıfın defaultObjectCategory değerinden ayarlanır. Bu, aramayı kolaylaştırır; ancak doğru nesne türünü tek başına seçmez. (objectCategory=person) user ile contact nesnelerini, (objectClass=user) ise user ile ondan türeyen computer nesnelerini seçebilir. User nesnelerini ayırmak için iki koşulu birleştir: (&(objectClass=user)(objectCategory=person)). Hangi domain ya da OU içinde arandığı ayrıca base ve scope ile belirlenir.

Zorunlu ve isteğe bağlı alanlar sınıftan gelir

Bir sınıfın hangi attribute'ları taşımak zorunda olduğu mustContain/systemMustContain, hangilerini taşıyabileceği mayContain/systemMayContain ile tanımlanır. Bir instance yalnız kendi sınıfının değil, subClassOf zinciriyle miras aldığı bütün superclass'ların ve dahil edilen auxiliary sınıfların attribute kümesini kullanabilir.

Bu yüzden 'bir user'a istediğim herhangi bir alanı yazarım' doğru değildir: yazmak istediğiniz attribute ilgili sınıf zincirinin izin verdiği kümede olmalıdır. Aksi halde işlem schema düzeyinde reddedilir; bu bir erişim reddi değil, tanım reddidir.

Syntax değerin biçimini ve karşılaştırmasını belirler

Her attribute tam olarak bir syntax ile ilişkilidir. Syntax, değerin bir Unicode string mi (2.5.5.12), integer/enumeration mı (2.5.5.9), SID mi (2.5.5.17), yoksa bir nesnenin DN'i mi (2.5.5.1) olduğunu ve nasıl karşılaştırılacağını belirler. Örneğin userAccountControl integer'dır; department Unicode string'dir.

Syntax'e uymayan bir değer yazmayı denemek başarısız olur. Bu, artifact'ta göreceğimiz AttributeSyntaxOID alanının neden anlamlı olduğunu açıklar: bir değişiklik kaydını okurken hangi attribute'un hangi biçimde değiştiğini schema'daki tanıma bağlayabilirsiniz.

Buradan sonraki mekanizmaya

Schema, hangi attribute’un hangi tür değeri kabul ettiğini söyler; caller’a yazma yetkisi vermez. 03.05’te bir entry’yi okuyacak, 03.07’de schema ve authorization kontrollerini tek Modify içinde ayıracağız. 05.05, effective control’ün ayrıca hangi hak yoluyla oluştuğunu açıklar.

Durum ve veri akışı

1. İstemci LDAP üzerinden yeni bir user nesnesi oluşturma isteği gönderir (03.05'te ele alınan search/scope ile aynı bağlantı katmanı).
2. Directory, hedef sınıfın classSchema tanımını okur; mustContain kümesindeki zorunlu attribute'ların sağlandığını doğrular.
3. Yazılmak istenen her attribute'un sınıf zincirinin mustContain/mayContain kümesinde olduğu ve değerin attribute syntax'ine uyduğu denetlenir.
4. Sistem objectClass'ın structural/abstract inheritance zincirini ve objectCategory'yi defaultObjectCategory'den ayarlar. Dynamic auxiliary class daha sonra objectClass'a eklenip çıkarılabilir; bu structuralObjectClass'ı veya objectCategory'yi değiştirmez.
5. Nesne, objectGUID ve objectSid gibi kimlik sabitleriyle birlikte veri deposuna yazılır (bu sabitler 03.03'ün konusudur).
6. Sonraki bir attribute değişikliği, SACL uygunsa 5136 kaydı üretir; kayıt hangi attribute'un hangi değere geçtiğini taşır.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım şudur: Bir hesabın attribute'unu değiştirebilmek yalnızca kozmetik bir yetkidir ve kimlik/servis davranışını etkilemez.

Technical prerequisites

• İşlemi yapan principal’ın hedef attribute veya property set için gereken etkili yazma hakkına sahip olması. Nesnenin sınıfı, attribute’a özgü işlem kısıtları ve DC’nin kabul ettiği yapılandırma yolu ayrıca denetlenir; Write Property tek başına bütün alanlar için başarı garantisi değildir.
• Değiştirilen attribute'un güvenlikle ilgili bir davranışı yönetmesi (örneğin userAccountControl, servicePrincipalName veya msDS-AllowedToActOnBehalfOfOtherIdentity).
• Değişikliğin replication ile diğer domain controller'lara yayılması ve ilgili servisin bu değeri okuması.
• Sınıf tanımının o attribute'a izin vermesi; schema dışı serbest alan yazılamaz.

Exploitation mechanism / İstismar mekanizması

Bir attribute değişikliği, onu okuyan servisin davranışını değiştirebilir. Örneğin servicePrincipalName bir servis adını hesabın key bağlamına bağlar; SPN değeri boş bir metin değildir, geçerli ve benzersiz bir servis kimliği olmalıdır. userAccountControl kimlik doğrulama koşullarını, delegation yapılandırması ise bir principal’ın başka bir principal adına erişim kurmasının sınırlarını etkileyebilir. Bu alanlar telefon numarası gibi yalnız sunum verisi sayılmaz. Yine de bir yazma hakkından otomatik değişiklik başarısı veya domain compromise sonucu çıkmaz: nesne, işlem kısıtları, etkin yapılandırma ve servisin kullandığı credential ayrıca incelenir. Savunmada bu alanların kim tarafından, hangi gerekçeyle değiştirilebildiğini daralt ve değişiklikten sonraki davranışı doğrula.

Yetkiyi nesne değil attribute düzeyinde düşün

Delege edilmiş bir yardım masası hesabına 'yalnız telefon numarasını güncelle' diye verilen yetki, ACE'nin kapsamı property set veya tek attribute yerine geniş tanımlandığında güvenlik davranışını yöneten alanlara da uzanabilir. Değerlendirmede 'kim, hangi nesnenin, hangi attribute'una yazabiliyor' sorusu tek tek yanıtlanmalıdır.

Bir attribute'un tehlikeli olup olmadığı adından değil, hangi mekanizmayı beslediğinden anlaşılır. Bu yüzden schema mantığı bir güvenlik konusudur: attribute'un syntax'i ve onu okuyan servis, riskin gerçek sınırını belirler.

Şema etiketi ile işlem sonucunu ayır

RBCD’ye ait msDS-AllowedToActOnBehalfOfOtherIdentity alanı bir security descriptor taşır. Microsoft’un şema belgesinde systemOnly=TRUE olarak tanımlanır; MS-ADTS, system-only alanlara yönelik genel Modify kısıtlarını ayrıca açıklar. Buna karşılık Set-ADComputer belgesi, PrincipalsAllowedToDelegateToAccount parametresinin bu alanı yapılandırdığını belirtir. Bu bilgilerden “GenericWrite gördüm, her LDAP işlemi kesin başarılı olur” sonucu çıkarma. Yapılandırmayı yönetme yetkisini, kabul edilen değişikliği ve KDC’nin sonraki delegation kararını ayrı kanıtlarla incele. Bir ACE’de geçen hak adı, bu üç sonucun yerine geçmez.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Directory attribute değişiklikleri Audit Directory Service Changes alt kategorisinde izlenir ve bu alt kategori yalnız domain controller'larda olay üretir.
• 5136 olayının üretilmesi için hedef nesnenin SACL'inde ilgili 'Write' denetim girdisinin bulunması gerekir; SACL yoksa değişiklik sessizce loglanmaz.
• Bir tek değişiklik çoğunlukla iki 5136 üretir: aynı Correlation ID ile önce 'Value Deleted' (eski değer) sonra 'Value Added' (yeni değer).
• Bu alt kategori domain controller'larda yüksek hacimlidir; kapsam SACL ile hedeflenmezse gürültü analizi zorlaştırır.

Events and relevant fields

• 5136 Subject bölümünde SubjectUserSid, SubjectUserName, SubjectDomainName ve SubjectLogonId; değişikliği yapan principal'ı verir ve SubjectLogonId 4624 ile korele edilebilir.
• Object bölümünde ObjectDN, ObjectGUID ve ObjectClass; hangi nesnenin değiştiğini isimden bağımsız GUID ile sabitler.
• Attribute bölümünde AttributeLDAPDisplayName, AttributeSyntaxOID ve AttributeValue; değişen alanı schema tanımına bağlar.
• Operation bölümünde OperationType (%%14674 Value Added / %%14675 Value Deleted) ve Correlation ID; ilişkili 5137 (create), 5139 (move) ve 5141 (delete) olayları aynı alt kategoridedir.

Kaydı schema'ya bağlayarak oku

5136'yı okurken AttributeLDAPDisplayName ve AttributeSyntaxOID alanları, değişen alanı schema'daki attributeSchema tanımına bağlar. Bu, 'hangi mekanizma etkilendi' sorusunu yanıtlamanın en hızlı yoludur: syntax integer ise bir bayrak/sayaç, DN ise bir ilişki, SID ise bir kimlik alanı değişmiş olabilir.

ObjectGUID alanı, nesnenin adı değişmiş olsa bile kaydı doğru nesneye sabitler. Bu yüzden bir soruşturmada isim yerine GUID'i anahtar olarak kullanmak, yeniden adlandırma veya taşımaların yanıltıcı etkisini ortadan kaldırır.

Detection logic · XPath

*[System[EventID=5136]] and *[EventData[Data[@Name='AttributeLDAPDisplayName']='msDS-AllowedToActOnBehalfOfOtherIdentity']]

Query assumptions

• İfade tek bir Windows Event Log belgesinde seçim yapar; çok-host veya zaman-penceresi korelasyonu yapmaz.
• Named-field seçimi yalnız EventData/Data/@Name değerleri gerçekten bu adlarla üretiliyorsa çalışır; backend'in alanları düzleştirme biçimi doğrulanmalıdır.
• 5136 üretimi hedef nesnenin SACL'ine bağlıdır; SACL kapsamadıysa olay hiç oluşmaz ve sorgu boş döner.
• Sorgu bu oturumda gerçek bir DC veya SIEM üzerinde çalıştırılmadı; eşik ve veri kümesi yoktur.

False positives

• Meşru yönetim, provisioning ve HR entegrasyonları çok sayıda 5136 üretir; olay tek başına kötü niyet göstermez.
• Toplu değişikliklerde her attribute için ayrı Value Deleted/Value Added çiftleri normaldir.
• servicePrincipalName gibi alanların meşru servis kurulumları sırasında değişmesi beklenir; bağlam (kim, hangi hesap, hangi zaman) olmadan alarm zayıftır.
• Olayın yokluğu değişiklik olmadığını değil, SACL'in o attribute'u kapsamadığını da gösterebilir.

Hardening

• Yüksek değerli nesne ve attribute'lara (AdminSDHolder, Domain Admins, KRBTGT, delegasyon attribute'ları) hedeflenmiş SACL uygulayarak sinyali gürültüden ayır; her nesneyi denetlemek yerine envanter temelli seç.
• Attribute ve property-set düzeyinde delegasyonu least-privilege ilkesiyle gözden geçir; help-desk rollerinin güvenlik davranışını yöneten alanlara yazamadığını doğrula.
• Schema değişiklik haklarını (Schema Admins) kalıcı değil, aşamalı ve denetimli ver; schema genişletmeyi change-control ile eşle.
• Değişiklikleri geri alınabilir tutmak için AD backup ve recycle bin durumunu doğrula; kontrolü uygulamadan önce pilot OU'da etkisini ölç.

Ö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>5136</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>14081</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
  </System>
  <EventData>
    <Data Name="OpCorrelationID">{4b2f7d90-0c2a-4c7f-9f1e-8c5a2b3d6e10}</Data>
    <Data Name="AppCorrelationID">-</Data>
    <Data Name="SubjectUserSid">S-1-5-21-3623811015-3361044348-303003820-1108</Data>
    <Data Name="SubjectUserName">deleg-hr</Data>
    <Data Name="SubjectDomainName">OUTREASON</Data>
    <Data Name="SubjectLogonId">0x3b8f2</Data>
    <Data Name="DSName">outreason.example</Data>
    <Data Name="DSType">%%14676</Data>
    <Data Name="ObjectDN">CN=İlkkan,OU=Staff,DC=outreason,DC=example</Data>
    <Data Name="ObjectGUID">{7d3a1f6c-2b45-4e88-9a0c-1e2f3a4b5c6d}</Data>
    <Data Name="ObjectClass">user</Data>
    <Data Name="AttributeLDAPDisplayName">department</Data>
    <Data Name="AttributeSyntaxOID">2.5.5.12</Data>
    <Data Name="AttributeValue">Guvenlik Operasyonlari</Data>
    <Data Name="OperationType">%%14674</Data>
  </EventData>
</Event>

İki yanlış kanı / Two reality checks

Sanılan: objectClass'ı düzenleyerek bir user nesnesini group'a ya da başka bir türe dönüştürebilirim.

Gerçekte: Structural sınıf ve objectCategory nesne oluşturulurken belirlenir ve değiştirilemez. Dynamic auxiliary class objectClass'a eklenip çıkarılabilir, ancak nesnenin structuralObjectClass'ını değiştirmez; user'ı group gibi başka bir structural tür yapmak için ayrı bir nesne gerekir.

Sanılan: Bir user'a schema'da tanımlı olmayan istediğim herhangi bir attribute'u yazabilirim.

Gerçekte: Her attribute schema'daki bir attributeSchema ile tanımlıdır; bir nesneye yalnız sınıf zincirinin mustContain/mayContain kümesindeki attribute'lar yazılabilir ve değer o attribute'un syntax'ine uymak zorundadır. Bu bir erişim reddi değil, schema düzeyinde tanım reddidir.

Kaynaklar / Sources

• Microsoft · Active Directory Domain Services overview
  Directory'nin nesne/attribute modeli ve schema'nın yeri
• Microsoft · Characteristics of Attributes
  attributeSchema; lDAPDisplayName, schemaIDGUID, syntax ve isSingleValued
• Microsoft · Structural, Abstract, and Auxiliary Classes
  objectClassCategory (1/2/3) ve mustContain/mayContain birleşimi
• Microsoft · Object Class and Object Category
  Multi-valued objectClass superclass zinciri ve tek değerli objectCategory
• Microsoft · 5136(S) A directory service object was modified
  Event XML, Field Descriptions ve OperationType değerleri
• Microsoft · Audit Directory Service Changes
  SACL koşulu, yalnız DC üzerinde üretim ve kapsam
• IETF · RFC 4511 Lightweight Directory Access Protocol (LDAP): The Protocol
  Add/Modify işlemleri ve attribute-value modeli bağlamı
• Microsoft · Determining the Classes Associated With an Object Instance
  structuralObjectClass versus objectClass; dynamically attached auxiliary classes and statically linked auxiliary classes
• Microsoft · Adding an Auxiliary Class to an Object Instance
  An existing object instance can receive a dynamic auxiliary class through objectClass
• Microsoft Open Specifications · [MS-ADTS] Auxiliary Classes
  §3.1.1.3.1.1.5; dynamic auxiliary classes are added/removed through objectClass; objectClass contains structural, abstract, and dynamic auxiliary classes
• Microsoft · Deciding What to Find
  Finding user objects; AND of objectClass=user and objectCategory=person
• Microsoft · MS-ADA2 RBCD attribute
  §2.218; systemOnly TRUE; descriptor semantics; Windows Server 2012 first implementation
• Microsoft · MS-ADTS Modify constraints
  §3.1.1.5.3.2 system-only constraint and listed exceptions; no RBCD exception stated in this passage
• Microsoft · Set-ADComputer
  PrincipalsAllowedToDelegateToAccount parameter documentation; no inference of exact protocol or caller ACL check