Hindi pinoprotektahan ng sertipiko ng VPN ang bahaging LDAP
Walang sinasabi ang naka-encrypt na sesyon ng kliyente tungkol sa koneksyon ng LDAP ng gateway. Pumili ng StartTLS o LDAPS at i-validate ang direktoryo gamit ang sarili nitong trust store.
Ang pag-login sa VPN na nagche-check ng mga kredensyal laban sa isang direktoryo ay may dalawang magkahiwalay na koneksyon sa network. Ang koneksyon ng gumagamit sa gateway ay pinoprotektahan ng sariling sertipiko ng VPN at ng kompigurasyon ng protokol. Ang koneksyon ng gateway sa direktoryo ay isang ibang sesyon na may sariling mga setting ng TLS, sariling trust store at sariling mga paraan ng pagpalya. Wala sa una ang gumagarantiya ng anuman tungkol sa pangalawa.
Ang asimetriyang iyon ang mekanismo sa likod ng pag-login na mukhang naka-encrypt at nagpapadala pa rin ng password ng bind nang lantad.
Dalawang koneksyon, dalawang desisyon sa pagtitiwala
Ang panlabas na sesyon ay ang nakikita ng gumagamit: isang sertipikong nakatali sa hostname ng VPN, na-validate ng kliyente, na nagdadala ng palitan ng authentication. Ang panloob na sesyon ay pag-aari ng kliyente ng direktoryo sa loob ng gateway, na nagbubukas ng sariling koneksyon at nag-uusap man o hindi tungkol sa TLS. Bawat panig ay nagva-validate ng kausap nito, gamit ang materyal mula sa ibang file ng kompigurasyon. Ang maling kompigurasyong panloob na bahagi ay nananatiling hindi nakikita mula sa panig ng gumagamit, dahil gumagana ang panlabas na bahagi nang eksakto ayon sa intensyon.
Kaya’t ang pagpalya ay tahimik at hindi maingay. Ang gateway na hindi kailanman nagche-check ng sertipiko ng direktoryo ay nagpapatunay pa rin ng mga gumagamit nang tama; pinatutunayan lamang sila sa isang channel na hindi nito na-verify.
StartTLS at LDAPS, sadyang pinili
Nagbubukas ang StartTLS bilang ordinaryong LDAP at naa-upgrade sa lugar, karaniwang sa port 389. Sinisimulan ng LDAPS ang TLS kasama ang koneksyon, karaniwang sa 636. Pareho itong lehitimo at dapat tumugma ang adapter sa inaalok ng direktoryo. Ang paghingi ng StartTLS ay iba sa pagsubok nito at pagpapatuloy kapag nabigo ang upgrade, at doon mismo sa pagkakaibang iyon maaaring makatakas ang password ng bind. I-kompigur ang mahigpit na mode, at huwag pahintulutan ang walang proteksyong reserbang landas para sa bind na may password.
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
Ang opsyon na -ZZ ang buong punto: nabibigo ang query sa halip na tahimik na magpatuloy nang walang upgrade. Ang mga pangalan at account sa linyang iyon ay mga halimbawa. Sinasaklaw ng dokumentasyon ng TLS ng OpenLDAP ang mga setting ng pagtitiwala sa likod nito.
Aling trust store ang binabasa ng kliyente ng LDAP?
Binabasa ng library ng kliyente ng OpenLDAP ang sarili nitong kompigurasyon ng pagtitiwala, mula man sa file ng system o sa setting na partikular sa plugin. Naaangkop ang direktiba ng CA ng VPN sa mga peer ng VPN at hindi ito patunay na binabasa ng library ng LDAP ang parehong file. Gamitin ang hostname ng direktoryo na aktwal na sinasaklaw ng sertipiko, kasama ang issuing chain na pinagkakatiwalaan ng library. Sa Active Directory, mag-deploy ng sertipiko ng serbisyo ng direktoryo na may tamang paggamit para sa server authentication sa halip na maghinuha mula sa display name.
Dapat matugunan ng bawat destinasyon ng failover ang parehong patakaran sa pagkakakilanlan. Ang kapaligirang na-validate ang pangunahin at hindi ang pangalawa ay mas masahol kaysa sa walang failover, dahil ang mas mahinang landas ay natutuklasan lamang sa panahon ng pagkagambala.
Ang account ng bind ay nananatiling hiwalay na problema
Hindi binabawasan ng pagprotekta sa transportasyon ang maaaring gawin ng account ng bind. Ang saklaw ng paghahanap sa direktoryo, awtorisasyon ng grupo at mga pribilehiyo ng service account ay magkakahiwalay na desisyon, at ang malawak na account ng bind ay nananatiling malawak pagkatapos paganahin ang TLS. Gamitin ang pinakamakitid na service account at search base na kailangan ng integrasyon, at itala ang endpoint, TLS mode, may-ari ng pagtitiwala at proseso ng pag-renew kasama ng kompigurasyon ng VPN.
Kapag lumitaw ang hindi pagkakatugma ng sertipiko, i-deploy ang tamang sertipiko o chain. Ang pag-disable ng verification ay ginagawang hindi nakikita ang nakikitang hindi pagkakatugma at iniiwan ang pangalawang ugnayan ng pagtitiwala na hindi nasubukan.
Dalawang koneksyon, dalawang may-ari, dalawang petsa ng pag-renew. Ang paghiwalay sa kanila sa dokumentasyon ang nagpapanatiling tapat ang pag-login.