Cheti cha VPN hakilindi sehemu ya LDAP

Kuingia kwa VPN kunakokagua vitambulisho dhidi ya saraka kunahusisha miunganisho miwili tofauti ya mtandao. Muunganisho wa mtumiaji kwa lango unalindwa na cheti cha VPN chenyewe na usanidi wa itifaki. Muunganisho wa lango kwa saraka ni kipindi kingine chenye mipangilio yake ya TLS, hifadhi yake ya uaminifu na njia zake za kushindwa. Hakuna chochote katika cha kwanza kinachohakikisha chochote kuhusu cha pili.

Utengano huo ndio utaratibu ulio nyuma ya kuingia kunakoonekana kusimbwa na bado kutuma nenosiri la bind wazi.

Miunganisho miwili, maamuzi mawili ya uaminifu

Kipindi cha nje ndicho mtumiaji anachokiona: cheti kilichofungwa kwa jina la mwenyeji wa VPN, kilichothibitishwa na mteja, kinachobeba mabadilishano ya uthibitishaji. Kipindi cha ndani ni cha mteja wa saraka ndani ya lango, ambaye hufungua muunganisho wake mwenyewe na ama hujadili TLS au hafanyi. Kila upande huthibitisha mwenzake anaongea naye, kwa kutumia nyenzo kutoka faili lingine la usanidi. Sehemu ya ndani iliyowekwa vibaya inabaki isionekane kutoka upande wa mtumiaji, kwa sababu sehemu ya nje hufanya kazi kama ilivyokusudiwa.

Ndio sababu hitilafu hiyo ni ya kimya na si ya kelele. Lango lisilokagua kamwe cheti cha saraka bado huthibitisha watumiaji kwa usahihi; linawathibitisha tu kupitia njia isiyothibitishwa.

StartTLS na LDAPS, zilizochaguliwa kwa makusudi

StartTLS hufunguka kama LDAP ya kawaida na hupandishwa mahali hapo, kwa kawaida kwenye lango 389. LDAPS huanza TLS pamoja na muunganisho, kwa kawaida kwenye 636. Zote mbili ni halali na adapta lazima ilingane na kile saraka inachotoa. Kuhitaji StartTLS ni tofauti na kuijaribu na kuendelea wakati upandishaji unashindikana, na ndani ya tofauti hiyo nenosiri la bind linaweza kutoroka. Sanidi hali ya ukali, na usiruhusu njia mbadala isiyolindwa kwa bind ya nenosiri.

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

Chaguo -ZZ ndio hoja yote: swali hushindikana badala ya kuendelea kimya bila upandishaji. Majina na akaunti kwenye mstari huo ni mifano. Nyaraka za TLS za OpenLDAP zinashughulikia mipangilio ya uaminifu iliyo nyuma.

Hifadhi ipi ya uaminifu inasomwa na mteja wa LDAP?

Maktaba ya mteja ya OpenLDAP husoma usanidi wake wa uaminifu, iwe kutoka faili la mfumo au kutoka mpangilio maalum wa programu-jalizi. Maelekezo ya CA ya VPN yanahusu wenza wa VPN na si ushahidi kwamba maktaba ya LDAP inasoma faili lile lile. Tumia jina la mwenyeji wa saraka ambalo cheti kinashughulikia kweli, pamoja na mnyororo wa mtoaji ambao maktaba inauamini. Katika Active Directory, tumia cheti cha huduma ya saraka kwa matumizi sahihi ya uthibitishaji wa seva badala ya kukisia kutoka jina la kuonyesha.

Kila lengwa la uhamishaji wakati wa kushindwa lazima litimize sera ile ile ya utambulisho. Mazingira ambayo ya msingi yanathibitishwa na ya pili hayathibitishwi ni mabaya zaidi kuliko yasiyokuwa na uhamishaji, kwa sababu njia dhaifu hugunduliwa tu wakati wa kukatika.

Akaunti ya bind inabaki kuwa tatizo tofauti

Kulinda usafirishaji hakupunguzi kile ambacho akaunti ya bind inaweza kufanya. Wigo wa utafutaji wa saraka, idhini ya kikundi na mapendeleo ya akaunti ya huduma ni maamuzi tofauti, na akaunti ya bind pana hubaki pana baada ya TLS kuwezeshwa. Tumia akaunti ya huduma na msingi wa utafutaji nyembamba zaidi unaohitajika na ujumuishaji, na rekodi kituo cha mwisho, hali ya TLS, mmiliki wa uaminifu na mchakato wa uhuishaji pamoja na usanidi wa VPN.

Wakati kutokulingana kwa cheti kunapotokea, tumia cheti au mnyororo sahihi. Kulemaza uthibitishaji hubadilisha kutokulingana kunakoonekana kuwa kusikoonekana na kuacha uhusiano wa pili wa uaminifu bila kujaribiwa.

Miunganisho miwili, wamiliki wawili, tarehe mbili za uhuishaji. Kuziweka tofauti katika nyaraka ndiko kunakofanya kuingia kuwa kwa uaminifu.