Merhaba
Active Directory Sıkılaştırma serisinin beşinci bölümünde, Bölüm 3‘te başladığımız LDAP güvenliği konusunu bir adım öteye taşıyoruz. Konu: LDAP (Lightweight Directory Access Protocol) channel binding zorlaması.
Bölüm 3‘te LDAP signing’i ele almış, imzasız LDAP bağlantılarının nasıl relay saldırılarına açık olduğunu konuşmuştuk. Ancak LDAP signing tek başına tabloyu tamamlamaz. Şifreli LDAPS (LDAP over TLS) bağlantılarında saldırganların hala kimlik doğrulamayı aktarabildiği bir açık kalır. Channel binding, tam olarak bu açığı kapatır. İki ayarı, LDAP signing ile channel binding’i birlikte uyguladığınızda LDAP relay saldırılarının kapısını gerçek anlamda kapatmış olursunuz.
Channel Binding Neden Gerekli
Bölüm 3‘te gördüğümüz gibi, LDAP signing şifresiz LDAP (389 portu) bağlantılarının bütünlüğünü korur. Peki ya trafik zaten TLS ile şifreliyse, yani LDAPS (636 portu) kullanılıyorsa?
Channel binding bu boşluğu kapatır. Channel binding token (CBT), uygulama katmanındaki kimlik doğrulamayı, altındaki TLS tüneline kriptografik olarak bağlar. Böylece o kimlik doğrulama yalnızca o TLS oturumu içinde geçerli olur; başka bir tünele aktarıldığında doğrulama başarısız olur ve bağlantı reddedilir. Kısacası channel binding, TLS ile şifreli LDAP bağlantılarında relay saldırısını etkisiz kılar.
LDAP signing ile channel binding birbirini tamamlar: signing şifresiz LDAP’ı korur, channel binding ise şifreli LDAPS’i. İkisini birlikte zorunlu kıldığınızda LDAP relay saldırı yüzeyi büyük ölçüde ortadan kalkar.
Windows Server 2025 ve Güncel Durum
Microsoft, LDAP channel binding konusunda 2020’den bu yana kurumları zorunlu yapılandırmaya yönlendiriyor. Windows Server 2025, LDAP signing ve channel binding varsayılanları konusunda önceki sürümlere göre daha sıkı bir çizgi izler; ancak yine de ortamınızdaki mevcut durumu doğrulamak ve gerekli yapılandırmayı bilinçli şekilde uygulamak sizin sorumluluğunuzdadır.
Doğru hedef, Domain Controller’ları channel binding’i her zaman zorunlu kılacak (Always) şekilde yapılandırmak. Ancak channel binding token’ı desteklemeyen eski istemciler veya uygulamalar varsa, bunları doğrudan zorlamak kimlik doğrulamalarının kesilmesine yol açabilir. Bu yüzden yaklaşım, serinin genel mantığıyla aynı: önce görmek, sonra zorlamak.
LDAP Channel Binding Seviyeleri
Domain Controller tarafında channel binding davranışı, registry’de şu konumda tutulur:
- Anahtar:
HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters - Değer:
LdapEnforceChannelBinding
| Değer | Group Policy Object Karşılığı | Anlamı | Güvenlik |
|---|---|---|---|
| 0 | Never | Channel binding istenmez (devre dışı) | Zayıf |
| 1 | When Supported | Destekleyen istemcilerde uygulanır, desteklemeyenlere izin verilir | Orta |
| 2 | Always | Channel binding her zaman zorunlu | Güçlü |
Hedef değer 2 (Always). Ancak geçiş sürecinde önce 1 (When Supported) ile başlamak, desteklemeyen istemcileri kesintiye uğratmadan görünürlük kazanmanızı sağlar.
Aşama 1: Uyumsuz İstemcileri Tespit Etmek
Zorlamaya geçmeden önce ortamda hangi istemcilerin channel binding token sağlamadığını görmelisiniz. Domain Controller’lar, LDAPS bağlantılarındaki channel binding durumunu Directory Service olay günlüğüne kaydeder.
Channel binding ile ilgili anahtar olaylar:
| Event ID | Anlamı |
|---|---|
| 3039 | Channel binding doğrulaması başarısız oldu (bağlantı reddedildi ya da reddedilirdi) |
| 3074 | İstemci, TLS üzerinden bind yaptı; Always modunda olsaydı bu bağlantı başarısız olurdu (denetim uyarısı) |
| 3075 | İstemci, TLS üzerinden bind yaptı ve channel binding bilgisi sağlamadı |
Denetim aşaması için pratik yol, önce LdapEnforceChannelBinding değerini 1 (When Supported) yapmaktır. Bu modda, channel binding sağlamayan istemciler henüz reddedilmez, ancak olay günlüğünde işaretlenir. Böylece hangi istemcilerin uyumsuz olduğunu, üretimi kesintiye uğratmadan görürsünüz.
Bu kayıtları toplamak için:
Get-WinEvent -LogName "Directory Service" |
Where-Object { $_.Id -in 3074, 3075, 3039 } |
Select-Object TimeCreated, Id, Message -First 50

