Anpassen Ihrer Website an neue Lokale Netzwerkzugriffseinschränkungen in Microsoft Edge

Letzte Aktualisierung: 1. Oktober 2025

Lokale Netzwerkzugriffseinschränkungen beginnen in Microsoft Edge 143 standardmäßig mit dem Versand. Weitere Hintergrundinformationen zum Lokalen Netzwerkzugriff und zu den Beweggründen für die Anforderung von Benutzerberechtigungen für lokale Netzwerkanforderungen finden Sie in der Spezifikation für den Zugriff auf lokale Netzwerke.

Wenn Sie über eine Website verfügen, die eine Verbindung mit einem Server herstellen muss, auf dem localhost oder irgendwo im lokalen Netzwerk des Benutzers (möglicherweise über eine Drittanbieterbibliothek) ausgeführt wird, versucht dieses Dokument, häufig gestellte Fragen zu beantworten und Anleitungen zur Anpassung Ihrer Website an diese neuen Einschränkungen bereitzustellen.

In vielen Fällen sollten lokale Netzwerkanforderungen weiterhin wie zuvor funktionieren, aber Benutzer sehen eine Berechtigungsaufforderung, wenn sie zum ersten Mal an einem Standort auftreten. In einigen Fällen müssen Sie Ihre Website anpassen, damit diese Anforderungen weiterhin funktionieren (und nicht als gemischter Inhalt blockiert werden). Wenn Sie beispielsweise fetch()-Anforderungen an einen öffentlichen Domänennamen senden, der in eine lokale Netzwerkadresse aufgelöst wird, müssen Sie Ihre fetch()-Aufrufe explizit als an eine lokale Adresse kennzeichnen. Oder wenn Sie Ihre Website heute aufgrund der Blockierung gemischter Inhalte unter HTTP (anstelle von HTTPS) hosten müssen, möchten Sie sich für unsere Ursprungstestversion registrieren, um Ihre Website vorübergehend von den HTTPS-Anforderungen für das Anfordern der LNA-Berechtigung auszunehmen.

Was sind die aktuellen LNA-Einschränkungen in Microsoft Edge?

Die Berechtigungsaufforderung wird ausgelöst, wenn eine Verbindung mit einem Ziel im lokalen Netzwerk oder localhost hergestellt wird. Ab Microsoft Edge 143 gelten LNA-Einschränkungen für:

• Unterressourcenanforderungen
• fetch()-Anforderungen
• Navigieren in Unterframes

LNA-Einschränkungen gelten zunächst nicht für die folgenden Verbindungstypen, obwohl wir sie in Kürze einbeziehen möchten:

• WebSockets
• WebTransport
• WebRTC

Es ist derzeit nicht geplant, LNA-Einschränkungen auf die Hauptframenavigation anzuwenden. (Obwohl sich ein Fehler in unserer Entwurfsimplementierung in Edge 139 und früher versehentlich auf die Hauptframenavigation auswirkte.)

Wir haben derzeit keine Pläne, LNA-Einschränkungen auf Erweiterungen anzuwenden. Derzeit können Erweiterungen, die über die erforderlichen Hostberechtigungen verfügen , lokale Netzwerkanforderungen senden.

LNA-Einschränkungen gelten nicht für Android WebView. Android-Apps, die WebViews einbetten, die lokale Netzwerkanforderungen stellen, unterliegen stattdessen der neuen Lokalen Netzwerkberechtigung von Android.

Wie kann ich meinen Benutzern zusätzlichen Kontext für die LNA-Berechtigungsaufforderung bereitstellen?

Wenn Sie eine Berechtigung anfordern, kann es vorteilhaft sein, dem Benutzer zusätzlichen Kontext in Ihrer Web-App zu geben, warum Sie die Berechtigung benötigen und wofür Sie sie verwenden. Mit der Berechtigungs-API können Sie abfragen, ob ein Benutzer eine bestimmte Berechtigung erteilt (oder verweigert) hat, und ihre Benutzeroberfläche entsprechend anpassen.

Aufgrund der Funktionsweise der Berechtigungs-API gibt die Abfrage nach dem Status der Berechtigung "local-network-access" "prompt" zurück, unabhängig davon, ob das LNA-Featureflag aktiviert ist, wenn dem Benutzer die Berechtigung nicht erteilt oder verweigert wird. Das Featureflag ist in Microsoft Edge 143 standardmäßig aktiviert, sodass Sie je nach Hauptversion in der Benutzer-Agent-Zeichenfolge unterschiedliche Verhaltensweisen verteilen können.

