CN, DN, UPN ve sAMAccountName: Bir hesabın neden birden fazla adı var?

1. Core Mechanism / Temel mekanizma

Bu ders yalnız kullanıcı adlandırma attribute'larını ele alır: distinguishedName, cn/name, userPrincipalName ve sAMAccountName. Bunların değişmez karşılığı olan objectSid ve objectGUID 03.03'e; adların taşındığı LDAP bağlantısı ve arama 03.05'e; Global Catalog'un forest genelindeki rolü 03.04'e bırakılır. Amaç, hangi adın hangi işi yaptığını ve hangi kapsamda benzersiz olduğunu netleştirmektir.

Arabirimler ve belirtimler

• distinguishedName (DN): nesnenin dizindeki tam konumu; RDN'lerin virgülle bağlanmış dizisidir (RFC 4514).
• relativeDistinguishedName (RDN): nesnenin parent içindeki adı. Bu dersteki AD user örneğinde naming attribute cn, RDN ise CN=Büşra’dır. Genel LDAP string syntax’ında bir RDN bir veya daha fazla attribute-value assertion içerebilir.
• cn (commonName): kullanıcı nesnesinin adlandırma attribute'u; RDN'i buradan oluşur.
• userPrincipalName (UPN): prefix@suffix biçimindeki logon adı; forest genelindeki benzersizlik kontrolünün sürüm ve işlem koşulları vardır.
• sAMAccountName: 20 karakteri geçmeyen, domain içinde benzersiz down-level logon adı.
• upnSuffixes / Partitions container: alternatif UPN suffix'lerinin tanımlandığı Configuration bölümü girdisi.

distinguishedName bir konumdur, kimlik değil

DN, RDN’lerin virgülle bağlandığı dizin adresidir: CN=Büşra,OU=Staff,DC=outreason,DC=example. Burada CN=Büşra user nesnesinin RDN’i, geri kalanı parent yoludur. RFC 4514’ün genel string syntax’ında aynı RDN birden fazla attribute-value assertion içerirse bunlar + ile ayrılır; bu AD user örneğinin naming attribute’u ise cn’dir. Nesneyi taşımak parent yolunu, rename yapmak RDN’i değiştirir; ikisi de DN’e yansır.

Bir uygulama nesnenin DN’ini dış yapılandırmada sakladıysa rename veya move sonrasında eski adresle nesneyi bulamayabilir. Kalıcı directory referansı için objectGUID kullanmak bu sorunu ayırır. Windows DACL’deki ACE ise principal’ı DN ile değil trustee SID ile tanımlar. Uygulamanın sakladığı adres, nesnenin directory kimliği ve kaynak yetkilendirmesindeki SID aynı şey değildir.

cn ve yeniden adlandırma

cn, kullanıcı nesnesinin adlandırma attribute'udur ve nesnenin RDN'ini oluşturur. En soldaki RDN'i değiştirmek nesneyi 'rename' eder; nesneyi başka bir OU'ya almak ise 'move'dur. Her iki işlem de DN'i değiştirir, ama nesnenin objectGUID'i sabit kalır.

Aynı domain içinde rename veya başka OU’ya move yapıldığında DN değişir, objectGUID ve objectSid korunur. Domainler arası move farklıdır: objectGUID nesneyle kalır, yeni domain yeni objectSid verir ve önceki SID sIDHistory’ye eklenir. Silip aynı adla yeniden oluşturmak ise yeni bir nesne üretir; hem GUID hem SID yenidir. Bu üç sonucu yalnız görünen ada bakarak ayıramazsın.

userPrincipalName: internet tarzı logon adı

UPN, busra@outreason.example gibi prefix@suffix biçimindeki logon adıdır. Benzersizlik hedefi, tam değerin forest genelinde tek olmasıdır; busra@a.example ile busra@b.example farklı değerlerdir. Bu hedef, dizinde hiçbir zaman çakışan UPN bulunamayacağı anlamına gelmez.

MS-ADTS, forest genelindeki kontrolü DC functional level değeri DS_BEHAVIOR_WIN2012R2 veya üzeri olan DC’deki originating Add, Modify ve Undelete işlemleri için tanımlar. İlgili OS güncellemeleri ve yapılandırma da önemlidir. Yapılandırma istisnasıyla UPN kontrolü yapılmayabilir; replicated update sırasında bu benzersizlik kısıtı zorlanmaz. Adlandırma kuralını mutlak garanti saymak yerine gerçek DC sürümünü, güncellemelerini, yapılandırmasını ve dizin değerlerini kontrol et.

