Windows IKEv2 Client nutzt VPN User Credentials für Mapping der Domänen-Netzlaufwerke

[VGS1 0]

Moin,

 

wir haben hier folgende Ausgangssituation:
Windows Server 2016 Domäne, Windows 10/11 Client Rechner, Zyxel SSL VPN über eine Zyxel Firewall USG Flex 700 (VPN Terminator), Zyxel SSL VPN Client (SecuExtender) auf den Windows Client Notebooks.

Die einzelnen User der Windows Domäne bekommen, in Abhängigkeit des User Accounts, verschiedene Netzlaufwerke mittels Logon Script (net use ... persistant:yes) verbunden, wenn sie sich im LAN an der Domäne anmelden. Funktioniert alles seit Jahren gut, auch wenn man die Netzlaufwerke evtl. eher mit GPO mappen sollte.
Wenn User remote arbeiten, loggen sie sich normal mit ihren Domänen User Credentials auf dem Notebook ein. Netzlaufwerke werden durch das "persistant" angezeigt, sind aber mit einem roten Kreuz versehen, weil sie natürlich nicht erreichbar sind. Bei Bedarf bauen die User danach mit dem Zyxel SSL VPN Client und separaten VPN User Credentials eine VPN Verbindung zur Zyxel Firewall auf. Danach haben sie auch wieder Zugriff auf die Netzlaufwerke. Das funktioniert seit Jahren problemlos.

Nun stellt Zyxel seinen Support für den SSL VPN Client ein und wir stellen unseren VPN Tunnel auf IPSec IKEv2 um. Auf Client Seite versuchen wir nun den Windows-eigenen IKEv2 Client zu nutzen. Nach ein wenig Einstellungsarbeit funktioniert das jetzt soweit gut. Ein Tunnel wird aufgebaut, wir können alles pingen, die Namensauflösung für die Domäne funktioniert und die genutzte 3rd Party Software im Firmen-LAN ist erreichbar (z.B. Email Server, Roundcube, etc.)

Allerdings gibt es ein Problem: Wenn man auf Client Seite nach dem Aufbau des Tunnels auf ein Netzlaufwerk klickt, gibt Windows immer verschiedene Fehlermeldungen aus, entweder, dass der Gerätename bereits in Verwendung ist oder die User Credentials falsch sind bzw. diese neu einzugeben sind. Meistens erhält man dann aber gar keine Möglichkeit, neue Userdaten einzugeben, um vorhandene Netzlaufwerke neu zu verbinden. Lange Rede, kurzer Sinn. Mittlerweile haben wir herausbekommen, dass Windows scheinbar die VPN User Credentials nutzt, um dann auch die Netzlaufwerke damit zu verbinden. Wenn wir nämlich die VPN Zugangsdaten dahingehend anpassen, dass diese den Domänen User Credentials entsprechen, funktioniert die Verbindung der Netzlaufwerke. Wir möchten aber unterschiedliche Anmeldedaten für die Domäne und die VPN Einwahl beibehalten.

 

Zu "Domänen-Netzlaufwerke durch VPN Tunnel verbinden" gibt es viele Anleitungen im Netz. Kaum eine behandelt aber das Problem bei abweichenden Zugangsdaten zwischen VPN Einwahl und Domänen Login. Dazu habe ich nur eine Anleitung von einem IT Service Heilbronn gefunden, wonach in einer Datei  rasphone.pbk die UseRASCredentials auf "0" zu setzen sind. Hat aber auch nicht geholfen. Wir haben das Laufwerk-Mapping auch mal auf GPO umgestellt und die GPO vom DC nach VPN Tunnelaufbau zunächst manuell neu abgerufen, um es zu testen. Die GPOs werden auf dem Client auch alle sauber abgearbeit. Es gibt immer nur eine Warnung "Schnelle Verbindung erkannt" (o.ä.). Ansonsten bzgl. der Netzlaufwerke immer dasselbe Ergebnis.

Gibt es eine Möglichkeit zu Verhindern, dass die VPN Zugangsdaten auch für eine spätere Verbindung der Netzlaufwerke genutzt wird? Hier soll Windows die Domänenzugangsdaten des angemeldeten Nutzers nehmen und nicht die VPN Credentials. Wenn das nicht geht, müssen wir uns sonst wieder einen separaten IKEv2 Client suchen.

[zahni 571]

Für IPSEC für ich den NCP-Client empfehlen:

 

https://www.ncp-e.com/de/produkte/zentral-gemanagte-vpn-loesung/managed-clients

Der unterstützt auch eine VPN-Anmeldung in der Domäne:

 

Zitat

Um Mitarbeitern eine sichere Anmeldung an der Windows-Domäne VOR der Anmeldung am Windows-System zu ermöglichen, unterstützt der Client die Domänenanmeldung mittels Credential Service Provider. Hierfür baut der Client eine VPN Verbindung in die Firmenzentrale auf. Die Benutzeranmeldung am lokalen Windows System geschieht daraufhin durch diesen VPN-Tunnel, so dass er an der zentralen Windows Domäne / Active Directory authentifiziert wird. Des Weiteren unterstützt der Client bereits in der Pre-Logon-Phase die sichere Anmeldung an einem WLAN-HotSpot, d.h. der Client ist durch die integrierte dynamische Firewall zu jedem Zeitpunkt der Anmeldung am HotSpot optimal geschützt. Für den Anwender macht es also keinen Unterschied, ob er sich im Büro oder an einem HotSpot seiner Wahl befindet.

 

PS: Willkommen im Forum.

bearbeitet Donnerstag um 09:05 von zahni