NetExtender nag-log in pero walang access: SonicWall lokal + LDAP

Nagtagumpay ang pag-log in, bumabangon ang tunnel, at walang sumasagot sa likod ng firewall. Ang pattern na iyon sa isang SonicWall SSL VPN ay karaniwang nangangahulugang nakapasa ang account sa pagpapatotoo at huminto sa isa sa dalawang susunod na pahintulot: pagtanggap sa serbisyong SSL VPN, o pahintulot na maabot ang isang resource. Pinapalala ito ng magkahalong lokal at LDAP na account, dahil iba't ibang landas ang tinatahak ng dalawang imbakan para maabot ang mga pahintulot na iyon. Pareho ang sintomas mula sa client, kaya kailangang sadyang paghiwalayin ang mga layer.

Ang sintomas at ang tatlong pahintulot sa likod nito

Tatlong malayang desisyon ang nasa pagitan ng username at maaabot na server. Ang paraan ng pagpapatotoo ang nagpapasya kung tatanggapin ang kredensyal at ng aling imbakan. Ang pagiging miyembro ng serbisyong SSL VPN ang nagpapasya kung maaaring gumamit ng SSL VPN ang pagkakakilanlang iyon. Ang listahan ng Pag-access ng VPN ang nagpapasya kung aling mga pribadong destinasyon ang maaabot ng sesyon. Ang pagpasa sa isa ay walang sinasabi tungkol sa susunod na dalawa.

Ang user na nagpapatotoo ngunit wala sa grupo ng serbisyong SSL VPN ay nakakakita ng koneksyong nabubuo at pagkatapos ay walang dinadala, at ang log ng firewall ay nagpapakita ng tinanggap na pag-log in sa halip na pagkabigo. Ito ang kaso na sulit agad na makilala, dahil ang solusyon ay pagiging miyembro ng grupo at hindi pag-reset ng password.

Ang user na tinatanggap ngunit walang resource ay nakakakita ng sesyong kumokonekta at hindi nagruruta sa anumang kapaki-pakinabang. Pareho silang mukhang sirang tunnel mula sa help desk, at pareho silang configuration at hindi konektibidad.

Ang kahon ng domain ay hindi ang direktoryo

Humihingi ng domain ang NetExtender, at ang field na iyon ay hindi search base para sa Active Directory. Sa default na kaayusan, kailangang katumbas ng field ang domain ng user ng SSL VPN na na-configure ng firewall, at ang dokumentadong default na halaga para doon ay LocalDomain. Sensitibo sa malaking titik ang paghahambing, kaya ang halagang naipasok nang may ibang malaking titik ay nabibigo kahit tama ang account.

Kapag na-configure ang paghahati ng pagpapatotoo, ang mga pangalan ng partisyon ang pumipili ng panlabas na konteksto ng pagpapatotoo, at pinananatili ng na-configure na default ang sarili nitong papel. Sa alinman sa dalawang kaayusan, ang label ng domain sa panig ng client ay hindi ipinapasa sa LDAP o RADIUS bilang bahagi ng username, kaya hindi ito magagamit upang gabayan ang paghahanap sa direktoryo.

Panatilihing hiwalay ang tatlong string sa iyong mga tala: ang DNS suffix ng kumpanya, ang search base ng LDAP at ang label ng domain ng NetExtender. Magkamukha sila at wala sa kanila ang pumapalit sa isa. Kopyahin ang halaga ng operator para sa installation na ito at hindi ang halaga mula sa post sa forum tungkol sa ibang release ng firmware.

Ang pagtanggap at pag-access sa resource ay magkahiwalay na pahintulot

Kailangan ng mga lokal na account ang pagiging miyembro sa grupo ng serbisyong SSL VPN bago sila tanggapin ng serbisyo. Naabot ng mga account sa direktoryo ang parehong grupo sa pamamagitan ng sinusuportahang workflow ng pagmamapa ng grupo, na nangangahulugang kailangang i-configure ang relasyon ng grupo sa LDAP at pagkatapos i-verify bilang epektibong pagiging miyembro sa halip na ipalagay mula sa panig ng direktoryo.

Kasunod ang pag-access sa resource, sa ilalim ng Pag-access ng VPN sa user o grupo. Ibigay ang partikular na subnet at serbisyo na kailangan ng role, at labanan ang shortcut ng pagbibigay ng buong LAN dahil kailangan ang isang application. Ang mga ruta ng sesyon, ang mga patakaran sa pag-access at ang mga pahintulot ng serbisyong patutunguhan ay dapat lahat naaayon sa saklaw na iyon.

Ang ruta sa client ay nagpapaging-pili ng destinasyon at hindi ito pinapahintulutan. Ang pagiging miyembro sa grupo ng SSL VPN ay hindi rin ginagawang administrator ng firewall ang account, at hindi ito dapat ituring na pangkalahatang pagbibigay ng pribilehiyo.

Dalawang pagkakakilanlan, apat na pagsusuri bawat isa

Subukan gamit ang isang lokal na account at isang account sa direktoryo, parehong makitid ang pahintulot at parehong dokumentado bilang mga test account. Para sa bawat isa, itala ang pinagmulan ng pagpapatotoo na tumanggap ng pag-log in, ang mga epektibong grupo, ang itinalagang pag-access sa resource at isang pinahihintulutang operasyon ng application. Apat na pagsusuri, dalawang imbakan at nakasulat na resulta para sa bawat kombinasyon.

Pagkatapos ay subukan ang mga negatibong kaso: isang resource na hindi dapat maabot ng account, at isang account na dapat tanggihan agad. Ang disenyong nagpapatunay lamang sa positibong landas ay may tendensiyang mag-iwan ng pangalawang pasukan na bukas, lalo na kapag ang parehong maikling username ay umiiral sa parehong imbakan. I-disable ang account sa direktoryo at tiyakin na ang lokal ay hindi tahimik na patuloy na gumagana.

Suriin ang mga doble na pangalan bilang bahagi ng rollout at hindi pagkatapos ng insidente. Ang parehong tao sa dalawang imbakan ay parehong kaginhawahan sa suporta at problema sa audit, at ang firewall ay masayang magpapatotoo sa alinman na na-configure mo.

Panatilihing makitid ang landas ng pagbawi

Panatilihin ang patakaran ng MFA para sa bawat klase ng account sa halip na ilibre ang mga lokal na account mula rito. Kung ang mga lokal na account ay nag-aalok ng inaprubahang landas ng pagbawi para sa pagkaantala ng direktoryo, limitahan ang landas na iyon sa mga pinangalanang administrator at sadyang patakbuhin ito, dahil ang lokal na emergency account para sa bawat empleyado ay pangalawang sistema ng pagpapatotoo na mas mahina ang pangangasiwa.

Isulat ang domain ng client, ang pinagmulan ng pagpapatotoo at ang epektibong pag-access sa parehong record. Ang susunod na administrator ay makakapagparami ng gumaganang disenyo ng magkahalong account sa halip na subukan ang mga string ng domain hanggang magtagumpay ang pag-log in.