Um mehr Kontext vor dem Auslösen der LNA-Berechtigungsaufforderung bereitzustellen, verwenden Sie in unserer aktuellen Anleitung ein Muster wie das folgende:

• Wenn der Client Edge < 143 ist, sollten lokale Netzwerkanforderungen im Hintergrund funktionieren.
• Wenn der Client Edge >= 143 ist, fragen Sie die Berechtigungs-API ab (siehe Beispielaufruf unten).
  • Wenn die Berechtigung erteilt wurde, fahren Sie mit dem Anforderungsversuch fort.
  • Wenn die Berechtigung verweigert wird, können Sie optional die Benutzeroberfläche anzeigen, um den Benutzer bei Bedarf zu unterstützen.
  • Wenn berechtigung status "prompt" ist, kontextualisieren Sie in Ihrer App, dass eine Eingabeaufforderung auftritt.

Beispielaufruf der Berechtigungs-API:

navigator.permissions.query({ name: "local-network-access" })
.then((result) => {
  console.log(`LNA permission state: ${result.state}`)
});

Hinweis: Die Berechtigungs-API gibt immer "denied" zurück, wenn sie von einer HTTP-Seite aufgerufen wird.

Wie kann ich die Berechtigungsaufforderung programmgesteuert auslösen?

Die LNA-Berechtigungsaufforderung wird nicht ausgelöst, wenn keine Verbindung mit dem Remoteendpunkt hergestellt wird. Wenn es für Ihren Workflow einfacher ist, die Berechtigungsaufforderung auszulösen, bevor versucht wird, eine Verbindung mit dem lokalen Gerät herzustellen, besteht eine Möglichkeit, eine fetch()-Anforderung an einen Hostnamen zu senden, der durch visuelle Überprüfung des Hostnamens (d. h. localhost oder ein Loopback- oder lokales IP-Adressliteral) überprüft werden kann.

In der Praxis bedeutet dies, dass, wenn Sie eine Berechtigungsaufforderung für Verbindungen mit localhost auslösen, in JavaScript einen fetch()-Aufruf wie folgt auslösen:

fetch("http://localhost")

Oder wenn Sie eine Berechtigungsaufforderung für eine Verbindung mit einem lokalen Gerät auslösen, dann:

fetch("https://10.0.0.1")

Einige Hinweise:

• Funktioniert in Microsoft Edge 144 oder höher
• Wenn der Benutzer die Berechtigung akzeptiert (oder verweigert) hat, wird dem Benutzer keine weitere Berechtigungsaufforderung angezeigt.
• Dadurch wird keine Berechtigungsaufforderung ausgelöst, wenn der Kontext, in dem der fetch() ausgeführt wurde, nicht die Berechtigung zum Kontaktieren von localhost (oder dem lokalen Netzwerk) benötigt.

Wie kann ich lokale Netzwerkanforderungen innerhalb eines iFrames senden?

Um eine lokale Netzwerkanforderung innerhalb eines iframes zu erstellen, muss das Einbettungsdokument das Richtlinienflag für lokale Netzwerkzugriffsberechtigungen für den iFrame angeben. Wenn domainA.example beispielsweise einen iframe für domainB.example enthält, müssen Sie die Berechtigung wie folgt explizit an den iframe delegieren:

<iframe src="domainB.example" allow="local-network-access"></iframe>

Wenn eine lokale Netzwerkanforderung aus dem eingebetteten Dokument erfolgt, wird sie so behandelt, als hätte das Einbettungsdokument die LNA-Berechtigung angefordert, und jede Berechtigungsentscheidung des Benutzers wird an den Ursprung des einbettenden Dokuments gebunden.

Wenn das Dokument innerhalb des iframes zu anderen Dokumenten navigiert, die auch lokale Netzwerkanforderungen stellen, müssen Sie alle Ursprünge aller Dokumente angeben, die möglicherweise lokale Netzwerkanforderungen über das Berechtigungsrichtlinienflag senden können. Um das obige Beispiel zu erweitern: Wenn domainB.example den iframe zu domainC.example navigiert und sowohl domainB.example als auch domainC.example lokale Netzwerkzugriffsanforderung stellen, müssen Sie die Berechtigung explizit wie folgt an beide Ursprünge delegieren:

<iframe src="domainB.example" allow="local-network-access domainB.example domainC.example"></iframe>

