Certificatul VPN nu protejează segmentul LDAP

O autentificare VPN care verifică acreditările într-un director implică două conexiuni de rețea separate. Conexiunea utilizatorului la gateway este protejată de certificatul propriu al VPN-ului și de configurația protocolului. Conexiunea gateway-ului la director este o altă sesiune cu propriile setări TLS, propriul depozit de încredere și propriile moduri de eșec. Nimic din prima nu garantează nimic despre a doua.

Această asimetrie este mecanismul din spatele unei autentificări care pare criptată și totuși trimite parola de bind în clar.

Două conexiuni, două decizii de încredere

Sesiunea exterioară este ceea ce vede utilizatorul: un certificat legat de numele gazdă al VPN-ului, validat de client, care transportă schimbul de autentificare. Sesiunea interioară aparține clientului de director din interiorul gateway-ului, care deschide propria conexiune și fie negociază TLS, fie nu. Fiecare parte validează partenerul cu care vorbește, folosind material dintr-un alt fișier de configurare. Un segment interior configurat greșit rămâne invizibil din partea utilizatorului, deoarece segmentul exterior funcționează exact cum a fost prevăzut.

De aceea eșecul este silențios și nu zgomotos. Un gateway care nu verifică niciodată certificatul directorului autentifică în continuare utilizatorii corect; doar îi autentifică printr-un canal pe care nu l-a verificat.

StartTLS și LDAPS, alese deliberat

StartTLS se deschide ca LDAP simplu și este actualizat pe loc, convențional pe portul 389. LDAPS pornește TLS odată cu conexiunea, convențional pe 636. Ambele sunt legitime, iar adaptorul trebuie să corespundă cu ceea ce oferă directorul. A solicita StartTLS este diferit de a-l încerca și de a continua când actualizarea eșuează, și exact în această diferență o parolă de bind poate scăpa. Configurați modul strict și nu permiteți o cale de rezervă neprotejată pentru un bind cu parolă.

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

Opțiunea -ZZ este tot sensul: interogarea eșuează în loc să continue silențios fără actualizare. Numele și conturile din acea linie sunt exemple. Documentația TLS a OpenLDAP acoperă setările de încredere din spate.

Ce depozit de încredere citește clientul LDAP?

Biblioteca client OpenLDAP își citește propria configurație de încredere, fie din fișierul de sistem, fie dintr-o setare specifică modulului. Directiva CA a VPN-ului se aplică partenerilor VPN și nu este dovadă că biblioteca LDAP citește același fișier. Folosiți numele de gazdă al directorului pe care certificatul îl acoperă efectiv, plus lanțul emitent în care biblioteca are încredere. În Active Directory, implementați un certificat de serviciu de director cu utilizarea corectă pentru autentificarea serverului, în loc să raționați pornind de la un nume afișat.

Fiecare destinație de failover trebuie să îndeplinească aceeași politică de identitate. Un mediu în care primarul este validat, iar secundarul nu, este mai rău decât unul fără failover, deoarece calea mai slabă este descoperită doar în timpul unei întreruperi.

Contul de bind rămâne o problemă separată

Protejarea transportului nu reduce ceea ce poate face contul de bind. Domeniul de căutare în director, autorizarea pe grupuri și privilegiile contului de serviciu sunt decizii separate, iar un cont de bind larg rămâne larg după activarea TLS. Folosiți cel mai îngust cont de serviciu și baza de căutare de care are nevoie integrarea, și înregistrați punctul final, modul TLS, proprietarul încrederii și procesul de reînnoire împreună cu configurația VPN.

Când apare o nepotrivire de certificat, implementați certificatul sau lanțul corect. Dezactivarea verificării transformă o nepotrivire vizibilă într-una invizibilă și lasă a doua relație de încredere netestată.

Două conexiuni, doi proprietari, două date de reînnoire. Păstrarea lor separate în documentație este ceea ce menține autentificarea onestă.