Lässt der Microsoft Edge 109.x den Application Guard abstürzen?

[English]Lässt der Microsoft Edge-Browser in der Version 109.x Microsofts Sicherheitsfeature Application Guard unter Windows abstürzen? Das ist die Aussage eines Nutzers in Blog-Kommentaren. Nachdem der Betroffene mich mit einigen Informationen versorgt hat, greife ich das Thema im Blog auf, um herauszufinden, ob es ggf. weitere Betroffene gibt, die dies bestätigen können.

Der Edge und der Application Guard

Der Windows Defender Application Guard (WDAG) wurde für Windows 10 und Microsoft Edge in Unternehmensumgebungen entwickelt. Administratoren können definieren, was zu den vertrauenswürdigen Websites, Cloud-Ressourcen und internen Netzwerken gehört. Alles, was nicht in der Liste enthalten ist, wird als nicht vertrauenswürdig eingestuft. Der WDAG isoliert die Browsersitzungen dann per Hyper-V vom Rest des Betriebssystems. Der Application Guard hilft Administratoren in Unternehmen also beim Isolieren von als nicht vertrauenswürdig definierten Websites. Dies stellt sicher, dass das Unternehmen geschützt ist, wenn Mitarbeiter im Internet auf nicht vertrauenswürdigen Webseiten surfen.

Inzwischen steht der Application Guard auch für den Google Chrome sowie den Mozilla Firefox-Browser zur Verfügung und kann über Extensions genutzt werden (siehe Links am Artikelende). Microsoft beschreibt im Artikel Microsoft Edge support for Microsoft Defender Application Guard wie Microsoft Edge den Microsoft Defender Application Guard (Application Guard) unterstützt.

Erste Benutzermeldungen

Problem an diesem Ansatz ist, dass dieser funktionieren sollte, das aber nicht immer funktioniert. Im Dezember 2022 hat ein Benutzer den Beitrag Windows Defender Application Guard doesn't work properly in domain environment .Hangs and cant connect to internet bei Learn Microsoft eingestellt und beklagt, dass der Windows Defender Application Guard (WDAG) nicht funktioniere. WDAG hängt und der Edge kommt nicht ins Internet. Und im September 2021 wurde der Thread MSEDGE crashes when trying to open a new application guard window zu Abstürzen des Microsoft Edge-Browsers in Verbindung mit dem Application Guard eröffnet.

Auf reddit.com gibt es ebenfalls einen Thread Microsoft Defender Application Guard 22H2 Bug, der im Oktober 2022 Abstürze des Windows Defender Application Guard bei neuen Geräten mit Windows 11 22H2 berichtet, wenn Nutzer versuchen eine Website im Microsoft Edge zu öffnen. Daher mussten die Administratoren diese Funktion deaktivieren.

Neuer Bericht: Absturz im Edge 109.x

Ein Blog-Leser meldete sich vor einigen Tagen zum Blog-Beitrag Massive Druckprobleme im Edge 109er Zweig – Umlaute als Problem mit nachfolgenden Kommentaren:

Bei uns schießt die Funktion Application Guard ab, Edge ist damit praktisch nicht mehr darüber surffähig

Verteilen Proxy Settings über WPAD

108 funktioniert
109*55, tot
Müssen mal noch mit. 52 testen

Jop alles was 109.* ist tötet Application Guard

Später ergänzte der Benutzer in diesem Kommentar zum Beitrag Edge 109.0.1518.61 fixt Druckprobleme – weitere Bugs offen? PWA-Fix:

Hier der Kommentator mit den Application Guard Problemen.
Leider ändert auch die Version nichts, ERR_CONNECTION_TIMED_OUT ist das Resultat.

Inzwischen haben wir auch den Dev Zweig (v110) durchgetestet, Ergebnis ist dasselbe
Ticket bei MS ist offen, bisher aber ohne Ergebnis

Übrigens wird Application Guard schon länger für Chromium Edge unterstützt, seit Version 77 aber da war's eher…nun ja mit vielen Nachteilen aber so Richtung v90 war's dann doch in gut implementiert

Ich hatte dann beim Betroffenen nachgefragt, ob er mir weitere Details bereitstellen könne. Das ist nun passiert und ich stelle die Informationen nachfolgend bereit.

Details zum WDAG-Absturz

In einer ergänzenden Mail schrieb der Betreffende, der in einem IT-Bereich bei einem Unternehmen arbeitet, folgendes:

Hallo Günter,

bezüglich dem Application Guard Problem ab v109

