VPN sertifikatı LDAP ayağını qorumur

İstifadəçi məlumatlarını kataloqa qarşı yoxlayan VPN girişi iki ayrı şəbəkə bağlantısından ibarətdir. İstifadəçinin gateway-ə bağlantısı VPN-in öz sertifikatı və protokol konfiqurasiyası ilə qorunur. Gateway-in kataloqa bağlantısı isə öz TLS parametrləri, öz trust store-u və öz nasazlıq rejimləri olan başqa bir sessiyadır. Birincisi ilə bağlı heç nə ikincisi üçün heç nə zəmanət vermir.

Bu asimmetriya şifrələnmiş görünən, amma bind parolunu açıq şəkildə göndərən girişin mexanizmidir.

İki bağlantı, iki etimad qərarı

Xarici sessiya istifadəçinin gördüyüdür: VPN host adına bağlanmış, müştəri tərəfindən yoxlanılan və autentifikasiya mübadiləsini daşıyan sertifikat. Daxili sessiya gateway-in içindəki kataloq müştərisinə aiddir; o, öz bağlantısını açır və ya TLS razılaşdırır, ya da razılaşdırmır. Hər tərəf danışdığı həmsöhbəti başqa konfiqurasiya faylından götürülmüş materialla yoxlayır. Səhv konfiqurasiya edilmiş daxili ayaq istifadəçi tərəfindən görünməz qalır, çünki xarici ayaq tam nəzərdə tutulduğu kimi işləyir.

Buna görə nasazlıq uca deyil, səssizdir. Kataloqun sertifikatını heç vaxt yoxlamayan gateway istifadəçiləri yenə də düzgün autentifikasiya edir; sadəcə onları yoxlamadığı kanal üzərindən autentifikasiya edir.

StartTLS və LDAPS, şüurlu seçim

StartTLS adi LDAP kimi açılır və yerində yüksəldilir, adətən 389 portunda. LDAPS isə TLS-i bağlantı ilə birlikdə başladır, adətən 636 portunda. Hər ikisi qanunidir və adapter kataloqun təklif etdiyinə uyğun olmalıdır. StartTLS tələb etmək onu sınayıb yüksəltmə uğursuz olduqda davam etməkdən fərqlidir və məhz bu fərq bind parolunun çıxa biləcəyi yerdir. Ciddi rejimi konfiqurasiya edin və parol bind üçün qorunmayan ehtiyat yoluna icazə verməyin.

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 seçimi bütün məsələnin özüdür: sorğu yüksəltmə olmadan səssizcə davam etmək əvəzinə uğursuz olur. O sətirdəki adlar və hesablar nümunədir. OpenLDAP TLS sənədləri bunun arxasındakı etimad parametrlərini əhatə edir.

LDAP müştərisi hansı trust store-u oxuyur?

OpenLDAP müştəri kitabxanası öz etimad konfiqurasiyasını oxuyur: istər sistem faylından, istərsə də plaginə xas parametrdən. VPN-in CA direktivi VPN həmsöhbətlərinə aiddir və LDAP kitabxanasının eyni faylı oxumasına dəlil deyil. Sertifikatın həqiqətən əhatə etdiyi kataloq host adını, üstəlik kitabxananın etibar etdiyi verən zənciri istifadə edin. Active Directory-də göstərilən addan çıxış edərək deyil, düzgün server autentifikasiyası istifadəsi ilə kataloq xidməti sertifikatı yerləşdirin.

Hər failover hədəfi eyni kimlik siyasətini təmin etməlidir. Əsasın yoxlanıldığı, ikincisinin yoxlanmadığı mühit heç failover olmayan mühitdən pisdir, çünki zəif yol yalnız kəsinti zamanı aşkar edilir.

Bind hesabı ayrı bir problem olaraq qalır

Nəqli qorumaq bind hesabının nə edə biləcəyini azaltmır. Kataloq axtarış əhatəsi, qrup avtorizasiyası və xidmət hesabının imtiyazları ayrı qərarlardır və geniş bind hesabı TLS aktivləşdirildikdən sonra da geniş qalır. İnteqrasiyanın ehtiyac duyduğu ən dar xidmət hesabını və axtarış bazasını istifadə edin, endpoint-i, TLS rejimini, etimad sahibini və yenilənmə prosesini VPN konfiqurasiyası ilə birlikdə qeyd edin.

Sertifikat uyğunsuzluğu görünəndə düzgün sertifikatı və ya zənciri yerləşdirin. Yoxlamanı söndürmək görünən uyğunsuzluğu görünməz birinə çevirir və ikinci etimad əlaqəsini sınaqsız qoyur.

İki bağlantı, iki sahib, iki yenilənmə tarixi. Onları sənədləşdirmədə ayrı saxlamaq girişi dürüst saxlayan şeydir.