Kerberos delegation: Unconstrained, constrained, RBCD ve S4U’nun amacı.

1. Core Mechanism / Temel mekanizma

Delegation kararı üç yerde birden yaşar: bileti düzenleyen KDC (domain controller), yetkiyi tanımlayan AD öznitelikleri (userAccountControl bitleri, msDS-AllowedToDelegateTo, msDS-AllowedToActOnBehalfOfOtherIdentity) ve akışı yürüten TGS genişletmeleri S4U2self ile S4U2proxy. Bu dersin sınırı 'yetki nerede durur ve her model neyi değiştirir' sorusudur: PAC/authorization data ayrıntısı 06.05'te, SPN sahipliği 06.03'te, bilet ömrü ve hata durumları 06.07'dedir.

Arabirimler ve belirtimler

• RFC 4120 §2.6: forwardable / forwarded ticket flag'leri; delege edilen kimlik forwarded bir TGT ile taşınır.
• RFC 4120 §2.8: ok-as-delegate ticket flag; KDC, servis hesabı unconstrained delegation'a güvenilir işaretlendiğinde bu flag'i set eder ve istemciye 'bu servise credential delege etmek realm politikasınca uygundur' der.
• MS-SFU §1.3: S4U2self (protocol transition) ve S4U2proxy (constrained delegation) TGS genişletmeleri; ikisi ayrı adımdır.
• userAccountControl bitleri: TRUSTED_FOR_DELEGATION 0x80000 (unconstrained), TRUSTED_TO_AUTH_FOR_DELEGATION 0x1000000 (protocol transition), NOT_DELEGATED 0x100000 (hesap delege edilemez).
• msDS-AllowedToDelegateTo: klasik constrained delegation'da front-end hesabında duran, izinli hedef SPN listesi.
• msDS-AllowedToActOnBehalfOfOtherIdentity: RBCD'de back-end hesabında duran ve izinli front-end SID'lerini taşıyan security descriptor (String(NT-Sec-Desc), 2.5.5.15).
• Windows Security 4769 · Transited Services alanı: S4U2proxy ile düzenlenen bilette delegation'ın hangi servis üzerinden yapıldığını gösterir; yalnızca domain controller üzerinde.

Delegation neyi çözer: double-hop problemi

tunahan kullanıcısı WEB01 üzerindeki bir uygulamaya Kerberos ile eriştiğinde, istemci WEB01 için bir service ticket sunar. Bu bilet yalnızca 'tunahan WEB01'e kimliğini kanıtladı' bilgisini taşır. WEB01 arka planda DB01 üzerindeki veritabanına tunahan adına gitmek isterse elinde tunahan'ın DB01 için bir bileti yoktur.

Delegation olmadan bu ikinci sıçrama (double-hop) çözülemez: WEB01 kendi kimliğiyle DB01'e gidebilir, ama 'tunahan adına' gidemez. Delegation, kullanıcı kimliğini ikinci servise taşımanın protokolce onaylanmış yoludur. Fark, bu taşımaya kimin ve ne kadar izin verdiğidir.

Üç delegation modeli bu kararı farklı yerlerde tutar. S4U2self ve S4U2proxy ise özellikle constrained delegation ve RBCD akışlarında kullanılan protocol extension'lardır; dördüncü bir model değildir. Hangi kurulumun kullanıldığını anlamak için 'servis kullanıcı adına gidebiliyor mu?' değil, 'bu gitmeye izin veren kayıt hangi nesnede?' diye sor.

Unconstrained: kimlik sınırsız taşınır

TRUSTED_FOR_DELEGATION, servisin delegated credential almasına ilişkin realm güvenini ifade eder. OK-AS-DELEGATE bu policy bilgisini istemciye taşır; istemci bunu delegation kararında kullanabilir veya yok sayabilir. Flag’in bulunması, TGT’nin gerçekten gönderildiğini göstermez (RFC 4120 §2.8).

İstemci gerçekten forwarded TGT delege etmişse front-end bu credential ile kullanıcı adına sonraki servisler için ticket isteyebilir. Bu model classic constrained SPN listesiyle daraltılmaz. Yine de hedefin authentication ve resource authorization koşulları ortadan kalkmaz.

