gpupdate funktioniert nur zum Teil bei VPN Benutzung

AAAA-Familie

Cadet 1st Year
Registriert
Apr. 2024
Beiträge
8
Moin Moin,

ich bin über ein kleines Problem gestolpert und komme gerade nicht weiter.
Nach einem Jahr müssen bei uns die Benutzer das Domain PW abändern.

Benutzer, die per im HO per VPN verbunden sind können jedoch das PW nicht abändern.
Das neue PW wird nicht auf die Clients aufgespielt.

gpupdate /force funktioniert nur zum Teil:
Die Aktualisierung der Computerrichtlinie wurde erfolgreich abgeschlossen.
Die Benutzerrichtlinie konnte nicht erfolgreich aktualisiert werden. Folgende Probleme sind aufgetreten:

Fehler bei der Verarbeitung der Gruppenrichtlinie. Es wurde versucht, neue Gruppenrichtlinieneinstellungen für diesen Benutzer oder Computer abzurufen. Den Fehlercode und eine Beschreibung finden Sie auf der Registerkarte "Details". Dieser Vorgang wird automatisch beim nächsten Aktualisierungszyklus wiederholt. Computer, die der Domäne beigetreten sind, müssen über eine geeignete Namensauflösung sowie über eine Netzwerkverbindung zu einem Domänencontroller zum Ermitteln von neuen Gruppenrichtlinienobjekten und -einstellungen verfügen. Wenn die Gruppenrichtlinie erfolgreich ist, wird ein Ereignis protokolliert.

Lesen Sie zur Fehlerdiagnose das Ereignisprotokoll, oder führen Sie den Befehl "GPRESULT /H GPReport.html" aus, um auf Informationen über Gruppenrichtlinienergebnisse zuzugreifen.


Wenn die Geräte in der Firma sind läuft gpupdate /force ohne Probleme durch.

Das PW wird auf die Clients wohl erst bei einem erfolgreichen Update von Benutzerrichtlinie gesetzt?
Was könnte das Problem sein?
VPN ist aufgebaut und ich sehe keine geblockten Pakete in beide Richtungen zwischen Client im VPN und DC

DC läuft auf einem Server 2022 (AD Version 2016 natürlich)
Clients sind neue Windows 10 und oder Windows 11 Geräte.

Was kann ich euch noch an Infos geben, damit mir geholfen wird?

Danke schon mal für die Hilfe.
 
AAAA-Familie schrieb:
Lesen Sie zur Fehlerdiagnose das Ereignisprotokoll, oder führen Sie den Befehl "GPRESULT /H GPReport.html" aus, um auf Informationen über Gruppenrichtlinienergebnisse zuzugreifen.
Hast du das denn schonmal gemacht?
Und ist der Logonserver auf den Clients korrekt?
 
  • Gefällt mir
Reaktionen: nutrix
AAAA-Familie schrieb:
Wenn die Geräte in der Firma sind läuft gpupdate /force ohne Probleme durch.
Das ist klar, weil sich die Geräte im Netzwerk gleich in der richtigen Domäne befinden, und sie dort korrekt registriert werden, da kann sich das lokale Profil brav mit dem AD/Exchange abgleichen.

Aber nochmals nachgefragt, bei einer laufenden VPN Verbindung kann das PW nicht geändert werden? Was kommt da bitte als Fehler beim Client? Was sagt hier die Ereignisanzeige? Oder wars vielleicht doch so, daß die Leute zuerst ihr PW änderten, und dann sich versuchten per VPN anzuwählen? Das passiert so eher, weil die Richtlinien einen am letzten Tag bei Ablaufen der Änderungszeit ein PW-Wechsel sofort erzwingen, auch beim Start des Gerätes, wo es noch nicht per VPN verbunden ist.
 
  • Gefällt mir
Reaktionen: Yesman9277
Ja, ich mein Fehler 1030 war da. so wirklich weiter gebracht hat mich das nicht.
Den genauen Auszug habe ich gerade nicht zur Hand. müsste ich gleich mal mit meinem Gerät reproduzieren. (Hotspot usw... bin gerade in der Firma)

