VPN-certifikatet skyddar inte LDAP-delen

En VPN-inloggning som kontrollerar autentiseringsuppgifter mot en katalog omfattar två separata nätverksanslutningar. Användarens anslutning till gatewayen skyddas av VPN:ens eget certifikat och protokollkonfigurationen. Gatewayens anslutning till katalogen är en annan session med egna TLS-inställningar, eget förtroendelager och egna felmoder. Inget i den första garanterar något om den andra.

Den asymmetrin är mekanismen bakom en inloggning som ser krypterad ut och ändå skickar ett bind-lösenord i klartext.

Två anslutningar, två förtroendebeslut

Den yttre sessionen är det användaren ser: ett certifikat bundet till VPN:ens värdnamn, validerat av klienten, som bär autentiseringsutbytet. Den inre sessionen tillhör katalogklienten inne i gatewayen, som öppnar sin egen anslutning och antingen förhandlar TLS eller inte. Varje sida validerar motparten den talar med, med material från en annan konfigurationsfil. En felkonfigurerad inre del förblir osynlig från användarens sida, eftersom den yttre delen fungerar exakt som avsett.

Därför är felet tyst och inte högljutt. En gateway som aldrig kontrollerar katalogens certifikat autentiserar ändå användarna korrekt; den autentiserar dem bara över en kanal den inte har verifierat.

StartTLS och LDAPS, medvetet valda

StartTLS öppnas som vanlig LDAP och uppgraderas på plats, vanligen på port 389. LDAPS startar TLS med anslutningen, vanligen på 636. Båda är legitima och adaptern måste matcha det katalogen erbjuder. Att kräva StartTLS är något annat än att prova det och fortsätta när uppgraderingen misslyckas, och just i den skillnaden kan ett bind-lösenord läcka ut. Konfigurera det strikta läget och tillåt ingen oskyddad reservväg för en bind med lösenord.

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-flaggan är hela poängen: frågan misslyckas i stället för att tyst fortsätta utan uppgraderingen. Namnen och kontona på den raden är exempel. OpenLDAP:s TLS-dokumentation täcker förtroendeinställningarna bakom.

Vilket förtroendelager läser LDAP-klienten?

OpenLDAP-klientbiblioteket läser sin egen förtroendekonfiguration, antingen från systemfilen eller från en plugin-specifik inställning. VPN:ens CA-direktiv gäller VPN-peers och är inte bevis för att LDAP-biblioteket läser samma fil. Använd det katalogvärdnamn som certifikatet faktiskt täcker, plus den utgivarkedja biblioteket litar på. I Active Directory distribuerar du ett katalogtjänstcertifikat med rätt användning för serverautentisering i stället för att resonera från ett visningsnamn.

Varje failover-mål måste uppfylla samma identitetspolicy. En miljö där den primära valideras och den sekundära inte är sämre än en utan failover, eftersom den svagare vägen först upptäcks vid ett avbrott.

Bind-kontot förblir ett separat problem

Att skydda transporten minskar inte vad bind-kontot får göra. Sökningens omfattning i katalogen, gruppauktorisering och tjänstekontots behörigheter är separata beslut, och ett brett bind-konto förblir brett när TLS har slagits på. Använd det smalaste tjänstekontot och den smalaste sökbasen som integrationen behöver, och registrera slutpunkten, TLS-läget, förtroendeägaren och förnyelseprocessen tillsammans med VPN-konfigurationen.

När en certifikatavvikelse dyker upp distribuerar du rätt certifikat eller kedja. Att stänga av verifieringen förvandlar en synlig avvikelse till en osynlig och lämnar det andra förtroendeförhållandet otestat.

Två anslutningar, två ägare, två förnyelsedatum. Att hålla dem åtskilda i dokumentationen är det som håller inloggningen ärlig.