Bu yüzden değerlendirmede üç kanıtı ayır: account configuration, istemcinin gerçek delegation davranışı ve hedefteki sonuç. Yalnız bir flag okuması diğer ikisini kanıtlamaz.

Constrained delegation: hedef SPN listesi ve S4U akışı

Classic constrained delegation’ın hedef SPN listesi, front-end hesabındaki msDS-AllowedToDelegateTo değeridir. KDC istenen hedef SPN’i bu listeyle karşılaştırır; listenin back-end’deki RBCD descriptor’ı ile karıştırılması yanlış policy owner’ı incelemeye yol açar.

Protocol transition kullanılıyorsa front-end uygulama önce kullanıcıyı kendi authentication yöntemiyle yeterli biçimde doğrulamalıdır. S4U2self, kullanıcının Kerberos credential’ını almadan kullanıcıya ait authorization data sağlayabilir; ticket düzenlenmesi uygulamanın bu kullanıcıyı gerçekten doğruladığının kanıtı değildir. S4U2proxy ise ikinci servis için delegation kararıyla ilgilidir (MS-SFU §5.1).

Hedef listesi hangi servislerin delegation kapsamına girebildiğini sınırlar. Kullanıcıya uygulanan delegation kısıtları, ticket koşulları ve hedef resource izni ayrıca değerlendirilir; bir listenin bulunması bütün bu kapıların geçildiğini göstermez.

RBCD: kararı kaynak verir

RBCD’de değerlendirilen security descriptor back-end hesabındaki msDS-AllowedToActOnBehalfOfOtherIdentity değeridir. Örnekte WEB01 front-end, DB01 back-end’dir; policy’nin sahibi DB01 hesabıdır.

KDC, front-end servisin authorization context’iyle back-end descriptor üzerinde access check yapar. Trustee SID, uygulanabilir group SID’leri, ACE türü, requested rights ve ACE sırası genel DACL semantiğinin parçalarıdır. Tek allow ACE’de SID görmek, bütün access check’in başarılı olduğu anlamına gelmez. Bu ders RBCD’ye özgü exact desired-access mask hesaplamaz.

Configuration’ı değiştirme yetkisi ile KDC’nin o configuration’ı değerlendirmesi iki ayrı karardır. Descriptor owner’ı, değişikliği yapan kişinin kimliği değildir. Hedef account’ın yönetim yetkilerini incelerken kullanılan interface, effective permission ve gözlenen read-back’i birlikte değerlendir.

msDS-AllowedToActOnBehalfOfOtherIdentity  (String(NT-Sec-Desc), OID 2.5.5.15)
--------------------------------------------------------------------------------
O:BA                       owner: Built-in Administrators
D:(A;;CCDC...WDWO;;;SID)   DACL: tek ACCESS_ALLOWED (A) ACE
        type   = A         ACCESS_ALLOWED
        rights = CCDC..WO   AD araclarinin yazdigi genis nesne haklari kumesi
        trustee= S-1-5-...  IZINLI front-end principal'in SID'i
--------------------------------------------------------------------------------
KDC'nin S4U2proxy kontrolu: 'istek yapan front-end SID bu descriptor'da izinli mi?'
Karar 'degisikligi kim yapti' degil, 'SID allow ACE'de mi' sorusudur.

Üç delegation modelinde tek soru: kararı hangi nesne tutar

Unconstrained realm güveni front-end account configuration’ında, classic constrained hedef listesi front-end account’ta, RBCD descriptor’ı back-end account’ta durur. KDC kararı bu girdileri değerlendirir; client delegation davranışı, uygulama authentication’ı ve resource authorization ayrı kalır.

Bu yüzden bir ortamda delegation'ı değerlendirmek, 'delegation açık mı' demek değildir; 'her hedef için yetkiyi hangi nesne tutuyor ve o nesneye kim yazabiliyor' haritasını çıkarmaktır. Ders boyunca izlediğimiz tunahan → WEB01 → DB01 örneğinde bu harita, DB01 nesnesinin ACL'ine kadar iner.

Durum ve veri akışı

