NetExtender loggar in men ingen åtkomst: SonicWall lokal + LDAP
NetExtender ansluter men inget svarar: separera SonicWall-autentisering, medlemskap i SSL VPN-tjänsten och VPN-åtkomstbehörigheter för lokala och LDAP-användare.
Inloggningen lyckas, tunneln kommer upp och inget bakom brandväggen svarar. Det mönstret på en SonicWall SSL VPN betyder oftast att kontot har klarat autentiseringen och stannat vid en av två senare behörigheter: tillträde till SSL VPN-tjänsten eller behörighet att nå en resurs. Blandade lokala konton och LDAP-konton gör det värre, eftersom de två lagren når dessa behörigheter via olika vägar. Symtomet är identiskt från klienten, och därför måste lagren medvetet separeras.
Symtomet och de tre behörigheterna bakom
Tre oberoende beslut står mellan ett användarnamn och en nåbar server. Autentiseringsmetoden avgör om uppgifterna accepteras och av vilket lager. Medlemskapet i SSL VPN-tjänsten avgör om den identiteten får använda SSL VPN över huvud taget. VPN-åtkomstlistan avgör vilka privata mål sessionen får nå. Att klara ett säger inget om de två nästa.
En användare som autentiserar sig men inte är i SSL VPN-tjänstens grupp ser en anslutning som upprättas och sedan inte bär något, och brandväggsloggen visar en accepterad inloggning i stället för ett fel. Det är fallet som är värt att känna igen snabbt, eftersom lösningen är ett gruppmedlemskap och inte en återställning av lösenordet.
En användare som släpps in men inte har några resurser ser en session som ansluter och inte dirigerar någonstans användbart. Båda ser ut som en trasig tunnel från supporten, och båda är konfiguration och inte anslutning.
Domänfältet är inte katalogen
NetExtender frågar efter en domän, och det fältet är inte en sökbas för Active Directory. I standarduppställningen måste fältet vara lika med den SSL VPN-användardomän som brandväggen har konfigurerat, och det dokumenterade standardvärdet för det är LocalDomain. Jämförelsen skiljer mellan stora och små bokstäver, så ett värde som skrivits med annan versal misslyckas även när kontot är korrekt.
När autentiseringspartitionering är konfigurerad väljer partitionsnamnen den externa autentiseringskontexten i stället, och det konfigurerade standardvärdet behåller sin egen roll. I båda uppställningarna skickas klientens domänetikett inte vidare till LDAP eller RADIUS som en del av användarnamnet, så den kan inte styra en katalogsökning.
Håll de tre strängarna åtskilda i dina anteckningar: företagets DNS-suffix, LDAP-sökbasen och NetExtender-domänetiketten. De ser lika ut och ingen av dem ersätter en annan. Kopiera operatörens värde för den här installationen och inte ett värde från ett foruminlägg om en annan firmwareversion.
Tillträde och resursåtkomst är separata behörigheter
Lokala konton behöver medlemskap i SSL VPN-tjänstens grupp innan tjänsten accepterar dem. Katalogkonton når samma grupp via det stödda gruppmappningsarbetsflödet, vilket innebär att LDAP-grupprelationen måste konfigureras och sedan verifieras som ett faktiskt medlemskap i stället för att antas från katalogsidan.
Resursåtkomst kommer därefter, under VPN-åtkomst på användaren eller gruppen. Ge de specifika subnäten och tjänsterna som rollen behöver, och stå emot genvägen att ge hela LAN eftersom en applikation krävs. Sessionens rutter, åtkomstreglerna och måltjänstens behörigheter måste alla stämma med den omfattningen.
| 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 |
En rutt på klienten gör ett mål valbart och auktoriserar det inte. Medlemskap i SSL VPN-gruppen gör inte heller kontot till brandväggsadministratör, och det bör inte behandlas som ett allmänt behörighetsgivande.
Två identiteter, fyra kontroller var
Testa med ett lokalt konto och ett katalogkonto, båda snävt auktoriserade och båda dokumenterade som testkonton. För varje, registrera autentiseringskällan som accepterade inloggningen, de effektiva grupperna, den tilldelade resursåtkomsten och en tillåten applikationsåtgärd. Fyra kontroller, två lager och ett skriftligt resultat för varje kombination.
Testa sedan de negativa fallen: en resurs som kontot inte ska nå, och ett konto som ska avvisas direkt. En design som bara bevisar den positiva vägen tenderar att lämna en andra ingång öppen, särskilt när samma korta användarnamn finns i båda lagren. Inaktivera katalogkontot och bekräfta att det lokala inte tyst fortsätter att fungera.
Granska dubblerade namn som en del av utrullningen och inte efter en incident. Samma person i två lager är samtidigt en supportförmån och ett revisionsproblem, och brandväggen autentiserar gärna den du konfigurerade.
Håll återställningsvägen smal
Bevara MFA-policyn för varje kontoklass i stället för att undanta lokala konton från den. Om lokala konton erbjuder en godkänd återställningsväg för ett katalogavbrott, begränsa den vägen till namngivna administratörer och driv den medvetet, eftersom ett lokalt nödkonto för varje anställd är ett andra autentiseringssystem med svagare tillsyn.
Skriv klientdomänen, autentiseringskällan och den effektiva åtkomsten i samma post. Nästa administratör kan då återskapa en fungerande blandad kontodesign i stället för att prova domänsträngar tills en inloggning lyckas.