NetExtender ensalutas sed sen aliro: SonicWall loka + LDAP

Ensaluto sukcesas, la tunelo leviĝas, kaj nenio malantaŭ la fajroŝirmilo respondas. Tiu ŝablono sur SonicWall SSL VPN kutime signifas, ke la konto trapasis aŭtentikigon kaj haltis ĉe unu el du postaj permesoj: akcepto en la SSL VPN-servon, aŭ permeso atingi rimedon. Miksitaj lokaj kaj LDAP-kontoj plimalbonigas tion, ĉar la du konservejoj atingas tiujn permesojn per malsamaj vojoj. La simptomo estas identa ĉe la kliento, kaj tial la tavoloj devas esti intence apartigitaj.

La simptomo kaj la tri permesoj malantaŭ ĝi

Tri sendependaj decidoj staras inter uzantnomo kaj atingebla servilo. La aŭtentikiga metodo decidas, ĉu la akreditaĵo estas akceptata kaj de kiu konservejo. La membreco en la SSL VPN-servo decidas, ĉu tiu identeco rajtas uzi la SSL VPN entute. La VPN-alirolisto decidas, kiujn privatajn celojn la seanco rajtas atingi. Trapasi unu diras nenion pri la sekvaj du.

Uzanto, kiu aŭtentikiĝas sed ne estas en la servo-grupo de SSL VPN, vidas konekton, kiu establiĝas kaj poste portas nenion, kaj la fajroŝirmila protokolo montras akceptitan ensaluton anstataŭ fiaskon. Tiu estas la kazo inda rekoni rapide, ĉar la solvo estas grupa membreco, ne pasvorta restarigo.

Uzanto, kiu estas akceptita sed havas neniujn rimedojn, vidas seancon, kiu konektiĝas kaj enkursigas nenie utile. Ambaŭ aspektas kiel difektita tunelo el la helpdesko, kaj ambaŭ estas agordo, ne konekteco.

La domajna kampo ne estas la dosierujo

NetExtender demandas domajnon, kaj tiu kampo ne estas serĉbazo por Active Directory. En la defaŭlta aranĝo la kampo devas egali la SSL VPN-uzantdomajnon, kiun la fajroŝirmilo agordis, kaj la dokumentita defaŭlto por tiu valoro estas LocalDomain. La komparo distingas inter uskleco, do valoro tajpita kun alia uskleco fiaskas eĉ kiam la konto estas ĝusta.

Kiam aŭtentikiga subdivido estas agordita, la subdividaj nomoj elektas la eksteran aŭtentikigan kuntekston anstataŭe, kaj la agordita defaŭlto konservas sian propran rolon. En ambaŭ aranĝoj la klienta domajna etikedo ne estas plusendata al LDAP aŭ RADIUS kiel parto de la uzantnomo, do ĝi ne povas gvidi dosierujan serĉon.

Tenu la tri ĉenojn aparte en viaj notoj: la kompania DNS-sufikso, la LDAP-serĉbazo kaj la NetExtender-domajna etikedo. Ili aspektas similaj kaj neniu anstataŭas alian. Kopiu la valoron de la funkciigisto por ĉi tiu instalaĵo anstataŭ valoron el forumafiŝo pri alia firmvara eldono.

Akcepto kaj rimedaliro estas apartaj permesoj

Lokaj kontoj bezonas membrecon en la servo-grupo de SSL VPN antaŭ ol la servo akceptos ilin. Dosierujaj kontoj atingas la saman grupon per la subtenata grup-mapa laborfluo, kio signifas, ke la LDAP-grupa rilato devas esti agordita kaj poste kontrolita kiel efika membreco anstataŭ supozita de la dosieruja flanko.

Rimedaliro venas poste, sub VPN-aliro ĉe la uzanto aŭ la grupo. Donu la koncernajn subretojn kaj servojn, kiujn la rolo bezonas, kaj rezistu la mallongigon doni la tutan LAN-on ĉar unu aplikaĵo estas bezonata. La itineroj de la seanco, la aliroloj kaj la permesoj de la cela servo ĉiuj devas kongrui kun tiu amplekso.

Itinero ĉe la kliento igas celon elektebla kaj ne rajtigas ĝin. Membreco en la SSL VPN-grupo ankaŭ ne igas la konton fajroŝirmila administranto, kaj ĝi ne devus esti traktata kiel ĝenerala privilegia dono.

Du identecoj, kvar kontroloj ĉiu

Testu per unu loka konto kaj unu dosieruja konto, ambaŭ mallarĝe rajtigitaj kaj ambaŭ dokumentitaj kiel testkontoj. Por ĉiu registru la aŭtentikigan fonton, kiu akceptis la ensaluton, la efikajn grupojn, la asignitan rimedaliron kaj unu permesitan aplikaĵan operacion. Kvar kontroloj, du konservejoj kaj skribita rezulto por ĉiu kombinaĵo.

Poste testu la negativajn kazojn: rimedon, kiun la konto ne devus atingi, kaj konton, kiu devus esti tuj rifuzita. Dezajno, kiu pruvas nur la pozitivan vojon, emas lasi duan enirejon malfermita, precipe kiam la sama mallonga uzantnomo ekzistas en ambaŭ konservejoj. Malŝaltu la dosierujan konton kaj konfirmu, ke la loka ne silente daŭre funkcias.

Reviziu duoblajn nomojn kiel parton de la lanĉo anstataŭ post okazaĵo. La sama persono en du konservejoj samtempe estas subtena oportuneco kaj revizia problemo, kaj la fajroŝirmilo volonte aŭtentikigos tiun, kiun vi agordis.

Tenu la reakiran vojon mallarĝa

Konservu la MFA-politikon por ĉiu kontoklaso anstataŭ liberigi lokajn kontojn de ĝi. Se lokaj kontoj provizas aprobitan reakiradon por dosieruja paneo, limigu tiun vojon al nomitaj administrantoj kaj funkciigu ĝin intence, ĉar loka kriza konto por ĉiu dungito estas dua aŭtentikiga sistemo kun pli malforta superrigardo.

Skribu la klientan domajnon, la aŭtentikigan fonton kaj la efikan aliron en la saman rikordon. La sekva administranto povas tiam reprodukti funkciantan miksitan kontodezajnon anstataŭ ciklumi tra domajnaj ĉenoj ĝis ensaluto sukcesas.