VPN-varmente ei suojaa LDAP-osuutta

VPN-kirjautuminen, joka tarkistaa tunnistetiedot hakemistoa vastaan, sisältää kaksi erillistä verkkoyhteyttä. Käyttäjän yhteys yhdyskäytävään on suojattu VPN:n omalla varmenteella ja protokollan asetuksilla. Yhdyskäytävän yhteys hakemistoon on toinen istunto, jolla on omat TLS-asetukset, oma luottamusvarasto ja omat virhetilansa. Mikään ensimmäisessä ei takaa mitään toisesta.

Tämä epäsymmetria on mekanismi kirjautumisen takana, joka näyttää salatulta ja lähettää silti bind-salasana selkokielisenä.

Kaksi yhteyttä, kaksi luottamuspäätöstä

Ulompi istunto on se, mitä käyttäjä näkee: VPN:n isäntänimeen sidottu varmenne, asiakkaan validoima, joka kuljettaa todennusvaihdon. Sisempi istunto kuuluu yhdyskäytävän sisällä olevalle hakemistoasiakkaalle, joka avaa oman yhteytensä ja joko neuvottelee TLS:n tai ei. Kumpikin osapuoli validoi vastapuolen, jonka kanssa se puhuu, toisen asetustiedoston materiaalilla. Väärin asetettu sisempi osuus jää käyttäjän puolelta näkymättömäksi, koska ulompi osuus toimii juuri niin kuin on tarkoitettu.

Siksi vika on äänetön eikä äänekäs. Yhdyskäytävä, joka ei koskaan tarkista hakemiston varmennetta, todentaa käyttäjät silti oikein; se vain todentaa heidät kanavan kautta, jota se ei varmistanut.

StartTLS ja LDAPS, tietoisesti valittuina

StartTLS avautuu tavallisena LDAP:na ja päivitetään paikan päällä, tavallisesti portissa 389. LDAPS aloittaa TLS:n yhteyden mukana, tavallisesti portissa 636. Molemmat ovat laillisia ja sovittimen on vastattava sitä, mitä hakemisto tarjoaa. StartTLS:n vaatiminen on eri asia kuin sen kokeileminen ja jatkaminen, kun päivitys epäonnistuu, ja juuri siinä erossa bind-salasana voi vuotaa. Aseta tiukka tila äläkä salli suojaamatonta varareittiä salasanabindille.

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

-ZZ-valitsin on koko pointti: kysely epäonnistuu sen sijaan, että jatkuisi hiljaa ilman päivitystä. Rivin nimet ja tilit ovat esimerkkejä. OpenLDAP:n TLS-dokumentaatio kattaa sen taustalla olevat luottamusasetukset.

Mitä luottamusvarastoa LDAP-asiakas lukee?

OpenLDAP-asiakaskirjasto lukee oman luottamusasetuksensa, joko järjestelmätiedostosta tai liitännäiskohtaisesta asetuksesta. VPN:n CA-direktiivi koskee VPN-vastapuolia eikä todista, että LDAP-kirjasto lukee samaa tiedostoa. Käytä hakemiston isäntänimeä, jonka varmenne todella kattaa, sekä sitä myöntäjäketjua, johon kirjasto luottaa. Active Directoryssa ota käyttöön hakemistopalveluvarmenne oikealla palvelintodennuksen käytöllä sen sijaan, että päättelisit näyttönimestä.

Jokaisen failover-kohteen on täytettävä sama identiteettikäytäntö. Ympäristö, jossa ensisijainen validoidaan ja toissijaista ei, on huonompi kuin ympäristö ilman failoveria, koska heikompi polku havaitaan vasta katkon aikana.

Bind-tili pysyy erillisenä ongelmana

Liikenteen suojaaminen ei vähennä sitä, mitä bind-tili voi tehdä. Hakemistohaun laajuus, ryhmävaltuutus ja palvelutilin käyttöoikeudet ovat erillisiä päätöksiä, ja laaja bind-tili pysyy laajana myös TLS:n käyttöönoton jälkeen. Käytä kapeinta palvelutiliä ja hakukantaa, jonka integraatio tarvitsee, ja kirjaa päätepiste, TLS-tila, luottamuksen omistaja ja uusintaprosessi VPN-asetusten yhteyteen.

Kun varmenneepäsuhta ilmenee, ota käyttöön oikea varmenne tai ketju. Vahvistuksen poistaminen käytöstä muuttaa näkyvän epäsuhdan näkymättömäksi ja jättää toisen luottamussuhteen testaamatta.

Kaksi yhteyttä, kaksi omistajaa, kaksi uusintapäivää. Niiden pitäminen erillään dokumentaatiossa pitää kirjautumisen rehellisenä.