NetExtender meldet sich an, aber kein Zugriff: SonicWall lokal + LDAP

Die Anmeldung gelingt, der Tunnel steht, und nichts hinter der Firewall antwortet. Dieses Muster auf einer SonicWall SSL VPN bedeutet meist, dass das Konto die Authentifizierung bestanden hat und an einer von zwei späteren Berechtigungen hängen blieb: der Zulassung zum SSL-VPN-Dienst oder der Erlaubnis, eine Ressource zu erreichen. Gemischte lokale Konten und LDAP-Konten verschärfen das, weil die beiden Speicher diese Berechtigungen auf unterschiedlichen Wegen erreichen. Für den Client ist das Symptom identisch, weshalb die Ebenen bewusst getrennt werden müssen.

Das Symptom und die drei Berechtigungen dahinter

Zwischen einem Benutzernamen und einem erreichbaren Server stehen drei unabhängige Entscheidungen. Die Authentifizierungsmethode entscheidet, ob die Anmeldedaten akzeptiert werden und von welchem Speicher. Die Mitgliedschaft im SSL-VPN-Dienst entscheidet, ob diese Identität das SSL VPN überhaupt nutzen darf. Die Liste VPN-Zugriff entscheidet, welche privaten Ziele die Sitzung erreichen darf. Das Bestehen einer Prüfung sagt nichts über die nächsten beiden aus.

Ein Benutzer, der sich authentifiziert, aber nicht in der Gruppe des SSL-VPN-Dienstes ist, sieht eine Verbindung, die aufgebaut wird und dann nichts überträgt, und im Firewall-Protokoll steht eine akzeptierte Anmeldung statt eines Fehlers. Diesen Fall sollte man schnell erkennen, denn die Lösung ist eine Gruppenmitgliedschaft und kein Zurücksetzen des Passworts.

Ein Benutzer, der zugelassen ist, aber keine Ressourcen hat, sieht eine Sitzung, die sich verbindet und nirgendwohin Nützliches routet. Vom Helpdesk aus sehen beide wie ein defekter Tunnel aus, und beide sind Konfiguration und nicht Konnektivität.

Das Domänenfeld ist nicht das Verzeichnis

NetExtender fragt nach einer Domäne, und dieses Feld ist keine Suchbasis für Active Directory. In der Standardanordnung muss das Feld der SSL-VPN-Benutzerdomäne entsprechen, die auf der Firewall konfiguriert ist, und der dokumentierte Standardwert dafür ist LocalDomain. Der Vergleich unterscheidet zwischen Groß- und Kleinschreibung, daher schlägt ein Wert mit anderer Schreibweise fehl, selbst wenn das Konto korrekt ist.

Ist die Authentifizierungspartitionierung konfiguriert, wählen stattdessen die Partitionsnamen den externen Authentifizierungskontext, und der konfigurierte Standard behält seine eigene Rolle. In beiden Anordnungen wird die Domänenbezeichnung des Clients nicht als Teil des Benutzernamens an LDAP oder RADIUS weitergegeben, sodass sie keine Verzeichnissuche steuern kann.

Halten Sie die drei Zeichenketten in Ihren Notizen auseinander: das DNS-Suffix des Unternehmens, die LDAP-Suchbasis und die NetExtender-Domänenbezeichnung. Sie sehen ähnlich aus, und keine ersetzt eine andere. Übernehmen Sie den Wert des Betreibers für diese Installation und nicht einen Wert aus einem Forumsbeitrag zu einer anderen Firmware-Version.

Zulassung und Ressourcenzugriff sind getrennte Berechtigungen

Lokale Konten benötigen eine Mitgliedschaft in der Gruppe des SSL-VPN-Dienstes, bevor der Dienst sie akzeptiert. Verzeichniskonten erreichen dieselbe Gruppe über den unterstützten Gruppenabbildungs-Workflow, das heißt, die LDAP-Gruppenbeziehung muss konfiguriert und dann als wirksame Mitgliedschaft überprüft werden, statt von der Verzeichnisseite her angenommen zu werden.

Als Nächstes kommt der Ressourcenzugriff unter VPN-Zugriff am Benutzer oder an der Gruppe. Gewähren Sie die konkreten Subnetze und Dienste, die die Rolle benötigt, und widerstehen Sie der Abkürzung, das gesamte LAN freizugeben, weil eine Anwendung gebraucht wird. Die Routen der Sitzung, die Zugriffsregeln und die Dienstberechtigungen am Ziel müssen alle mit diesem Umfang übereinstimmen.

Eine Route auf dem Client macht ein Ziel auswählbar und autorisiert es nicht. Die Mitgliedschaft in der SSL-VPN-Gruppe macht das Konto auch nicht zum Firewall-Administrator, und sie sollte nicht als allgemeine Rechtevergabe behandelt werden.

Zwei Identitäten, je vier Prüfungen

Testen Sie mit einem lokalen Konto und einem Verzeichniskonto, beide eng autorisiert und beide als Testkonten dokumentiert. Halten Sie für jedes die Authentifizierungsquelle fest, die die Anmeldung akzeptiert hat, die wirksamen Gruppen, den zugewiesenen Ressourcenzugriff und eine erlaubte Anwendungsoperation. Vier Prüfungen, zwei Speicher und ein schriftliches Ergebnis für jede Kombination.

Prüfen Sie dann die Gegenfälle: eine Ressource, die das Konto nicht erreichen darf, und ein Konto, das rundheraus abgelehnt werden soll. Ein Entwurf, der nur den positiven Weg belegt, lässt tendenziell einen zweiten Eingang offen, besonders wenn derselbe kurze Benutzername in beiden Speichern existiert. Deaktivieren Sie das Verzeichniskonto und bestätigen Sie, dass das lokale nicht stillschweigend weiter funktioniert.

Prüfen Sie doppelte Namen als Teil der Einführung und nicht erst nach einem Vorfall. Dieselbe Person in zwei Speichern ist gleichzeitig eine Erleichterung für den Support und ein Prüfungsproblem, und die Firewall authentifiziert bereitwillig diejenige Variante, die Sie konfiguriert haben.

Halten Sie den Wiederherstellungspfad eng

Behalten Sie die MFA-Richtlinie für jede Kontoklasse bei, statt lokale Konten davon auszunehmen. Wenn lokale Konten einen genehmigten Wiederherstellungspfad für einen Verzeichnisausfall bieten, beschränken Sie diesen Pfad auf namentlich benannte Administratoren und betreiben Sie ihn bewusst, denn ein lokales Notfallkonto für jeden Mitarbeiter ist ein zweites Authentifizierungssystem mit schwächerer Aufsicht.

Schreiben Sie die Client-Domäne, die Authentifizierungsquelle und den wirksamen Zugriff in denselben Datensatz. Der nächste Administrator kann dann ein funktionierendes gemischtes Kontodesign nachvollziehen, statt Domänenzeichenketten durchzuprobieren, bis eine Anmeldung gelingt.