Certifikata VPN nuk mbron segmentin LDAP

Një hyrje VPN që kontrollon kredencialet kundrejt një drejtorie përfshin dy lidhje rrjeti të ndara. Lidhja e përdoruesit me portën mbrohet nga certifikata e vetë VPN-së dhe konfigurimi i protokollit. Lidhja e portës me drejtorinë është një sesion tjetër me cilësimet e veta TLS, depon e vet të besimit dhe mënyrat e veta të dështimit. Asgjë në të parën nuk garanton asgjë për të dytën.

Kjo asimetri është mekanizmi pas një hyrjeje që duket e kriptuar dhe gjithsesi dërgon fjalëkalimin e bind-it hapur.

Dy lidhje, dy vendime besimi

Sesioni i jashtëm është ajo që sheh përdoruesi: një certifikatë e lidhur me emrin e hostit të VPN-së, e verifikuar nga klienti, që mbart shkëmbimin e vërtetimit. Sesioni i brendshëm i përket klientit të drejtorisë brenda portës, i cili hap lidhjen e vet dhe ose negocion TLS ose jo. Secila anë verifikon palën me të cilën flet, duke përdorur material nga një skedar tjetër konfigurimi. Segmenti i brendshëm i konfiguruar gabimisht mbetet i padukshëm nga ana e përdoruesit, sepse segmenti i jashtëm funksionon saktësisht siç është planifikuar.

Kjo është arsyeja pse dështimi është i qetë dhe jo i zhurmshëm. Një portë që nuk kontrollon kurrë certifikatën e drejtorisë vazhdon t’i vërtetojë përdoruesit saktë; thjesht i vërteton ata përmes një kanali që nuk e ka verifikuar.

StartTLS dhe LDAPS, të zgjedhura me qëllim

StartTLS hapet si LDAP i thjeshtë dhe përmirësohet në vend, zakonisht në portin 389. LDAPS nis TLS bashkë me lidhjen, zakonisht në 636. Të dyja janë legjitime dhe përshtatësi duhet të përputhet me atë që ofron drejtoria. Të kërkosh StartTLS është ndryshe nga ta provosh dhe të vazhdosh kur përmirësimi dështon, dhe pikërisht në atë ndryshim fjalëkalimi i bind-it mund të shpëtojë. Konfiguroni modalitetin strikt dhe mos lejoni një rrugë rezervë të pambrojtur për një bind me fjalëkalim.

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

Opsioni -ZZ është i gjithë qëllimi: kërkesa dështon në vend që të vazhdojë në heshtje pa përmirësimin. Emrat dhe llogaritë në atë rresht janë shembuj. Dokumentacioni TLS i OpenLDAP mbulon cilësimet e besimit pas tij.

Cilën depo besimi lexon klienti LDAP?

Biblioteka e klientit OpenLDAP lexon konfigurimin e vet të besimit, qoftë nga skedari i sistemit qoftë nga një cilësim specifik i shtojcës. Direktiva CA e VPN-së vlen për palët e VPN-së dhe nuk është provë që biblioteka LDAP lexon të njëjtin skedar. Përdorni emrin e hostit të drejtorisë që certifikata mbulon vërtet, plus zinxhirin lëshues që biblioteka i beson. Në Active Directory, vendosni një certifikatë shërbimi drejtorie me përdorimin e saktë për vërtetimin e serverit në vend që të arsyetoni nga një emër i shfaqur.

Çdo destinacion i kalimit në rast dështimi duhet të plotësojë të njëjtën politikë identiteti. Një mjedis ku primari verifikohet dhe sekondari jo është më i keq se një pa kalim, sepse rruga më e dobët zbulohet vetëm gjatë një ndërprerjeje.

Llogaria e bind-it mbetet problem më vete

Mbrojtja e transportit nuk zvogëlon atë që llogaria e bind-it mund të bëjë. Shtrirja e kërkimit në drejtori, autorizimi i grupeve dhe privilegjet e llogarisë së shërbimit janë vendime të ndara, dhe një llogari bind e gjerë mbetet e gjerë pasi aktivizohet TLS. Përdorni llogarinë e shërbimit dhe bazën e kërkimit më të ngushta që i nevojiten integrimit, dhe regjistroni pikën fundore, modalitetin TLS, pronarin e besimit dhe procesin e rinovimit së bashku me konfigurimin e VPN-së.

Kur shfaqet një mospërputhje certifikate, vendosni certifikatën ose zinxhirin e saktë. Çaktivizimi i verifikimit e kthen një mospërputhje të dukshme në të padukshme dhe e lë lidhjen e dytë të besimit të paprovuar.

Dy lidhje, dy pronarë, dy data rinovimi. Mbajtja e tyre të ndara në dokumentacion është ajo që e mban hyrjen të ndershme.