Posted in

Ldap to Ldaps (Neden Ldaps)

Merhablar,

Bu makalemde kurumsal ağlarda PKI altyapınızı kullanarak, ldap için tanımladığınız DNS kaydına göre ldaps geçişini anlatacağım. LDAPS (Lightweight Directory Access Protocol over SSL/TLS), en basit tabiriyle standart LDAP protokolünün üzerine bir güvenlik katmanı eklenmiş halidir.

Varsayılan olarak, istemci ve sunucu uygulamaları arasındaki LDAP iletişimleri şifrelenmez. Bir ağ izleme cihazı/yazılımı kullanarak LDAP istemci ve sunucu bilgisayarları arasında gerçekleşen iletişimleri görüntülemenin mümkün olduğu anlamına gelir. Bu durum, LDAP kullanıldığında sorun teşkil eder çünkü kimlik bilgileri (kullanıcı adı ve parola) ağ üzerinden şifrelenmeden iletilir. Bu durum kimlik bilgilerinin hızla ele geçirilmesine yol açabilir. Bunun için LDAPS kullanılması özellikle kurumsal networklerde kesinlikle önerilmektedir. Ldaps geçişi, ldap attacklarına karşı da koruma sağlamış olacaktır.

Öncelikle ldap için belirlediğimiz DNS kayıtlarımızı (benim örneğimde: ldap.m3g.intra) DC’lerimizi point edecek şekilde DNS sunucumuza giriyoruz.

Ldap Testi

Ldapsearch kullanarak herhangi bir dummy user ile 389 portundan ad objelerini çekmeye çalışıyorum.

Tüm AD Objelerini çektiğim için liste çok uzun fakat ekran görüntüsünde görüldüğü üzere başarılı bir şekilde çekilmiş gözükmektedir.

Ldaps Configuration

Bir etki alanı denetleyicisine Kurumsal Kök Sertifika Yetkilisi (CA) kurduğunuzda, LDAP over SSL/TLS (LDAPS) otomatik olarak etkinleştirilir (ancak bir etki alanı denetleyicisine CA kurmak önerilen bir uygulama değildir). Bu sebeple CA sunucumuz üzerinde, Ldap(s) için kullanacağımız sertifikayı talep etmemiz gerekiyor. Talep edebilmek için bu sertifikanın template’ ini aşağıdaki gibi oluşturuyoruz. Ortamımda ldap.m3g.intra dns name kullanmak istediğim için “Supply in request” seçeneğini seçiyorum. Tabi ki bu seçenek seçildiğinde güvenlik zafiyeti oluşturmamak adına “Admin Approval” seçeneğini de işaretledim. Bu durum Microsoft tarafından da önerilen yöntemdir. Admin approval checkbox’ ını işaretlemeden Supply in request seçeneğini seçerseniz, bu durumu belirten bir uyarı penceresi göreceksiniz.

Not : Ben ortamımda ldap kullanacak kişi/admin/developer/servis ‘ler için tek bir DNS name olan ldap.m3g.intra kullanmak için supply in request seçeneğini seçiyorum. Supply in request seçeneğini işaretlemeden de işlemi yapabilirsiniz. Fakat bu durumda sertifika common name olarak bilgisayarın DNS Name özelliğinden üretileceğinden, belirtmeniz gereken dns name sunucu adresleri olmalıdır. Hatta seçmediğiniz durumda zaten AD üzerindeki domain controller’ların Kerberos Authenticaton template’inden auto enroll oldukları sertifikalar da kullanılabilir. Ama yine bu durumda da dns name computer adını işaret ettiğinden ldap sunucular olarak dağıtmanız gereken dns’ler DC’lerinizin adını içeren dns name olması gerekmektedir.
  ç

Template oluşturduktan sonra bu sertifika için istekte bulunuyoruz ve ldap.m3g.intra için istek yaptığımız sertifikaya SAN olarak DC computer isimlerimizi de ekliyoruz.

Sertikayı onayladıktan sonra export ederek Domain Controller makinemize NTDS\Personal altına import ediyoruz.

   

Buradaki önemli nokta : Ldaps sertifikasını iki yere de yükleyebilirsiniz:

  • Local Computer’s Personal certificate store
  • NT Directory Services (NTDS) certificate store

Microsoft der ki: Active Directory tercihen öncelikle NTDS deposunu kontrol eder. NT Directory Services (NTDS) deposunda bir sertifika yoksa, Local Computer\Personal deposundaki sertifikayı kullanır.

NTDS deposunu kullanmak çeşitli avantajlar sağladığı gibi bazı dezavantajları da vardır.

NTDS\Personal altına etmeniz durumunda automatic certificate enrollment gibi bazı özellikleri kullanamıyorsunuz. Fakat Local Computer\Personal altında farklı Server Atuhentication ya da KDC Authentication sertifikalar var ise bunların karışması durumunun önüne geçiyorsunuz. Avantajları ve dezavantajları ilgili linklerden kontrol edebilirsiniz.

Buraya kadar yapılan işlemler ile ldaps için “yapılanmamızı” tamamlamış oluyoruz. ldp.exe ile test ettiğimizde artık 636 portundan ssl isteklerine sunucumuzun yanıt verdiğini görebilmekteyiz.

Fakat ldaps yapılandırmasını tamamlamış olmamız ldaps geçişini yaptığımız anlamına gelmez. Şu anda sunucumuz artık ldaps protokolüne 636 portundan yanıt veriyor. Ama aynı zamanda 389 portundan encrypted (cleartext) isteklere de yanıt veriyor.

Ldap to Ldaps

Ldaps protokolünü zorunlu kılabilmek için Group Policy Settings üzerinde 3 adet policy değişikliğine ihtiyacımız bulunmaktadır.

  • Domain Controller: LDAP Server signing requirements= Require Signing
  • Domain controller: LDAP server channel binding token requirements=Always
  • Network security: LDAP client signing requirements=Require signing

 

İlgili ayarlar geçerli olduktan sonra Ldaps geçişimizi tamamlamış oluyoruz. Artık 389 portundan herhangi bir sorgu için sertifikalı iletişim gerektiğinden ekran görüntüsündeki gibi SSL/TLS hatası almaktayız.

Ldp.exe ile kontrol sağladığımızda sorguların encrypted olarak göndeirildiği “simple bind” seçeneğini seçtiğimizde sunucumuzun isteği reddettiğini görebilmekteyiz.

Ldaps geçişi için ekteki yararlı linkleri de incelemenizi tavsiye ederim.

https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-over-ssl-3rd-certification-authority

https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server

Faydalı olması dileğiyle…

Leave a Reply

Your email address will not be published. Required fields are marked *