VPN certifikát nechrání větev LDAP

Přihlášení přes VPN, které ověřuje přihlašovací údaje proti adresáři, zahrnuje dvě samostatná síťová připojení. Připojení uživatele k bráně chrání vlastní certifikát VPN a nastavení protokolu. Připojení brány k adresáři je jiná relace s vlastním nastavením TLS, vlastním úložištěm důvěry a vlastními režimy selhání. Nic z prvního nezaručuje nic o druhém.

Právě tato asymetrie je mechanismem přihlášení, které vypadá šifrovaně a přesto posílá heslo pro bind v otevřené podobě.

Dvě připojení, dvě rozhodnutí o důvěře

Vnější relace je to, co uživatel vidí: certifikát navázaný na název hostitele VPN, ověřený klientem, který nese výměnu autentizace. Vnitřní relace patří klientu adresáře uvnitř brány, který otevírá vlastní připojení a buď vyjedná TLS, nebo ne. Každá strana ověřuje protějšek, s nímž mluví, pomocí materiálu z jiného konfiguračního souboru. Špatně nakonfigurovaná vnitřní větev zůstává z pohledu uživatele neviditelná, protože vnější větev funguje přesně tak, jak má.

Proto je selhání tiché, a ne hlasité. Brána, která nikdy neověří certifikát adresáře, přesto uživatele autentizuje správně; jen je autentizuje přes kanál, který neověřila.

StartTLS a LDAPS, zvolené vědomě

StartTLS se otevírá jako obyčejné LDAP a na místě se povýší, obvykle na portu 389. LDAPS spouští TLS s připojením, obvykle na 636. Obojí je legitimní a adaptér musí odpovídat tomu, co adresář nabízí. Vyžadovat StartTLS je něco jiného než ho zkusit a pokračovat, když povýšení selže, a právě v tomto rozdílu může heslo pro bind uniknout. Nastavte striktní režim a nepovolujte nechráněnou záložní cestu pro bind s heslem.

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

Přepínač -ZZ je celý smysl: dotaz selže, místo aby tiše pokračoval bez povýšení. Názvy a účty v tomto řádku jsou příklady. Dokumentace OpenLDAP k TLS popisuje nastavení důvěry, které je za tím.

Které úložiště důvěry čte klient LDAP?

Klientská knihovna OpenLDAP čte vlastní konfiguraci důvěry, ať už ze systémového souboru, nebo z nastavení specifického pro plugin. Direktiva CA ve VPN platí pro protějšky VPN a není důkazem, že knihovna LDAP čte stejný soubor. Použijte název hostitele adresáře, který certifikát skutečně pokrývá, plus vydávající řetězec, kterému knihovna důvěřuje. V Active Directory nasaďte certifikát služby adresáře se správným použitím pro autentizaci serveru, místo abyste usuzovali ze zobrazovaného názvu.

Každý cíl přepnutí při výpadku musí splňovat stejnou zásadu identity. Prostředí, kde je primární uzel ověřen a sekundární ne, je horší než prostředí bez přepnutí, protože slabší cesta se odhalí jen během výpadku.

Účet pro bind zůstává samostatným problémem

Ochrana přenosu nesnižuje to, co může účet pro bind dělat. Rozsah hledání v adresáři, autorizace skupin a oprávnění servisního účtu jsou samostatná rozhodnutí a široký účet pro bind zůstává široký i po zapnutí TLS. Použijte nejužší servisní účet a vyhledávací základnu, které integrace potřebuje, a zaznamenejte koncový bod, režim TLS, vlastníka důvěry a proces obnovy spolu s konfigurací VPN.

Když se objeví neshoda certifikátu, nasaďte správný certifikát nebo řetězec. Vypnutí ověřování promění viditelnou neshodu v neviditelnou a druhý vztah důvěry zůstane neotestovaný.

Dvě připojení, dva vlastníci, dvě data obnovy. Právě jejich oddělení v dokumentaci drží přihlášení poctivé.