SSL VPN mit Authentisierung an AD

[LP81]

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

[carsten]

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.

[LP81]

Hallo Carsten,

das klingt schon einmal sehr schön. Habt Ihr schon ein Releasedatum hierfür?

[oliver]

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.

[LP81]

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.

[oliver]

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.

[LP81]

Hi,
habe ich getan. Ohne Veränderung. Beim RADIUS Server kommt keine SID an ... Kontoname und Anmeldedomäne sind OK ....

[Petasch]

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

[Petasch]

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

[Erik]

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.

[LP81]

@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

[Petasch]

funktioniert :-) Vielen Dank..

[Petasch]

kurze Frage noch dazu. Kann ich als Radius Server auf der Firewall auch einen Radius hinter einen VPN Tunnel angeben? Also vom Prinzip mehrere Standorte, alle mit SP vernetzt, ein zentraler Radius? Klappt das?

[Erik]

Können Sie tun. Sie brauchen dann aber noch ein HideNAT:

Quelle: External_Interface
NAT-Relationship:
Ziel:
Typ: Include

[Petasch]

Okay habe es probiert, Authentifizierung am internen Radius klappt, am Radius hinter dem VPN Tunnel nicht. Hide NAT hab ich eingestellt, gibt es noch etwas zu beachten???

[Petasch]

welche Ports nutzt eigentlich der Radius Client der Securepoint für die Authentifizierung? 1812 oder 1645???

[Erik]

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:

Code: Alles auswählen

# tcpdump -i eth0 -nnp port 1812 or port 1813

[bernicertus]

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

[Pascalk]

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.

[bernicertus]

Howto wie von Pascal beschrieben funktioniert für den Fehler den LP81 hat (Ursachencode 16)