User hat Windows-Passwort offline geändert-Loginprobleme via VPN
Hallo,
wir verwenden in der Firma eine Watchguard Firebox M270 Firewall. Darüber melden sich die User auch an, wenn sie sich aus dem Homeoffice über VPN einloggen. Das geschieht mittels eines VPN-Tools vom gleichen Hersteller. Dabei gleicht die Firewall ab, ob der User, der sich da gerade per VPN einwählen will, in der Active-Directory-Gruppe "SSL-User" befindet. Wer nicht drin ist, dem wird der Login via VPN verweigert. Sprich: für den Login via VPN werden die gleichen Zugangsdaten benutzt wie für den Login in die Domäne.
Beim Verbindungsaufbau wird dann abgeglichen, ob das zum Login in Windows verwendete Passwort mit dem übereinstimmt, was zum VPN-Aufbau benutzt wurde und dem, das im AD hinterlegt ist.
Nun, wie in vielen Firmen, gibts auch bei uns eine Policy, die die User alle 90 Tage zum Passwortwechsel des Windows-Passworts verdonnert und das auch 7 Tage vorher ankündigt. Die User wurden auch etliche Male ermahnt, dass Windows-Passwort unter keinen Umständen zu ändern, wenn sie sich nicht im LAN direkt in der Firma aufhalten.
Man ahnt vielleicht, was jetzt kommt: Aufforderungen, dass Passwort rechtzeitig zu ändern und das nur zu tun, wenn sie in der Firma im LAN sind, werden fröhlich ignoriert, sondern es wird gewartet, bis das Passwort abgelaufen ist und sie beim Login in Windows zur Änderung verdonnert werden. Dumm halt nur, wenn das passiert,wenn sie sich nicht im Büro aufhalten, sondern am betreffenden Tag Homeoffice machen wollen. Dann kriegt das AD vom geänderten Windows-Passwort nämlich nichts mit, da ja die VPN-Verbindung in die Firma noch nicht besteht. Und dann gibts Probleme beim Aufbau der VPN-Verbindung, weil Windows-Passwort, VPN-Passwort und das im AD hinterlegte Passwort nicht zusammenpassen. Denn kriegt man die Meldung zu sehen,dass die Domäne nicht gefunden werden konnte.
Normalerweise ist die Lösung vergleichsweise einfach: User in die Firma zurückbeordern, im AD das Passwort zurücksetzen, 1x einloggen lassen, danach klappt auch wieder der Zugang via VPN. Hat jemand eine Idee, ob man das auch hinkriegt, ohne die Leute in die Firma zu beordern ? Natürlich haben wir schon ausprobiert, ob es was bringt, wenn man sich von den Usern das neue Passwort geben lässt und das im AD hinterlegte Passwort darauf ändert, aber das brachte auch keinen Erfolg.
Ach ja: Als Serverbetriebssystem kommt Windows Server 2016 zum Einsatz.
wir verwenden in der Firma eine Watchguard Firebox M270 Firewall. Darüber melden sich die User auch an, wenn sie sich aus dem Homeoffice über VPN einloggen. Das geschieht mittels eines VPN-Tools vom gleichen Hersteller. Dabei gleicht die Firewall ab, ob der User, der sich da gerade per VPN einwählen will, in der Active-Directory-Gruppe "SSL-User" befindet. Wer nicht drin ist, dem wird der Login via VPN verweigert. Sprich: für den Login via VPN werden die gleichen Zugangsdaten benutzt wie für den Login in die Domäne.
Beim Verbindungsaufbau wird dann abgeglichen, ob das zum Login in Windows verwendete Passwort mit dem übereinstimmt, was zum VPN-Aufbau benutzt wurde und dem, das im AD hinterlegt ist.
Nun, wie in vielen Firmen, gibts auch bei uns eine Policy, die die User alle 90 Tage zum Passwortwechsel des Windows-Passworts verdonnert und das auch 7 Tage vorher ankündigt. Die User wurden auch etliche Male ermahnt, dass Windows-Passwort unter keinen Umständen zu ändern, wenn sie sich nicht im LAN direkt in der Firma aufhalten.
Man ahnt vielleicht, was jetzt kommt: Aufforderungen, dass Passwort rechtzeitig zu ändern und das nur zu tun, wenn sie in der Firma im LAN sind, werden fröhlich ignoriert, sondern es wird gewartet, bis das Passwort abgelaufen ist und sie beim Login in Windows zur Änderung verdonnert werden. Dumm halt nur, wenn das passiert,wenn sie sich nicht im Büro aufhalten, sondern am betreffenden Tag Homeoffice machen wollen. Dann kriegt das AD vom geänderten Windows-Passwort nämlich nichts mit, da ja die VPN-Verbindung in die Firma noch nicht besteht. Und dann gibts Probleme beim Aufbau der VPN-Verbindung, weil Windows-Passwort, VPN-Passwort und das im AD hinterlegte Passwort nicht zusammenpassen. Denn kriegt man die Meldung zu sehen,dass die Domäne nicht gefunden werden konnte.
Normalerweise ist die Lösung vergleichsweise einfach: User in die Firma zurückbeordern, im AD das Passwort zurücksetzen, 1x einloggen lassen, danach klappt auch wieder der Zugang via VPN. Hat jemand eine Idee, ob man das auch hinkriegt, ohne die Leute in die Firma zu beordern ? Natürlich haben wir schon ausprobiert, ob es was bringt, wenn man sich von den Usern das neue Passwort geben lässt und das im AD hinterlegte Passwort darauf ändert, aber das brachte auch keinen Erfolg.
Ach ja: Als Serverbetriebssystem kommt Windows Server 2016 zum Einsatz.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7658296375
Url: https://administrator.de/forum/user-hat-windows-passwort-offline-geaendert-loginprobleme-via-vpn-7658296375.html
Ausgedruckt am: 16.05.2025 um 17:05 Uhr
13 Kommentare
Neuester Kommentar
Hi,
ich verstehe das Problem ehrlichgesagt nicht wirklich.
Wenn die Leute zu Hause sind und nicht per VPN verbunden, dann kommt die Aufforderung auch nicht (wie auch, die Aufforderung zum PW ändern kommt vom DC, nicht vom Client).
Sollte die Leute per VPN verbunden sein und das PW ändern, dann bekommt das der Client auch mit.
Was bei uns schon vorkommt: Passwort ist abgelaufen, und man kann sich deshalb per VPN nicht mehr verbinden, denn der User steht auf "muss PW beim nächsten Login ändern".
Auch wir nutzen Watchguard, hier wird Username und PW aber bei jeder VPN Einwahl abgefragt.
Lösung:
- Anmelden am Computer mit dem "alten" Passwort
- über office.com das Windows-PW ändern
- VPN mit Watchguard aufbauen (mit dem jetzt "neuen" PW)
-> VPN steht -> Computer sperren über Windows + L -> mit neuem PW anmelden. Fertig.
Klappt natürlich nur bei einer Azure-Hybrid-Stellung.
ich verstehe das Problem ehrlichgesagt nicht wirklich.
Wenn die Leute zu Hause sind und nicht per VPN verbunden, dann kommt die Aufforderung auch nicht (wie auch, die Aufforderung zum PW ändern kommt vom DC, nicht vom Client).
Sollte die Leute per VPN verbunden sein und das PW ändern, dann bekommt das der Client auch mit.
Was bei uns schon vorkommt: Passwort ist abgelaufen, und man kann sich deshalb per VPN nicht mehr verbinden, denn der User steht auf "muss PW beim nächsten Login ändern".
Auch wir nutzen Watchguard, hier wird Username und PW aber bei jeder VPN Einwahl abgefragt.
Lösung:
- Anmelden am Computer mit dem "alten" Passwort
- über office.com das Windows-PW ändern
- VPN mit Watchguard aufbauen (mit dem jetzt "neuen" PW)
-> VPN steht -> Computer sperren über Windows + L -> mit neuem PW anmelden. Fertig.
Klappt natürlich nur bei einer Azure-Hybrid-Stellung.
Moin,
@Starmanager
Gruß,
Dani
Natürlich haben wir schon ausprobiert, ob es was bringt, wenn man sich von den Usern das neue Passwort geben lässt und das im AD hinterlegte Passwort darauf ändert, aber das brachte auch keinen Erfolg.
nicht zu glauben...Hat jemand eine Idee, ob man das auch hinkriegt, ohne die Leute in die Firma zu beordern ?
Eine Art Notfall Profil im VPN Client einrichten. Über den IT Helpdesk werden temporär, einmalig Zugangsdaten erzeugt und dem Mitarbeiter telefonisch mitgeteilt. Danach erfolgt an einem RDS Host, ADFS Passwort Reset, etc. durch den Mitarbeiter die Änderung des Passworts. Danach werden die Zugangsdaten für Notfall VPN gelöscht. Abschließend kann sich der Nutzer wieder regulär anmelden.@Starmanager
Die 90 Tage Regelung ausschalten. Macht laut Microsoft sowieso keinen Sinn mehr.
Nur gut, dass Microsoft die Regeln macht und die Rahmenbedingungen in den Unternehmen umfangreich kennen. Bei solchen Sätzen bekomme ich Ausschlag.Gruß,
Dani
Hallo,
das kennen wir auch und die Lösung ist:
1) Als Admin im AD das Kennwort ändern, ohne den Punkt "bei der nächsten Anmeldung ändern"
2) Dem Benutzer dieses temporäre Kennwort sagen, er soll sich damit anmelden am VPN
3) VPN wird aufgebaut und User hat Domänenverbindung
4) je nachdem wie ihr arbeitet und Notebook lokal, RDP oder Citrix: Bildschirm sperren
5) Admin ändert wieder im AD des Kennwort auf das gleiche Kennwort wie in Schritt 1, aber mit dem Punkt "bei der nächsten Anmeldung ändern"
6) ca. 10 Sekunden warten, Bildschirm weiterhin gesperrt
7) Bildschirm wieder entsperren mit Kennwort aus 5 und der User gibt sich ein neues Kennwort, fertig
Und ja, 90 Tage sind vorbei, lieber ein längere Kennwort mit Sonderzeichen und/oder 2FA, und dafür länger gültig.
Viele Grüße
Deepsys
das kennen wir auch und die Lösung ist:
1) Als Admin im AD das Kennwort ändern, ohne den Punkt "bei der nächsten Anmeldung ändern"
2) Dem Benutzer dieses temporäre Kennwort sagen, er soll sich damit anmelden am VPN
3) VPN wird aufgebaut und User hat Domänenverbindung
4) je nachdem wie ihr arbeitet und Notebook lokal, RDP oder Citrix: Bildschirm sperren
5) Admin ändert wieder im AD des Kennwort auf das gleiche Kennwort wie in Schritt 1, aber mit dem Punkt "bei der nächsten Anmeldung ändern"
6) ca. 10 Sekunden warten, Bildschirm weiterhin gesperrt
7) Bildschirm wieder entsperren mit Kennwort aus 5 und der User gibt sich ein neues Kennwort, fertig
Und ja, 90 Tage sind vorbei, lieber ein längere Kennwort mit Sonderzeichen und/oder 2FA, und dafür länger gültig.
Viele Grüße
Deepsys
Moin,
bin komplett bei @Deepsys.
Außerdem sollte der WA Login noch mit dem alten Kennwort funktionieren. Ggf. Muss der User es danach erneut ändern. Ich weiß gerade nicht ob der Client Sync zum AD ausreicht.
Die Lösung von WA ist da eine Eigenentwicklung und macht nichts als einen Abglich zum DC per Agent.
Allseits bekanntes Verfahren bei AD Auth für VPN.
Gruß
Spirit
bin komplett bei @Deepsys.
Außerdem sollte der WA Login noch mit dem alten Kennwort funktionieren. Ggf. Muss der User es danach erneut ändern. Ich weiß gerade nicht ob der Client Sync zum AD ausreicht.
Die Lösung von WA ist da eine Eigenentwicklung und macht nichts als einen Abglich zum DC per Agent.
Allseits bekanntes Verfahren bei AD Auth für VPN.
Gruß
Spirit
Moin,
sowas passiert eigentlich nur, wenn Mitarbeiter*innen die Windows-Erinnerungen zum Ändern des Passwortes ignorieren.
Würden Sie dem Folge leisten und bei eingeschaltetem VPN das Passwort ändern, gäbe es das Problem nicht.
Also Arbeitsanweisung erstellen lassen und die Änderung erzwingen.
Gruß
Looser
sowas passiert eigentlich nur, wenn Mitarbeiter*innen die Windows-Erinnerungen zum Ändern des Passwortes ignorieren.
Würden Sie dem Folge leisten und bei eingeschaltetem VPN das Passwort ändern, gäbe es das Problem nicht.
Also Arbeitsanweisung erstellen lassen und die Änderung erzwingen.
Gruß
Looser
sowas passiert eigentlich nur, wenn Mitarbeiter*innen die Windows-Erinnerungen zum Ändern des Passwortes ignorieren.
Würden Sie dem Folge leisten und bei eingeschaltetem VPN das Passwort ändern, gäbe es das Problem nicht.
Würden Sie dem Folge leisten und bei eingeschaltetem VPN das Passwort ändern, gäbe es das Problem nicht.
Naja oder man ist in der Zeit, in der die Erinnerung käme, z.B. krank. Mal ne Woche oder sogar 2 krank zu sein ist gerade im Herbst nicht ungewöhnlich.
Da hilft einem die Arbeitsanweisung wenig.
Zitat von @DerWoWusste:
Man kann keine Domänenpasswörter offline ändern und es kommen auch keine Aufforderungen, dies zu tun, wenn man offline ist. Ein abgelaufenes Kennwort kann offline weiterbenutzt werden, bis man wieder im Büro ist.
Man kann keine Domänenpasswörter offline ändern und es kommen auch keine Aufforderungen, dies zu tun, wenn man offline ist. Ein abgelaufenes Kennwort kann offline weiterbenutzt werden, bis man wieder im Büro ist.
Das ist schon klar, aber die Einwahl ins VPN ist nicht mehr möglich, wenn auf dem DC der Account auf "Muss Kennwort beim nächsten Anmelden ändern" steht.
Wenn das Büro 800km entfernt ist, kann das schon lästig sein nur deshalb hinfahren zu müssen.
Es macht also schon Sinn, für solche Fälle einen Plan zu haben, wie den oben schön Beschriebenen User hat Windows-Passwort offline geändert-Loginprobleme via VPN
also AlwaysOn VPN ist eine Sicherheitslücke von Scheunentorgröße, da die Variante für VPN mit einem Zertifikat authorisiert wird und dann jeden ins Kern-Netzwerk reinläßt, der sich am Endgerät anmelden kann. Wir hatten das mal 2 Stunden aktiv, als unsere Rechner mitten in einem Lockdown in eine neue Domäne umgehängt werden sollten. Bei den gescheiterten Umstellungsversuchen half noch ein lokales Konto, mit dem man das zu frün deaktivierte bzw nicht installierte Always On noch mal einschalten konnte. Nach diesem Domänenumzug wurde das auch serverseitig wieder deaktiviert.
Wer da aber NACH der Pandemie reingerasselt ist - der muß ins Büro und mit einem vom Admin vergebenen Initialpassword für das eigene Konto sich ein neues Kennwort anlegen, weil sich die VPN Infrastruktur halt mit dem AD synchronisiert und nicht umgekehrt. Kann Pulse Secure nicht. Pech gehabt. Sorry. Und beim nächsten Mal ein Tag Gehaltsabzug. Für die die unbelehrbar sind und einen Tag nicht arbeiten konnten deshalb.
Stand jedenfalls in einer Mail unseres Managements drin, es gab nämlich eindeutige Anweisungen, daß das Kennwort ENTWEDER bei bestehender Verbindung ODER auf einer Selfservice Webseite geändert werden muß... das kann man z.B. im IIS bzw Web-Gateway von den Terminalservices einrichten.
Sorry aber ohne ein wenig Disziplin gehen solche Arbeitsmodelle nicht. Ich selbst bin teilweise in so einer Situation, 350 km vom HQ entfernt dem ich zugeordnet bin, da paßt man halt auf.
Wer da aber NACH der Pandemie reingerasselt ist - der muß ins Büro und mit einem vom Admin vergebenen Initialpassword für das eigene Konto sich ein neues Kennwort anlegen, weil sich die VPN Infrastruktur halt mit dem AD synchronisiert und nicht umgekehrt. Kann Pulse Secure nicht. Pech gehabt. Sorry. Und beim nächsten Mal ein Tag Gehaltsabzug. Für die die unbelehrbar sind und einen Tag nicht arbeiten konnten deshalb.
Stand jedenfalls in einer Mail unseres Managements drin, es gab nämlich eindeutige Anweisungen, daß das Kennwort ENTWEDER bei bestehender Verbindung ODER auf einer Selfservice Webseite geändert werden muß... das kann man z.B. im IIS bzw Web-Gateway von den Terminalservices einrichten.
Sorry aber ohne ein wenig Disziplin gehen solche Arbeitsmodelle nicht. Ich selbst bin teilweise in so einer Situation, 350 km vom HQ entfernt dem ich zugeordnet bin, da paßt man halt auf.