VPN certifikat ne štiti dionicu LDAP

Prijava putem VPN-a koja provjerava vjerodajnice prema direktoriju uključuje dvije odvojene mrežne veze. Veza korisnika s pristupnikom zaštićena je vlastitim certifikatom VPN-a i konfiguracijom protokola. Veza pristupnika s direktorijem je druga sesija s vlastitim TLS postavkama, vlastitim spremištem povjerenja i vlastitim načinima kvara. Ništa u prvoj ne jamči ništa u drugoj.

Upravo je ta asimetrija mehanizam iza prijave koja izgleda šifrirano, a ipak šalje bind lozinku otvorenim tekstom.

Dvije veze, dvije odluke o povjerenju

Vanjska sesija je ono što korisnik vidi: certifikat vezan uz ime hosta VPN-a, koji je klijent provjerio i koji nosi razmjenu autentifikacije. Unutarnja sesija pripada klijentu direktorija unutar pristupnika, koji otvara vlastitu vezu i ili pregovara TLS, ili ne. Svaka strana provjerava sugovornika s kojim razgovara, koristeći materijal iz druge konfiguracijske datoteke. Pogrešno konfigurirana unutarnja dionica ostaje nevidljiva s korisničke strane, jer vanjska dionica radi točno kako je predviđeno.

Zato je kvar tih, a ne glasan. Pristupnik koji nikad ne provjerava certifikat direktorija i dalje ispravno autentificira korisnike; samo ih autentificira preko kanala koji nije provjerio.

StartTLS i LDAPS, odabrani svjesno

StartTLS se otvara kao obični LDAP i nadograđuje na mjestu, obično na portu 389. LDAPS pokreće TLS zajedno s vezom, obično na 636. Oba su legitimna i adapter mora odgovarati onome što direktorij nudi. Zahtijevati StartTLS nije isto što i isprobati ga i nastaviti kada nadogradnja ne uspije, i upravo u toj razlici bind lozinka može iscuriti. Postavite strogi način rada i ne dopustite nezaštićeni rezervni put za bind s lozinkom.

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

Opcija -ZZ je cijela poanta: upit ne uspijeva umjesto da tiho nastavi bez nadogradnje. Imena i računi u tom retku su primjeri. Dokumentacija OpenLDAP-a o TLS-u pokriva postavke povjerenja iza toga.

Koje spremište povjerenja čita klijent LDAP-a?

Klijentska biblioteka OpenLDAP čita vlastitu konfiguraciju povjerenja, bilo iz sistemske datoteke, bilo iz postavke specifične za dodatak. CA direktiva u VPN-u odnosi se na VPN partnere i nije dokaz da LDAP biblioteka čita istu datoteku. Koristite ime hosta direktorija koje certifikat stvarno pokriva, plus lanac izdavatelja kojem biblioteka vjeruje. U Active Directoryju primijenite certifikat usluge direktorija s ispravnom namjenom za autentifikaciju poslužitelja, umjesto da zaključujete iz prikazanog imena.

Svako odredište za prebacivanje pri kvaru mora zadovoljiti istu politiku identiteta. Okruženje u kojem je primarni provjeren, a sekundarni nije, gore je od onoga bez prebacivanja, jer se slabiji put otkriva samo tijekom prekida.

Bind račun ostaje odvojen problem

Zaštita prijenosa ne smanjuje ono što bind račun smije raditi. Opseg pretrage u direktoriju, grupna autorizacija i privilegije servisnog računa odvojene su odluke, i širok bind račun ostaje širok i nakon uključivanja TLS-a. Koristite najuži servisni račun i bazu pretrage koji su integraciji potrebni, i zabilježite krajnju točku, TLS način, vlasnika povjerenja i proces obnove zajedno s konfiguracijom VPN-a.

Kada se pojavi nepodudarnost certifikata, primijenite ispravan certifikat ili lanac. Isključivanje provjere pretvara vidljivu nepodudarnost u nevidljivu i ostavlja drugi odnos povjerenja neprovjerenim.

Dvije veze, dva vlasnika, dva datuma obnove. Njihovo razdvajanje u dokumentaciji ono je što prijavu drži iskrenom.