1. Front-end uygulamanın kullanıcı authentication’ını değerlendir. Bu kimlik kanıtı, S4U authorization data’sından ayrıdır.
2. WEB01 → DB01 ihtiyacını belirle. Kullanıcının WEB01’e erişmiş olması ikinci servis için yetki sağlamaz.
3. Policy’nin hangi hesapta olduğunu karşılaştır: classic constrained listesi WEB01’de, RBCD descriptor’ı DB01’de; unconstrained istemci kararını ayrıca içerir.
4. KDC policy kararını ayrı izle. Örnekteki izin/ret, önceden tanımlı bir gözlemdir; gerçek access check veya ticket isteği çalıştırılmaz.
5. Policy uygunluğu, kullanıcı kısıtları ve ticket koşullarının yerine geçmez. Uygulama authentication’ı gözlenmediyse kimlik doğrulanmış sayılmaz.
6. Audit kaydını kendi kapsamıyla oku: 5136 configuration değişikliği; 4769 constrained-delegation bağlamı olabilir. Boş Transited Services delegation yok demek değildir.
7. DB01’de resource authorization sonucunu ayrıca doğrula. Delegation kararı erişim izninin yerine geçmez.

2. Exploitation / İstismar

Broken trust assumption

Delegation configuration’ını yalnız resmî yönetici rolündeki kişilerin etkileyebileceğini varsaymak hatalıdır. RBCD policy’si back-end account üzerindeki descriptor’da tutulur; bu yapılandırmayı yönetebilen hesapların yetkisi bu yüzden güvenlik açısından önemlidir. Ancak yapılandırma yetkisi, gerçekten kabul edilmiş değişiklik, KDC’nin delegation kararı ve hedefteki kaynak yetkisi aynı şey değildir.

Technical prerequisites

• Delegation configuration’ını etkileyen account yönetim yetkileri. DACL yönetimi, attribute güncelleme ve KDC policy değerlendirmesi ayrı incelenir.
• Front-end account ve kayıtlı SPN sahibinin doğru belirlenmesi; account oluşturma yetkisi hedef policy yönetim yetkisi değildir.
• Uygulamanın kullanıcıyı hangi authentication yöntemiyle doğruladığına dair kanıt.
• User delegation kısıtlarının ve hedef resource haklarının ayrı değerlendirilmesi.

Exploitation mechanism / İstismar mekanizması

Risk, başka bir servisin kullanıcı kimliğini temsil edebilmesine ilişkin güvenin yanlış kişilere yönetim yetkisi olarak bırakılmasıdır. Örnekte front-end policy ile back-end descriptor ayrı hesaplarda durur; yalnız birinde değişiklik gözlemek bütün delegation modellerini açıklamaz. Uygulamanın kullanıcıyı nasıl doğruladığı ve hedefin hangi resource haklarını verdiği, configuration değerlendirmesinin dışındaki ayrı sınırlardır.

Yapılandırma yetkisi ile delegation kararını ayır

Account’ın DACL’ini yönetme yetkisi ile delegation attribute’unu güncelleme yetkisi aynı işlem değildir. Değerlendirme, object/attribute kapsamını, kullanılan yönetim interface’ini ve gözlenen effective sonucu ayrı tutmalıdı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.

Computer account yönetimini ayrı değerlendir

MachineAccountQuota ve delege edilmiş create yetkisi farklı yönetim yollarıdır. Sayısal quota tek başına her kullanıcının her OU’da account oluşturabildiğini göstermez. Yeni principal oluşturulabilmesi, hedef account’ın delegation configuration’ını değiştirme hakkı vermez.

Savunmada join süreçlerini, açık create delegation’ını ve kritik service account yönetimini ayrı envanterle. Quota değişikliği tek başına mevcut principal’ları veya başka bir delege edilmiş create yolunu ortadan kaldırmaz.

Nerede durur, nasıl sınırlanır

İmpersonate edilecek kimlik NOT_DELEGATED işaretliyse veya Protected Users grubundaysa KDC delegation'ı reddeder; bu, kritik hesaplar için gerçek bir sınırdır.

