NetExtender loggar inn, men ingen tilgang: SonicWall lokal + LDAP
NetExtender koplar til, men ingenting svarar: skil SonicWall-autentisering, medlemskap i SSL VPN-tenesta og VPN-tilgangsløyve for lokale og LDAP-brukarar.
Innlogginga går gjennom, tunnelen kjem opp, og ingenting bak brannmuren svarar. Det mønsteret på ein SonicWall SSL VPN tyder vanlegvis at kontoen har passert autentiseringa og stoppa ved eitt av to seinare løyve: opptak i SSL VPN-tenesta, eller løyve til å nå ein ressurs. Blanda lokale kontoar og LDAP-kontoar gjer det verre, fordi dei to lagera når desse løyva langs ulike vegar. Symptomet er identisk frå klienten, og difor må laga med vilje skiljast.
Symptomet og dei tre løyva bak det
Tre uavhengige avgjerder står mellom eit brukarnamn og ein tilgjengeleg tenar. Autentiseringsmetoden avgjer om innloggingsdataa blir godtekne og av kva lager. Medlemskapen i SSL VPN-tenesta avgjer om den identiteten i det heile får bruke SSL VPN. VPN-tilgangslista avgjer kva private mål økta får nå. Å klare eitt seier ingenting om dei to neste.
Ein brukar som autentiserer seg, men ikkje er i gruppa til SSL VPN-tenesta, ser ei tilkopling som blir oppretta og deretter ikkje fraktar noko, og brannmurloggen viser ei godteken innlogging i staden for ein feil. Det er tilfellet det er verdt å kjenne att raskt, fordi løysinga er eit gruppemedlemskap og ikkje ein passordreset.
Ein brukar som blir sleppt inn, men ikkje har ressursar, ser ei økt som koplar til og ikkje rutar nokon stad nyttig. Begge ser ut som ein øydelagd tunnel frå brukarstøtta, og begge er konfigurasjon og ikkje tilkopling.
Domenefeltet er ikkje katalogen
NetExtender spør etter eit domene, og det feltet er ikkje ein søkjebase for Active Directory. I standardoppsettet må feltet vere likt det SSL VPN-brukardomenet som brannmuren har sett opp, og den dokumenterte standardverdien for det er LocalDomain. Samanlikninga skil mellom store og små bokstavar, så ein verdi skriven med annan bokstavstorleik feilar sjølv når kontoen er rett.
Når autentiseringspartisjonering er sett opp, vel partisjonsnamna den eksterne autentiseringskonteksten i staden, og den sette standarden held på si eiga rolle. I begge oppsetta blir domenemerket på klientsida ikkje sendt vidare til LDAP eller RADIUS som del av brukarnamnet, så det kan ikkje styre eit katalogsøk.
Hald dei tre strengane frå kvarandre i notata dine: DNS-suffikset til verksemda, LDAP-søkjebasen og NetExtender-domenemerket. Dei ser like ut, og ingen av dei erstattar ein annan. Kopier verdien til operatøren for denne installasjonen og ikkje ein verdi frå eit foruminnlegg om ein annan fastvareversjon.
Opptak og ressurstilgang er separate løyve
Lokale kontoar treng medlemskap i gruppa til SSL VPN-tenesta før tenesta godtek dei. Katalogkontoar når same gruppa gjennom den støtta gruppekartleggingsflyten, noko som tyder at LDAP-grupperelasjonen må setjast opp og deretter stadfestast som eit verkeleg medlemskap i staden for å bli antatt frå katalogsida.
Ressurstilgang kjem etterpå, under VPN-tilgang på brukaren eller gruppa. Gi dei spesifikke subneta og tenestene som rolla treng, og stå imot snarvegen med å gi heile LAN-et fordi ein applikasjon er nødvendig. Rutene i økta, tilgangsreglane og løyva til måltenesta må alle stemme med dette omfanget.
| 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 |
Ei rute på klienten gjer eit mål valbart og autoriserer det ikkje. Medlemskap i SSL VPN-gruppa gjer heller ikkje kontoen til brannmuradministrator, og det bør ikkje handsamast som ei generell privilegiegiving.
To identitetar, fire kontrollar kvar
Test med ein lokal konto og ein katalogkonto, begge trongt autoriserte og begge dokumenterte som testkontoar. Registrer for kvar kjelda til autentiseringa som godtok innlogginga, dei effektive gruppene, den tildelte ressurstilgangen og éin tillaten applikasjonsoperasjon. Fire kontrollar, to lager og eit skriftleg resultat for kvar kombinasjon.
Test deretter dei negative tilfella: ein ressurs som kontoen ikkje skal nå, og ein konto som skal avvisast med ein gong. Eit design som berre provar den positive vegen, let ofte ein andre inngang stå open, særleg når det same korte brukarnamnet finst i begge lager. Slå av katalogkontoen og stadfest at den lokale ikkje stille held fram med å verke.
Gå gjennom dupliserte namn som del av utrullinga og ikkje etter ein hending. Same person i to lager er samtidig ei brukarstøttelenpe og eit revisjonsproblem, og brannmuren autentiserer gjerne den du sette opp.
Hald attopprettingsvegen trong
Hald på MFA-policyen for kvar kontoklasse i staden for å frita lokale kontoar frå han. Viss lokale kontoar gir ein godkjend attopprettingsveg for eit katalogutfall, avgrens den vegen til namngitte administratorar og driv han med vilje, fordi ein lokal naudkonto for kvar tilsett er eit andre autentiseringssystem med svakare tilsyn.
Skriv klientdomenet, autentiseringskjelda og den effektive tilgangen i same posten. Den neste administratoren kan då attskape eit fungerande blanda kontodesign i staden for å prøve domenestrengar til ei innlogging går gjennom.