NetExtender logger ind, men ingen adgang: SonicWall lokal + LDAP

Login lykkes, tunnelen kommer op, og intet bag firewallen svarer. Det mønster på en SonicWall SSL VPN betyder normalt, at kontoen har bestået godkendelsen og er stoppet ved en af to senere tilladelser: adgang til SSL VPN-tjenesten eller tilladelse til at nå en ressource. Blandede lokale konti og LDAP-konti gør det værre, fordi de to lagre når disse tilladelser ad forskellige veje. Symptomet er identisk fra klienten, og derfor skal lagene bevidst adskilles.

Symptomet og de tre tilladelser bag det

Tre uafhængige beslutninger står mellem et brugernavn og en tilgængelig server. Godkendelsesmetoden afgør, om legitimationsoplysningerne accepteres, og af hvilket lager. Medlemskabet af SSL VPN-tjenesten afgør, om den identitet overhovedet må bruge SSL VPN. VPN-adgangslisten afgør, hvilke private destinationer sessionen må nå. At bestå én siger intet om de næste to.

En bruger, der godkendes, men ikke er i SSL VPN-tjenestens gruppe, ser en forbindelse, der etableres og derefter ikke bærer noget, og firewall-loggen viser et accepteret login i stedet for en fejl. Det er tilfældet, der er værd at genkende hurtigt, fordi løsningen er et gruppemedlemskab og ikke en nulstilling af adgangskoden.

En bruger, der lukkes ind, men ikke har ressourcer, ser en session, der forbinder og ikke router nogen steder hen, hvor det er nyttigt. Begge ser ud som en brudt tunnel fra helpdesken, og begge er konfiguration og ikke forbindelse.

Domænefeltet er ikke kataloget

NetExtender spørger efter et domæne, og det felt er ikke en søgebase for Active Directory. I standardopsætningen skal feltet svare til det SSL VPN-brugerdomæne, som firewallen har konfigureret, og den dokumenterede standardværdi for det er LocalDomain. Sammenligningen skelner mellem store og små bogstaver, så en værdi skrevet med en anden bogstavstørrelse fejler, selv når kontoen er korrekt.

Når godkendelsesopdeling er konfigureret, vælger partitionsnavnene i stedet den eksterne godkendelseskontekst, og den konfigurerede standard bevarer sin egen rolle. I begge opsætninger videresendes klientens domænelabel ikke til LDAP eller RADIUS som en del af brugernavnet, så den kan ikke bruges til at styre en katalogsøgning.

Hold de tre strenge adskilt i dine noter: virksomhedens DNS-suffiks, LDAP-søgebase og NetExtender-domænelabel. De ligner hinanden, og ingen af dem erstatter en anden. Kopier operatørens værdi for denne installation i stedet for en værdi fra et forumindlæg om en anden firmwareversion.

Adgang og ressourceadgang er separate tilladelser

Lokale konti har brug for medlemskab af SSL VPN-tjenestens gruppe, før tjenesten accepterer dem. Katalogkonti når samme gruppe via den understøttede gruppetilknytningsproces, hvilket betyder, at LDAP-grupperelationen skal konfigureres og derefter verificeres som et effektivt medlemskab i stedet for at antages fra katalogsiden.

Ressourceadgang kommer derefter, under VPN-adgang på brugeren eller gruppen. Tildel de specifikke undernet og tjenester, som rollen har brug for, og modstå genvejen med at give hele LAN'et, fordi én applikation er nødvendig. Sessionens ruter, adgangsreglerne og destinationsserviceens tilladelser skal alle stemme overens med dette omfang.

En rute på klienten gør en destination valgbar og autoriserer den ikke. Medlemskab af SSL VPN-gruppen gør heller ikke kontoen til firewall-administrator, og det bør ikke behandles som en generel privilegietildeling.

To identiteter, fire kontroller hver

Test med én lokal konto og én katalogkonto, begge snævert autoriserede og begge dokumenterede som testkonti. Registrer for hver den godkendelseskilde, der accepterede login, de effektive grupper, den tildelte ressourceadgang og én tilladt applikationshandling. Fire kontroller, to lagre og et skriftligt resultat for hver kombination.

Test derefter de negative tilfælde: en ressource, som kontoen ikke bør nå, og en konto, der bør afvises helt. Et design, der kun beviser den positive vej, har tendens til at efterlade en anden indgang åben, især når det samme korte brugernavn findes i begge lagre. Deaktiver katalogkontoen, og bekræft at den lokale ikke stille fortsætter med at virke.

Gennemgå dublerede navne som en del af udrulningen i stedet for efter en hændelse. Den samme person i to lagre er samtidig en supportfordel og et revisionsproblem, og firewallen godkender villigt den, du konfigurerede.

Hold gendannelsesvejen smal

Bevar MFA-politikken for hver kontoklasse i stedet for at undtage lokale konti fra den. Hvis lokale konti giver en godkendt gendannelsesvej ved et katalogudfald, skal du begrænse den vej til navngivne administratorer og betjene den bevidst, fordi en lokal nødkonto til hver medarbejder er et andet godkendelsessystem med svagere tilsyn.

Skriv klientdomænet, godkendelseskilden og den effektive adgang i samme post. Den næste administrator kan derefter genskabe et fungerende blandet kontodesign i stedet for at cykle gennem domænestrenge, indtil et login lykkes.