Etki hedef kaynakla sınırlıdır: DB01'e RBCD kurmak, DB01 üzerinde impersonate edilen kimliğin yapabildiklerini verir; tek başına 'domain ele geçti' demek değildir. Kapsam, hedefin Tier 0 olup olmadığına ve impersonate edilen kimliğin haklarına göre değerlendirilir.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Audit Directory Service Changes alt kategorisi (yalnız DC, ilgili nesne/attribute üzerinde SACL gerekir): msDS-AllowedToActOnBehalfOfOtherIdentity değişikliği 5136 üretir.
• Audit Computer Account Management: yeni bir computer account oluşturulması 4741, değiştirilmesi 4742 üretir; MachineAccountQuota ile oluşturulan hesap 4741 olarak görünür.
• Audit Kerberos Service Ticket Operations, DC üzerinde 4769 gözlemi sağlar. Transited Services constrained delegation bağlamıyla ilgilidir; boş veya “-” değer unconstrained delegation’ı dışlamaz.
• SACL yapılandırılmadıysa 5136 hiç üretilmez; 'her attribute değişikliği otomatik loglanır' varsayımı yanlıştır. Bu ders için gözlem noktası önce SACL kurulumudur.
• userAccountControl'de TRUSTED_FOR_DELEGATION veya TRUSTED_TO_AUTH_FOR_DELEGATION bitlerinin açılması hesap değişikliği (kullanıcıda 4738, bilgisayarda 4742) olarak görünür.

Events and relevant fields

• 5136 / AttributeLDAPDisplayName: değişen attribute'un adı; RBCD izi için msDS-AllowedToActOnBehalfOfOtherIdentity.
• 5136 / AttributeValue: yazılan yeni security descriptor'ın SDDL biçimi; izinli front-end SID buradan okunur.
• 5136 / OperationType: %%14674 Value Added, %%14675 Value Deleted. Ekleme mi silme mi olduğunu ayırır.
• 5136 / SubjectUserSid ve SubjectUserName: değişikliği yapan principal; beklenmedik bir hesabın Tier 0 nesnesine yazması bir sinyaldir.
• 5136 / ObjectDN ve ObjectClass: hangi nesnenin (ör. computer) hedeflendiği.
• 4769 / Transited Services: görünen alan etiketi; raw XML Data adı TransmittedServices’tir. S4U2proxy bağlamını araştırmak için kullanılabilir. Boş veya “-” değer tek başına delegation olmadığını kanıtlamaz; kullanılan Windows sürümü, audit ve collector eşlemesini doğrula.

Değişikliği önce gör: SACL olmadan 5136 yok

5136 kaydı, yalnızca ilgili nesne veya attribute üzerinde bir SACL varsa ve Audit Directory Service Changes açıksa üretilir. SACL yoksa RBCD'yi kuran değişiklik telemetride hiç görünmez.

Bu kayıt yalnızca domain controller üzerinde oluşur ve hacmi yüksektir. Toplama kapsamı ve filtre önceden planlanmazsa, kritik bir delegation değişikliği gürültü içinde kaybolur.

İki farklı iz: kurulum ile kullanım aynı olay değildir

5136 attribute değişikliği kaydıdır. 4769’daki Transited Services constrained delegation için istenen SPN listesiyle ilgilidir; raw alan adı TransmittedServices’tir. Configuration değişikliği, ticket isteği ve hedef resource sonucu ayrı kanıtlardır. Liste boşsa yalnız bu kayıtta liste gözlenmediğini söyle; “delegation yok” sonucunu çıkarma.

Doğru okuma, 'kim yazdı' (5136 SubjectUserSid) ile 'ne zaman ve hangi kullanıcı adına kullanıldı' (4769) sorularını ayrı tutup normal davranış temeline göre değerlendirmektir.

Detection logic · Sigma

title: RBCD attribute'una yazma (msDS-AllowedToActOnBehalfOfOtherIdentity)
id: 8a1e2c74-4b19-4d0a-9f22-3d7c1a0e5b44
status: experimental
description: >
  Directory Service Changes kaydinda (5136) msDS-AllowedToActOnBehalfOfOtherIdentity
  attribute'unun degistirilmesini arar. Tek basina kanit degildir; mesru RBCD kurulumu
  da ayni kaydi uretir. SubjectUserSid ve ObjectDN ile normal davranis temeline gore
  degerlendirilmelidir.
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5136
    AttributeLDAPDisplayName: 'msDS-AllowedToActOnBehalfOfOtherIdentity'
  condition: selection
fields:
  - SubjectUserSid
  - SubjectUserName
  - ObjectDN
  - AttributeValue
  - OperationType
falsepositives:
  - Yoneticiler veya otomasyon tarafindan yapilan mesru RBCD kurulumu
  - Gecis/migration araclarinin toplu delegation ayari
level: medium

Query assumptions

