VPN sertifikatas neapsaugo LDAP atkarpos

VPN prisijungimas, kuris tikrina prisijungimo duomenis kataloge, apima du atskirus tinklo ryšius. Naudotojo ryšys su šliuzu apsaugotas pačiu VPN sertifikatu ir protokolo konfigūracija. Šliuzo ryšys su katalogu yra kita sesija su savais TLS nustatymais, sava patikimumo saugykla ir savais gedimo būdais. Niekas pirmajame negarantuoja nieko apie antrąjį.

Ši asimetrija yra mechanizmas, slypintis už prisijungimo, kuris atrodo užšifruotas ir vis tiek siunčia bind slaptažodį atviru tekstu.

Du ryšiai, du pasitikėjimo sprendimai

Išorinė sesija yra tai, ką mato naudotojas: sertifikatas, susietas su VPN mazgo vardu, kliento patikrintas, perduodantis autentifikavimo mainus. Vidinė sesija priklauso katalogo klientui šliuzo viduje, kuris atidaro savo ryšį ir arba derasi dėl TLS, arba ne. Kiekviena pusė tikrina pašnekovą, su kuriuo kalba, naudodama medžiagą iš kito konfigūracijos failo. Neteisingai sukonfigūruota vidinė atkarpa lieka nematoma naudotojo pusėje, nes išorinė atkarpa veikia būtent taip, kaip numatyta.

Todėl gedimas tylus, o ne garsus. Šliuzas, kuris niekada netikrina katalogo sertifikato, vis tiek teisingai autentifikuoja naudotojus; jis tiesiog autentifikuoja juos kanalu, kurio nepatikrino.

StartTLS ir LDAPS, pasirinkti sąmoningai

StartTLS atsidaro kaip paprastas LDAP ir atnaujinamas vietoje, įprastai prievade 389. LDAPS pradeda TLS kartu su ryšiu, įprastai 636. Abu yra teisėti ir adapteris turi atitikti tai, ką siūlo katalogas. Reikalauti StartTLS yra kas kita nei jį išbandyti ir tęsti, kai atnaujinimas nepavyksta, ir būtent tame skirtume bind slaptažodis gali ištrūkti. Nustatykite griežtą režimą ir neleiskite neapsaugoto atsarginio kelio slaptažodžio bind atveju.

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 parinktis yra visas esmė: užklausa nepavyksta, o ne tyliai tęsiasi be atnaujinimo. Tos eilutės vardai ir paskyros yra pavyzdžiai. OpenLDAP TLS dokumentacija apima pasitikėjimo nustatymus, kurie už to slypi.

Kurią patikimumo saugyklą skaito LDAP klientas?

OpenLDAP kliento biblioteka skaito savo pasitikėjimo konfigūraciją, arba iš sistemos failo, arba iš papildinio specifinio nustatymo. VPN CA direktyva taikoma VPN partneriams ir nėra įrodymas, kad LDAP biblioteka skaito tą patį failą. Naudokite katalogo mazgo vardą, kurį sertifikatas iš tikrųjų apima, kartu su išdavimo grandine, kuria biblioteka pasitiki. Active Directory aplinkoje įdiekite katalogo tarnybos sertifikatą su tinkamu serverio autentifikavimo naudojimu, o ne spręskite iš rodomo vardo.

Kiekviena perjungimo vietą turi atitikti tą pačią tapatybės politiką. Aplinka, kurioje pirminis patikrinamas, o antrinis ne, yra blogesnė nei be perjungimo, nes silpnesnis kelias atrandamas tik per triktį.

Bind paskyra lieka atskira problema

Transporto apsauga nesumažina to, ką gali daryti bind paskyra. Katalogo paieškos apimtis, grupės autorizacija ir tarnybos paskyros privilegijos yra atskiri sprendimai, o plati bind paskyra išlieka plati įjungus TLS. Naudokite siauriausią tarnybos paskyrą ir paieškos bazę, kurių reikia integracijai, ir užrašykite galinį tašką, TLS režimą, pasitikėjimo savininką ir atnaujinimo procesą kartu su VPN konfigūracija.

Kai atsiranda sertifikato neatitikimas, įdiekite teisingą sertifikatą arba grandinę. Patikros išjungimas matomą neatitikimą paverčia nematomu ir palieka antrąjį pasitikėjimo santykį neišbandytą.

Du ryšiai, du savininkai, dvi atnaujinimo datos. Jų atskyrimas dokumentacijoje ir palaiko prisijungimą sąžiningą.