NetExtender meldt oan, mar gjin tagong: SonicWall lokaal + LDAP
NetExtender ferbynt, mar nimmen antwurdet: skied SonicWall-autentikaasje, lidmaatskip fan de SSL VPN-tsjinst en VPN-tagongsrjochten foar lokale en LDAP-brûkers.
Oanmelde slagget, de tunnel komt op, en neat efter de firewall antwurdet. Dat patroan op in SonicWall SSL VPN betsjut meastal dat it akkount de autentikaasje trochstien hat en by ien fan twa lettere rjochten stoppe is: talitting ta de SSL VPN-tsjinst, of tastimming om in boarne te berikken. Mingde lokale en LDAP-akkounts meitsje it slimmer, omdat de twa opslachplakken dy rjochten fia ferskate paden berikke. It symptoom is itselde fan de klant ôf, en dêrom moatte de lagen bewust skieden wurde.
It symptoom en de trije rjochten dêrefter
Trije ûnôfhinklike besluten steane tusken in brûkersnamme en in berikbere tsjinner. De autentikaasjemetoade beslút oft de oanmeldgegevens akseptearre wurde en troch hokker opslachplak. It lidmaatskip fan de SSL VPN-tsjinst beslút oft dy identiteit de SSL VPN hielendal brûke mei. De VPN-tagongslist beslút hokker partikuliere bestimmings de sesje berikke mei. Ien trochstien seit neat oer de folgjende twa.
In brûker dy't autentisearret mar net yn 'e SSL VPN-tsjinstgroep sit, sjocht in ferbining dy't oprjochte wurdt en dan neat draacht, en it firewall-logboek toant in akseptearre oanmelding ynstee fan in mislearring. Dat is it gefal dat de muoite wurdich is om fluch te werkenne, want de oplossing is in groepslidmaatskip en net in wachtwurdreset.
In brûker dy't talitten is mar gjin boarnen hat, sjocht in sesje dy't ferbynt en nearne nuttich hinne rûtelet. Beide lykje fan de helpdesk ôf op in stikken tunnel, en beide binne konfiguraasje en net ferbining.
It domeinfjild is net it adresboek
NetExtender freget om in domein, en dat fjild is gjin sykbasis foar Active Directory. Yn 'e standertopstelling moat it fjild gelyk wêze oan it SSL VPN-brûkersdomein dat de firewall konfigurearre hat, en de dokumintearre standertwearde dêrfoar is LocalDomain. De ferliking is haadlettergefoelich, dus in wearde ynfierd mei in oare haadletterstiksel mislearret sels as it akkount korrekt is.
As autentikaasjepartisjonearring konfigurearre is, kieze de partisjenammen ynstee de eksterne autentikaasjekontekst, en de konfigurearre standert behâldt syn eigen rol. Yn beide opstellings wurdt it domeinlabel fan de kliïntside net as part fan de brûkersnamme nei LDAP of RADIUS trochjûn, dus it kin gjin adresboksyking stjoere.
Hâld de trije strings apart yn jo notysjes: it DNS-suffiks fan it bedriuw, de LDAP-sykbasis en it NetExtender-domeinlabel. Se lykje opinoar en gjinien ferfangt in oare. Kopiearje de wearde fan de operator foar dizze ynstallaasje ynstee fan in wearde út in forumberjocht oer in oare firmwareferzje.
Talitting en boarnetagong binne aparte rjochten
Lokale akkounts hawwe lidmaatskip fan de SSL VPN-tsjinstgroep nedich foardat de tsjinst se akseptearret. Adresboekakkounts berikke deselde groep fia de stipe groepsmapping-wurkstream, wat betsjut dat de LDAP-groepsrelaasje konfigurearre wurde moat en dêrnei as effektyf lidmaatskip ferifiearre wurde moat ynstee fan fan de adresboekkant ôf oannommen te wurden.
Boarnetagong komt dêrnei, ûnder VPN-tagong op de brûker of de groep. Jou de spesifike subnetten en tsjinsten dy't de rol nedich hat, en wjerstean de koarte wei om it hiele LAN te jaan omdat ien tapassing nedich is. De rûtes fan de sesje, de tagongsregels en de rjochten fan de bestimmingstsjinst moatte allegear mei dy omfang oerienkomme.
| 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 |
In rûte op de klant makket in bestimming selektearber en autorisearret dy net. Lidmaatskip fan de SSL VPN-groep makket it akkount ek gjin firewall-administrator, en it moat net as in algemiene privilezjeferliening behannele wurde.
Twa identiteiten, fjouwer kontrôles elk
Test mei ien lokaal akkount en ien adresboekakkount, beide nau autorisearre en beide as testakkounts dokumintearre. Registrearje foar elk de autentikaasjeboarne dy't de oanmelding akseptearre, de effektive groepen, de tawiisde boarnetagong en ien tastiene tapassingsoperaasje. Fjouwer kontrôles, twa opslachplakken en in skreaun resultaat foar elke kombinaasje.
Test dêrnei de negative gefallen: in boarne dy't it akkount net berikke moat, en in akkount dat daliks wegere wurde moat. In ûntwerp dat allinnich it positive paad bewissiget, lit gauris in twadde yngong iepen, benammen as deselde koarte brûkersnamme yn beide opslachplakken bestiet. Deaktivearje it adresboekakkount en befêstigje dat it lokale net stil trochwurket.
Besjoch dûbele nammen as part fan de útrôl ynstee fan nei in ynsidint. Deselde persoan yn twa opslachplakken is tagelyk in helpdesk-gemak en in audytprobleem, en de firewall sil de iene dy't jo konfigurearre hawwe ree autentisearje.
Hâld it herstelpaad smel
Behâld it MFA-belied foar elke akkountklasse ynstee fan lokale akkounts dêrfan út te sluten. As lokale akkounts in goedkard herstelpaad foar in adresboekútfal biede, behein dat paad dan ta neamde administraterers en betsjinje it bewust, want in lokaal needakkount foar elke meiwurker is in twadde autentikaasjesysteem mei swakker tafersjoch.
Skriuw it klantdomein, de autentikaasjeboarne en de effektive tagong yn itselde record. De folgjende administrater kin dan in wurkjend mingd akkountûntwerp reprodusearje ynstee fan domeinstrings te sykjen oant in oanmelding slagget.