• Kural, ilgili nesne/attribute üzerinde SACL yapılandırıldığını ve Audit Directory Service Changes'in açık olduğunu varsayar; aksi halde 5136 hiç üretilmez.
• 5136 yalnızca domain controller üzerinde oluşur; kaynak host'ta bu kayıt aranmaz.
• Alan adları Windows Security kanalındaki EventData adlarıdır; normalize eden bir backend kullanılıyorsa field mapping ayrıca yapılmalıdır.
• AttributeValue içindeki SDDL ayrıştırılmadan eşleşir; izinli SID'i çıkarmak için ek parse gerekir. Bu kural bu oturumda gerçek bir SIEM üzerinde çalıştırılmadı.

False positives

• Yöneticinin veya bir otomasyonun bilinçli RBCD kurulumu aynı kaydı üretir; bu normaldir.
• Bir servis geçişinde toplu delegation ayarı yapan araçlar deseni tetikler.
• Negatif örnek: attribute WriteDACL ile önce erişilir sonra değiştirilirse, SACL yalnızca değişiklik olayını yakalar; DACL manipülasyonu ayrı bir gözlem gerektirir. Kural bir kapsam sınırıdır, kanıt değildir.

Hardening

• Kritik hesapları 'Account is sensitive and cannot be delegated' (NOT_DELEGATED) olarak işaretle ve Protected Users grubuna al; bu, impersonation'ı bilet düzeyinde reddettirir.
• MachineAccountQuota’yı ve açık create delegation’larını join ihtiyaçlarıyla birlikte değerlendir. Quota 0, mevcut principal’ları veya başka delege edilmiş create yollarını ortadan kaldırmaz; hedef service-account yönetim yetkileri ayrıca daraltılır.
• Kritik account’ların DACL ve delegation configuration yönetimini en az yetkiyle sınırla. Hak adlarından effective yazma sonucu çıkarma; desteklenen management interface ve gerçek yetki sınırlarını ayrıca doğrula.
• Delegation attribute'ları için SACL kur ve 5136'yı topla; değişiklik önce görünür olmalı. Yüksek hacim nedeniyle toplama ve saklama önceden planlanır.
• Unconstrained delegation kullanan servisleri ve client credential aktarımını envanterle. Uygulama ihtiyacını doğrulayarak daha sınırlı delegation modellerini değerlendir; yalnız flag bulunması TGT aktarımı kanıtı değildir.
• Değişiklik sonrası configuration’ı yeniden oku; beklenen descriptor ve yönetim kapsamıyla karşılaştır. Uygun audit/SACL/collection altında değişiklik kaydını kontrol et. SID listesi tek başına effective KDC veya resource kararı değildir.

Örnekler üzerinde oku / Read the examples

O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-1109110911-2202220222-3303330333-1140)

<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>
    <TimeCreated SystemTime="2026-09-29T05:58:11.9930000Z" />
    <EventRecordID>44120</EventRecordID>
    <Correlation ActivityID="{5b2d9a41-77aa-4c19-9d0e-2b7c6a1f3e77}" />
    <Execution ProcessID="712" ThreadID="1332" />
    <Channel>Security</Channel>
    <Computer>DC01.iyelabs.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="OpCorrelationID">{9f14c7a2-0e33-4a51-8b6d-7c0d2a44e109}</Data>
    <Data Name="AppCorrelationID">-</Data>
    <Data Name="SubjectUserSid">S-1-5-21-1109110911-2202220222-3303330333-1105</Data>
    <Data Name="SubjectUserName">birkan</Data>
    <Data Name="SubjectDomainName">IYELABS</Data>
    <Data Name="SubjectLogonId">0x3f9c1</Data>
    <Data Name="DSName">iyelabs.example</Data>
    <Data Name="DSType">%%14676</Data>
    <Data Name="ObjectDN">CN=DB01,CN=Computers,DC=iyelabs,DC=example</Data>
    <Data Name="ObjectGUID">{7c2a1e90-4d5b-4a37-9be2-71c4ad0f3e12}</Data>
    <Data Name="ObjectClass">computer</Data>
    <Data Name="AttributeLDAPDisplayName">msDS-AllowedToActOnBehalfOfOtherIdentity</Data>
    <Data Name="AttributeSyntaxOID">2.5.5.15</Data>
    <Data Name="AttributeValue">O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-21-1109110911-2202220222-3303330333-1140)</Data>
    <Data Name="OperationType">%%14674</Data>
  </EventData>
