NetExtender logt in maar geen toegang: SonicWall lokaal + LDAP

De aanmelding lukt, de tunnel komt op en niets achter de firewall antwoordt. Dat patroon op een SonicWall SSL VPN betekent meestal dat het account de authenticatie heeft doorstaan en is gestopt bij een van twee latere toekenningen: toelating tot de SSL VPN-service of toestemming om een resource te bereiken. Gemengde lokale en LDAP-accounts maken het erger, omdat de twee opslagplaatsen die toekenningen via verschillende paden bereiken. Het symptoom is identiek vanaf de client, en daarom moeten de lagen bewust worden gescheiden.

Het symptoom en de drie toekenningen erachter

Drie onafhankelijke beslissingen staan tussen een gebruikersnaam en een bereikbare server. De authenticatiemethode bepaalt of de inloggegevens worden geaccepteerd en door welke opslagplaats. Het lidmaatschap van de SSL VPN-service bepaalt of die identiteit de SSL VPN helemaal mag gebruiken. De VPN-toegangslijst bepaalt welke privébestemmingen de sessie mag bereiken. Eén halen zegt niets over de volgende twee.

Een gebruiker die authenticeert maar niet in de groep van de SSL VPN-service zit, ziet een verbinding die tot stand komt en vervolgens niets vervoert, en het firewall-logboek toont een geaccepteerde aanmelding in plaats van een fout. Dat is het geval dat je snel wilt herkennen, want de oplossing is een groepslidmaatschap en geen wachtwoordreset.

Een gebruiker die wordt toegelaten maar geen resources heeft, ziet een sessie die verbindt en nergens nuttigs routeert. Beide lijken vanuit de helpdesk op een kapotte tunnel, en beide zijn configuratie en geen connectiviteit.

Het domeinveld is niet de directory

NetExtender vraagt om een domein, en dat veld is geen zoekbasis voor Active Directory. In de standaardopstelling moet het veld gelijk zijn aan het SSL VPN-gebruikersdomein dat de firewall heeft geconfigureerd, en de gedocumenteerde standaardwaarde daarvoor is LocalDomain. De vergelijking is hoofdlettergevoelig, dus een waarde met een andere schrijfwijze van hoofdletters mislukt zelfs als het account correct is.

Als authenticatiepartitionering is geconfigureerd, kiezen de partitienamen de externe authenticatiecontext, en de geconfigureerde standaard behoudt zijn eigen rol. In beide opstellingen wordt het domeinlabel aan de clientzijde niet als deel van de gebruikersnaam naar LDAP of RADIUS doorgegeven, dus het kan geen directoryzoekopdracht sturen.

Houd de drie strings gescheiden in je notities: het DNS-suffix van het bedrijf, de LDAP-zoekbasis en het NetExtender-domeinlabel. Ze lijken op elkaar en geen ervan vervangt een ander. Kopieer de waarde van de beheerder voor deze installatie en niet een waarde uit een forumbericht over een andere firmwareversie.

Toelating en resourcetoegang zijn aparte toekenningen

Lokale accounts hebben lidmaatschap van de groep van de SSL VPN-service nodig voordat de service ze accepteert. Directory-accounts bereiken dezelfde groep via de ondersteunde groepstoewijzingsworkflow, wat betekent dat de LDAP-groepsrelatie moet worden geconfigureerd en daarna geverifieerd als effectief lidmaatschap in plaats van aangenomen vanaf de directorykant.

Resourcetoegang komt daarna, onder VPN-toegang op de gebruiker of de groep. Verleen de specifieke subnetten en services die de rol nodig heeft, en weersta de snelkoppeling om het hele LAN te verlenen omdat één applicatie nodig is. De routes van de sessie, de toegangsregels en de machtigingen van de doelservice moeten allemaal met dat bereik overeenkomen.

Een route op de client maakt een bestemming selecteerbaar en autoriseert die niet. Lidmaatschap van de SSL VPN-groep maakt het account ook geen firewallbeheerder, en het moet niet als een algemene privilegeschenking worden behandeld.

Twee identiteiten, elk vier controles

Test met één lokaal account en één directoryaccount, beide nauw geautoriseerd en beide gedocumenteerd als testaccounts. Noteer voor elk de authenticatiebron die de aanmelding accepteerde, de effectieve groepen, de toegewezen resourcetoegang en één toegestane applicatiebewerking. Vier controles, twee opslagplaatsen en een schriftelijk resultaat voor elke combinatie.

Test daarna de negatieve gevallen: een resource die het account niet mag bereiken, en een account dat direct moet worden geweigerd. Een ontwerp dat alleen het positieve pad bewijst, laat vaak een tweede ingang open, vooral wanneer dezelfde korte gebruikersnaam in beide opslagplaatsen bestaat. Schakel het directoryaccount uit en bevestig dat het lokale niet stilletjes blijft werken.

Beoordeel dubbele namen als onderdeel van de uitrol en niet na een incident. Dezelfde persoon in twee opslagplaatsen is tegelijk een gemak voor de helpdesk en een auditprobleem, en de firewall authenticeert met plezier degene die je hebt geconfigureerd.

Houd het herstelpad smal

Behoud het MFA-beleid voor elke accountklasse in plaats van lokale accounts ervan vrij te stellen. Als lokale accounts een goedgekeurd herstelpad bieden voor een directorystoring, beperk dat pad dan tot genoemde beheerders en bedien het bewust, want een lokaal noodaccount voor elke medewerker is een tweede authenticatiesysteem met zwakker toezicht.

Schrijf het clientdomein, de authenticatiebron en de effectieve toegang in hetzelfde record. De volgende beheerder kan dan een werkend gemengd accountontwerp reproduceren in plaats van domeinstrings te proberen tot een aanmelding lukt.