VPN sertifikası LDAP bacağını korumaz

Kimlik bilgilerini bir dizine karşı denetleyen VPN oturum açma işlemi iki ayrı ağ bağlantısı içerir. Kullanıcının ağ geçidine bağlantısı VPN’in kendi sertifikası ve protokol yapılandırmasıyla korunur. Ağ geçidinin dizine bağlantısı kendi TLS ayarları, kendi güven deposu ve kendi hata modları olan başka bir oturumdur. İlkiyle ilgili hiçbir şey ikincisi hakkında hiçbir şeyi garanti etmez.

Bu asimetri, şifrelenmiş görünen ama yine de bind parolasını açık metin olarak gönderen oturum açmanın ardındaki mekanizmadır.

İki bağlantı, iki güven kararı

Dış oturum kullanıcının gördüğüdür: VPN ana bilgisayar adına bağlı, istemci tarafından doğrulanan ve kimlik doğrulama alışverişini taşıyan bir sertifika. İç oturum, ağ geçidinin içindeki dizin istemcisine aittir; kendi bağlantısını açar ve TLS üzerinde anlaşır ya da anlaşmaz. Her taraf konuştuğu karşı tarafı başka bir yapılandırma dosyasından alınan malzemeyle doğrular. Yanlış yapılandırılmış iç bacak kullanıcı tarafından görünmez kalır, çünkü dış bacak tam olarak amaçlandığı gibi çalışır.

Bu yüzden hata gürültülü değil sessizdir. Dizinin sertifikasını hiç denetlemeyen bir ağ geçidi kullanıcıların kimliğini yine doğru şekilde doğrular; yalnızca bunu doğrulamadığı bir kanal üzerinden yapar.

StartTLS ve LDAPS, bilinçli olarak seçilmiş

StartTLS düz LDAP olarak açılır ve yerinde yükseltilir, genellikle 389 numaralı bağlantı noktasında. LDAPS TLS’i bağlantıyla birlikte başlatır, genellikle 636’da. İkisi de meşrudur ve bağdaştırıcı dizinin sunduğuyla eşleşmelidir. StartTLS’i zorunlu kılmak, onu deneyip yükseltme başarısız olduğunda devam etmekten farklıdır ve bind parolasının kaçabileceği yer tam olarak bu farktır. Katı modu yapılandırın ve parolalı bind için korumasız bir yedek yol izin vermeyin.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

-ZZ seçeneği bütün meseledir: sorgu, yükseltme olmadan sessizce ilerlemek yerine başarısız olur. O satırdaki adlar ve hesaplar örnektir. OpenLDAP TLS belgeleri bunun ardındaki güven ayarlarını kapsar.

LDAP istemcisi hangi güven deposunu okur?

OpenLDAP istemci kitaplığı kendi güven yapılandırmasını okur; ister sistem dosyasından ister eklentiye özgü bir ayardan. VPN’in CA yönergesi VPN eşlerine uygulanır ve LDAP kitaplığının aynı dosyayı okuduğunun kanıtı değildir. Sertifikanın gerçekten kapsadığı dizin ana bilgisayar adını ve kitaplığın güvendiği veren zincirini kullanın. Active Directory’de görünen addan akıl yürütmek yerine doğru sunucu kimlik doğrulama kullanımıyla bir dizin hizmeti sertifikası dağıtın.

Her yedekleme hedefi aynı kimlik ilkesini karşılamalıdır. Birincil düğümün doğrulandığı, ikincil düğümün doğrulanmadığı bir ortam, yedekleme olmayan bir ortamdan daha kötüdür, çünkü daha zayıf yol yalnızca bir kesinti sırasında keşfedilir.

bind hesabı ayrı bir sorun olarak kalır

Aktarımı korumak, bind hesabının neler yapabileceğini azaltmaz. Dizindeki arama kapsamı, grup yetkilendirmesi ve hizmet hesabının ayrıcalıkları ayrı kararlardır ve geniş bir bind hesabı TLS etkinleştirildikten sonra da geniş kalır. Entegrasyonun ihtiyaç duyduğu en dar hizmet hesabını ve arama tabanını kullanın; uç noktayı, TLS modunu, güven sahibini ve yenileme sürecini VPN yapılandırmasıyla birlikte kaydedin.

Bir sertifika uyuşmazlığı ortaya çıktığında doğru sertifikayı veya zinciri dağıtın. Doğrulamayı devre dışı bırakmak görünür bir uyuşmazlığı görünmez hale getirir ve ikinci güven ilişkisini test edilmemiş bırakır.

İki bağlantı, iki sahip, iki yenileme tarihi. Bunları belgelerde ayrı tutmak, oturum açmayı dürüst tutan şeydir.