Ich poste das Ergebnis, sobald ich es habe.
Muss für heute Schluss machen. Familie ruft. Morgen mehr. Vielen Dank schon mal für die ersten Reaktionen.
Ergänzung ()

nutrix schrieb:
Das ist klar, weil sich die Geräte im Netzwerk gleich in der richtigen Domäne befinden, und sie dort korrekt registriert werden, da kann sich das lokale Profil brav mit dem AD/Exchange abgleichen.

Aber nochmals nachgefragt, bei einer laufenden VPN Verbindung kann das PW nicht geändert werden? Was kommt da bitte als Fehler beim Client? Was sagt hier die Ereignisanzeige? Oder wars vielleicht doch so, daß die Leute zuerst ihr PW änderten, und dann sich versuchten per VPN anzuwählen? Das passiert so eher, weil die Richtlinien einen am letzten Tag bei Ablaufen der Änderungszeit ein PW-Wechsel sofort erzwingen, auch beim Start des Gerätes, wo es noch nicht per VPN verbunden ist.

habe jetzt noch nicht genau rausgefunden was und wie das gekommen ist.
Thema ist hier noch relativ neu.
Beim letzten Benutzer habe ich das AD PW manuell zurückgesetzt.
mit dem neuen PW konnte er sich auch per VPN (AD Sync) verbinden.
Als er Verbunden war, wollte ich durch gpupdate manuell das PW auf seinen Client nachladen, dass auch der PW beim Anmelden das neue PW hat. das hat aber wohl nicht geklappt.
Frage an sich selbst: Weil der Client den DC mit dem altem PW, der noch auf dem Client gespeichert ist, versucht zu melden, der DC aber schon das neue PW hat?

mich wundert es halt warum das eine aktualisiert wurde aber das andere nicht:

Die Aktualisierung der Computerrichtlinie wurde erfolgreich abgeschlossen.
Die Benutzerrichtlinie konnte nicht erfolgreich aktualisiert werden.
 
Zuletzt bearbeitet:
Das Kennwort hat nichts mit den Benutzerrichtlinien zu tun. Da bringt dich gpupdate nicht weiter.
Das Kennwort wird lokal gecached bei erfolgreicher Anmeldung an der Domäne.
Wenn du das Kennwort für die User änderst kommt diese Änderung nie am Client an ausser er hat eine Verbindung zum DC vor der Anmeldung.
Dazu ist es erfoderlich, dass die VPN Verbindung aufgebaut wird bevor sich die User anmelden.
 
  • Gefällt mir
Reaktionen: AAAA-Familie, Yesman9277, nutrix und eine weitere Person
Wie mein Kollegen oben richtig sagte. Das AD-Profil mit PW wird lokal gespeichert, und in der Dömäne. Es greift immer zuerst das lokale PW, wenn Du Dich nicht in der Domäne befindest. Wenn das lokale Profil vom dem in AD abweicht, kommt es zum obigen Fehlerbild.

Dann hilft hier nur, Rechner im lokalen Netzwerk:
  1. Rechner als Admin aus der Domäne nehmen, so daß das lokale AD Profil nicht mehr gilt, sondern das lokale Profil ohne AD
  2. In der AD PW neu vergeben und mit PW-Änderung erzwingen Haken setzen
  3. Neu starten
  4. Normal anmelden
  5. Rechner als Admin wieder in die Domäne aufnehmen
  6. Dann mit neuem PW bei der Domäne anmelden
    1. Erst jetzt wird wieder das Profil abgeglichen
  7. PW neu setzen
Als Notlösung einen Admin User setzten, der per Remotetool wie Teamviewer und Co. sich immer einklinken kann, dann kannst Du das auch von der Ferne machen. Sprich, Du startest dann als Remoteadmin immer vorher das VPN, und gehst genau so alle Punkte durch!
 
  • Gefällt mir