UPN suffix'i, kullanıcının bulunduğu domain'in adı olmak zorunda değildir; forest içindeki bir domain adı ya da Partitions container'daki upnSuffixes ile tanımlı alternatif bir ad olabilir. Bir UPN atandığında kullanıcı yeniden adlandırılsa veya taşınsa bile UPN etkilenmez; ancak bir yönetici UPN'i açıkça değiştirebilir. Oturum açarken UPN önce yerel domain'de, sonra Global Catalog'da doğrulanır; GC'de bulunamazsa oturum açma başarısız olur.

sAMAccountName: down-level logon adı

sAMAccountName, Windows NT 4.0, 95/98 ve LAN Manager gibi önceki sürümlerdeki istemci ve sunucuları desteklemek için kullanılan logon adıdır; DOMAIN\kullanıcı biçiminde down-level oturum açmada görünür. En fazla 20 karakter olabilir ve yalnız kendi domain'i içindeki tüm security principal'lar arasında benzersizdir.

Buradaki kritik nokta kapsamdır: sAMAccountName forest genelinde değil, domain içinde benzersizdir. Bu yüzden farklı iki domain'de aynı sAMAccountName bulunabilir; bir kimliği yalnız sAMAccountName ile eşleştirmek, çok domain'li bir ortamda yanlış principal'a işaret edebilir.

Durum ve veri akışı

1. Kullanıcı busra@outreason.example gibi bir UPN ile oturum açar; sistem UPN'i yerel domain'de ve gerekirse Global Catalog'da doğrular.
2. Down-level bir istemci ise oturum OUTREASON\busra.old biçiminde sAMAccountName ile kurulur; bu ad yalnız OUTREASON domain'i içinde benzersizdir.
3. Bir uygulama nesneyi dizinde ararken konum için distinguishedName veya kalıcı kimlik için objectGUID (03.03) kullanır.
4. Yönetici nesneyi yeniden adlandırır veya aynı domain içinde başka OU’ya taşır; DN değişir, objectGUID ve objectSid sabit kalır. Domainler arası move’un SID sınırı ayrıdır.
5. Yönetici UPN değiştirirken tam değerin forest genelindeki benzersizliğini korumalıdır; işlemin bunu zorlayıp zorlamadığı originating DC’ye ve belgelenmiş koşullara bağlıdır. sAMAccountName’in domain kapsamındaki adlandırma kuralları ayrıdır.
6. 4781 kaydı sAMAccountName değişimini gösterir; TargetSid kaydı hesaba bağlar. UPN değişimi için ilgili audit/SACL koşullarında ayrı 5136 kanıtı gerekir.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım şudur: Bir hesabı adıyla eşleştirmek onu benzersiz ve doğru principal olarak sabitler.

Technical prerequisites

• Yetkilendirme veya eşleştirme mantığının SID/objectGUID yerine bir ada (sAMAccountName, UPN prefix, cn veya DN) dayanması.
• Kimliği adın yalnız bir parçasıyla eşleştirmek: sAMAccountName domain kapsamındadır; UPN prefix’i tek başına suffix’i dışarıda bırakır. Tam UPN için de benzersizlik kontrolünün belgelenmiş istisnaları vardır.
• Bir nesnenin silinip aynı adla yeniden oluşturulabilmesi veya rename ile adının başka bir eski referansa denk gelmesi.
• Çok domain'li veya trust'lı bir ortamda aynı sAMAccountName'in farklı domain'lerde bulunabilmesi.

Exploitation mechanism / İstismar mekanizması

Adlar değişebilir ve benzersizlik kapsamları dardır. Rename ve aynı domain içindeki OU move sırasında objectSid ve objectGUID sabit kalır; nesne başka bir domain'e taşındığında objectSid değişebilir ve önceki SID sIDHistory'ye eklenir (03.03). objectGUID ise rename ve move sırasında değişmez. Bir erişim veya eşleştirme kararı ada göre verildiğinde, rename/recreate sonrası aynı ad başka bir nesneye denk gelebilir ya da farklı domain'deki aynı sAMAccountName karıştırılabilir. Sonuç, yanlış principal'a yetki tanınması veya bir kaydın yanlış hesaba atfedilmesidir. Kapsam, kararı ada bağlayan uygulama/konfigürasyondur; engelleyici kontrol, isimden bağımsız kimlik kullanmak ve domain migration sırasında SID değişimi ile sIDHistory ilişkisini uzlaştırmaktır.

