VPN-sertifikatet beskytter ikke LDAP-benet

En VPN-innlogging som kontrollerer legitimasjon mot en katalog, omfatter to separate nettverkstilkoblinger. Brukerens tilkobling til gatewayen er beskyttet av VPN-ens eget sertifikat og protokollkonfigurasjonen. Gatewayens tilkobling til katalogen er en annen sesjon med egne TLS-innstillinger, eget tillitslager og egne feilmoduser. Ingenting ved den første garanterer noe om den andre.

Denne asymmetrien er mekanismen bak en innlogging som ser kryptert ut og likevel sender et bind-passord i klartekst.

To tilkoblinger, to tillitsbeslutninger

Den ytre sesjonen er det brukeren ser: et sertifikat bundet til VPN-vertsnavnet, validert av klienten, som bærer autentiseringsutvekslingen. Den indre sesjonen tilhører katalogklienten inne i gatewayen, som åpner sin egen tilkobling og enten forhandler TLS eller ikke. Hver side validerer motparten den snakker med, ved hjelp av materiale fra en annen konfigurasjonsfil. Et feilkonfigurert indre ben forblir usynlig fra brukerens side, fordi det ytre benet fungerer nøyaktig som tiltenkt.

Derfor er feilen stille og ikke høylytt. En gateway som aldri kontrollerer katalogens sertifikat, autentiserer fortsatt brukerne riktig; den autentiserer dem bare over en kanal den ikke har verifisert.

StartTLS og LDAPS, valgt bevisst

StartTLS åpner som vanlig LDAP og oppgraderes på stedet, vanligvis på port 389. LDAPS starter TLS med tilkoblingen, vanligvis på 636. Begge er legitime, og adapteren må samsvare med det katalogen tilbyr. Å kreve StartTLS er noe annet enn å prøve det og fortsette når oppgraderingen feiler, og nettopp i den forskjellen kan et bind-passord slippe ut. Konfigurer den strenge modusen, og ikke tillat en ubeskyttet reservevei for en 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 hele poenget: spørringen feiler i stedet for stille å fortsette uten oppgraderingen. Navn og kontoer på den linjen er eksempler. OpenLDAPs TLS-dokumentasjon dekker tillitsinnstillingene bak.

Hvilket tillitslager leser LDAP-klienten?

OpenLDAP-klientbiblioteket leser sin egen tillitskonfigurasjon, enten fra systemfilen eller fra en plugin-spesifikk innstilling. VPN-ens CA-direktiv gjelder VPN-motparter og er ikke bevis for at LDAP-biblioteket leser samme fil. Bruk katalogvertsnavnet sertifikatet faktisk dekker, pluss utstedelseskjeden biblioteket stoler på. I Active Directory, distribuer et katalogtjenestesertifikat med riktig bruk for serverautentisering i stedet for å resonnere fra et visningsnavn.

Hver failover-destinasjon må oppfylle samme identitetspolicy. Et miljø der primæren valideres og sekundæren ikke, er verre enn ett uten failover, fordi den svakere veien først oppdages under en driftsstans.

Bind-kontoen forblir et separat problem

Å beskytte transporten reduserer ikke hva bind-kontoen kan gjøre. Katalogsøkeomfang, gruppeautorisasjon og tjenestekontoens rettigheter er separate beslutninger, og en bred bind-konto forblir bred etter at TLS er aktivert. Bruk den smaleste tjenestekontoen og søkebasen integrasjonen trenger, og registrer endepunktet, TLS-modus, tillitseieren og fornyelsesprosessen sammen med VPN-konfigurasjonen.

Når en sertifikatavvik oppstår, distribuer det riktige sertifikatet eller kjeden. Å deaktivere verifisering gjør et synlig avvik usynlig og lar det andre tillitsforholdet være utestet.

To tilkoblinger, to eiere, to fornyelsesdatoer. Å holde dem atskilt i dokumentasjonen er det som holder innloggingen ærlig.