9
Nach VPN Einwahl Netzlaufwerke nicht mehr erreichbar
Hallo,
folgendes funktioniert seit der Einführung von Windows 7 Clients bei uns im Netzwerk nicht mehr zufriedenstellend.
Ein Mobiler Client baut eine VPN Verbindung in die Firma auf und versucht auf seine Netzlaufwerke zuzugreifen.
Entweder bekommt der User Benutzername oder Passwort nicht Korrekt Meldung oder NetzPfad kann nicht gefunden werden.
Testweise habe ich ein Netzlaufwerk an meinem Platz getrennt und nach der VPN Einwahl diese wieder manuell einbinden wollen
(net use P: \\server\freigabe)
Ich wurde nach Benutzername und passwort gefragt, was sonst nie der Fall ist, da Windows meine Logindaten automatisch im Hintergrund überträgt (normalerweise).
Ich habe den Eindruck, dass die VPN Einwahldaten als Benutzername und Passwort übergeben werden.
Diese sind natürlich nicht die, welche Zugriffberechtigung auf die Netzwerkressource haben.
Hintergrund:
Firewall: Watchguard x1250e
Datenserver: Win 2003 R2
Clients: Win 7 (jedenfalls die, die das Problem haben, XP Clients haben keine Probleme)
DHCP Funtion wird durch Watchguard übernommen.
2 DNS Server (beide DC, auch Win2003 R2)
Jede Anregung ist gern gesehen.
Viele Grüße aus Hamburg
folgendes funktioniert seit der Einführung von Windows 7 Clients bei uns im Netzwerk nicht mehr zufriedenstellend.
Ein Mobiler Client baut eine VPN Verbindung in die Firma auf und versucht auf seine Netzlaufwerke zuzugreifen.
Entweder bekommt der User Benutzername oder Passwort nicht Korrekt Meldung oder NetzPfad kann nicht gefunden werden.
Testweise habe ich ein Netzlaufwerk an meinem Platz getrennt und nach der VPN Einwahl diese wieder manuell einbinden wollen
(net use P: \\server\freigabe)
Ich wurde nach Benutzername und passwort gefragt, was sonst nie der Fall ist, da Windows meine Logindaten automatisch im Hintergrund überträgt (normalerweise).
Ich habe den Eindruck, dass die VPN Einwahldaten als Benutzername und Passwort übergeben werden.
Diese sind natürlich nicht die, welche Zugriffberechtigung auf die Netzwerkressource haben.
Hintergrund:
Firewall: Watchguard x1250e
Datenserver: Win 2003 R2
Clients: Win 7 (jedenfalls die, die das Problem haben, XP Clients haben keine Probleme)
DHCP Funtion wird durch Watchguard übernommen.
2 DNS Server (beide DC, auch Win2003 R2)
Jede Anregung ist gern gesehen.
Viele Grüße aus Hamburg
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 137880
Url: https://administrator.de/forum/nach-vpn-einwahl-netzlaufwerke-nicht-mehr-erreichbar-137880.html
Ausgedruckt am: 27.12.2024 um 01:12 Uhr
9 Kommentare
Neuester Kommentar
Mir fällt spontan die UAC ein.
Also ein clientseitiges Berechtigungsproblem.
Wie wird die VPN Verbindung hergestellt?
Startest du beim manuellen Versuch die CMD mit Administratorrechten?
lg
Also ein clientseitiges Berechtigungsproblem.
Wie wird die VPN Verbindung hergestellt?
Startest du beim manuellen Versuch die CMD mit Administratorrechten?
lg
Hallo maragello,
probiere mal folgendes...
net use [LW-Buchstabe]: [Passwort] \\Servername\Freigabe /USER:....
Hab die Erfahrung gemacht, daß die Win7-Clients nach dem ersten Verbindungsversuch in dem Fenster das aufpoppt, beim Usernamen folgendes drin stehen haben "\\Hostname\Username". Könnte mir vorstellen, daß das wieder so eine Nickeligkeit gegenüber Linux und dem Samba darstellt, damit das nicht reibungslos funktioniert, mit dem Hintergrund, daß Windows da ja ohne Schwierigkeiten akzepiert "Stichwort Vertrauensstellung" und für Nicht-MS-Server eben \\Hostname\Username nicht das gleiche ist wie \Username...
Gruß Roger
probiere mal folgendes...
net use [LW-Buchstabe]: [Passwort] \\Servername\Freigabe /USER:....
Hab die Erfahrung gemacht, daß die Win7-Clients nach dem ersten Verbindungsversuch in dem Fenster das aufpoppt, beim Usernamen folgendes drin stehen haben "\\Hostname\Username". Könnte mir vorstellen, daß das wieder so eine Nickeligkeit gegenüber Linux und dem Samba darstellt, damit das nicht reibungslos funktioniert, mit dem Hintergrund, daß Windows da ja ohne Schwierigkeiten akzepiert "Stichwort Vertrauensstellung" und für Nicht-MS-Server eben \\Hostname\Username nicht das gleiche ist wie \Username...
Gruß Roger
Sorry,
wurde zu anderen Störungen gerufen. Daher antworte ich jetzt erst.
Also:
@bert:
Es ist kein Berechtigungsproblem. Freigabe und Sicherheitsberehctigungen sind OK. Sonst würde es ja überhaupt nicht funktionieren. Das ganze läuft nur nach VPN-Einwahl nicht.
VPN Einwahl erfolgt über das Windows Boardmittel. Also --> Neue Verbindung --> Verbindung mit dem Arbeitsplatz --> VPN --> Firewall-IP --> VPN Logindaten
Zur info: VPN Logindaten sind nicht die Domain Logindaten.
@Roger
Angeregt durch deinen ersten Hinweis (Hostname\Username) habe ich dies überprüft und festgestellt, dass es tatsächlich so ist.
Über die Console net use L: \\servername\freigabe funktionierte es nicht mit anschließenden Logindaten.
Wenn die Auth.Daten aber mit Domain\User und dann passwort eingegeben werden läuft es auch nach VPN Einwahl.
Die Frage ist nur warum macht Windows so etwas unerwartetes?
Ich würde gerne die Logindaten in ein Batch File testweise eintriggern.
Dies ist jedoch klartext. Würde es anschließend durch tools in eine .exe datei umwandeln.
Wie sieht die Zeile aus (mit Credentials)?
Ohne sieht es bei mir so aus:
%LOGONSERVER%\NETLOGON\ifmember.exe Gruppe
if %errorlevel%==1 (
net use T: \\Servername\Freigabe
)
wurde zu anderen Störungen gerufen. Daher antworte ich jetzt erst.
Also:
@bert:
Es ist kein Berechtigungsproblem. Freigabe und Sicherheitsberehctigungen sind OK. Sonst würde es ja überhaupt nicht funktionieren. Das ganze läuft nur nach VPN-Einwahl nicht.
VPN Einwahl erfolgt über das Windows Boardmittel. Also --> Neue Verbindung --> Verbindung mit dem Arbeitsplatz --> VPN --> Firewall-IP --> VPN Logindaten
Zur info: VPN Logindaten sind nicht die Domain Logindaten.
@Roger
Angeregt durch deinen ersten Hinweis (Hostname\Username) habe ich dies überprüft und festgestellt, dass es tatsächlich so ist.
Über die Console net use L: \\servername\freigabe funktionierte es nicht mit anschließenden Logindaten.
Wenn die Auth.Daten aber mit Domain\User und dann passwort eingegeben werden läuft es auch nach VPN Einwahl.
Die Frage ist nur warum macht Windows so etwas unerwartetes?
Ich würde gerne die Logindaten in ein Batch File testweise eintriggern.
Dies ist jedoch klartext. Würde es anschließend durch tools in eine .exe datei umwandeln.
Wie sieht die Zeile aus (mit Credentials)?
Ohne sieht es bei mir so aus:
%LOGONSERVER%\NETLOGON\ifmember.exe Gruppe
if %errorlevel%==1 (
net use T: \\Servername\Freigabe
)
Nach VPN Einwahl:
ein "net view \\Servername" liefert
SystemFehler 5
Zugriff verweigert
Ohne VPn Einwahl werden natürlich die vorhandenen Freigabenamen angezeigt.
Ich verstehe nicht warum die Usercredentials nach der VPN Einwahl nicht mehr in Form von Domain\username übermittelt werden.
ein "net view \\Servername" liefert
SystemFehler 5
Zugriff verweigert
Ohne VPn Einwahl werden natürlich die vorhandenen Freigabenamen angezeigt.
Ich verstehe nicht warum die Usercredentials nach der VPN Einwahl nicht mehr in Form von Domain\username übermittelt werden.
Ok, erstmal:
warum machst du die Authentifizierung deiner VPN-User nicht über LDAP aufs AD? Die WatchGuard kann das. Dann kannst du gleich schnieke über eine Sicherheitsgruppe steuern, wer VPN darf und wer nicht, deine User müssen sich nicht zig Passwörter merken und du weniger konfigurieren, falls deine Passwörter nicht endlos gültig sind, erhöht sich vielleicht sogar etwas die Sicherheit des Zugriffs, aber gut. Du wirst deine Gründe haben - was auch völlig legitim ist.
Nichtsdestotrotz kenn ich die von dir beschriebenen Probleme eher bei XP-Maschinen, mit Win7 ist das hier bisher noch nicht aufgetreten, ich nutz seit dem RC Win7 und mach viel über VPN - ich hatte das Problem nie.
Andere User haben das Problem aber regelmäßig, hab das dann über ne Batch gelöst (ähnlich wie bereits weiter oben erwähnt), die ich dem betreffenden User auf den Desktop lege. Dann musse er/sie nur sein Kennwort einhacken und die Sache funktioniert. Ist bei mir aber nie ein wirklich reproduzierbares Problem, meist wenn das Laptop im Standby vom LAN abgezogen wurde und dann nach dem Aufwecken mit VPN weitermachen sollte. Mal wochenlang garnicht, mal ständig.
Mir war die Sache aber auch nicht wichtig genug, um länger danach zu suchen, das mit dem Workaround geht schneller und ist ziemlich zuverlässig. Ist die Verbindung erstmal hergestellt, läufts wie am Schnürchen.
Das mit dem Domain\Usernamen... hast du bei dem Windows-VPN denn die Domain angegeben, mit der er sich verbinden soll? Tust du das nicht, nimmt Windows IMHO an, dass die lokaler Maschine die Domain sein soll.
Alternativ: bring deine User dazu, sich mit username@domain.local anzumelden, das sollte auch funktionieren.
warum machst du die Authentifizierung deiner VPN-User nicht über LDAP aufs AD? Die WatchGuard kann das. Dann kannst du gleich schnieke über eine Sicherheitsgruppe steuern, wer VPN darf und wer nicht, deine User müssen sich nicht zig Passwörter merken und du weniger konfigurieren, falls deine Passwörter nicht endlos gültig sind, erhöht sich vielleicht sogar etwas die Sicherheit des Zugriffs, aber gut. Du wirst deine Gründe haben - was auch völlig legitim ist.
Nichtsdestotrotz kenn ich die von dir beschriebenen Probleme eher bei XP-Maschinen, mit Win7 ist das hier bisher noch nicht aufgetreten, ich nutz seit dem RC Win7 und mach viel über VPN - ich hatte das Problem nie.
Andere User haben das Problem aber regelmäßig, hab das dann über ne Batch gelöst (ähnlich wie bereits weiter oben erwähnt), die ich dem betreffenden User auf den Desktop lege. Dann musse er/sie nur sein Kennwort einhacken und die Sache funktioniert. Ist bei mir aber nie ein wirklich reproduzierbares Problem, meist wenn das Laptop im Standby vom LAN abgezogen wurde und dann nach dem Aufwecken mit VPN weitermachen sollte. Mal wochenlang garnicht, mal ständig.
Mir war die Sache aber auch nicht wichtig genug, um länger danach zu suchen, das mit dem Workaround geht schneller und ist ziemlich zuverlässig. Ist die Verbindung erstmal hergestellt, läufts wie am Schnürchen.
Das mit dem Domain\Usernamen... hast du bei dem Windows-VPN denn die Domain angegeben, mit der er sich verbinden soll? Tust du das nicht, nimmt Windows IMHO an, dass die lokaler Maschine die Domain sein soll.
Alternativ: bring deine User dazu, sich mit username@domain.local anzumelden, das sollte auch funktionieren.
Hallo Wannabe,
vielen Dank für deine Anregungen. Hast mich auf jedenfall weiter gebracht.
Die User haben sich bis dato immer mit Domain\User an Windows angemeldet und das Problem trat nie auf.
In den VPN Einstellungen wird die Domäne nicht angegeben.
Vorerst:
Ich habe angeregt durch deinen Beitrag oben testweise die MUVPN Software von Wathcguard installiert und getestet. Damit läufts wie gewünscht.
Fall es jemand nicht kennt: Mobile User VPN arbeitet mit IPSEC.
Werde aber auf jeden Fall auch deine Anregung bezüglich über LDAP zu Arbeiten verfolgen und gegebenenfalls (wenn genehmigt) einsetzen.
Klingt aus meiner Sicht sehr Positiv.
Vielen Dank und Grüße
vielen Dank für deine Anregungen. Hast mich auf jedenfall weiter gebracht.
Die User haben sich bis dato immer mit Domain\User an Windows angemeldet und das Problem trat nie auf.
In den VPN Einstellungen wird die Domäne nicht angegeben.
Vorerst:
Ich habe angeregt durch deinen Beitrag oben testweise die MUVPN Software von Wathcguard installiert und getestet. Damit läufts wie gewünscht.
Fall es jemand nicht kennt: Mobile User VPN arbeitet mit IPSEC.
Werde aber auf jeden Fall auch deine Anregung bezüglich über LDAP zu Arbeiten verfolgen und gegebenenfalls (wenn genehmigt) einsetzen.
Klingt aus meiner Sicht sehr Positiv.
Vielen Dank und Grüße
Gern geschehen.
Meines erachtens nach hat die MUVPN-Software von WatchGuard den eklatanten Nachteil, dass diese bei XP mit der GINA arbeitet, sprich bei Laptops mit Fingerprint-Sensor gibt's dann ein entweder-oder Problem, sprich entweder VPN-Login vor Windows-Authentifizierung - oder halt Fingerprint-Login, aber sonst ist die Software echt super. Im Grunde ist das ein angepasster NCP-Client, und der tun sein Ding ziemlich hervorragend.
Meiner Erfahrung nach wird das Problem früher oder später trotzdem auftreten (wie gesagt, nur sporadisch, ohne direkt erkennbare Ursache, meistens funktionierts glänzend, vor allem unter Windows 7) - aber falls das auftritt, hilft die ebenfalls erwähnte Lösung über Batch.
Ich setzte die LDAP-Geschichte für alle normalen User ein, habe eigentlich nur einen "normalen" (also WatchGuard-internen) VPN-Account - falls ich mal meinen Firmen-Laptop nicht parat habe - oder im Worst-Case der DC aussteigt -, um halt ne Möglichkeit zu haben, überhaupt ins Netz zu kommen. Funktioniert glänzend. Gibt bei mir ne Sicherheitsgruppe im AD, die von der WatchGuard abgefragt wird - wer dort drin ist, erhält Zugang, wer nicht, naja.
Again, gern geschehen, viel Erfolg beim durch- und umsetzen.
Gruß
Meines erachtens nach hat die MUVPN-Software von WatchGuard den eklatanten Nachteil, dass diese bei XP mit der GINA arbeitet, sprich bei Laptops mit Fingerprint-Sensor gibt's dann ein entweder-oder Problem, sprich entweder VPN-Login vor Windows-Authentifizierung - oder halt Fingerprint-Login, aber sonst ist die Software echt super. Im Grunde ist das ein angepasster NCP-Client, und der tun sein Ding ziemlich hervorragend.
Meiner Erfahrung nach wird das Problem früher oder später trotzdem auftreten (wie gesagt, nur sporadisch, ohne direkt erkennbare Ursache, meistens funktionierts glänzend, vor allem unter Windows 7) - aber falls das auftritt, hilft die ebenfalls erwähnte Lösung über Batch.
Ich setzte die LDAP-Geschichte für alle normalen User ein, habe eigentlich nur einen "normalen" (also WatchGuard-internen) VPN-Account - falls ich mal meinen Firmen-Laptop nicht parat habe - oder im Worst-Case der DC aussteigt -, um halt ne Möglichkeit zu haben, überhaupt ins Netz zu kommen. Funktioniert glänzend. Gibt bei mir ne Sicherheitsgruppe im AD, die von der WatchGuard abgefragt wird - wer dort drin ist, erhält Zugang, wer nicht, naja.
Again, gern geschehen, viel Erfolg beim durch- und umsetzen.
Gruß
@Roger
Angeregt durch deinen ersten Hinweis (Hostname\Username) habe ich dies überprüft und festgestellt, dass es
tatsächlich so ist.
Über die Console net use L: \\servername\freigabe funktionierte es nicht mit anschließenden Logindaten.
Wenn die Auth.Daten aber mit Domain\User und dann passwort eingegeben werden läuft es auch nach VPN Einwahl.
Die Frage ist nur warum macht Windows so etwas unerwartetes?
Angeregt durch deinen ersten Hinweis (Hostname\Username) habe ich dies überprüft und festgestellt, dass es
tatsächlich so ist.
Über die Console net use L: \\servername\freigabe funktionierte es nicht mit anschließenden Logindaten.
Wenn die Auth.Daten aber mit Domain\User und dann passwort eingegeben werden läuft es auch nach VPN Einwahl.
Die Frage ist nur warum macht Windows so etwas unerwartetes?
Unerwartet, nunja, ich hole da jetzt ein bißchen aus.
Ich bin KEIN Verteidiger eines Betriebssystems, egal aus welcher Ecke es kommt. Es gibt Unterschiede und solange die BS das tun, was ich will ist mir egal welches ich hernehme. Windows hat seine Wurzeln im DOS und das war ein Single-User/Single-Task BS und es hat sich im Laufe der Zeit gewandelt. Aus Kompatibilität behält man schon mal "Altlasten" die dann irgendwann auch abgeschaltet werden.
Gedankensprung: Bei den BS gibt es verschiedene Sicherheitsstufen, C1 C2 ... soweit ich mich entsinnen kann. Darin wird auch geregelt, wie zu protokollieren ist (Wer Wann Wie Worauf zugegriffen hat). Jetzt überlege mal was das in Bezug auf Single-Sign-On heißt...
Auch wenn Du eine Gast-Kennung verwendest um auf eine Resource der Zielmaschine zuzugreifen (selbst wenn es für den Gast vollständig freigeben ist) , ist eine Mitlieferung des Hostnames schon lange überfällig...
Ich würde gerne die Logindaten in ein Batch File testweise eintriggern.
Dies ist jedoch klartext. Würde es anschließend durch tools in eine .exe datei umwandeln.
Wie sieht die Zeile aus (mit Credentials)?
Ohne sieht es bei mir so aus:
%LOGONSERVER%\NETLOGON\ifmember.exe Gruppe
if %errorlevel%==1 (
net use T: \\Servername\Freigabe
)
da muß ich Dich um ein wenig Geduld bitten, ich kann nur soviel sagen, wir haben hier keine Hyper-Super-Hochsicherheitsarchitektur am Start. Das Problem war für mich mit ".... [Passwort] /USER:username" gelöst und ich hab nicht weiter nachgeforscht...
Gruß Roger
Google hat mich hier her geführt:
Ich hatte das gleiche Problem bei einem Kunden und konnte mir auch nicht erklären, wo die Ursache liegt.
Seltsamerweise greift hier IPS, der Intrusion Prevention Service der Watchguard - einfach die Signature ID als Ausnahme hinzufügen und das Verbinden der Netzlaufwerke funktioniert wieder problemlos
Ich hatte das gleiche Problem bei einem Kunden und konnte mir auch nicht erklären, wo die Ursache liegt.
Seltsamerweise greift hier IPS, der Intrusion Prevention Service der Watchguard - einfach die Signature ID als Ausnahme hinzufügen und das Verbinden der Netzlaufwerke funktioniert wieder problemlos
