VPN-certifikatet beskytter ikke LDAP-benet

Et VPN-login, der kontrollerer legitimationsoplysninger mod et katalog, omfatter to separate netværksforbindelser. Brugerens forbindelse til gatewayen er beskyttet af VPN’ens eget certifikat og protokolopsætning. Gatewayens forbindelse til kataloget er en anden session med sine egne TLS-indstillinger, sit eget trust store og sine egne fejlmåder. Intet ved det første garanterer noget om det andet.

Den asymmetri er mekanismen bag et login, der ser krypteret ud og alligevel sender en bind-adgangskode i klartekst.

To forbindelser, to tillidsbeslutninger

Den ydre session er det, brugeren ser: et certifikat bundet til VPN-værtsnavnet, valideret af klienten, som bærer autentificeringsudvekslingen. Den indre session tilhører katalogklienten inde i gatewayen, som åbner sin egen forbindelse og enten forhandler TLS eller lader være. Hver side validerer den modpart, den taler med, ved hjælp af materiale fra en anden konfigurationsfil. Et fejlkonfigureret indre ben forbliver usynligt fra brugerens side, fordi det ydre ben fungerer præcis som tilsigtet.

Derfor er fejlen tavs snarere end højlydt. En gateway, der aldrig kontrollerer katalogets certifikat, autentificerer stadig brugerne korrekt; den autentificerer dem blot over en kanal, den ikke har verificeret.

StartTLS og LDAPS, valgt bevidst

StartTLS åbner som almindelig LDAP og opgraderes på stedet, konventionelt på port 389. LDAPS starter TLS med forbindelsen, konventionelt på 636. Begge er legitime, og adapteren skal matche det, kataloget tilbyder. At kræve StartTLS er noget andet end at prøve det og fortsætte, når opgraderingen fejler, og netop den forskel er, hvor en bind-adgangskode kan slippe ud. Konfigurer den strenge tilstand, og tillad ikke en ubeskyttet fallback til en bind med adgangskode.

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-flaget er hele pointen: forespørgslen fejler i stedet for lydløst at fortsætte uden opgraderingen. Navne og konti på den linje er eksempler. OpenLDAP’s TLS-dokumentation dækker de tillidsindstillinger, der ligger bag.

Hvilket trust store læser LDAP-klienten?

OpenLDAP-klientbiblioteket læser sin egen tillidskonfiguration, enten fra systemfilen eller fra en pluginspecifik indstilling. VPN’ens CA-direktiv gælder for VPN-peers og er ikke bevis for, at LDAP-biblioteket læser den samme fil. Brug det katalogværtsnavn, certifikatet faktisk dækker, plus den udstedende kæde, biblioteket stoler på. I Active Directory skal du implementere et katalogtjenestecertifikat med den korrekte brug til servergodkendelse i stedet for at ræsonnere ud fra et visningsnavn.

Hver failover-destination skal opfylde samme identitetspolitik. Et miljø, hvor den primære valideres og den sekundære ikke, er værre end et uden failover, fordi den svagere vej først opdages under et nedbrud.

Bind-kontoen forbliver et separat problem

Beskyttelse af transporten reducerer ikke, hvad bind-kontoen må gøre. Katalogsøgningsomfang, gruppeautorisation og servicekontoens privilegier er separate beslutninger, og en bred bind-konto forbliver bred, efter TLS er aktiveret. Brug den snævreste servicekonto og søgebasis, som integrationen har brug for, og registrér endpoint, TLS-tilstand, tillidsejer og fornyelsesproces sammen med VPN-konfigurationen.

Når en certifikatmismatch opstår, skal du implementere det korrekte certifikat eller den korrekte kæde. Deaktivering af validering gør en synlig mismatch usynlig og lader det andet tillidsforhold være utestet.

To forbindelser, to ejere, to fornyelsesdatoer. At holde dem adskilt i dokumentationen er det, der holder login’et ærligt.