Windows 10 20H2: Zerschießt das Jan. 2022-Update den AGPM-Server?

[English]Kurze Frage in die Runde der Windows-Administratoren, die Microsofts Advanced Group Policy Management (AGPM) einsetzen. Gibt es seit dem Update vom 11. Januar 2022 Probleme, den AGPM-Server zu erreichen? Mir liegt eine entsprechende Nutzermeldung vor, die ich hier im Blog mal zur Information einstelle. Bei einer Suche habe ich derzeit nicht gefunden – und es könnte sein, dass die Korrekturupdates vom 17.1.2022 das gefixt haben. Ergänzung: Es gibt eine Lösung, und Microsoft hat das dokumentiert.

Eine Nutzermeldung für Windows 10 20H2

Blog-Leser Markus K. verwendet AGPM in einer größeren Netzwerkumgebung im universitären Umfeld und hat mich bereits zum 13.1.2022 per Mail über ein Problem informiert, welches er auf der patchmanagement.org Mailing-Liste unter dem Titel AGPM client fails to connect with 2022-01 CU eingestellt hat. Dort schrieb er:

Dear all,

just a heads up cause it might concern you.

We have a 20H2 machine with an AGPM client installed.
After installing 2022-01 CU the connection to the AGPM server failed.
After uninstalling the patch the connection to the server works again.
The 2019 server has the 2022-01 CU installed though.

The error on the clients log:
2022-01-13 10:21:23:1869726 [pid=8016,tid=3] [Error] Error in AgpmClient.Reconnect() System.ServiceModel.Security.SecurityNegotiationException: Either the target name is incorrect or the server has rejected the client credentials. —> System.Security.Authentication.InvalidCredentialException: Either the target name is incorrect or the server has rejected the client credentials. —> System.ComponentModel.Win32Exception: The logon attempt failed
— End of inner exception stack trace —
at System.Net.Security.NegoState.ProcessAuthentication(LazyAsyncResult lazyResult)
at System.Net.Security.NegotiateStream.AuthenticateAsClient(NetworkCredential credential, String targetName, ProtectionLevel requiredProtectionLevel, TokenImpersonationLevel allowedImpersonationLevel)
at System.ServiceModel.Channels.WindowsStreamSecurityUpgradeProvider.WindowsStreamSecurityUpgradeInitiator.OnInitiateUpgrade(Stream stream, SecurityMessageProperty& remoteSecurity)
— End of inner exception stack trace —

Seems the patch breaks the auth process. Not much we can do except waiting for a fix I guess.

In der Diskussion stellte sich aber heraus, dass auf der Liste kaum jemand AGPM nutzt und andere auch nicht betroffen sind. Einen Troubleshooting-Artikel zu AGPM gibt es hier. Wie ich obige Diskussion aber verstehe, hat Markus K. bei seiner Meldung nichts gefunden, was das Problem der fehlenden Server-Verbindung behoben hat. Bleibt die Frage, ob zufällig jemand diesen Fehler festgestellt hat? Oder ist der Bug durch die Sonderupdates vom 17.1.2022 behoben worden?

Ergänzung: Markus K. hat mir inzwischen folgendes geantwortet:

Guten Morgen,
wir öffnen ein Ticket bei MS.

Habe eine VM erstellt Build 19042.508, via gpedit.msc "Specify settings for optional component installation and component repair" mit Option "Download repair content and optional featuresdirectly from Windows Update instead of Windows Server Update Service (WSUS)" gesetzt,
"Windows Communication Foundation Non-HTTP Activation installiert (feature), RSAT.GPMC installiert, agpm_403_client.exe installiert.

19042.508 + AGPM funktioniert.
19042.1415 und danach auch noch 2022-01 .NET Framework patch installiert => AGPM funktioniert.

Da gibts sonst nichts das irgendwie fancy wäre auf der Maschine.

2022-01 KB5010793 CU installiert und man bekommt folgenden Fehler in der MMC:

AGPM-Fehler

---

Anzeige

---