Adı anahtar yapma, kimliği anahtar yap

Bir sistemin 'kullanıcı adı X ise izin ver' mantığı, X bir ad olduğu sürece kırılgandır. Ad yeniden atanabilir, farklı bir kapsamda tekrarlanabilir veya rename ile taşınabilir. Rename ve aynı-domain OU move'da objectSid/objectGUID sabit kalır; domainler arası move'da objectSid değişebilir, objectGUID ise değişmez. Bu yüzden log korelasyonu ve yetkilendirme, mümkün olduğunca objectSid veya objectGUID gibi isimden bağımsız kimliklere dayanmalıdır; domain migration varsa SID geçmişi ayrıca uzlaştırılmalıdır.

Değerlendirmede 'bu karar hangi alana bakıyor?' sorusu tek tek yanıtlanmalıdır. Ada bakan her nokta, rename/recreate ve çok-domain senaryolarında yanlış eşleşme riskini taşır; bunu 03.03'teki kimlik sabitleriyle kapatmak gerekir.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• sAMAccountName değişikliği Audit User Account Management alt kategorisinde 4781 (The name of an account was changed) olarak kaydedilir.
• 4781 kullanıcı hesapları için domain controller, üye sunucu ve iş istasyonlarında; bilgisayar hesapları için yalnız domain controller'larda üretilir.
• userPrincipalName gibi diğer adlandırma attribute'larının değişimi 4781 değil, Directory Service Changes altında 5136 olarak yüzeye çıkar ve nesnenin SACL'ini gerektirir.
• Nesne taşımaları (DN değişimi) aynı Directory Service Changes alt kategorisinde 5139 (object was moved) olarak izlenir.

Events and relevant fields

• 4781 Target Account bölümünde OldTargetUserName ve NewTargetUserName; eski ve yeni sAMAccountName değerlerini verir.
• 4781 TargetSid alanı, ad değişse bile aynı kalan hesabın objectSid'ini taşır; bu, olayı isimden bağımsız kimliğe bağlar.
• Subject bölümünde SubjectUserSid, SubjectUserName, SubjectDomainName ve SubjectLogonId; değişikliği yapan principal'ı verir.
• PrivilegeList çoğunlukla '-' değerindedir; 4781 Version 0'dır ve Task 13824 taşır.

Rename'i sabit kimlikle çapala

4781'i okurken OldTargetUserName ve NewTargetUserName adın değiştiğini gösterir, ama asıl çapa TargetSid'dir: bu alan değişmediği için olayı doğru hesaba bağlar. Bir soruşturmada 'hangi hesap' sorusunu ada göre değil TargetSid'e göre yanıtlamak, rename kaynaklı yanılmayı önler.

UPN değişimini de kapsamak isteyen bir tespit, yalnız 4781'e bakmamalı; userPrincipalName bir attribute olduğundan değişimi 5136 olarak görünür ve nesnenin SACL'ine bağlıdır. İki olay ailesini birlikte izlemek, 'ad değişti' senaryosunun tamamını görmeyi sağlar.

Detection logic · XPath

*[System[EventID=4781]]

Query assumptions

• İfade yalnız Event ID seçer; TargetSid bazlı korelasyon için EventData alanları backend tarafında ayrıca düzleştirilmelidir.
• 4781 sAMAccountName değişimine özgüdür; UPN değişimini yakalamak için 5136 (AttributeLDAPDisplayName='userPrincipalName') ayrıca izlenmelidir.
• Sorgu tek bir Windows Event Log belgesinde seçim yapar; çok-host zaman korelasyonu yapmaz.
• İfade bu oturumda gerçek bir sistem veya SIEM üzerinde çalıştırılmadı; eşik ve veri kümesi yoktur.

False positives