Wie geschrieben, v108 funktioniert, v109 funktioniert nicht mit der gleichen Konfiguration, und wie erwartet ist der MS Support etwas schleppend.

In der betreffenden Umgebung gilt folgendes zur Infrastruktur und Einrichtung der Systeme:

• Konfiguration erfolgt über GPO
• Konfiguration setzt einen expliziten Proxy für Application Guard
• Konfiguration setzt eine WPAD/PAC Datei für "nicht Application Guard"

Der Leser hat mir dann noch einige Screenshots, die Konfiguration und die log-Dateien geschickt, um zu verdeutlichen, wo die Probleme liegen. Dazu schreibt er:

Es wird schlicht das Konfigsetting "ApplicationGuardContainerProxy" nicht mehr genutzt/korrekt ausgelesen und dann will der er(vermutlich) auf die wpad Quelle zugreifen, auf die er aber nicht darf.

Dazu hat mir der Leser nachfolgenden Screenshot zugeschickt – zum Vergrößern auf das Bild klicken, um dieses in einem separaten Browserfenster zu öffnen.

In den Application Guard Internals wird auf der Utilities-Seite ein Konfiguration-Error angezeigt (siehe nachfolgenden Screenshot).

Dazu schreibt der Leser: Nach Refresh zieht er (WDAG) scheinbar unsere "Systemsettings" an welche NICHT für Application Guard gedacht sind. Dazu sei gesagt, dass die aktuelle Konfiguration keinen Zugriff aus dem Application Guard heraus auf wpad.sdk.local erlaubt (testen wir noch obs dann „läuft").

In obigem Screenshot sind die Einstellungen für den Prox sowie die Application Guard Internals zu sehen. Im Microsoft 108er Entwicklungszweig des Edge-Browsers funktioniert das Zusammenspiel mit dem WDAG.

An dieser Stelle die Frage an die Leserschaft, ob noch jemand ähnliche Erfahrungen mit dem Edge 109 gemacht hat? Oder setzt ihr WDAG in Verbindung mit dem Edge nicht ein?

Ursache für den WDAG-Absturz

Blog-Leser Matthias hat in einer Nachtrags-Mail dann noch einige Erkenntnisse offen gelegt (siehe auch den inzwischen freigeschalteten Kommentar):

Nachtrag weil wichtig für Application Guard und hier ein Workaround schlummert: Die Network Isolation Konfig, in der man auch sieht dass wpad.sdk.local für den Application Guard nicht erreichhar ist (und sein soll)

Unsere Proxies sind für „internen Edge" und „externen Edge" zwei unterschiedliche.

Wenn wir jetzt unsere Network Isolation anpassen und sowohl wpad als auch internen Proxy als "Sowohl als Arbeits- als auch als persönliche Ressource kategorisierte Domänen" packen (NeutralResources -> Domains categorized as both work and personal (admx.help)) funktioniert der Application Guard über den Internen Proxy, mit welchem man aber nur eine kleine Zahl Websites aufrufen kann, die auf einer Whitelist stehen.

Darüber lässt sich ein Workaround schaffen der ein paar Hinkefüße hat, Application Guard hat intern 3 Subnetbereiche (die ich gerade suche) über die man steuern könnte dass hier die WPAD dann eben einen anderen proxy setzt.

Sprich wenn man die wpad darauf auslegt betrifft das eben auch genau jene Hyper-V Maschinen. Deshalb senden wir eigentlich mit dem Browser die Datenverkehrserkennung (im wesentliche ne Header Info -> ApplicationGuardTrafficIdentificationEnabled -> Microsoft Edge Browser Policy Documentation | Microsoft Learn dass unser Externer alle anderen Anfragen abblockt weil im App Guard auch keine Auth möglich ist … also müssten wir auch am Externen Proxy die „internen needs" für die Hyper-V Nutzer abbilden was aufgrund von Netzsegmentierungen nicht wirklich gewollt ist.

Nunja mal schauen wie wir mit den Infos weiterarbeiten

Weiter geht es dann mit dem Folgekommentar von Matthias.

Ähnliche Artikel:
Windows 10 Enterprise soll Edge-Virtualisierung bekommen
Windows Defender Application Guard Extensions für Chrome und Firefox
Windows Defender Application Guard für Chrome/Firefox
Windows 10: Defender Application Guard statt Edge starten
Falsche Sprache im Windows Defender Application Guard
Massive Druckprobleme im Edge 109er Zweig – Umlaute als Problem
Edge 109.0.1518.61 fixt Druckprobleme – weitere Bugs offen? PWA-Fix