Die VPN-sertifikaat beskerm nie die LDAP-been nie

’n VPN-aanmelding wat geloofsbriewe teen ’n gids nagaan, behels twee afsonderlike netwerkverbindings. Die gebruiker se verbinding na die gateway word deur die VPN se eie sertifikaat en protokolopstelling beskerm. Die gateway se verbinding na die gids is ’n ander sessie met sy eie TLS-instellings, sy eie trust store en sy eie foutmodusse. Niks omtrent die eerste waarborg enigiets omtrent die tweede nie.

Daardie asimmetrie is die meganisme agter ’n aanmelding wat geënkripteer lyk en steeds ’n bind-wagwoord in die oopte stuur.

Twee verbindings, twee vertrouensbesluite

Die buitenste sessie is wat die gebruiker sien: ’n sertifikaat wat aan die VPN-gasheernaam gebind is, deur die kliënt gevalideer, wat die verifikasie-uitruiling dra. Die binneste sessie behoort aan die gidskliënt binne die gateway, wat sy eie verbinding oopmaak en óf TLS onderhandel óf nie. Elke kant valideer die eweknie waarmee dit praat, met materiaal uit ’n ander opstellêer. ’n Verkeerd opgestelde binneste been bly onsigbaar van die gebruiker se kant, want die buitenste been werk presies soos bedoel.

Dit is waarom die fout stil eerder as hardop is. ’n Gateway wat nooit die gids se sertifikaat nagaan nie, verifieer steeds gebruikers korrek; dit verifieer hulle bloot oor ’n kanaal wat dit nie geverifieer het nie.

StartTLS en LDAPS, doelbewus gekies

StartTLS begin as gewone LDAP en gradeer in die plek op, gewoonlik op poort 389. LDAPS begin TLS saam met die verbinding, gewoonlik op 636. Albei is geldig en die adapter moet by die gids pas. Om StartTLS te vereis verskil daarvan om dit te probeer en voort te gaan wanneer die opgradering misluk, en juis daardie verskil is waar ’n bind-wagwoord kan ontsnap. Stel die streng modus op, en moenie ’n onbeskermde terugval vir ’n wagwoordbind toelaat nie.

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

Die -ZZ-vlag is die hele punt: die navraag misluk eerder as om stilweg sonder die opgradering voort te gaan. Name en rekeninge in daardie reël is voorbeelde. Die OpenLDAP TLS-dokumentasie dek die vertrouensinstellings daaronder.

Watter trust store lees die LDAP-kliënt?

Die OpenLDAP-kliëntbiblioteek lees sy eie vertrouensopstelling, hetsy uit die stelsellêer of uit ’n inprop-spesifieke instelling. Die VPN se CA-riglyn geld vir VPN-eweknieë en is nie bewys dat die LDAP-biblioteek dieselfde lêer lees nie. Gebruik die gids-gasheernaam wat die sertifikaat werklik dek, plus die uitreikende ketting wat die biblioteek vertrou. Op Active Directory, ontplooi ’n gidsdiens-sertifikaat met die regte bediener-verifikasiegebruik eerder as om uit ’n vertoonnaam af te lei.

Elke oorskakelingsbestemming moet aan dieselfde identiteitsbeleid voldoen. ’n Omgewing waar die primêre gevalideer word en die sekondêre nie, is slegter as een sonder oorskakeling, want die swakker pad word eers tydens ’n onderbreking ontdek.

Die bind-rekening bly ’n aparte probleem

Die beskerming van die vervoer verminder nie wat die bind-rekening mag doen nie. Gidssoekbereik, groepmagtiging en die voorregte van die diensrekening is afsonderlike besluite, en ’n breë bind-rekening bly breed nadat TLS geaktiveer is. Gebruik die nouste diensrekening en soekbasis wat die integrasie nodig het, en teken die eindpunt, TLS-modus, vertrouensienaar en hernuwingsproses saam met die VPN-opstelling aan.

Wanneer ’n sertifikaatwanpassing opduik, ontplooi die korrekte sertifikaat of ketting. Om verifikasie te deaktiveer verander ’n sigbare wanpassing in ’n onsigbare een en laat die tweede vertrouensverhouding ongetoets.

Twee verbindings, twee eienaars, twee hernuwingsdatums. Om hulle in die dokumentasie geskei te hou, is wat die aanmelding eerlik hou.