Certifikát VPN nechráni vetvu LDAP

Prihlásenie cez VPN, ktoré overuje prihlasovacie údaje proti adresáru, zahŕňa dve samostatné sieťové pripojenia. Pripojenie používateľa k bráne chráni vlastný certifikát VPN a nastavenie protokolu. Pripojenie brány k adresáru je iná relácia s vlastným nastavením TLS, vlastným úložiskom dôvery a vlastnými režimami zlyhania. Nič v prvom nezaručuje nič o druhom.

Práve táto asymetria je mechanizmom prihlásenia, ktoré vyzerá šifrovane a napriek tomu posiela heslo pre bind v otvorenej podobe.

Dve pripojenia, dve rozhodnutia o dôvere

Vonkajšia relácia je to, čo používateľ vidí: certifikát naviazaný na názov hostiteľa VPN, overený klientom, ktorý nesie výmenu autentifikácie. Vnútorná relácia patrí klientovi adresára vo vnútri brány, ktorý otvára vlastné pripojenie a buď vyjedná TLS, alebo nie. Každá strana overuje protistranu, s ktorou hovorí, pomocou materiálu z iného konfiguračného súboru. Nesprávne nakonfigurovaná vnútorná vetva zostáva z pohľadu používateľa neviditeľná, pretože vonkajšia vetva funguje presne tak, ako má.

Preto je zlyhanie tiché a nie hlasné. Brána, ktorá nikdy neoverí certifikát adresára, aj tak autentifikuje používateľov správne; len ich autentifikuje cez kanál, ktorý neoverila.

StartTLS a LDAPS, zvolené vedome

StartTLS sa otvára ako obyčajné LDAP a na mieste sa povýši, zvyčajne na porte 389. LDAPS spúšťa TLS s pripojením, zvyčajne na 636. Oboje je legitímne a adaptér musí zodpovedať tomu, čo adresár ponúka. Vyžadovať StartTLS je niečo iné ako ho skúsiť a pokračovať, keď povýšenie zlyhá, a práve v tomto rozdiele môže heslo pre bind uniknúť. Nastavte striktný režim a nepovoľte nechránenú záložnú cestu pre bind s heslom.

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

Prepínač -ZZ je celý zmysel: dopyt zlyhá namiesto toho, aby ticho pokračoval bez povýšenia. Názvy a účty v tomto riadku sú príklady. Dokumentácia OpenLDAP k TLS pokrýva nastavenia dôvery, ktoré sú za tým.

Ktoré úložisko dôvery číta klient LDAP?

Klientská knižnica OpenLDAP číta vlastnú konfiguráciu dôvery, či už zo systémového súboru, alebo z nastavenia špecifického pre plugin. Direktíva CA vo VPN platí pre protistrany VPN a nie je dôkazom, že knižnica LDAP číta ten istý súbor. Použite názov hostiteľa adresára, ktorý certifikát skutočne pokrýva, plus vydávajúcu reťaz, ktorej knižnica dôveruje. V Active Directory nasaďte certifikát služby adresára so správnym použitím na autentifikáciu servera, namiesto usudzovania zo zobrazovaného názvu.

Každý cieľ prepnutia pri výpadku musí spĺňať rovnakú zásadu identity. Prostredie, kde je primárny uzol overený a sekundárny nie, je horšie ako prostredie bez prepnutia, pretože slabšia cesta sa odhalí len počas výpadku.

Účet pre bind zostáva samostatným problémom

Ochrana prenosu neznižuje to, čo môže účet pre bind robiť. Rozsah hľadania v adresári, autorizácia skupín a privilégiá servisného účtu sú samostatné rozhodnutia a široký účet pre bind zostáva široký aj po zapnutí TLS. Použite najužší servisný účet a základňu hľadania, ktoré integrácia potrebuje, a zaznamenajte koncový bod, režim TLS, vlastníka dôvery a proces obnovy spolu s konfiguráciou VPN.

Keď sa objaví nezhoda certifikátu, nasaďte správny certifikát alebo reťaz. Vypnutie overovania premení viditeľnú nezhodu na neviditeľnú a druhá relačná dôvera zostane neotestovaná.

Dve pripojenia, dvaja vlastníci, dva dátumy obnovy. Práve ich oddelenie v dokumentácii drží prihlásenie čestné.