Sie können auch allow="local-network-access *" angeben, um allen Ursprüngen, die möglicherweise im iframe geladen werden, lokale Netzwerkanforderungen zu senden (auch wenn Sie nicht unbedingt wissen, was sie im Voraus sind). Dies kann z. B. nützlich sein, wenn ein iframe beliebige Umleitungen zu einem anderen Ursprung (z. B. für SSO) vor der Umleitung zurück zu localhost vorgibt.

Weitere Punkte, die Sie beachten müssen:

• Sowohl die Einbettungsseite als auch der iframe müssen sichere Kontexte sein, um die LNA-Berechtigung anfordern zu können.
• Das Anfordern der LNA-Berechtigung innerhalb eines geschachtelten iframes (z. B. domainA.example bettet einen iframe für domainB.example ein, wodurch ein iframe für domainC.example einbettet, wodurch die lokale Netzwerkanforderung ausgeführt wird) erfordert, dass alle iframes das Richtlinienflag local-network-access permissions angeben.
• Die Berechtigungsrichtlinie muss für iFrames festgelegt werden, die lokale Netzwerkanforderungen stellen, auch wenn Sie die Berechtigungsaufforderung über eine Unternehmensrichtlinie umgehen.

Wie kann ich lokale Netzwerkanforderungen von einem Service Worker oder einem freigegebenen Worker senden?

Lokale Netzwerkanforderungen von Service Workern und freigegebenen Workern werden unterstützt, solange dem Workerursprung bereits die LNA-Berechtigung in einem Hauptfensterkontext erteilt wurde. Sie möchten versuchen, die Berechtigung anzufordern, indem Sie eine anfängliche lokale Netzwerkanforderung aus Dem Hauptanwendungsfenster senden. Anschließend können Ihre Worker diese Berechtigung (auch im Hintergrund) verwenden.

Wie kann ich lokale Netzwerkanforderungen von einem dedizierten Worker senden?

Dedizierte Worker sind streng im Besitz eines vorhandenen Hauptfensters, sodass lokale Netzwerkanforderungen von einem dedizierten Worker die LNA-Berechtigungsaufforderung im besitzenden Fenster auslösen.

Wie kann ich verhindern, dass meine lokalen Netzwerkanforderungen als gemischte Inhalte blockiert werden?

Mit LNA sind bestimmte lokale Netzwerkanforderungen jetzt von der Blockierung gemischter Inhalte ausgenommen, sodass HTTPS-Standorte lokale Netzwerkanforderungen an diese HTTP-Endpunkte senden können:

