Potrdilo VPN ne ščiti odseka LDAP

Prijava v VPN, ki preverja poverilnice proti imeniku, vključuje dve ločeni omrežni povezavi. Povezava uporabnika s prehodom je zaščitena z lastnim potrdilom VPN in konfiguracijo protokola. Povezava prehoda z imenikom je druga seja z lastnimi nastavitvami TLS, lastnim skladiščem zaupanja in lastnimi načini okvare. Nič v prvi ne zagotavlja ničesar v drugi.

Ta asimetrija je mehanizem za prijavo, ki je videti šifrirana in vseeno pošlje geslo bind v odprti obliki.

Dve povezavi, dve odločitvi o zaupanju

Zunanja seja je tisto, kar vidi uporabnik: potrdilo, vezano na ime gostitelja VPN, ki ga preveri odjemalec in ki nosi izmenjavo overitve. Notranja seja pripada odjemalcu imenika znotraj prehoda, ki odpre svojo povezavo in bodisi se pogaja o TLS bodisi ne. Vsaka stran preveri nasprotno stran, s katero govori, z gradivom iz druge konfiguracijske datoteke. Napačno konfiguriran notranji odsek ostane z uporabnikove strani neviden, ker zunanji odsek deluje natanko tako, kot je bilo predvideno.

Zato je okvara tiha in ne glasna. Prehod, ki nikoli ne preveri potrdila imenika, še vedno pravilno overi uporabnike; preprosto overi jih po kanalu, ki ga ni preveril.

StartTLS in LDAPS, izbrana zavestno

StartTLS se odpre kot navaden LDAP in se nadgradi na mestu, običajno na vratih 389. LDAPS začne TLS s povezavo, običajno na 636. Oba sta legitimna in vmesnik se mora ujemati s tem, kar ponuja imenik. Zahtevati StartTLS je nekaj drugega kot ga preizkusiti in nadaljevati, ko nadgradnja ne uspe, in prav v tej razliki lahko geslo bind uide. Nastavite strogi način in ne dovolite nezaščitene rezervne poti za bind z geslom.

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

Možnost -ZZ je bistvo: poizvedba ne uspe, namesto da bi tiho nadaljevala brez nadgradnje. Imena in računi v tej vrstici so primeri. Dokumentacija OpenLDAP o TLS pokriva nastavitve zaupanja za tem.

Katero skladišče zaupanja bere odjemalec LDAP?

Knjižnica odjemalca OpenLDAP bere svojo konfiguracijo zaupanja, bodisi iz sistemske datoteke bodisi iz nastavitve, specifične za vtičnik. Direktiva CA v VPN velja za partnerje VPN in ni dokaz, da knjižnica LDAP bere isto datoteko. Uporabite ime gostitelja imenika, ki ga potrdilo dejansko pokriva, skupaj z izdajateljsko verigo, ki ji knjižnica zaupa. V Active Directory namestite potrdilo storitve imenika s pravilno uporabo za preverjanje strežnika, namesto da sklepate iz prikazanega imena.

Vsak cilj preklopa ob odpovedi mora izpolnjevati isto politiko identitete. Okolje, v katerem je primarni preverjen in sekundarni ne, je slabše od okolja brez preklopa, ker se šibkejša pot odkrije šele med izpadom.

Račun bind ostaja ločen problem

Zaščita prenosa ne zmanjša tega, kar sme račun bind početi. Obseg iskanja v imeniku, avtorizacija skupin in pravice servisnega računa so ločene odločitve, in širok račun bind ostane širok tudi po omogočitvi TLS. Uporabite najožji servisni račun in iskalno osnovo, ki ju integracija potrebuje, ter zabeležite končno točko, način TLS, lastnika zaupanja in postopek obnove skupaj s konfiguracijo VPN.

Ko se pojavi neujemanje potrdila, namestite pravilno potrdilo ali verigo. Izklop preverjanja spremeni vidno neujemanje v nevidno in pusti drugo razmerje zaupanja nepreverjeno.

Dve povezavi, dva lastnika, dva datuma obnove. Prav njuna ločenost v dokumentaciji ohranja prijavo pošteno.