Het VPN-certificaat beschermt het LDAP-deel niet

Een VPN-aanmelding die inloggegevens tegen een directory controleert, omvat twee afzonderlijke netwerkverbindingen. De verbinding van de gebruiker met de gateway is beschermd door het eigen certificaat van de VPN en de protocolconfiguratie. De verbinding van de gateway met de directory is een andere sessie met eigen TLS-instellingen, een eigen truststore en eigen faalwijzen. Niets aan de eerste garandeert iets over de tweede.

Die asymmetrie is het mechanisme achter een aanmelding die versleuteld lijkt en toch een bind-wachtwoord in platte tekst verstuurt.

Twee verbindingen, twee vertrouwensbeslissingen

De buitenste sessie is wat de gebruiker ziet: een certificaat dat aan de VPN-hostnaam is gebonden, door de client gevalideerd, dat de authenticatie-uitwisseling draagt. De binnenste sessie hoort bij de directoryclient in de gateway, die zijn eigen verbinding opent en al dan niet TLS onderhandelt. Elke kant valideert de tegenpartij waarmee hij spreekt, met materiaal uit een ander configuratiebestand. Een verkeerd geconfigureerd binnenste been blijft onzichtbaar vanaf de kant van de gebruiker, omdat het buitenste been precies werkt zoals bedoeld.

Daarom is de fout stil en niet luid. Een gateway die nooit het certificaat van de directory controleert, authenticeert gebruikers nog steeds correct; hij authenticeert ze alleen over een kanaal dat hij niet heeft geverifieerd.

StartTLS en LDAPS, bewust gekozen

StartTLS opent als gewone LDAP en wordt ter plaatse opgewaardeerd, gewoonlijk op poort 389. LDAPS start TLS met de verbinding, gewoonlijk op 636. Beide zijn legitiem en de adapter moet overeenkomen met wat de directory biedt. StartTLS eisen is iets anders dan het proberen en doorgaan wanneer de upgrade mislukt, en juist in dat verschil kan een bind-wachtwoord ontsnappen. Configureer de strikte modus en sta geen onbeveiligde terugvalweg toe voor een wachtwoord-bind.

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

De optie -ZZ is het hele punt: de query mislukt in plaats van stil door te gaan zonder de upgrade. Namen en accounts op die regel zijn voorbeelden. De TLS-documentatie van OpenLDAP behandelt de vertrouwensinstellingen erachter.

Welke truststore leest de LDAP-client?

De OpenLDAP-clientbibliotheek leest zijn eigen vertrouwensconfiguratie, hetzij uit het systeembestand, hetzij uit een plug-inspecifieke instelling. De CA-richtlijn van de VPN geldt voor VPN-peers en is geen bewijs dat de LDAP-bibliotheek hetzelfde bestand leest. Gebruik de directory-hostnaam die het certificaat werkelijk dekt, plus de uitgevende keten die de bibliotheek vertrouwt. Implementeer in Active Directory een directoryservicecertificaat met het juiste gebruik voor serverauthenticatie in plaats van te redeneren vanuit een weergavenaam.

Elke failover-bestemming moet aan hetzelfde identiteitsbeleid voldoen. Een omgeving waarin de primaire wordt gevalideerd en de secundaire niet, is slechter dan een zonder failover, omdat het zwakkere pad pas tijdens een storing wordt ontdekt.

Het bind-account blijft een apart probleem

Het transport beschermen vermindert niet wat het bind-account mag doen. Het zoekbereik in de directory, groepsautorisatie en de rechten van het serviceaccount zijn afzonderlijke beslissingen, en een breed bind-account blijft breed nadat TLS is ingeschakeld. Gebruik het smalste serviceaccount en de smalste zoekbasis die de integratie nodig heeft, en leg het eindpunt, de TLS-modus, de eigenaar van het vertrouwen en het vernieuwingsproces vast samen met de VPN-configuratie.

Wanneer een certificaatafwijking optreedt, implementeer het juiste certificaat of de juiste keten. Verificatie uitschakelen maakt een zichtbare afwijking onzichtbaar en laat de tweede vertrouwensrelatie ongetest.

Twee verbindingen, twee eigenaren, twee vernieuwingsdata. Ze gescheiden houden in de documentatie is wat de aanmelding eerlijk houdt.