Reaktionen: AAAA-Familie und Yesman9277
OK, das ist zwar nicht so schön wie erhofft, aber wenn es hierzu sonst keine andere Lösung gibt dann muss ich das wohl so akzeptieren.
In dem Fall warte ich glaube ich bis der Benutzer in den nächsten Wochen einfach mal in der Firma ist. Dann synct sich das ja wieder zurecht.

Wie kann man so etwas vermeiden?
Hilft es, wenn die Benutzer rechtzeitig ihr PW ändern? also 1-2 Wochen vor dem Ablauf. Wird die Änderung lokal vom PC der im VPN ist an das AD gespielt?

VPN vor der Einwahl des Benutzers wollte ich eigentlich nicht einrichten, wäre sicher temporär auch eine Möglichkeit.
 
Wie gesagt, Du mußt mal prüfen, warum trotz VPN vom HO sich das Profil im AD nicht synct, sprich, ob die Abläufe eingehalten werden.
Ergänzung ()

AAAA-Familie schrieb:
In dem Fall warte ich glaube ich bis der Benutzer in den nächsten Wochen einfach mal in der Firma ist. Dann synct sich das ja wieder zurecht.
Nein, da muß ein AD Admin wieder ran, wenn die Kennwörter abweichen
AAAA-Familie schrieb:
Wie kann man so etwas vermeiden?
Mir nicht bekannt, außer rechtzeitig im internen Netz oder per VPN das Kennwort ändern.
AAAA-Familie schrieb:
Hilft es, wenn die Benutzer rechtzeitig ihr PW ändern? also 1-2 Wochen vor dem Ablauf.
Natürlich.
AAAA-Familie schrieb:
Wird die Änderung lokal vom PC der im VPN ist an das AD gespielt?
Nein, anders. Kennwortänderungen gehen - soweit mir bekannt - bei einer bestehenden AD-Verbindung intern im Firmennetz oder per VPN, zuerst an den AD, der das dann wieder auf das Notebook synct, nicht umgekehrt.
 
  • Gefällt mir
Reaktionen: AAAA-Familie
AAAA-Familie schrieb:
Wie kann man so etwas vermeiden?
Ich würde die Passwortwechsel-Richtlinie rausschmeißen. Das sollte doch jetzt wirklich langsam mal überall angekommen sein, dass das kontraproduktiv ist. Besser ist es, eine Mindestlänge von 16 Zeichen vorzugeben (+ evt. auch die Komplexität).
 
Sehe ich nicht ganz so.
Ein mal im Jahr ist es ok.

2FA oder SSO kommt in den nächsten Monaten bei nahezu allen Sachen dazu.
Da kann man das überlegen. Solange es aber nicht etabliert ist bei uns können die ruhig mal das wechseln.
Komplex und lang ist es jetzt schon.
 
nubi80 schrieb:
Das Kennwort hat nichts mit den Benutzerrichtlinien zu tun. Da bringt dich gpupdate nicht weiter.
Das Kennwort wird lokal gecached bei erfolgreicher Anmeldung an der Domäne.
Wenn du das Kennwort für die User änderst kommt diese Änderung nie am Client an ausser er hat eine Verbindung zum DC vor der Anmeldung.
Dazu ist es erfoderlich, dass die VPN Verbindung aufgebaut wird bevor sich die User anmelden.
mal was interessantes was ich aber noch nicht überprüfen konnte.

Heute früh hat sich der Mitarbeiter im HO, der per VPN verbunden ist berichtet, dass sein PW sich nun aktualisiert hat. Nach einer langer Zeit verbunden sein im VPN.

kann das hinkommen? Erzählt er stuss?
Wie gesagt, ich konnte seine Aussage noch nicht überprüfen.
Ergänzung ()

Und noch was anderes.

Wenn man im AD das PW zurücksetzt als Admin auf das letzte, was der PC auch kennt.
Wären die dann wieder Synchron, zwischen PC und AD? Oder gäbe es da ein Hash gap?

Wenn das PW dann aktuell wäre, könnte man es dann über VPN auf ein neues setzen.
 
