Windows 10: Remote WMI ab V1803 kaputt (0x80070005)

[English]In Windows 10 hat Microsoft ab der Version 1803 noch einen dicken Bock eingebaut. Es sind keine Remote WMI-Anfragen mehr möglich. Hier ein paar Informationen zu einem Thema, zu dem Microsoft bisher den Betroffenen die kalte Schulter zeigt.

Was ist Remote WMI?

Per Windows Management Instrumentation (WMI) kann man auf allerlei Windows-Informationen zugreifen. Microsoft schreibt in diesem Dokument zu WMI:

Windows Management Instrumentation (WMI) ist die Infrastruktur für Verwaltungsdaten und Operationen auf Windows-basierten Betriebssystemen. Sie können WMI-Skripte oder -Anwendungen schreiben, um Verwaltungsaufgaben auf Remote-Computern zu automatisieren, aber WMI liefert auch Verwaltungsdaten an andere Teile des Betriebssystems und Produkte, z.B. System Center Operations Manager, früher Microsoft Operations Manager (MOM), oder Windows Remote Management.

Es wird in dieser Intro bereits angedeutet: WMI funktioniert nicht nur lokal, sondern auch remote über Netzwerk für andere Windows Maschinen. Microsoft erklärt die notwendigen Schritte im Dokument Connecting to WMI on a Remote Computer.

Weil ich gerade darauf gestoßen bin: Microsoft hat übrigens diverse Remote Desktop Services WMI Provider Error Codes auf dieser Webseite dokumentiert.

Welches Problem gibt es mit Remote WMI?

Wie es ausschaut, funktioniert Remote WMI seit Windows 10 Version 1803 und auch in der Folgeversion 1809 nicht mehr. Ich wurde durch einen Tweet von @PhantomofMobile auf das Problem aufmerksam:

REMOTE CONNECTION "ACCESS DENIED" for REMOTE WMI:
Started in 1803 continues 1809@Microsoft seems nobody is LISTENING!

ICYMI: @SBSDiva @woodyleonhard @AskWoody @AdminKirsty @bdsams @mehedih_ @ruthm @etguenni @SwiftOnSecurity @Karl_F1_Fan (Tweet gelöscht) @JobCackahttps://t.co/vdOkpARVQg

1/3

— Crysta T. Lacey (@PhantomofMobile) 29. November 2018

Das Ganze wurde auf patchmanagement.org hochgespült und durch Susan Bradley aufgegriffen. Hier ist beispielsweise ein Thread zu diesem Thema. Auf MSDN findet sich dieser Forenthread, der das Problem beschreibt.

We have a custom service using system.managementscope.connect to connect to a remote wmi to gather it's system/hardware/software data.

This service runs on a windows 1803 as Local System and adds the correct impersonation & authentication level and also sets the connection options with the local username & password on the remote target.

This worked on target machines running windows 10 pro <= 1703 but started returning "access denied" on targets windows 10 pro >= 1803.

Remark: This problem only occurs when a windows 1803 (or later) machine is trying to remotely connect wmi to another 1803 (or later) machine.

We can simulate this malfunction using wbemtest.exe:

We have a problem getting a windows 10 pro machine (both in domain and workgroup) to connect to remote WMI to a windows 10 >= 1803 target in a domain or a workgroup.

Every time we try to access it, we get "access denied".  This is related to the user executing the remote WMI connection.

If this user does not exist on the target machine, the remote WMI connection will always fail with "access denied", even when this user has been passed with the connection options. This has worked on targets with windows 10 <= 1703.

We did our tests using wbemtest.exe with the same impersonation & authentication level as the target (configured using dcomcnfg.exe).

Until 1703:

Test wbemtest.exe with local user of remote destination filled in in the credentials section:

Able to connect and retrieve data

Starting from 1803:

Test wbemtest.exe with local user of remote destination filled in in the credentials section):

0x80070005 access denied

Request:

We need to specifically find which LocalSecurityPolicy/Registry settings have been modified in 1803 which is blocking the remote WMI connects.

We already tried disabling windows defender, modifying remote uac, LocalAccountTokenFilterPolicy (and rebooting) but none of these changes worked so far.

Im Post ist der Benutzer zwar durch eine spezielle Anwendung auf das Problem gestoßen. Er konnte den Fehler aber grundsätzlich durch das Windows-Programm wbemtest.exe nachweisen:

• Lokal lassen sich WMI-Abfragen per wbemtest.exe auf Windows 10-Maschinen ausführen.
• Remote können WMI-Abfragen per wbemtest.exe auf Windows 10 V1709-Maschinen erfolgreich durchgeführt werden.
• Sobald eine Remote WMI-Abfrage per wbemtest.exe auf Windows 10 V1803-Maschinen versucht wird, weist das Betriebssystem den Zugriff mit dem Fehlercode 0x80070005 access denied zurück.

Das Problem besteht auch unter Windows 10 V1809 und Windows Server 2019 (und wohl auch unter Windows Server V1809). Das Problem wurde inzwischen durch verschiedene Benutzer bestätigt, liegt also nicht an Zugriffsrechten oder ähnlichem.

not only this, also if you use Event Manager the Event Collections are not shown remotely, only local
e.g. open Event Viewer and remotely connect on a Server with NPS role, locally you see Event Collection view, not so remote, also affect other services

— al Qamar (@Karl_F1_Fan) 29. November 2018

Aktuell läuft die Diskussion seit Anfang November 2018 auf MSDN. Auf Twitter bestätigt @Karl_F1_Fan, dass der Event Manager keine Remote Ereignisse anzeigen kann. Das Ganze hat also eine Menge Auswirkungen, die ein Remote-Arbeiten unmöglich machen. Wie es ausschaut, hat der @AzureSupport das Thema laut diesem Tweet aber zur Kenntnis genommen. Falls jemand von euch von dem Thema tangiert wird, könnte das dort mit eingespeist werden.