VPN-sertifikatet vernar ikkje LDAP-beinet

Ei VPN-innlogging som kontrollerer legitimasjon mot ein katalog, omfattar to separate nettverkstilkoplingar. Tilkoplinga til brukaren mot gatewayen er verna av VPN-sertifikatet sjølv og protokollkonfigurasjonen. Tilkoplinga til gatewayen mot katalogen er ein annan sesjon med eigne TLS-innstillingar, eige tillitslager og eigne feilmodusar. Ingenting ved den første garanterer noko om den andre.

Den asymmetrien er mekanismen bak ei innlogging som ser kryptert ut og likevel sender eit bind-passord i klartekst.

To tilkoplingar, to tillitsavgjerder

Den ytre sesjonen er det brukaren ser: eit sertifikat bunde til VPN-vertsnamnet, validert av klienten, som ber autentiseringsutvekslinga. Den indre sesjonen høyrer til katalogklienten inne i gatewayen, som opnar si eiga tilkopling og anten forhandlar TLS eller ikkje. Kvar side validerer motparten han snakkar med, ved hjelp av materiale frå ei anna konfigurasjonsfil. Eit feilkonfigurert indre bein blir verande usynleg frå brukarsida, fordi det ytre beinet fungerer nøyaktig som tenkt.

Derfor er feilen stille og ikkje høglydt. Ein gateway som aldri kontrollerer sertifikatet til katalogen, autentiserer brukarane likevel korrekt; han autentiserer dei berre over ein kanal han ikkje har verifisert.

StartTLS og LDAPS, valde med vilje

StartTLS opnar som vanleg LDAP og blir oppgradert på staden, vanlegvis på port 389. LDAPS startar TLS med tilkoplinga, vanlegvis på 636. Begge er legitime, og adapteren må samsvare med det katalogen tilbyr. Å krevje StartTLS er noko anna enn å prøve det og halde fram når oppgraderinga feilar, og nettopp i den skilnaden kan eit bind-passord sleppe ut. Konfigurer den strenge modusen, og tillat ikkje ein uverna reserveveg for ein bind med passord.

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-flagget er heile poenget: spørjinga feilar i staden for å halde stille fram utan oppgraderinga. Namn og kontoar på den linja er døme. OpenLDAP sin TLS-dokumentasjon dekkjer tillitsinnstillingane bak.

Kva tillitslager les LDAP-klienten?

OpenLDAP-klientbiblioteket les sin eigen tillitskonfigurasjon, anten frå systemfila eller frå ei plugin-spesifikk innstilling. CA-direktivet til VPN gjeld VPN-motpartar og er ikkje prov for at LDAP-biblioteket les same fila. Bruk katalogvertsnamnet sertifikatet faktisk dekkjer, pluss utferdskjeda biblioteket stolar på. I Active Directory, distribuer eit katalogtenestesertifikat med rett bruk for tenarautentisering i staden for å resonnere frå eit visingsnamn.

Kvar failover-destinasjon må oppfylle same identitetspolitikk. Eit miljø der primæren blir validert og sekundæren ikkje, er verre enn eitt utan failover, fordi den svakare vegen først blir oppdaga under eit avbrot.

Bind-kontoen blir verande eit separat problem

Å verne transporten reduserer ikkje kva bind-kontoen kan gjere. Katalogsøkjeomfang, gruppeautorisasjon og rettane til tenestekontoen er separate avgjerder, og ein brei bind-konto blir verande brei etter at TLS er slått på. Bruk den smalaste tenestekontoen og søkjebasen integrasjonen treng, og registrer endepunktet, TLS-modus, tillitseigaren og fornyingsprosessen saman med VPN-konfigurasjonen.

Når eit sertifikatavvik dukkar opp, distribuer det rette sertifikatet eller kjeda. Å slå av verifisering gjer eit synleg avvik usynleg og lèt det andre tillitsforholdet stå utesta.

To tilkoplingar, to eigarar, to fornyingsdatoar. Å halde dei fråskilde i dokumentasjonen er det som held innlogginga ærleg.