NetExtender hyn, por pa akses: SonicWall lokal + LDAP
NetExtender lidhet, por asgjë nuk përgjigjet: ndani vërtetimin e SonicWall, anëtarësimin në shërbimin SSL VPN dhe lejet e aksesit VPN për përdoruesit lokalë dhe LDAP.
Hyrja kryhet me sukses, tuneli ngrihet dhe asgjë pas firewall-it nuk përgjigjet. Ky model në një SonicWall SSL VPN zakonisht do të thotë se llogaria ka kaluar vërtetimin dhe është ndalur në një nga dy lejet e mëvonshme: pranimi në shërbimin SSL VPN ose leja për të arritur një burim. Llogaritë lokale dhe LDAP të përziera e përkeqësojnë situatën, sepse dy ruajtëset i arrijnë këto leje në rrugë të ndryshme. Simptoma është identike nga ana e klientit, prandaj shtresat duhet të ndahen qëllimisht.
Simptoma dhe tre lejet prapa saj
Tre vendime të pavarura qëndrojnë midis një emri përdoruesi dhe një serveri të arritshëm. Metoda e vërtetimit vendos nëse kredencialet pranohen dhe nga cila ruajtëse. Anëtarësimi në shërbimin SSL VPN vendos nëse ajo identitet mund të përdorë fare SSL VPN. Lista e aksesit VPN vendos cilat destinacione private sesioni mund të arrijë. Kalimi i njërës nuk thotë asgjë për dy të tjerat.
Një përdorues që vërtetohet, por nuk është në grupin e shërbimit SSL VPN, sheh një lidhje që krijohet dhe më pas nuk transporton asgjë, dhe regjistri i firewall-it tregon një hyrje të pranuar në vend të një dështimi. Ky është rasti që ia vlen të njihet shpejt, sepse zgjidhja është anëtarësim në grup dhe jo rivendosje e fjalëkalimit.
Një përdorues që pranohet, por nuk ka burime, sheh një sesion që lidhet dhe nuk rrugëton askund të dobishëm. Të dyja duken si tunel i prishur nga ndihma, dhe të dyja janë konfigurim dhe jo lidhshmëri.
Fusha e domenit nuk është drejtoria
NetExtender kërkon një domen, dhe ajo fushë nuk është bazë kërkimi për Active Directory. Në rregullimin standard fusha duhet të jetë e barabartë me domenin e përdoruesit SSL VPN që ka konfiguruar firewall-i, dhe vlera standarde e dokumentuar është LocalDomain. Krahasimi dallon shkronjat e mëdha nga të voglat, kështu që një vlerë e shtypur me shkronja të tjera dështon edhe kur llogaria është e saktë.
Kur është konfiguruar ndarja e vërtetimit, emrat e ndarjeve zgjedhin kontekstin e vërtetimit të jashtëm, dhe vlera standarde e konfiguruar mban rolin e vet. Në të dyja rregullimet, etiketa e domenit në anën e klientit nuk përcillet te LDAP ose RADIUS si pjesë e emrit të përdoruesit, prandaj nuk mund të drejtojë një kërkim në drejtori.
Mbajini tre vargjet të ndara në shënimet tuaja: prapashtesa DNS e kompanisë, baza e kërkimit LDAP dhe etiketa e domenit NetExtender. Duken të ngjashme dhe asnjëra nuk zëvendëson tjetrën. Kopjoni vlerën e operatorit për këtë instalim dhe jo një vlerë nga një postim forumi për një version tjetër firmueri.
Pranimi dhe aksesi në burime janë leje të ndara
Llogaritë lokale kanë nevojë për anëtarësim në grupin e shërbimit SSL VPN përpara se shërbimi t'i pranojë. Llogaritë e drejtorisë arrijnë të njëjtin grup përmes rrjedhës së punës së hartëzimit të grupeve që mbështetet, që do të thotë se marrëdhënia e grupit LDAP duhet konfiguruar dhe më pas verifikuar si anëtarësim efektiv në vend që të supozohet nga ana e drejtorisë.
Aksesi në burime vjen më pas, nën Aksesin VPN te përdoruesi ose grupi. Jepni nënrrjetet dhe shërbimet konkrete që kërkon roli, dhe rezistoni shkurtores së dhënies së të gjithë LAN-it sepse kërkohet një aplikacion. Rrugët e sesionit, rregullat e aksesit dhe lejet e shërbimit të destinacionit duhet të gjitha të përputhen me këtë shtrirje.
| Layer | What it decides | Where it is set |
|---|---|---|
| Authentication | Whether the credential is accepted, and by which store | Authentication method and directory configuration |
| Admission | Whether the identity may use the SSL VPN | SSL VPN service group membership |
| Resource | Which destinations the session may reach | VPN Access on the user or group |
Një rrugë në klient e bën një destinacion të zgjedhshëm dhe nuk e autorizon. Anëtarësimi në grupin SSL VPN as nuk e bën llogarinë administrator firewall-i, dhe nuk duhet trajtuar si dhënie e përgjithshme privilegjesh.
Dy identitete, katër kontrolle secili
Testoni me një llogari lokale dhe një llogari drejtorie, të dyja të autorizuara ngushtë dhe të dyja të dokumentuara si llogari testimi. Për secilën, regjistroni burimin e vërtetimit që pranoi hyrjen, grupet efektive, aksesin në burime të caktuar dhe një veprim aplikacioni të lejuar. Katër kontrolle, dy ruajtëse dhe një rezultat i shkruar për çdo kombinim.
Më pas testoni rastet negative: një burim që llogaria nuk duhet të arrijë dhe një llogari që duhet refuzuar menjëherë. Një dizajn që provon vetëm rrugën pozitive ka tendencë të lërë një hyrje të dytë të hapur, veçanërisht kur i njëjti emër i shkurtër përdoruesi ekziston në të dyja ruajtëset. Çaktivizoni llogarinë e drejtorisë dhe konfirmoni që ajo lokale nuk vazhdon të punojë në heshtje.
Rishikoni emrat e dyfishtë si pjesë e vendosjes dhe jo pas një incidenti. I njëjti person në dy ruajtëse është njëkohësisht lehtësi për mbështetjen dhe problem auditimi, dhe firewall-i do të vërtetojë me kënaqësi atë që keni konfiguruar.
Mbajeni rrugën e rikuperimit të ngushtë
Ruani politikën MFA për çdo klasë llogarie në vend që të përjashtoni llogaritë lokale prej saj. Nëse llogaritë lokale ofrojnë një rrugë rikuperimi të miratuar për një ndërprerje të drejtorisë, kufizoni atë rrugë te administratorë të emërtuar dhe operojeni me qëllim, sepse një llogari emergjente lokale për çdo punonjës është një sistem i dytë vërtetimi me mbikëqyrje më të dobët.
Shkruani domenin e klientit, burimin e vërtetimit dhe aksesin efektiv në të njëjtin rekord. Administratori tjetër mund të riprodhojë më pas një dizajn funksional llogarish të përziera në vend që të provojë vargje domenesh derisa një hyrje të ketë sukses.