</Event>

İki yanlış kanı / Two reality checks

Sanılan: RBCD'de delegation kararını yalnızca domain admin verir.

Gerçekte: RBCD configuration’ını yönetme yetkisi yalnız bir unvanla açıklanmaz. Policy back-end account üzerindedir; kimlerin bu configuration’ı etkileyebildiği account’ın yönetim sınırlarıyla değerlendirilir. KDC ise front-end authorization context’i ile descriptor üzerinde ayrı bir access check yapar. Bir trustee SID’in bulunması ne yazma yetkisini ne de bütün KDC kararını tek başına kanıtlar.

Sanılan: Constrained delegation kurulmuşsa servis yalnızca listelenen SPN'e gidebilir, dolayısıyla güvenlidir.

Gerçekte: Hedef SPN listesi önemli bir sınırdır; KDC istenen SPN’i front-end listesiyle karşılaştırır. Belgelenmiş sPNMappings bazı SPN türlerini eşdeğer kabul edebilir; bu, her aynı-host service class’ın serbestçe kabul edildiği genel bir kural değildir. Requested SPN, kayıtlı SPN sahibi ve ilgili mapping birlikte incelenir. Kullanıcı delegation kısıtları ve hedef resource hakları da bağımsızdır.

Kaynaklar / Sources

• RFC 4120 · The Kerberos Network Authentication Service (V5)
  §2.6 Renewable/forwardable ticket flag'leri; §2.8 OK as Delegate flag (KDC'nin unconstrained delegation'a güven işaretlemesi ve istemcinin forwarded TGT gönderme kararı).
• Microsoft Open Specifications · [MS-SFU] Kerberos Protocol Extensions: Service for User and Constrained Delegation Protocol
  §1.3 Overview: S4U2self (protocol transition) ve S4U2proxy (constrained/resource-based delegation); RBCD'de KDC'nin msDS-AllowedToActOnBehalfOfOtherIdentity üzerinde front-end SID access check'i.
• Microsoft · UserAccountControl property flags
  TRUSTED_FOR_DELEGATION 0x80000, TRUSTED_TO_AUTH_FOR_DELEGATION 0x1000000, NOT_DELEGATED 0x100000 bit değerleri ve anlamları.
• Microsoft · ms-DS-Allowed-To-Act-On-Behalf-Of-Other-Identity attribute
  Attribute tanımı: RBCD'de kaynağın kime güvendiğini belirleyen security descriptor; access check ile değerlendirilir; syntax String(NT-Sec-Desc) 2.5.5.15.
• Microsoft · ACE strings
  ACE type A (ACCESS_ALLOWED) ve nesne hakları token'ları (CC, DC, LC, SW, RP, WP, DT, LO, CR, SD, RC, WD, WO) SDDL sözdizimi.
• Microsoft · 5136(S) A directory service object was modified
  Event XML ve Field Descriptions; AttributeLDAPDisplayName, AttributeValue, AttributeSyntaxOID, OperationType %%14674/%%14675, SubjectUserSid; yalnız DC ve SACL koşulu.
• Microsoft · Default workstation numbers a user can join to the domain (ms-DS-MachineAccountQuota)
  ms-DS-MachineAccountQuota varsayılan 10; kimliği doğrulanmış her kullanıcının 10 adede kadar computer account oluşturabilmesi.
• Microsoft Learn · Protected Users security group
  Domain controller protections: Protected User accounts cannot delegate with unconstrained or constrained delegation; applicability requires supported host/domain conditions.
• Microsoft Learn · Event 4769
  Display label Transited Services; raw XML EventData/TransmittedServices. Backend mappings require separate validation.
• Microsoft Open Specifications · msDS-AllowedToDelegateTo
  Attribute definition and multivalued SPN scope; not the RBCD attribute.
• MS-SFU Security Considerations
  §5.1 application authentication before S4U2self
• MS-SFU front-end policy
  §3.2.5.2.1 requested SPN / Service1 account
• MS-SFU back-end descriptor
  §3.2.5.2.3 authorization context / descriptor access check
• Microsoft SPN-Mappings
  Documented type equivalence; no blanket same-host class rule
• 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