Zuletzt bearbeitet:
die Passwortprüfung vom Client zum DC erfolgt ausschließlich bei Anmeldungen.
Wenn sich der User anmeldet ohne Verbindung zum DC wird das zwischengespeicherter Kennwort des Domänenkontos auf dem Client verwendet.
Stellt er nun im Nachgang eine VPN Verbindung her und etabliert damit eine Verbindung zu DNS und Domäne wird dieser "Zwischenspeicher" nicht aktualisiert.
Die VPN Verbindung müsste vor der Benutzeranmeldung aufgebaut werden. Dann ist sowohl die Abarbeitung von GPOs bei Anmeldung als auch die Kennwortprüfung zum AD möglich.

Dennoch haben GPOs keinerlei Einfluss darauf.
Du könntest alle GPOs entfernen und trotzdem müsste der Mechanismus der Anmeldung und Kennwortänderung funktionieren.
Ergänzung ()

AAAA-Familie schrieb:
Und noch was anderes.

Wenn man im AD das PW zurücksetzt als Admin auf das letzte, was der PC auch kennt.
Wären die dann wieder Synchron, zwischen PC und AD? Oder gäbe es da ein Hash gap?

Ja das würde funktionieren.
 
  • Gefällt mir
Reaktionen: nutrix
nubi80 schrieb:
Ja das würde funktionieren.
dann ist das glaube die einfachste Lösung.

Trotzdem seltsam, was der Mitarbeiter berichtet hat, dass sich das PW auf dem Gerät im HO sich wohl mit dem AD synchronisiert hat. Solange ich es selbst nicht geprüft habe, glaube ich aber erstmal deiner Aussage ;)
 
Was ich mir noch vorstellen könnte ist, wenn die Passwortprüfung vom Client zum DC nur bei Anmeldungen erfolgt, was passiert, wenn sich der PC sperrt und der VPN-Dienst im Hintergrund weiterläuft. Man ist also gezwungen sich bei aktiver VPN Verbindung neu am PC anzumelden. Würde mich aber auch wundern.

Bei uns müssen die Anwender für den Sync auch in's Büro - oder halt damit Leben zwei Kennwörter zu nutzen.
 
Nein, VPN und Anmeldung an die AD sind 2 verschiedene Dinge.

Nochmals. Die Anmeldung erfolgt, wenn kein AD da ist, immer über das lokale Profil. Sobald die VPN Verbindung aufgebaut wird, und das VPN für die Authentifizierung das AD nutzt, wird das im AD hinterlegte verwendet. Und hier fängt es an, problematisch zu werden, weil der AD dann merkt, daß das lokale Profil bzw. Kennwort von dem abweicht, und damit "die Vertrauensstellung" fehlt. Lösungen habe ich oben schon genannt, oder man entkoppelt die VPN-Verbindung mit Authentifizierung vom AD, z.B. über anderes PW separat für VPN, externe Schlüssel wie Yubikey und Co., oder 2/MFA.
 
Hi,

das Kennwort sollte aber bei aktiver VPN Verbindung mit dem AD gesynct werden, wen der Rechner gesperrt und wieder entsperrt wird.
 
  • Gefällt mir
Reaktionen: Ja_Ge
Ja als Endanwender natürlich nicht, das ist schon klar. Mir gings nur darum, dass OpenVPN in den meisten Konfigurationen kein AD für eine Authentifizierung nutzt (kann man natürlich trotzdem über LDAP realisieren, wenn man will).
 
ob OpenVPN oder der VPN Client von Sophos der auch auf die OpenVPN basiert (soweit ich weiß) ist egal.
Ich kann ja bei Sophos auch die Leute mit einem lokalen Account sich mit VPN verbinden lassen.
das löst aber trotzdem das Problem nicht, dass der Benutzer vor der VPN Verbindung am PC anmeldet.
weit gesponnen aber was noch gehen würde, dass ich dem Benutzer ein Sophos RED Gerät nach Hause gebe. Das stellt eine VPN Verbindung von alleine auf hinter der z.B. FritzBox. und der Benutzer sich so schon in ein VPN Netz einwählt.
Da ist es aber einfacher, dass der Benutzer mit seinem Gerät mal sich in der IT am Standort meldet.
 
Zurück
Oben