SSL VPN mit Authentisierung an AD
Moderator: Securepoint
SSL VPN mit Authentisierung an AD
Hallo zusammen,
habe schon mehrfach mit dem Support gesprochen, da ich ein grosses Problem mit der Radius Authentifizierung an einem 2008 R2 NPS habe. Doch leider ohne wirklichen Erfolg
Die RADIUS Authentifizierung schlägt am NPS mit folgendem Auszug im Security Log fehl:
Benutzer:
Sicherheits-ID: NULL SID
Kontoname: USERNAME
Kontodomäne: DOMAIN
Vollqualifizierter Kontoname: DOMAIN\\USERNAME
Clientcomputer:
Sicherheits-ID: NULL SID
Kontoname: -
Vollqualifizierter Kontoname: -
Betriebssystemversion: -
Empfänger-ID: -
Anrufer-ID: 192.168.4.103
NAS:
NAS-IPv4-Adresse: 127.0.0.1
NAS-IPv6-Adresse: -
NAS-ID: OpenVpn
NAS-Porttyp: Virtuell
NAS-Port: 1
RADIUS-Client:
Clientanzeigenname: 192.168.4.254
Client-IP-Adresse: 192.168.4.254
Authentifizierungsdetails:
Name der Verbindungsanforderungsrichtlinie: Use Windows authentication for all users
Netzwerkrichtlinienname: -
Authentifizierungsanbieter: Windows
Authentifizierungsserver: NPSSERVER.FQDN
Authentifizierungstyp: PAP
EAP-Typ: -
Kontositzungs-ID: -
Protokollierungsergebnisse: Die Kontoinformationen wurden in die lokale Protokolldatei geschrieben.
Ursachencode: 16
Ursache: Authentifizierungsfehler aufgrund der Nichtübereinstimmung von Benutzeranmeldeinformationen. Der angegebene Benutzername ist keinem vorhandenen Benutzerkonto zugeordnet, oder das Kennwort war falsch.
Habe mir heute einen PPTP Zugang gebaut, den ich über RADIUS Authentifiziere. Das funktioniert ohne Probleme. Da ich diese Lösung schon mehrfach beim Kunden (SSL VPN mit RADIUS) laufen habe, stellt sich mir nun die Frage, warum gerade bei unserer eigenen Anlage die SID bei einer SSL VPN - Einwahl nicht ausgewertet/übermittelt/verschluckt wird. Wie gesagt, bei einer Einwahl über PPTP funktioniert der Zugriff. Kann es am SSLVPN - Server auf der Appliance liegen? Muss an der Stelle ein Update erfolgen? So langsam gehen mir die Ideen aus und komme mit Debuggen nicht weiter ....
Wer von Euch hat eine vergleichbare Config am Laufen? Oder hatte noch jemand solche Problem? Ich möchte ungern den Zugang über PPTP ausrollen, da der SSL VPN schön schnell ist ....
Grüße
habe schon mehrfach mit dem Support gesprochen, da ich ein grosses Problem mit der Radius Authentifizierung an einem 2008 R2 NPS habe. Doch leider ohne wirklichen Erfolg
Die RADIUS Authentifizierung schlägt am NPS mit folgendem Auszug im Security Log fehl:
Benutzer:
Sicherheits-ID: NULL SID
Kontoname: USERNAME
Kontodomäne: DOMAIN
Vollqualifizierter Kontoname: DOMAIN\\USERNAME
Clientcomputer:
Sicherheits-ID: NULL SID
Kontoname: -
Vollqualifizierter Kontoname: -
Betriebssystemversion: -
Empfänger-ID: -
Anrufer-ID: 192.168.4.103
NAS:
NAS-IPv4-Adresse: 127.0.0.1
NAS-IPv6-Adresse: -
NAS-ID: OpenVpn
NAS-Porttyp: Virtuell
NAS-Port: 1
RADIUS-Client:
Clientanzeigenname: 192.168.4.254
Client-IP-Adresse: 192.168.4.254
Authentifizierungsdetails:
Name der Verbindungsanforderungsrichtlinie: Use Windows authentication for all users
Netzwerkrichtlinienname: -
Authentifizierungsanbieter: Windows
Authentifizierungsserver: NPSSERVER.FQDN
Authentifizierungstyp: PAP
EAP-Typ: -
Kontositzungs-ID: -
Protokollierungsergebnisse: Die Kontoinformationen wurden in die lokale Protokolldatei geschrieben.
Ursachencode: 16
Ursache: Authentifizierungsfehler aufgrund der Nichtübereinstimmung von Benutzeranmeldeinformationen. Der angegebene Benutzername ist keinem vorhandenen Benutzerkonto zugeordnet, oder das Kennwort war falsch.
Habe mir heute einen PPTP Zugang gebaut, den ich über RADIUS Authentifiziere. Das funktioniert ohne Probleme. Da ich diese Lösung schon mehrfach beim Kunden (SSL VPN mit RADIUS) laufen habe, stellt sich mir nun die Frage, warum gerade bei unserer eigenen Anlage die SID bei einer SSL VPN - Einwahl nicht ausgewertet/übermittelt/verschluckt wird. Wie gesagt, bei einer Einwahl über PPTP funktioniert der Zugriff. Kann es am SSLVPN - Server auf der Appliance liegen? Muss an der Stelle ein Update erfolgen? So langsam gehen mir die Ideen aus und komme mit Debuggen nicht weiter ....
Wer von Euch hat eine vergleichbare Config am Laufen? Oder hatte noch jemand solche Problem? Ich möchte ungern den Zugang über PPTP ausrollen, da der SSL VPN schön schnell ist ....
Grüße
Zuletzt geändert von LP81 am Mo 07.06.2010, 19:57, insgesamt 1-mal geändert.
Hallo,
es wird ein Update für die FW geben wo das Problem der Authentifizierung an ein 2008R2 behoben ist. Zumindest konnten wir nach dem Update den Fehler nicht mehr reproduzieren.
es wird ein Update für die FW geben wo das Problem der Authentifizierung an ein 2008R2 behoben ist. Zumindest konnten wir nach dem Update den Fehler nicht mehr reproduzieren.
There are 10 types of people in the world... those who understand binary and those who don\'t.
Hallo,
sorry, muss mich korrigieren. Ich war beim falschen Protokoll. Bei der Kerberos
Authentifizierung gibt es ein Update was mit Windows 2008R2 zu tun hat. Beim
Radius Protokoll gab es keine Änderung. Wir haben das auch bei uns im Testcenter
nachvollzogen und es funktionierte ohne Probleme. Der Fehler mus an anderer
Stelle liegen.
sorry, muss mich korrigieren. Ich war beim falschen Protokoll. Bei der Kerberos
Authentifizierung gibt es ein Update was mit Windows 2008R2 zu tun hat. Beim
Radius Protokoll gab es keine Änderung. Wir haben das auch bei uns im Testcenter
nachvollzogen und es funktionierte ohne Probleme. Der Fehler mus an anderer
Stelle liegen.
Zuletzt geändert von oliver am Di 08.06.2010, 17:52, insgesamt 1-mal geändert.
best regards
oliver hausmann
--
Securepoint GmbH
oliver hausmann
--
Securepoint GmbH
Hallo Oliver,
das ist nicht gut zu hören. Mittlerweile hat sie ein befreundeter MVP (Most Valueable People), also ein Microsoft Guru die Config angesehen und kann auch keine Fehlkonfiguration beim NPS finden. Warum funktioniert der Radius Login, wenn ich PPTP nehme, aber nicht bei SSL VPN? Sind doch Firewallseitig zwei verschiedene Dienste, die aber beide das gleiche Protokoll nutzen. Dir Kurx an der Sache: Im Januar lief das ganze mit SRV2008R2 und Securepoint. Dann kam ein Update, DB aktualisierung auf UTF8 und ZACK - geht nicht mehr.
In unserem Kundenumfeld sind viele Unternehmen, die vergleichbare Netze im Einsatz haben und ebenfalls das Feature SSL-VPN mit RADIUS nutzen wollen. Da kann ich nicht die Try-And-Error Taktik anwenden.
das ist nicht gut zu hören. Mittlerweile hat sie ein befreundeter MVP (Most Valueable People), also ein Microsoft Guru die Config angesehen und kann auch keine Fehlkonfiguration beim NPS finden. Warum funktioniert der Radius Login, wenn ich PPTP nehme, aber nicht bei SSL VPN? Sind doch Firewallseitig zwei verschiedene Dienste, die aber beide das gleiche Protokoll nutzen. Dir Kurx an der Sache: Im Januar lief das ganze mit SRV2008R2 und Securepoint. Dann kam ein Update, DB aktualisierung auf UTF8 und ZACK - geht nicht mehr.
In unserem Kundenumfeld sind viele Unternehmen, die vergleichbare Netze im Einsatz haben und ebenfalls das Feature SSL-VPN mit RADIUS nutzen wollen. Da kann ich nicht die Try-And-Error Taktik anwenden.
Hi,
kannst Du mal den PSK für die Radius Authentisierung neu setzen (auf beiden Seiten).
Erstmal einen ganz einfachen Key ohne Sonderzeichen etc. Den SSL VPN Dienst dann
am besten auch neustarten.
kannst Du mal den PSK für die Radius Authentisierung neu setzen (auf beiden Seiten).
Erstmal einen ganz einfachen Key ohne Sonderzeichen etc. Den SSL VPN Dienst dann
am besten auch neustarten.
best regards
oliver hausmann
--
Securepoint GmbH
oliver hausmann
--
Securepoint GmbH
hast du zufällig ein kleines howto irgendwo dafür? habe es gestern mal kurz probiert, aber nicht wirklich hinbekommen. muss aber zugeben das ich mich mit dem radius dienst vom windows 2008 noch nie beschäftigt hab ;o( bisher immer nur freeradius genutzt. Danke
Hallo, ich wollte mal fragen ob du in der Richtung weiter gekommen bist? Ich wollte das jetzt auch gern mal probieren, jedoch ist mir das Grundprinzip noch nicht ganz klar. Wenn ich gegen den Radius authentifiziere, müssen wahrscheinlich auch die Zertifikate auf diesem abgelegt werden, oder? Oder wie ordner ich in der Firewall ein Zertifikat einem Benutzer zu wenn es keinen Benutzer gibt (da ja die Benutzer aus dem Radius kommen)?!?!?! Vieleicht könntest du, oder jemand vom Support, mir in der Richtung nochmal weiterhelfen. Vielen Dank
Der RADIUS-Server verifiziert nur die Zugangsdaten. Für den Client sieht es so aus, als würde das alles von der Firewall erledigt werden -> Zertifikate müssen auf der Firewall abgelegt werden. Die Zuordnung zum Benutzer erfolgt ja dadurch, dass der Benutzer das Zertifikat von Ihnen bekommt.
@Petasch:
Ja, ich bin da weiter gekommen. Das Problem lag im gemeinsamen "Geheimnis", was der RADIUS Client und der NPS (bis Server 2003 R2 IAC) miteinander austauschen. Ich hatte in meiner ersten Umgebung ein sehr kryptisches Geheimnis gewählt (mit Sonderzeichen). Das Problem waren hier auch die Sonderzeichen, die hier für Windows nicht richtig übergeben werden.
An dieser Stelle (da sich dieser Netzwerkverkehr im privaten Netzwerk abspielt) kann ein "Geheimnis" gewählt werden, was recht einfach ist. Damit hast Du die RADIUS - Komponente fertig und die UTM kann das AD zur Autorisierung benutzen. Die Zertifikate prüft die UTM ab, hat also nichts mit der AD Autorisierung zu tun.
Das Zertifikat der Firewall (ich denke, die Grundsätze von SSL VPN sind vorhanden) hängt in der Konfiguration des Client, will sagen an der Clientsoftware. Du erstellst also auf der Firewall einen Benutzer (oder mehrere), wo eiin Benutzer sich den VPN Client herunterladen kann (URL: https://47.11.08.15). Dieses Benutzerobjekt muss die Berechtigung haben, sich am Userinterface anzumelden. Hier "verheiratest" Du das Zertifikat mit dem Firewallbenutzer. Lädt sich der Benutzer den Client herunter, den Du für SSL VPN Konfiguriert hast, bekommt er das jeweilige Zertifikat. Hast Du die VPN Konfig auf diesem Wege verteilt, kann sich jeder AD Benutzer, der die Einwahlberechtigung hat, mit diesem Zertifikat über VPN Verbinden.
Hoffe, das hilft Dir weiter ....
Grüße
LP
Ja, ich bin da weiter gekommen. Das Problem lag im gemeinsamen "Geheimnis", was der RADIUS Client und der NPS (bis Server 2003 R2 IAC) miteinander austauschen. Ich hatte in meiner ersten Umgebung ein sehr kryptisches Geheimnis gewählt (mit Sonderzeichen). Das Problem waren hier auch die Sonderzeichen, die hier für Windows nicht richtig übergeben werden.
An dieser Stelle (da sich dieser Netzwerkverkehr im privaten Netzwerk abspielt) kann ein "Geheimnis" gewählt werden, was recht einfach ist. Damit hast Du die RADIUS - Komponente fertig und die UTM kann das AD zur Autorisierung benutzen. Die Zertifikate prüft die UTM ab, hat also nichts mit der AD Autorisierung zu tun.
Das Zertifikat der Firewall (ich denke, die Grundsätze von SSL VPN sind vorhanden) hängt in der Konfiguration des Client, will sagen an der Clientsoftware. Du erstellst also auf der Firewall einen Benutzer (oder mehrere), wo eiin Benutzer sich den VPN Client herunterladen kann (URL: https://47.11.08.15). Dieses Benutzerobjekt muss die Berechtigung haben, sich am Userinterface anzumelden. Hier "verheiratest" Du das Zertifikat mit dem Firewallbenutzer. Lädt sich der Benutzer den Client herunter, den Du für SSL VPN Konfiguriert hast, bekommt er das jeweilige Zertifikat. Hast Du die VPN Konfig auf diesem Wege verteilt, kann sich jeder AD Benutzer, der die Einwahlberechtigung hat, mit diesem Zertifikat über VPN Verbinden.
Hoffe, das hilft Dir weiter ....
Grüße
LP
1812 und 1813 udp
Und warum es nicht geht, kann ich so net sagen. Evtl mal mit tcpdump auf dem externen Interface schauen, ob die RADIUS Queries auch wirklich in den Tunnel gehen:
Und warum es nicht geht, kann ich so net sagen. Evtl mal mit tcpdump auf dem externen Interface schauen, ob die RADIUS Queries auch wirklich in den Tunnel gehen:
Code: Alles auswählen
# tcpdump -i eth0 -nnp port 1812 or port 1813
Zuletzt geändert von Erik am Do 10.03.2011, 19:42, insgesamt 1-mal geändert.
-
- Beiträge: 13
- Registriert: Di 17.03.2009, 16:51
Hallo
Ich habe genau die selbe Fehlermeldung wie LP81.
Leider hat bei mir das Ändern des gemeinsamen Keys nicht zum Erfolg geführt.
System:
Windows 2008 R2 SP1
FW Version 10.4
Radius + FW konfig nach Securepoint Howto
Hat noch jemand Erfahrung damit und kann mir helfen?
Gruß
bernhard
Ich habe genau die selbe Fehlermeldung wie LP81.
Leider hat bei mir das Ändern des gemeinsamen Keys nicht zum Erfolg geführt.
System:
Windows 2008 R2 SP1
FW Version 10.4
Radius + FW konfig nach Securepoint Howto
Hat noch jemand Erfahrung damit und kann mir helfen?
Gruß
bernhard
Verbinden Sie sich per Putty (als admin) zur FW oder benutzen Sie das Webinterface (Extras -> CLI )
und geben dort "show extc_glob_entry" ein.
Sollte dort der Eintrag wie folgt aussehen,
GLOB_RADIUS_SERVER_KEY;insecure
müssen Sie ihn per Hand ändern.
Dafür benutzen Sie folgenden Befehl:
change extc_glob_value GLOB_RADIUS_SERVER_KEY
Danach einmal die Anwendungen neustarten und die Config speichern.
und geben dort "show extc_glob_entry" ein.
Sollte dort der Eintrag wie folgt aussehen,
GLOB_RADIUS_SERVER_KEY;insecure
müssen Sie ihn per Hand ändern.
Dafür benutzen Sie folgenden Befehl:
change extc_glob_value GLOB_RADIUS_SERVER_KEY
Danach einmal die Anwendungen neustarten und die Config speichern.
-
- Beiträge: 13
- Registriert: Di 17.03.2009, 16:51
Howto wie von Pascal beschrieben funktioniert für den Fehler den LP81 hat (Ursachencode 16)