Bu sorgu, Directory Service olay günlüğündeki channel binding olaylarını (3074/3075/3039) listeler. Çıktı boş dönerse, When Supported modunda henüz uyumsuz bir istemci yakalanmamış demektir; iyi bir işarettir, ancak nadir çalışan uygulamaları kaçırmamak için taramayı bir süre sürdürün.
Event 3074 ve 3075 kayıtları, channel binding sağlamayan istemcilerin IP adresini ve ilgili hesabı gösterir. Bu istemciler genellikle eski uygulamalar, LDAP entegrasyonları veya güncellenmemiş cihazlardır. Öneri: When Supported modunu en az bir ay açık tutun ki nadir çalışan uygulamalar da yakalanabilsin.
Aşama 2: Channel Binding’i Zorunlu Kılmak
Denetim kayıtlarında görünen tüm uyumsuz istemcileri channel binding’i destekleyecek şekilde düzelttikten (veya güncelledikten) sonra zorlamaya geçebilirsiniz.
Group Policy ile Uygulama
Domain Controller’larda channel binding’i zorunlu kılmak için, Default Domain Controllers Policy (ya da Domain Controller’ları kapsayan birGPO (Group Policy Object)) üzerinden şu politikayı ayarlayın:
Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: LDAP server channel binding token requirements
Bu politikayı Always olarak ayarlayın. Bu, LdapEnforceChannelBinding değerini 2 yapar. Geçiş sürecinde önce When supported ile ilerleyip denetim yaptıktan sonra Always’e geçmek en güvenli yoldur.
Adımlar sırasıyla şöyle:
Security Options altında Domain controller: LDAP server channel binding token requirements politikasını bulun. Başlangıçta durumu genellikle Not Defined olur. (Hemen altındaki LDAP server signing requirements’ın Bölüm 3‘te Require signing yapıldığına da dikkat edin.)

Politikayı çift tıklayın, Define this policy setting kutusunu işaretleyip açılır listeden Always seçin ve Apply‘a tıklayın.

Ayarın Always olduğunu doğrulayıp OK ile pencereyi kapatın.

Politika listesinde değerin artık Always olduğunu görürsünüz. Değişikliğin Domain Controller’lara ulaşması için gpupdate /force çalıştırabilirsiniz.

Registry ile Uygulama (Tek Makine / Test)
İzole bir test veya tek makine senaryosu için registry doğrudan yazılabilir:
$ntds = "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters"
# 1 = When Supported (denetim asamasi), 2 = Always (zorunlu)
Set-ItemProperty -Path $ntds -Name LdapEnforceChannelBinding -Value 2 -Type DWord

PowerShell ile LdapEnforceChannelBinding değeri 2 (Always) olarak yazılıyor. Bu, GPO (Group Policy Object) ile aynı sonucu üreten registry karşılığıdır.