Alle Schritte wurden mit einem frisch installierten 20H2 in einer VM mit Snapshots abgebildet.
Man kann also vor und zurück steigen und zuschauen wie das ganze kaputt wird.
Aus dem Log das generiert wird lese ich ein Auth Problem heraus. Events etc., oder andere Hinweise habe ich bislang keine gefunden.
Der AGPM-Server ist ein Server 2019 und ist aktuell auch mit dem letzten gefixten Jänner CU ausgestattet.
Das Problem begann jedenfalls mit dem originalen Jänner Patchday CU.
Ich kann nur vermuten, dass da am irgendwas scharf wird was Auth betrifft und sobald beide am selben Patchlevel sind greift und AGPM abschießt.
Auf der NTSysadmin Liste habe ich jemanden gefunden, der zwar den Client auf das 2022-01 CU gepatcht aber den Server noch nicht, das dauert noch meinte er, bei dem funktioniert AGPM noch.

Manchmal frage ich mich schon, ob wir immer die einzigen oder ersten sind :).
Kostet halt immer Zeit, Nerven schlaflose Nächte.
Ist ja nicht so, dass AGPM um ~1000 GPOs zu verwalten nutzlos wäre…

Dem ist wenig hinzuzufügen.

Was ist AGPM?

Kurz für die Leute (wie mir), denen AGPM nichts sagt. Das Kürzel AGPM steht für Microsofts Advanced Group Policy Management. Laut diesem  Microsoft-Dokument erweitert das Microsoft Advanced Group Policy Management (AGPM) die Funktionen der Gruppenrichtlinien-Verwaltungskonsole (Group Policy Management Console, GPMC). Es wird eine umfassende Änderungssteuerung und verbesserte Verwaltung für Gruppenrichtlinienobjekte (Group Policy Objects, GPOs) bereitgestellt. AGPM steht im Rahmen des Microsoft Desktop Optimization Pack (MDOP) für Software Assurance zur Verfügung. Dabei gibt es mehrere Versionen:

• AGPM 4,0 SP3 unterstützt Windows 10, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 8,1, Windows Server 2012, Windows Server 2008 R2, Windows 7, Windows Server 2008 und Windows Vista mit SP1.
• AGPM 4,0 SP2 unterstützt Windows Server 2012 R2, Windows 8,1, Windows Server 2012, Windows Server 2008 R2, Windows 7, Windows Server 2008 und Windows Vista mit SP1.
• AGPM 4,0 SP1 unterstützt Windows Server 2012, Windows Server 2008 R2, Windows 7, Windows Server 2008 und Windows Vista mit SP1.
• AGPM 4 unterstützt Windows Server 2008 R2, Windows 7, Windows Server 2008 und Windows Vista mit SP1.
• AGPM 3 unterstützt Windows Server 2008 und Windows Vista mit SP1.
• AGPM 2,5 unterstützt Windows Vista (32-Bit) ohne Service Pack und Windows Server 2003 (32-Bit).

Relevant dürften nur noch Versionen ab 4 sein.

Die Lösung Microsofts

Ergänzung: Blog-Leser Markus K. hat sich zum 25. Februar 2022 nochmals per E-Mail bei mir gemeldet und schrieb:

Hallo,

Problem selber gelöst, weil das Ticket bei MS eine Farce ist.
Ein paar Leute auf der NTSysadmin Liste dürfte das auch freuen, da sie auch betroffen sind.

Wir hatten die IP des AGPM-Servers eingetragen. Split-DNS liefert somit einen FQDN außerhalb der Domäne. Kerberos funktioniert dann natürlich nicht also fallback auf NTLM.

Von Microsoft gab es zum 11. Januar 2022 ein Update zum Schließen der Schwachstelle CVE-2022-21920, welches den obigen Effekt auslösung. Markus K. wies mich dann auf den Microsoft-Supportbeitrag  KB5011233: Protections in CVE-2022-21920 may block NTLM authentication if Kerberos authentication is not successful hin, wo das thematisiert ist. Gemäß Support-Beitrag betrifft dies folgende Windows-Versionen.

Windows Server 2008
Windows 7 Service Pack 1
Windows Server 2008 R2 Service Pack 1
Windows Server 2012
Windows 8.1 Windows Server 2012 R2
Windows 10 Windows 10, version 1607,
all editions Windows 10, version 1809,
all editions Windows Server 2016
Windows 10, version 1909,
all editions Windows Server 2019
Windows 10, version 20H2,
all editions Windows 10, version 21H1,
all editions Windows 10, version 21H2,
all editions Windows 11 Windows Server 2022

Dazu schrieb mir Markus: Ersetzt man nun die IP mit dem richtigen FQDN der Domäne klappt wieder alles.