VPN Zugang (über Sophos VPN Client) sowie User Portal Fehler: Ungültiger Benutzername /Kennwort, oder Zugang verweigert aufgrund einer internen Vorgabe.

Hallo,

wir haben seit gestern Abend das gleiche Problem.

User werden per Prefetch aus dem AD auf der Sophos UTM angelegt, das funktioniert ohne Probleme.

Auf der Sophos gibt es eine Gruppe für SSL-VPN-Users, die die passende AD-Gruppe enthält.
Zusätzlich noch eine Gruppe für das User-Portal, selbes Schema.

Dieses Konstrukt hat über Monate/Jahre problemlos funktioniert.
Seit gestern Abend können sich diese Benutzer nicht mehr im User Portal anmelden und sich nicht mehr per VPN einwählen.
Die Fehlermeldungen/Logeinträge sind identisch wie bei Herrn Lehmann.

Sowohl an der UTM-Konfig als auch an den AD-Gruppen/-Benutzern wurde nichts verändert.
Die Tests bei den Auth-Servern funktionieren problemlos, User Prefetch auch ohne Probleme.

Erstelle ich eine Gruppe auf der Sophos, die die gesyncten User enthält, funktionieren User Portal und VPN ohne Probleme.

So langsam glaube ich nicht mehr an einen Zufall oder einen Fehler auf unserer Seite.

Any ideas?

'AUTH_FAILED' kann alles und nix sein... Aber da ist das SSL VPN Log eher nutzlos. Lieber mal das User authentication daemon Log anschauen ;-)

9.711-5 kann ich nix gegen sagen. Seit Release drauf (SG330 HA) und keine Probleme. Nutzen ebenfalls SSL VPN mit UserPrefetch und sowohl alten, als auch neuen SSL Client bei den Usern.

mal das user-synclog prüfen.

wenn die konten gefunden werden, ist die erste hürde genommen.

sonst die ad-server verbindung mit dem test button prüfen.

dann lässt sich die authentifizierung noch auf debugging schalten, dann steht im auth-log wirklich alles drin.

Der User-Sync funktioniert problemlos jede Nacht.

Die Verbindung zu den AD-Servern über den Test-Button und auch darunter der Test eines Users funktionieren problemlos.

Der Zugriff per VPN und auf das User-Portal funktionieren nicht, bei beiden wird auf eine Dynamic Membership Group verwiesen.
Der Zugriff auf den WebAdmin funktioniert, aber das betrifft ja auch die lokale Gruppe "SuperAdmins".

Mir ist nicht bekannt, wie man die Authentifizierung auf Debug stellen kann, ich kenn das nur bei der VPN-Einwahl.

2022:08:10-16:12:25 utm-1 aua[3870]: id="3006" severity="info" sys="System" sub="auth" name="Running _cleanup_up_children with max_run_time: 23"
2022:08:10-16:12:25 utm-1 aua[31659]: id="3006" severity="info" sys="System" sub="auth" name="Trying 192.168.xx.2 (adirectory)"
2022:08:10-16:12:25 utm-1 aua[31659]: id="3006" severity="info" sys="System" sub="auth" name="Trying 192.168.xx.1 (adirectory)"
2022:08:10-16:12:25 utm-1 aua[31659]: id="3005" severity="warn" sys="System" sub="auth" name="Authentication failed" srcip="192.168.xx.77" host="" user="JBE" caller="portal" reason="DENIED"

Im WebAdmin gibt es beim AD-Test auch den Test einer vollständigen Anmeldung.
Dort werden dann auch Gruppenzugehörigkeiten angezeigt.

Sonst mal kurze Kennworte ohne Sonderzeichen verwenden.

Der Test mit der vollständigen Anmeldung funktioniert.
Es werden nur lokale Gruppen (z.B. SuperAdmins) angezeigt, keine dynamischen.
Werden bei dir auch die dynamischen Gruppen angezeigt?

Die Passwörter wurden nicht verändert, das hat zuvor monatelang problemlos funktioniert.

ja. Ich bekomme auch die dynamischen Gruppen angezeigt.

zeig mal die Verknüpfung von SG-Gruppen mit AD-gruppen...

Ich denke mal, der LDAP-Read-User darf nicht die Gruppenzugehörigkeit anderer User lesen.

Dann mal TEMPORÄR / KURZZEITIG zum Domänen-Admin machen und gegentesten.

Danke, es lag tatsächlich daran, dass Authenticated Users keinen lesenden Zugriff auf die passenden Daten im AD hatten.

Danke, es lag tatsächlich daran, dass Authenticated Users keinen lesenden Zugriff auf die passenden Daten im AD hatten.