A VPN-tanúsítvány nem védi az LDAP-szakaszt

Az a VPN-bejelentkezés, amely a hitelesítő adatokat egy könyvtárral szemben ellenőrzi, két külön hálózati kapcsolatot foglal magában. A felhasználó átjáróhoz vezető kapcsolatát a VPN saját tanúsítványa és protokollkonfigurációja védi. Az átjáró könyvtárhoz vezető kapcsolata egy másik munkamenet, saját TLS-beállításokkal, saját trust store-ral és saját meghibásodási módokkal. Semmi az elsőben nem garantál semmit a másodikban.

Ez az aszimmetria áll annak a bejelentkezésnek a hátterében, amely titkosítottnak látszik, és mégis nyílt szövegben küldi a bind-jelszót.

Két kapcsolat, két bizalmi döntés

A külső munkamenet az, amit a felhasználó lát: a VPN-gépnévhez kötött tanúsítvány, amelyet a kliens validál, és amely a hitelesítési cserét szállítja. A belső munkamenet az átjárón belüli könyvtárkliensé, amely saját kapcsolatot nyit, és vagy megtárgyalja a TLS-t, vagy nem. Mindkét fél validálja a partnert, amellyel beszél, egy másik konfigurációs fájlból származó anyaggal. Egy hibásan konfigurált belső szakasz a felhasználó oldaláról láthatatlan marad, mert a külső szakasz pontosan a tervezett módon működik.

Ezért a hiba csendes, nem hangos. Az az átjáró, amely soha nem ellenőrzi a könyvtár tanúsítványát, továbbra is helyesen hitelesíti a felhasználókat; csak éppen egy olyan csatornán hitelesíti őket, amelyet nem ellenőrzött.

StartTLS és LDAPS, szándékosan választva

A StartTLS egyszerű LDAP-ként nyílik meg, és a helyszínen frissül, hagyományosan a 389-es porton. Az LDAPS a kapcsolattal együtt indítja a TLS-t, hagyományosan a 636-on. Mindkettő legitim, és az adapternek meg kell felelnie annak, amit a könyvtár kínál. A StartTLS megkövetelése más, mint kipróbálni, és folytatni, amikor a frissítés meghiúsul, és pontosan ebben a különbségben szökhet meg egy bind-jelszó. Konfigurálja a szigorú módot, és ne engedjen védelem nélküli tartalék utat jelszavas bindhez.

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

A -ZZ kapcsoló a lényeg: a lekérdezés meghiúsul, ahelyett hogy csendben folytatódna a frissítés nélkül. Az ebben a sorban szereplő nevek és fiókok példák. Az OpenLDAP TLS-dokumentációja lefedi a mögötte álló bizalmi beállításokat.

Melyik trust store-t olvassa az LDAP-kliens?

Az OpenLDAP klienskönyvtár a saját bizalmi konfigurációját olvassa, akár a rendszerfájlból, akár egy bővítményspecifikus beállításból. A VPN CA-direktívája a VPN-társakra vonatkozik, és nem bizonyíték arra, hogy az LDAP-könyvtár ugyanazt a fájlt olvassa. Használja azt a könyvtár-gépnevet, amelyet a tanúsítvány valóban lefed, plusz azt a kibocsátó láncot, amelyben a könyvtár megbízik. Az Active Directoryban telepítsen könyvtárszolgáltatás-tanúsítványt a helyes kiszolgálóhitelesítési felhasználással, ahelyett hogy egy megjelenített névből következtetne.

Minden failover-célnak ugyanazt az identitáspolitikát kell teljesítenie. Az a környezet, ahol az elsődleges validált, a másodlagos pedig nem, rosszabb, mint a failover nélküli, mert a gyengébb útvonal csak egy kiesés során derül ki.

A bind-fiók külön problémaként marad

A szállítás védelme nem csökkenti azt, amit a bind-fiók tehet. A könyvtárkeresési hatókör, a csoportos engedélyezés és a szolgáltatásfiók jogosultságai külön döntések, és egy széles bind-fiók széles marad a TLS engedélyezése után is. Használja a legszűkebb szolgáltatásfiókot és keresési bázist, amelyre az integrációnak szüksége van, és rögzítse a végpontot, a TLS-módot, a bizalom tulajdonosát és a megújítási folyamatot a VPN-konfigurációval együtt.

Amikor tanúsítvány-eltérés jelenik meg, telepítse a helyes tanúsítványt vagy láncot. Az ellenőrzés kikapcsolása látható eltérést tesz láthatatlanná, és a második bizalmi kapcsolat tesztelés nélkül marad.

Két kapcsolat, két tulajdonos, két megújítási dátum. A dokumentációban való elkülönítésük tartja őszintén a bejelentkezést.