Active Directory (AD) güvenlik değerlendirmelerinde neredeyse klasikleşmiş bir öneri var: “Unsecured LDAP yerine LDAPS kullanın.” Ancak uzmanlara göre bu tavsiye çoğu ortamda yanlış anlaşılıyor ve her zaman gerçek bir güvenlik kazanımı sağlamıyor.
AD ile çalışan yazılım üreticileri, müşterilerden sık sık aynı soruyu duyuyor: “Ürün LDAPS destekliyor mu? Desteklemiyorsa roadmap’te var mı?” Çoğu durumda verilen yanıt şaşırtıcı: “Hayır, ama bu bir güvenlik açığı değil.”
Peki neden?
LDAPS Gerçekten Sorunu Çözüyor mu?
İnternette, domain controller’lara TLS sertifikası yükleyerek LDAP’ı 636/TCP portu üzerinden TLS ile çalıştırmayı anlatan binlerce rehber bulunuyor. Ancak işin pratik tarafı bu kadar basit değil.
LDAPS etkinleştirildiğinde bile domain controller’lar 389 portu üzerinden TLS’siz LDAP hizmeti vermeye devam ediyor. Üstelik bu portu kapatmak ya da firewall üzerinden engellemek, Active Directory üyelerinde ciddi hizmet kesintilerine yol açabiliyor.
Önemli bir gerçek şu:
Bir AD üyesi makine, LDAP veya Global Catalog sorguları için varsayılan olarak her zaman 389/3268 portlarını kullanır. Bu davranışı değiştirmek mümkün değildir. Yani üyeleri zorla 636/3269 portuna yönlendiremezsiniz.
LDAPS İçin Denenen “Workaround” Yöntemleri Neden Çalışmıyor?
LDAP servis keşfi DNS üzerinden yapılır. Bu nedenle bazı yöneticiler farklı yöntemler denemiştir:
- _ldaps._tcp.domain.com gibi yeni SRV kaydı eklemek
- LDAP servis kayıtlarında portu 389’dan 636’ya çevirmek
- _ldap ve _gc kayıtlarını silmek
Ancak bu yaklaşımlar işe yaramaz.
_ldaps standart bir servis kaydı değildir. Uygulamaların büyük çoğunluğu bu kaydı aramaz. Port numarasını değiştirmek de çözüm değildir çünkü Windows tarafında 389 portu sabit tanımlıdır. _ldap kayıtlarını silmek ise servis keşfini tamamen bozabilir.
Kısacası, bu yöntemler Active Directory altyapısını kırma riski taşır.
Asıl Kritik Nokta: Simple Bind mi, SASL Bind mi?
LDAP’ın güvensiz olduğu iddiası genellikle “cleartext credential” konusuna dayanır. Ancak burada önemli bir ayrım vardır:
- Simple Bind: Kullanıcı adı ve parola açık metin iletilebilir.
- SASL Bind (GSS-SPNEGO): Kerberos veya NTLM ile kimlik doğrulama yapılır ve oturum anahtarları üzerinden şifreleme sağlanır.
Active Directory üyeleri ve modern uygulamaların büyük çoğunluğu simple bind kullanmaz. SASL bind kullanır. Bu durumda:
- Parola açık metin gönderilmez.
- Oturum zaten şifrelenmiştir.
- TLS katmanına ihtiyaç duyulmadan güvenli iletişim sağlanır.
Bu mekanizma sadece domain üyeleri için değil, uygun şekilde yapılandırılmış herhangi bir uygulama için geçerlidir.
Peki AD LDAP Nasıl Güçlendirilir?
389 portunu kapatmak çözüm değildir. Bunun yerine önerilen yaklaşım şudur:
- Domain controller’larda LDAP signing zorunlu hale getirilmelidir.
- Event log’lar izlenmeli, simple bind kullanım durumları tespit edilmelidir.
- Eğer bir uygulama simple bind gerektiriyorsa, o uygulama özelinde 636/3269 portu ve sertifika güveni yapılandırılmalıdır.
Eline sağlık.