Aynı değer Registry Editor üzerinden de görülebilir: NTDS\Parameters altında ldapenforcechannelbinding DWORD değeri 2. Yanındaki ldapserverintegrity = 1 ise Bölüm 3‘teki LDAP signing ayarıdır; iki değer birlikte LDAP relay korumasını tamamlar.
Kurumsal ortamda önerilen yöntem her zaman GPO (Group Policy Object)’dur; registry yalnızca test veya istisnai durumlar içindir. Değişikliğin etkin olması için değişikliğin ardından ilgili servisin ya da Domain Controller’ın yeniden başlatılması gerekebilir.
Doğrulama
Zorlamadan sonra, Domain Controller’larda channel binding sağlamayan istemcilerin artık reddedildiğini Event 3039 kayıtlarından görebilirsiniz. Denetim aşamasında (When Supported) 3074/3075 ile işaretlenen istemciler düzeltildiyse, Always moduna geçtikten sonra bu kayıtların büyük ölçüde kaybolması gerekir.
Hala reddedilen istemci varsa, o istemci henüz channel binding’i destekleyecek şekilde güncellenmemiş demektir. Bu yüzden Always’e geçmeden önce Aşama 1’deki denetimi dikkatle yapmak kritiktir.
Geri Alma (Rollback) Planı
Zorlama sonrası kritik bir uygulamanın kimlik doğrulaması kesilirse, GPO (Group Policy Object) ayarını geçici olarak When Supported veya Never‘a alıp gpupdate /force ile hızlıca eski davranışa dönebilirsiniz. Registry ile uyguladıysanız LdapEnforceChannelBinding değerini 1’e ya da 0’a döndürmek aynı etkiyi yapar.
Ancak bunu kalıcı bir çözüm değil, yalnızca sorunlu istemciyi channel binding’i destekleyecek şekilde düzeltene kadar geçici bir köprü olarak kullanın. Pilot yaklaşım burada da geçerlidir: değişikliği önce bir test DC’sinde uygulayın, izleyin, sonra tüm Domain Controller’lara yayın.
Genel Görünüm
LDAP channel binding zorlaması, LDAP signing ile birlikte, Domain Controller’lara yönelik NTLM relay saldırılarını gerçek anlamda kapatan ikili sıkılaştırmanın diğer yarısıdır. Signing şifresiz LDAP’ı, channel binding ise şifreli LDAPS’i korur; ikisi birlikte relay saldırı yüzeyini büyük ölçüde ortadan kaldırır.
İzlenecek yol serinin genel mantığıyla aynı: önce görünürlük (When Supported modunda Event 3074/3075 takibi), sonra uyumsuz istemcileri düzeltme, ardından GPO ile Always zorlaması, en son da Event 3039 ile doğrulama. Bu sırayı koruduğunuzda hem LDAPS üzerinden relay riskini kapatır hem de üretim ortamını kesintiye uğratmadan sıkılaştırmayı tamamlarsınız.
Serinin bir sonraki bölümünde SMB signing zorlamasını ele alacağız. Kimlik altyapısını katman katman güçlendirmeye devam edeceğiz.
Uyumluluk ve Çerçeve Eşlemesi
Aşağıdaki tablo, serideki her sıkılaştırmanın hangi uyumluluk çerçevesi kontrolünü karşıladığını ve hangi MITRE ATT&CK tekniğini engellediğini özetler. Hiçbir çerçeve bu ayarları isim isim zorunlu tutmaz; sıkılaştırmalar ilgili kontrolleri karşılar. Bağlayıcılık: Zorunlu = PCI DSS (kart verisi), KVKK (TR), TCMB (finansal), HIPAA (ABD sağlık); Taahhüde bağlı = ISO 27001; Gönüllü = NIST CSF, CIS Controls.
| Sıkılaştırma (Bölüm) | İlgili Çerçeve Kontrolleri | Engellenen MITRE ATT&CK |
|---|---|---|
| NTLMv1’i devre dışı bırakmak (Bölüm 1) | PCI DSS 2.2/4.2/8.3 · KVKK Md.12 · TCMB · ISO A.8.24/A.8.5 · NIST PR.AA/PR.DS · CIS Benchmark (LAN Manager auth level) | T1557 (NTLM relay), T1550.002 (Pass-the-Hash), T1187 |
| SMBv1’i kaldırmak (Bölüm 2) | PCI DSS 2.2/6.3/1 · KVKK Md.12 · TCMB · ISO A.8.8/A.8.9 · NIST PR.PS/ID.RA · CIS Benchmark (SMBv1 disable) | T1210 (EternalBlue), T1021.002 (SMB Shares), T1570 |
| LDAP signing zorlaması (Bölüm 3) | PCI DSS 4.2/2.2 · KVKK Md.12 · TCMB · ISO A.8.24/A.5.14/A.8.20 · NIST PR.DS/PR.AA · CIS Benchmark (LDAP server signing) | T1557 (LDAP/NTLM relay), T1550 |
| Kerberos için AES zorlaması (Bölüm 4) | PCI DSS 4.2/2.2 · KVKK Md.12 · TCMB · ISO A.8.24 · NIST PR.DS · CIS Benchmark (Kerberos encryption types) | T1558.003 (Kerberoasting), T1558 |
| LDAP channel binding zorlaması (Bölüm 5) | PCI DSS 4.2/2.2 · KVKK Md.12 · TCMB · ISO A.8.24/A.8.20 · NIST PR.DS/PR.AA · CIS Benchmark (LDAP channel binding token) | T1557 (LDAPS üzerinden NTLM relay) |
| SMB signing zorlaması (Bölüm 6) | PCI DSS 4.2/2.2 · KVKK Md.12 · TCMB · ISO A.8.24/A.5.14 · NIST PR.DS · CIS Benchmark (Microsoft network client/server digitally sign) | T1557 (SMB relay), T1187 |
| En az yetki (least privilege) (Bölüm 7) | PCI DSS 7.x/8.x · KVKK Md.12 · TCMB · ISO A.8.2/A.5.15 · NIST PR.AA · CIS Controls v8 5.4/6.8 | T1078 (Geçerli Hesaplar), T1548 (Yetki Yükseltme) |
| Windows LAPS (Bölüm 8) | PCI DSS 8.2/8.3/7 · KVKK Md.12 · TCMB · ISO A.5.17/A.8.2 · NIST PR.AA · CIS Controls v8 5.2/5.4/4.7 | T1078 (Geçerli Hesaplar), T1550.002 (Pass-the-Hash), T1021 |
Engellenen başlıca MITRE ATT&CK teknikleri: T1557 Adversary-in-the-Middle (NTLM relay), T1550.002 Pass-the-Hash, T1187 Forced Authentication
Başka bir yazımızda görüşmek dileğiyle…