• LOKALE DOMÄNEN (z. B. http://printer.local)
• Private IP-Literale (z. B. http://192.168.0.1/)

Darüber hinaus können Sie bei Verwendung der fetch()-API die Option targetAddressSpace angeben, um zu markieren, dass eine Anforderung für das lokale Netzwerk oder die Loopbackadresse bestimmt ist. Beispiel:

• fetch('http://domainA.example', {targetAddressSpace: 'local'}) funktioniert, wenn domainA.example in eine lokale IP-Adresse wie 192.168.10.1 aufgelöst wird
• fetch('http://domainB.example', {targetAddressSpace: 'loopback'}) funktioniert, wenn domainB.example in die Loopbackadresse 127.0.0.1 aufgelöst wird.

Diese werden alle von der Blockierung gemischter Inhalte ausgenommen.

Wie kann ich lokale Netzwerkanforderungen über eine HTTP-Seite senden?

Um die LNA-Berechtigung anzufordern, muss eine Website über HTTPS bereitgestellt werden (d. h., LNA erfordert einen sicheren Kontext). Aufgrund der Komplexität der Erstellung lokaler Netzwerkanforderungen, bei denen die Ziele derzeit nicht öffentlich vertrauenswürdiges HTTPS unterstützen, bedeutet dies jedoch, dass diese lokalen HTTP-Netzwerkanforderungen als gemischte Inhalte blockiert werden können.

Während LNA versucht, Ausnahmen für die gängigen Fälle zu entfernen (siehe abschnitt "Wie kann ich vermeiden, dass meine lokalen Netzwerkanforderungen als gemischte Inhalte blockiert werden?"), kann es sein, dass es nicht einfach ist, Ihre Website anzupassen, um Probleme mit gemischten Inhalten zu vermeiden.

Wenn Sie mehr Zeit benötigen, um Ihre Website auf DIE Verwendung von HTTPS umzustellen, oder wenn Blockierungsprobleme mit LNA-Ausnahmen für gemischte Inhalte auftreten, da diese derzeit in Microsoft Edge implementiert sind, können Sie sich für eine Ursprungstestversion registrieren, damit Ihre HTTP-Website vorübergehend die LNA-Berechtigung anfordern kann.

Hinweis: Das Ursprungstesttoken muss über HTTP-Header bereitgestellt werden. Diese Ursprungstestversion unterstützt keine Token, die über Metatags oder programmgesteuert über JS übermittelt werden.

Wie kann ich die browserübergreifende Kompatibilität am besten gewährleisten?

Da diese Einschränkungen von verschiedenen Browsern zu unterschiedlichen Zeiten eingeführt werden, müssen Sie möglicherweise eine Logik für die Benutzer-Agent-Erkennung implementieren, um die Kompatibilität zu maximieren.

Der Hauptkompatibilitätsunterschied zwischen einem Browser, der die neue Lokale Netzwerkzugriffsspezifikation unterstützt, und einem Browser, der noch nicht mit gemischten Inhalten arbeitet. In Browsern, die LNA unterstützen, sind der zugriff auf das lokale Netzwerk und die LNA-Berechtigung nur von sicheren Ursprüngen aus verfügbar. Anforderungen von unsicheren Ursprüngen schlagen fehl.

In Browsern, die die LNA-Spezifikation noch nicht unterstützen, ist es wahrscheinlich, dass der meiste lokale Netzwerkzugriff von einem unsicheren Ursprung aus erfolgt ist, um zu vermeiden, dass unsichere Anforderungen an lokale Ressourcen als gemischte Inhalte identifiziert werden.

Wenn Sie Ihre Seite derzeit aufgrund dieser Blockierung gemischter Inhalte über HTTP bereitstellen, können Sie eine Umleitung zu HTTPS für Microsoft Edge 143 und höher bereitstellen, aber weiterhin andere Browser über HTTP bereitstellen (bis sie auch LNA-Einschränkungen und die Ausnahmen für gemischte Inhalte enthalten).

Wenn Sie nur lokale Netzwerkanforderungen an localhost senden, sollten Sie Ihre Website bereits über HTTPS bereitstellen können, da localhost von der Spezifikation für gemischte Inhalte als sicherer Ursprung gilt und nicht als gemischter Inhalt blockiert wird.

Während des Rollouts von Microsoft Edge können Sie sich für eine Ursprungstestversion registrieren, um die LNA-Berechtigungsaufforderung für Ihre unsicheren Ursprünge (HTTP) vorübergehend zu aktivieren. Erfahren Sie mehr über die Registrierung in Ursprungsstudien. Diese Ursprungstestversion ist nur über Microsoft Edge 146 verfügbar (das im März 2026 zum stabilen Kanal wechseln soll). Benutzer der Ursprungstestversion sollten vor diesem Zeitpunkt eine Migration zu HTTPS anstreben.

Wie kann ich die LNA-Berechtigung in EdgeDriver/Selenium/etc. testen?

Die Zugriffsberechtigung für lokale Netzwerke kann über webDriver/EdgeDriver verwaltet werden. Weitere Informationen finden Sie in der Selenium-Dokumentation zu Edge-spezifischen Funktionen und in der Microsoft Edge-Dokumentation zur Verwendung von WebDriver zum Automatisieren von Microsoft Edge. Informationen zur speziellen Verwaltung von Berechtigungen finden Sie im WebDriver setPermissions-Befehl und in der Protokollspezifikation.

Wie kann ich die LNA-Eingabeaufforderung in meinem lokalen Test auslösen?

Da LNA→einschränkungen noch nicht für local→local→loopback→anforderungen gelten, lösen typische lokale Entwicklungssetups (z. B. das Ausführen eines Servers auf localhost) die Berechtigungsaufforderung in Microsoft Edge nicht aus.

Es kann jedoch nützlich sein, dass die Berechtigungsaufforderung bei lokalen Tests ausgelöst wird, z. B. wenn Sie daran arbeiten, Ihre Benutzeroberfläche so anzupassen, dass vor der Eingabeaufforderung mehr Kontext hinzugefügt wird, oder um Benutzern bei der Wiederherstellung zu helfen, wenn sie die Berechtigung verweigert haben (siehe Wie kann ich meinen Benutzern mehr Kontext für die LNA-Berechtigungsaufforderung bereitstellen? Oben).

Microsoft Edge bietet zwei Möglichkeiten, eine Seite so zu behandeln, als würde sie von einer öffentlichen Adresse bereitgestellt:

• Der Header Content-Security-Policy: treat-as-public-address im HTML-Dokument bewirkt, dass dieses Dokument so behandelt wird, als ob es von einer öffentlichen Adresse aus bereitgestellt würde.
• Das Befehlszeilenflag --ip-address-space-overrides kann verwendet werden, um zu erzwingen, dass bestimmte IP-Adressen als ein bestimmter Adressraum (öffentlich, lokal oder Loopback) behandelt werden.

Beispiel für das Außerkraftsetzungsflag des Adressraums: Ihr lokaler Hauptentwicklungsserver wird auf 192.168.10.11 ausgeführt, der dann Anforderungen an einen separaten Server unter 192.168.10.12 sendet. Sie könnten --ip-address-space-overrides=192.168.10.11:0=public übergeben, wenn Sie Microsoft Edge ausführen, um zu erzwingen, dass 192.168.10.11 als öffentliche Adresse behandelt wird (port 0 bedeutet "für alle" Ports anwenden). Wenn dann Anforderungen an den Server gesendet werden, der unter 192.168.10.12 ausgeführt wird, werden sie als lokale Netzwerkanforderungen behandelt und die Berechtigungsaufforderung ausgelöst.

Wie kann ich das Auslösen der LNA-Eingabeaufforderung in meinen automatisierten Tests vermeiden?

LNA-Einschränkungen gelten noch nicht für local→local→ oder localloopback→Anforderungen, aber einige browserbasierte Testsetups können lokale Server umfassen, die dazu führen können, dass die LNA-Eingabeaufforderung ausgelöst wird. Wenn dies unerwartet ist und nicht mit der tatsächlichen User Journey übereinstimmt, die Sie testen (z. B. würde Ihre Produktionswebsite nur Anforderungen an öffentliche Dienste senden), können Sie Microsoft Edge so konfigurieren, dass bestimmte IP-Adressen mit dem Befehlszeilenflag --ip-address-space-overrides=ip-address>:<port>=<address-space als öffentlich behandelt werden, sodass Anforderungen von öffentlichen Websites an sie nicht die LNA-Eingabeaufforderung auslösen.

Sie können einen Port von 0 angeben, um die Außerkraftsetzung auf alle Ports an dieser IP-Adresse anzuwenden. Sie können mehrere Überschreibungsregeln angeben, die durch Kommas getrennt sind (z. B. ip-address-space-overrides=192.168.0.1:8080=public,10.0.1.20:0=loopback). Die vollständige Grammatik für das Flag finden Sie hier.

Beispiel: Ihr Stagingserver wird unter 23.220.75.232 (eine öffentliche IP-Adresse) ausgeführt, sendet jedoch Anforderungen an einen Dienst, der intern unter 10.0.1.108 ausgeführt wird (eine private IP-Adresse). In der Produktion wird dieser Dienst unter einer öffentlichen IP-Adresse ausgeführt, sodass von echten Benutzern nicht erwartet wird, dass die LNA-Aufforderung angezeigt wird. In der automatisierten Testumgebung für diesen Dienst übergeben Sie das Befehlszeilenflag --ip-address-space-overrides=10.0.1.108:0=public, sodass alle Verbindungen mit dieser IP-Adresse als öffentlich gelten und keine LNA-Eingabeaufforderung beim Testen ausgelöst wird.

So ermitteln Sie, warum eine Website durch LNA blockiert wird

Wenn eine Webanwendung versucht, auf Ressourcen zuzugreifen, die als im lokalen Netzwerk gelten, wird eine Eingabeaufforderung ausgelöst, damit der Benutzer eine solche Anforderung zulassen oder blockieren kann:

Das Zulassen des Zugriffs entsperrt in der Regel die Funktionalität, die die Webanwendung erwartet. Wenn der Zugriffsversuch für das lokale Netzwerk an einen ursprungsübergreifenden iframe geht (oder von diesem stammt), der als im lokalen Netzwerk gilt, funktioniert das Ausschließen der Webanwendung (entweder manuell oder über eine Gruppenrichtlinie) nicht.

Dieses iframe-Szenario wird häufig von einem DevTools-Konsolenfehler begleitet:

Access to fetch at 'http://127.0.0.1:8080/data' from origin 'https://example.com'  

has been blocked by CORS policy: Permission was denied for this request to access the `unknown` address space. 

Identifizieren der für den iFrame definierten hosts cross-origin und top-level. Es wird zwar empfohlen, eine betroffene Webanwendung so anzupassen, dass die Berechtigung "local-network-access" im iframe hinzugefügt wird, dies ist jedoch ohne direkte Kontrolle über den Webanwendungscode möglicherweise nicht möglich.

Bestimmte Bibliotheken, die in Webanwendungen verwendet werden, die möglicherweise in ursprungsübergreifenden iframes verwendet werden, haben bereits Korrekturen zur Unterstützung der erforderlichen LNA-Berechtigungen veröffentlicht, z. B. MSAL-browser, die in Version 4.26.1 oder höher enthalten sind.

So verringern Sie die Auswirkungen auf ursprungsübergreifende iFrames

Wenn entweder die Hosts der obersten Ebene oder iFrame-Hosts als im lokalen Netzwerk gelten, besteht die einzige Möglichkeit, die Auswirkungen zu verringern, ohne Codeänderungen vorzunehmen, die Verwendung der LocalNetworkAccessRestrictionsTemporaryOptOut Richtlinieneinstellung.

Es ist geplant, zwei zusätzliche Richtlinieneinstellungen bereitzustellen, um dieses Szenario zu umgehen: eine, um zuzulassen, dass ursprungsübergreifende iframes die LNA-Berechtigung der obersten Ebene des Hosts erben , und eine andere, um einen bestimmten Adressraum davon auszunehmen, als lokales Netzwerk zu gelten (z. B. der NAT-Adressbereich des Anbieters ). Die Dokumentation wird aktualisiert, wenn Microsoft Edge offiziellen Support für diese Richtlinien bereitstellt.

Wie kann ich generell Feedback zu LNA geben?

Melden Sie ein Problem mit Ihrem Feedback im Repository für die Lokale Netzwerkzugriffsspezifikation auf GitHub.

Wie kann ich Fehler in der LNA-Implementierung von Microsoft Edge melden?

Bei Problemen, die mit der Implementierung des Zugriffs auf lokale Netzwerke in Microsoft Edge spezifisch sind, verwenden Sie die Microsoft Edge-Feedbackkanäle, oder wenden Sie sich an Microsoft-Support für Unternehmenskunden.

[Enterprise] Vorgehensweise: Zulassen oder Blockieren von URLs für lokale Netzwerkanforderungen

Es gibt zwei Unternehmensrichtlinien für LNA: LocalNetworkAccessAllowedForUrls und LocalNetworkAccessBlockedForUrls. Diese können verwendet werden, um lokale Netzwerkanforderungen von einer URL zuzulassen, ohne die Berechtigungsaufforderung anzuzeigen, oder um zu verhindern, dass eine URL lokale Netzwerkanforderungen senden kann.

Diese Richtlinien unterstützen auch Wildcards mit URL-Mustersyntax .

Die LocalNetworkAccessAllowedForUrls-Richtlinie gilt für den Ursprung der Website auf oberster Ebene, die die Anforderung stellt. Wenn der tatsächliche lokale Netzwerkzugriff in einem auf dieser Seite eingebetteten iframe (oder in einem geschachtelten iframe) erfolgt, müssen alle iFrames das Berechtigungsrichtlinienflag festlegen.

[Enterprise] Ich habe LocalNetworkAccessAllowedForUrls festgelegt, aber es treten weiterhin Probleme auf.

Wenn Sie die LocalNetworkAccessAllowedForUrls-Richtlinie richtig festgelegt haben, Ihre Anwendungen aber immer noch nicht funktionieren, müssen Sie wahrscheinlich Ihre iframes korrigieren. Weitere Informationen finden Sie im obigen Abschnitt mit dem Titel "Wie kann ich lokale Netzwerkanforderungen innerhalb eines iFrames ausführen?"

Es gibt auch eine temporäre Unternehmensrichtlinie, LocalNetworkAccessRestrictionsTemporaryOptOut, mit der Unternehmen alle LNA-Einschränkungen deaktivieren können. Diese Richtlinie ist eine temporäre Richtlinie und wird nach Edge 152 entfernt.

Hinweis: Diese Richtlinien können mithilfe von Gruppenrichtlinie (über ADMX-Vorlagen), Microsoft Intune (mithilfe des Einstellungskatalogs) oder anderen Mobile Geräteverwaltung (MDM)-Lösungen konfiguriert werden. Weitere Informationen zum Konfigurieren von Microsoft Edge-Richtlinien finden Sie unter Konfigurieren von Microsoft Edge-Richtlinieneinstellungen.