VPN-sertifikaat ei kaitse LDAP-lüli

VPN-sisselogimine, mis kontrollib volitusi kataloogi vastu, hõlmab kahte eraldi võrguühendust. Kasutaja ühendus lüüsiga on kaitstud VPN-i enda sertifikaadi ja protokolli seadistusega. Lüüsi ühendus kataloogiga on teine seanss, millel on oma TLS-seaded, oma usaldushoidla ja oma tõrkerežiimid. Miski esimeses ei taga midagi teise kohta.

See asümmeetria on mehhanism sisselogimise taga, mis näib krüpteeritud ja saadab siiski bind-parooli avatekstina.

Kaks ühendust, kaks usaldusotsust

Väline seanss on see, mida kasutaja näeb: VPN-i hostinimega seotud sertifikaat, mille klient on valideerinud ja mis kannab autentimisvahetust. Sisemine seanss kuulub lüüsi sees olevale kataloogikliendile, mis avab oma ühenduse ja kas läbiräägib TLS-i või mitte. Kumbki pool valideerib vestluspartneri, kellega ta räägib, kasutades materjali teisest seadistusfailist. Valesti seadistatud sisemine lüli jääb kasutaja poolt nähtamatuks, sest väline lüli töötab täpselt ettenähtud viisil.

Seetõttu on tõrge vaikne, mitte vali. Lüüs, mis ei kontrolli kunagi kataloogi sertifikaati, autentib kasutajaid siiski õigesti; ta lihtsalt autentib neid kanali kaudu, mida ta ei kontrollinud.

StartTLS ja LDAPS, teadlikult valitud

StartTLS avaneb tavalise LDAP-ina ja täiustatakse kohapeal, tavaliselt pordil 389. LDAPS käivitab TLS-i koos ühendusega, tavaliselt pordil 636. Mõlemad on legitiimsed ja adapter peab vastama sellele, mida kataloog pakub. StartTLS-i nõudmine erineb selle proovimisest ja jätkamisest, kui täiustamine ebaõnnestub, ja täpselt selles erinevuses võib bind-parool välja pääseda. Seadistage range režiim ja ärge lubage parooliga bindi jaoks kaitsmata varuteed.

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

Valik -ZZ on kogu mõte: päring ebaõnnestub, selle asemel et vaikselt ilma täiustamiseta jätkata. Selle rea nimed ja kontod on näited. OpenLDAP-i TLS-dokumentatsioon käsitleb selle taga olevaid usaldusseadeid.

Millist usaldushoidlat LDAP-klient loeb?

OpenLDAP-i klienditeek loeb oma usaldusseadistust, olgu see süsteemifailist või pistikupõhisest seadest. VPN-i CA-direktiiv kehtib VPN-partneritele ega ole tõestus, et LDAP-teek loeb sama faili. Kasutage kataloogi hostinime, mida sertifikaat tegelikult katab, pluss väljaandja ahelat, mida teek usaldab. Active Directorys juurutage kataloogiteenuse sertifikaat õige serveriautentimise kasutusega, selle asemel et kuvatavast nimest järeldada.

Iga ümberlülituse sihtkoht peab vastama samale identiteedipoliitikale. Keskkond, kus esmane on valideeritud ja teisene mitte, on halvem kui ilma ümberlülituseta, sest nõrgem tee avastatakse alles katkestuse ajal.

Bind-konto jääb eraldi probleemiks

Transpordi kaitsmine ei vähenda seda, mida bind-konto tohib teha. Kataloogi otsingu ulatus, gruppide autoriseerimine ja teenusekonto õigused on eraldi otsused ning lai bind-konto jääb laiaks ka pärast TLS-i lubamist. Kasutage kitsaimat teenusekontot ja otsingubaasi, mida integratsioon vajab, ning kirjutage lõpp-punkt, TLS-režiim, usalduse omanik ja uuendusprotsess VPN-i seadistuse juurde.

Kui ilmneb sertifikaadi mittevastavus, juurutage õige sertifikaat või ahel. Kontrollimise väljalülitamine muudab nähtava mittevastavuse nähtamatuks ja jätab teise usaldussuhte testimata.

Kaks ühendust, kaks omanikku, kaks uuenduskuupäeva. Nende dokumentatsioonis lahus hoidmine on see, mis hoiab sisselogimise ausana.