[English]Noch ein Beitrag der Art "Vorsicht vor Windows 11 und Windows Server 2025" für Administratoren, die mit der Migration liebäugeln. Es gibt wohl ein Problem bei Domain-Controllern auf Windows Server 2025. Windows 11 Clients scheinen nach 30 Tagen die Trust Relationship zu verlieren und bekommen Probleme beim Erneuern von Kennwörtern.
Anzeige
Ein Leserhinweis
Thomas H. hat mich bereits zum 21. Januar 2024 in einer Mail auf die Problematik hingewiesen (danke dafür) und schrieb, dass es ein Problem mit der Trust Relationship von Windows 11 Systemen mit Windows Server 2025 DCs gebe. Computerkennwörter können bei bestimmten Windows 11 Versionen nicht erneuert werden. Sein Hinweis war, das vielleicht hier im Blog kurz aufzugreifen, was ich hiermit nachhole.
Diskussion bei Microsoft
Thomas hat mich in seiner E-Mail auf die Diskussion Server 2025 Domain Controllers – Trust relationship issues on workstations after 30 days as "pwdLastSet" value unable to be updated bei Microsoft Answers hingewiesen.
Der Thread-Ersteller schreibt, dass er vier Domänencontroller in seiner Umgebung betreibt, die bereits auf Windows Server 2025 aktualisiert wurden. Zudem gibt es noch etwas mehr als 30 weitere Domain-Controller, die noch auf Windows Server 2022 laufen. Es scheint also eine größere Umgebung zu sein.
Im Betrieb hat man nun festgestellt, dass die auf Windows Server 2025 umgerüsteten Domain Controller einen Fehler aufweisen. Alle Arbeitsstationen (Clients), die über diese Domain-Controller laufen, sind beim Erreichen der 30-Tage-Grenze nicht mehr in der Lage, ihren pwdLastSet-Wert zu aktualisieren.
Anzeige
Damit geht nach 30 Tagen die Vertrauensbeziehung zur Domäne verloren. Der Administrator fragt, ob es ein bekannter Fehler von Windows Server 2025 sei und ob es bekannte Korrekturen für dieses Problem gebe?
Der betreffende Microsoft Answers-Forenthread umfasst inzwischen bereits fünf Seiten, das Problem wird von vielen Administratoren bestätigt. Allerdings gibt es ein sehr inhomogenes Bild. Während einige Administratoren schreiben, dass Clients mit Windows 11 22H2 und 23H2 betroffen sind, melden andere Nutzer auch Probleme mit Windows Server 2019 und Windows Server 2022 sowie Windows 10 als Client.
Ein Administrator gibt an, dass er mit Windows 11 23H2 oder 24H2 das Problem so löse, dass er das Passwort per PowerShell aktualisieren könne. Im verlinkten Thread finden sich noch weitere Diskussionen und Log-Auszüge. Aktuell sieht es nicht so aus, dass es eine Lösung gibt. Vielleicht mal den betroffenen Tread durchgehen, bevor ihr in die Problematik rauscht.
Anzeige
Mir lag beim letzten Thread (Hello for Business) schon die Frage auf der Zunge, was denn nun genau upgedated wurde. Der Server mit der DC-Rolle – ist klar. Aber wurde auch das Schema der Domain oder sogar der ganze Forest (im vorliegenden Fall ja wohl nicht, wenn noch alte DCs existieren) angehoben und hat ein Wizard irgendwelche Sicherheitseinstellungen verändert?
Darf ich dir gern beantworten.
Wir haben einen DC upgedated und das Problem wie beschrieben nachgestellt. Dann den 2022er entfernt und auch den auf 2025 gebracht + dann forest und domain level auf 2025. Hat alles nicht geholfen.
Es wurden keine Sicherheitseinstellungen verändert.
Das Trust-Relationship Problem trifft uns seit heute zusätzlich. Server2025 hat definitiv ein Problem.
Das "Nicht-Vertrauenswürdig"-Problem kenne ich auch aus dem Arbeitsumfeld, allerdings recht fragmentiert. Auch eine strukturfreudige Umgebung mit mehreren DCs und Clients. Komischerweise verhalten sich nicht alle Clients gleich. Es gibt Win11 24h2-Rechner ohne jedwede Probleme, aber auch mit. Anmelden ohne Netzwerkkabel (auch ohne WLAN) und dann erst verbinden, wenn der Rechner hochgefahren ist, ist hier der Workflow. Übergangsweise. Hoffentlich.
Mir ist in diesem Zusammenhang ein anderer Fehler vor die Augen getreten, den ich vorher noch nie hatte.
Die Fehlermeldung war: "Ihr Kennwort wurde auf einem anderen Gerät geändert. Sie müssen sich mit Ihrem neuen Kennwort einmal bei diesem Gerät anmelden, anschließend können Sie sich mit Ihrer PIN anmelden". Es wurde aber nie ein Kennwort geändert!
Nach einem Reboot der Domaincontroller WS2022 und WS2025 an beiden Standorten sowie des Clients (W11 24H2 LTSC) ging es bis jetzt wieder fehlerfrei!
Eventuell spielt da das oben genannte Problem auch mit rein. Es war auf jeden Fall sehr merkwürdig.
Dachte, ich teile hier mal meine Erkenntnisse zum Thema:
Der Fehler tritt nur mit Windows Server 2025 auf, und nur in Zusammenhang mit Windows 11 23H2. Unter Windows 11 24H2 tritt zwar der Fehler nicht mehr auf, das Feld pwdLastSet am AD-Objekt scheint aber trotzdem nicht aktualisiert zu werden. Hier teste ich aktuell noch mit unterschiedlichen Konfigurationen. Hat Microsoft nur einfach die Fehlermeldung ausgeblendet?
Auf einem betroffenen Domain Controller wird außerdem im Server Manager die Defender Firewall als "Private" angezeigt, und nicht als "Domain", was eigentlich richtig wäre. Das Problem lässt sich lösen, indem man nach dem Reboot eines betroffenen DCs die Netzwerkverbindung kurz trennt. Über PowerShell und einen Geplanten Task "On System Boot" geht das gut.
Weiters bleibt auf einem betroffenen Domain Controller der Dienst "Kerberos Local Key Distribution Center" im Status "Starting" stecken. Auch ein Reboot hilft nicht. Der Dienst reagiert auch auf keinerlei Steueranforderungen. Hierfür habe ich bis dato noch keine Lösung gefunden.
Es kursieren im Internet Lösungsansätze mit dem Setzen von Registry Keys, die funktionieren aber großteils unter Windows Server 2025 nicht mehr und werden ignoriert. Ich habe mir damit einen DC zerschossen, daher eine Warnung vor deren Einsatz.
Ein betroffener Client lässt sich mit dem folgenden Befehl fixen, ohne dass man ihn erneut komplett neu in die Domain joinen muss: Reset-ComputerMachinePassword -Credential InsertDomainAdminCredentialHere
Ich lasse jetzt folgendes Setting über GPO an meine PDCs ausrollen, und hatte das Domain Trust Problem damit in den letzten drei Tagen nicht mehr: Computer Configuration > Policies > Administrative Templates > System > Security Account Manager > Configure SAM change password RPC method policy > Enabled, Allow all change password RPC methods.
Der vorherige Punkt wird auch in den Change Notes von Windows Server 2025 erwähnt, ohne extrem tiefgehendes Wissen zum Active Directory stellt man allerdings kaum einen Zusammenhang zur vorhandenen Problematik her. Ein Test in meiner Laborstellung hat jedoch ergeben, dass Windows 11 23H2 damit jetzt das Maschinenpasswort richtig ins AD zurückschreiben kann.
Administratoren können bis zum Fixen des Bugs das maximale Alter für das Maschinenpasswort auch auf 999 Tage setzen (Default: 30 Tage), schön ist das jedoch nicht und die Änderung ist sicherheitsrelevant.
Das letzte kumulative Update (aktuell: Jänner 2025) hat keine Besserung gebracht.