• Evlilik, soyad değişikliği veya organizasyon değişimi gibi nedenlerle meşru rename'ler olağandır.
• Hesap provisioning ve toplu düzenleme sırasında sAMAccountName değişimleri beklenir.
• Ad değişiminin kendisi kötü niyet göstermez; risk, aynı TargetSid'in beklenmedik bir ada geçmesi ya da hassas bir hesabın yeniden adlandırılmasıdır.
• Bağlam (kim değiştirdi, hangi hesap, hangi zaman) olmadan tek 4781 alarmı zayıftır.

Hardening

• Yetkilendirme ve log korelasyonunu sAMAccountName/UPN gibi adlara değil objectSid/objectGUID'e bağla; ada dayalı kuralları envanterle ve aşamalı olarak taşı.
• Tam UPN değerlerini forest genelinde envanterle; çakışmaları ve beklenmedik suffix’leri incele. Yazma anındaki kontrolün mevcut çakışmaları araştırmayı gereksiz kıldığını varsayma.
• Naming attribute'larını (sAMAccountName, userPrincipalName, cn) kimlerin değiştirebileceğini least-privilege delegasyonla sınırla; hassas hesap rename'lerini özel olarak izle.
• Değişiklikleri geri alınabilir tutmak için AD backup/recycle bin durumunu doğrula; kontrol kuralını uygulamadan önce pilot kapsamda yanlış-pozitif 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>4781</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>13824</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
  </System>
  <EventData>
    <Data Name="OldTargetUserName">busra.old</Data>
    <Data Name="NewTargetUserName">busra</Data>
    <Data Name="TargetDomainName">OUTREASON</Data>
    <Data Name="TargetSid">S-1-5-21-3623811015-3361044348-303003820-1155</Data>
    <Data Name="SubjectUserSid">S-1-5-21-3623811015-3361044348-303003820-500</Data>
    <Data Name="SubjectUserName">Administrator</Data>
    <Data Name="SubjectDomainName">OUTREASON</Data>
    <Data Name="SubjectLogonId">0x2f1a4</Data>
    <Data Name="PrivilegeList">-</Data>
  </EventData>
</Event>

İki yanlış kanı / Two reality checks

Sanılan: sAMAccountName forest genelinde benzersizdir, bu yüzden bir kullanıcıyı yalnız bu adla güvenle eşleştirebilirim.

Gerçekte: sAMAccountName kendi domain’i kapsamındadır ve 20 karakterlik adlandırma sınırı vardır. Tam UPN için hedef forest genelinde benzersizliktir; kontrolün belgelenmiş koşulları ve replication istisnası bulunur. Adın bir parçasını veya bu hedefi kalıcı kimlik garantisi sayma; uygun domain bağlamıyla objectSid/objectGUID kullan.

Sanılan: Bir hesabı yeniden adlandırmak (cn/sAMAccountName/UPN) onun SID'ini ve mevcut erişimlerini değiştirir.

Gerçekte: Rename ve aynı domain içindeki OU move ad/konumu değiştirir; objectSid ve objectGUID sabit kalır. Domainler arası move sırasında yeni objectSid atanabilir ve eski SID sIDHistory'ye eklenir; objectGUID rename/move boyunca sabittir. 4781 kaydındaki TargetSid, rename sırasında aynı hesabı gösterir. Bu nedenle SID'e dayalı ACE'ler rename sonrasında çalışmaya devam eder (03.03).

Kaynaklar / Sources

• Microsoft · User Naming Attributes
  Naming attributes and design uniqueness scope; enforcement exceptions qualified separately by MS-ADTS Uniqueness Constraints; stable identity and cross-domain move behavior
• IETF · RFC 4514 LDAP: String Representation of Distinguished Names
  §2 DN = RDN dizisi; §2.3 RDN = attributeType=value
• Microsoft · 4781(S) The name of an account was changed
  Event XML, Field Descriptions; OldTargetUserName/NewTargetUserName ve sabit TargetSid
• Microsoft · Audit User Account Management
  Alt kategori tanımı ve 4781'in bağlı olduğu Events List
• Microsoft · 5136(S) A directory service object was modified
  AttributeLDAPDisplayName ile userPrincipalName gibi attribute değişiminin izlenmesi
• IETF · RFC 4511 Lightweight Directory Access Protocol (LDAP): The Protocol
  Modify DN işlemi ve rename/move semantiği bağlamı
• Microsoft Open Specifications · MS-ADTS Uniqueness Constraints
  §3.1.1.5.1.3: originating versus replicated updates, DC functional level, configuration and update scope