NetExtender meld aan maar geen toegang: SonicWall plaaslik + LDAP

Aanmelding slaag, die tonnel kom op, en niks agter die firewall antwoord nie. Daardie patroon op 'n SonicWall SSL VPN beteken gewoonlik dat die rekening verifikasie geslaag het en by een van twee latere toekennings gestop het: toelating tot die SSL VPN-diens, of toestemming om 'n hulpbron te bereik. Gemengde plaaslike en LDAP-rekeninge maak dit erger, want die twee store bereik daardie toekennings op verskillende weë. Die simptoom is identies vanaf die kliënt, daarom moet die lae doelbewus geskei word.

Die simptoom en die drie toekennings daaragter

Drie onafhanklike besluite staan tussen 'n gebruikersnaam en 'n bereikbare bediener. Die verifikasiemetode besluit of die geloofsbriewe aanvaar word en deur watter stoor. Die lidmaatskap van die SSL VPN-diens besluit of daardie identiteit die SSL VPN hoegenaamd mag gebruik. Die VPN-toegangslys besluit watter private bestemmings die sessie mag bereik. Om een te slaag sê niks van die volgende twee nie.

'n Gebruiker wat verifieer maar nie in die SSL VPN-diensgroep is nie, sien 'n verbinding wat opgebou word en dan niks dra nie, en die firewall-log wys 'n aanvaarde aanmelding eerder as 'n fout. Dit is die geval wat 'n mens vinnig moet herken, want die oplossing is 'n groepslidmaatskap en nie 'n wagwoordherstel nie.

'n Gebruiker wat toegelaat word maar geen hulpbronne het nie, sien 'n sessie wat verbind en nêrens nuttig heen roeteer nie. Beide lyk soos 'n stukkende tonnel van die diensbank af, en beide is konfigurasie eerder as verbinding.

Die domeinveld is nie die gids nie

NetExtender vra vir 'n domein, en daardie veld is nie 'n soekbasis vir Active Directory nie. In die verstekreëling moet die veld gelyk wees aan watter SSL VPN-gebruikersdomein die firewall ook al opgestel het, en die gedokumenteerde verstek vir daardie waarde is LocalDomain. Die vergelyking is hooflettergevoelig, so 'n waarde wat met ander hoofletters getik is, misluk selfs wanneer die rekening korrek is.

Met verifikasiepartisies opgestel, kies die partisiename eerder die eksterne verifikasiekonteks, en die opgestelde verstek behou sy eie rol. In enige van die twee reëlings word die kliëntkant se domeinetiket nie as deel van die gebruikersnaam aan LDAP of RADIUS deurgegee nie, so dit kan nie 'n gidsoektog rig nie.

Hou die drie stringe apart in jou notas: die maatskappy se DNS-agtervoegsel, die LDAP-soekbasis en die NetExtender-domeinetiket. Hulle lyk eenders en nie een vervang 'n ander nie. Kopieer die operateur se waarde vir hierdie installasie eerder as 'n waarde uit 'n forumpos oor 'n ander firmware-weergawe.

Toelating en hulpbrontoegang is aparte toekennings

Plaaslike rekeninge het lidmaatskap in die SSL VPN-diensgroep nodig voordat die diens hulle aanvaar. Gidsrekeninge bereik dieselfde groep deur die ondersteunde groepskarteringswerkvloei, wat beteken die LDAP-groepverhouding moet opgestel word en dan as 'n effektiewe lidmaatskap geverifieer word eerder as van die gidskant af aanvaar word.

Hulpbrontoegang kom volgende, onder VPN-toegang op die gebruiker of die groep. Ken die spesifieke subnette en dienste toe wat die rol nodig het, en weerstaan die kortpad om die hele LAN toe te ken omdat een toepassing vereis word. Die sessie se roetes, die toegangsreëls en die bestemmingsdiens se toestemmings moet almal met daardie omvang ooreenstem.

'n Roete op die kliënt maak 'n bestemming kiesbaar en magtig dit nie. Lidmaatskap in die SSL VPN-groep maak die rekening ook nie 'n firewall-administrateur nie, en dit moet nie as 'n algemene voorregtoekenning behandel word nie.

Twee identiteite, vier kontroles elk

Toets met een plaaslike rekening en een gidsrekening, albei nou toegestaan en albei as toetsrekeninge gedokumenteer. Teken vir elkeen die verifikasiiebron aan wat die aanmelding aanvaar het, die effektiewe groepe, die toegewysde hulpbrontoegang en een toegelate toepassingsbewerking. Vier kontroles, twee store, en 'n geskrewe resultaat vir elke kombinasie.

Toets dan die negatiewe gevalle: 'n hulpbron wat die rekening nie behoort te bereik nie, en 'n rekening wat heeltemal verwerp behoort te word. 'n Ontwerp wat net die positiewe pad bewys, laat gewoonlik 'n tweede ingang oop, veral wanneer dieselfde kort gebruikersnaam in albei store bestaan. Deaktiveer die gidsrekening en bevestig dat die plaaslike een nie stilweg aanhou werk nie.

Hersien duplikaatname as deel van die uitrol eerder as ná 'n voorval. Dieselfde persoon in twee store is terselfdertyd 'n diensbankgerief en 'n ouditprobleem, en die firewall sal gewillig die een verifieer wat jy opgestel het.

Hou die herstelpad smal

Behou die MFA-beleid vir elke rekeningklas in plaas daarvan om plaaslike rekeninge daarvan vry te stel. As plaaslike rekeninge 'n goedgekeurde herstelpad vir 'n gidsonderbreking bied, beperk daardie pad tot genoemde administrateurs en bedryf dit doelbewus, want 'n plaaslike noodrekening vir elke werknemer is 'n tweede verifikasiestelsel met swakker toesig.

Skryf die kliëntdomein, die verifikasiiebron en die effektiewe toegang in dieselfde rekord. Die volgende administrateur kan dan 'n werkende gemengde rekeningontwerp herproduseer in plaas daarvan om deur domeinstringe te sirkel totdat 'n aanmelding slaag.