Planen einer Microsoft Entra Anwendungsproxybereitstellung

Der Microsoft Entra-Anwendungsproxy ist eine sichere und kostengünstige Lösung für den Remotezugriff auf lokale Anwendungen. Es bietet einen sofortigen Übergangspfad für "Cloud First"-Organisationen, um den Zugriff auf ältere lokale Anwendungen zu verwalten, die noch nicht in der Lage sind, moderne Protokolle zu verwenden. Weitere Einführungsinformationen finden Sie unter "What is application proxy".

Der Anwendungsproxy wird empfohlen, um Remote-Zugriff auf interne Ressourcen zu gewähren. Durch den Anwendungsproxy entfällt die Notwendigkeit eines VPN oder Reverseproxys für solche Anwendungsfälle mit Remotezugriff. Sie ist nicht für Benutzer vorgesehen, die sich im Unternehmensnetzwerk befinden. Bei diesen Benutzern, die Anwendungsproxy für den Intranetzugriff verwenden, treten möglicherweise unerwünschte Leistungsprobleme auf.

Dieser Artikel enthält die Ressourcen, die Sie zum Planen, Betreiben und Verwalten des Microsoft Entra-Anwendungsproxys benötigen.

Planen Ihrer Implementierung

Der folgende Abschnitt bietet einen großen Überblick über die wichtigsten Planungselemente, die Sie auf eine effiziente Bereitstellung vorbereiten.

Voraussetzungen

Sie müssen die folgenden Voraussetzungen erfüllen, bevor Sie mit der Implementierung beginnen. Weitere Informationen zum Einrichten Ihrer Umgebung, einschließlich dieser Voraussetzungen, finden Sie im Lernprogramm.

• Connectors: Connectors sind einfache Agents, die Sie auf folgenden Komponenten bereitstellen können:

  • Lokale physische Hardware
  • Ein virtueller Computer (VM), der in einer hypervisor-Lösung gehostet wird
  • In Azure gehostete VM für die ausgehende Verbindung mit dem Anwendungsproxydienst.

• Eine ausführlichere Übersicht finden Sie unter Grundlegendes zu privaten Microsoft Entra-Netzwerkconnectors.

  • Verbindercomputer müssen für TLS (Transport Layer Security) 1.2 aktiviert sein , bevor die Connectors installiert werden.

  • Stellen Sie die Connectors nach Möglichkeit in demselben Netzwerk bereit, und führen Sie eine Segmentierung nach Back-End-Webanwendungsservern durch. Es empfiehlt sich, vor dem Bereitstellen der Connectors eine Anwendungsermittlung durchzuführen.

  • Um Hochverfügbarkeit und Skalierung zu gewährleisten, sollten jeder Connectorgruppe mindestens zwei Connectors zugewiesen werden. Drei Verbinder zu haben ist optimal, um eine Maschine jederzeit zu warten. Überprüfen Sie die Verbindungskapazitätstabelle , um den Typ des Computers für den Verbinder zu bestimmen.

• Netzwerkzugriffseinstellungen: Private Microsoft Entra-Netzwerkconnectors stellen über HTTPS (Transmission Control Protocol (TCP) Port 443) und HTTP (TCP-Port 80) eine Verbindung mit Azure her.

  • Das Beenden von TLS-Datenverkehr des Connectors wird nicht unterstützt und verhindert, dass Connectors einen sicheren Kanal mit ihren jeweiligen Microsoft Entra-Anwendungsproxyendpunkten herstellen.

  • Vermeiden Sie alle Arten von Inline-Untersuchungen der ausgehenden TLS-Kommunikation zwischen Connectors und Azure. Die interne Untersuchung zwischen einem Connector und Back-End-Anwendungen ist möglich, aber dies kann zu einer Beeinträchtigung der Benutzerfreundlichkeit führen. Aus diesem Grund wird diese Vorgehensweise nicht empfohlen.

  • Ein Lastenausgleich der Connectors selbst wird ebenfalls nicht unterstützt und ist auch nicht erforderlich.

Wichtige Aspekte vor der Konfiguration des Microsoft Entra-Anwendungsproxys

Die folgenden grundlegenden Anforderungen müssen erfüllt sein, um den Microsoft Entra-Anwendungsproxy konfigurieren und implementieren zu können.

• Azure-Onboarding: Vor dem Bereitstellen des Anwendungsproxys müssen Benutzeridentitäten aus einem lokalen Verzeichnis synchronisiert oder direkt auf Ihren Microsoft Entra-Mandanten erstellt werden. Die Identitätssynchronisierung ermöglicht es Microsoft Entra-ID, Benutzer vorab zu authentifizieren, bevor sie Zugriff auf veröffentlichte Anwendungen des Anwendungsproxys gewähren und über die erforderlichen Benutzerbezeichnerinformationen verfügen, um einmaliges Anmelden (Single Sign-On, SSO) durchzuführen.

• Anforderungen für bedingten Zugriff: Wir empfehlen nicht, den Anwendungsproxy für den Intranetzugriff zu verwenden, da dies zusätzliche Latenz verursacht, die sich negativ auf die Benutzer auswirkt. Wir empfehlen die Verwendung eines Anwendungsproxys mit Vorauthentifizierung und bedingten Zugriffsrichtlinien für den Remotezugriff aus dem Internet. Wenn Sie bedingten Zugriff für das Intranet bereitstellen möchten, können Sie Ihre Anwendungen modernisieren, sodass sie die Authentifizierung direkt mit Microsoft Entra ID durchführen können. Weitere Informationen finden Sie unter Ressourcen zum Migrieren von Anwendungen zu Microsoft Entra ID.

• Dienstgrenzwerte: Zum Schutz vor überlastung von Ressourcen durch einzelne Mandanten gibt es Drosselungsgrenzwerte pro Anwendung und Mandant. Die Grenzwerte finden Sie unter Dienst- und andere Einschränkungen für Microsoft Entra. Diese Einschränkungsgrenzwerte basieren auf einem Benchmark, der über das typische Verwendungsvolumen hinausgeht, und bieten ausreichend Puffer für die meisten Implementierungen.

• Öffentliches Zertifikat: Wenn Sie benutzerdefinierte Domänennamen verwenden, müssen Sie ein TLS-Zertifikat beschaffen. Je nach den Anforderungen Ihrer Organisation kann die Beschaffung eines Zertifikats einige Zeit dauern. Wir empfehlen Ihnen daher, sich so früh wie möglich darum zu kümmern. Der Azure-Anwendungsproxy unterstützt Standard-, Platzhalter- oder SAN-basierte Zertifikate. Weitere Informationen finden Sie unter Konfigurieren von benutzerdefinierten Domänen mit dem Microsoft Entra-Anwendungsproxy.

• Domänenanforderungen: Um kerberos-eingeschränkte Delegierung (KCD) für einmaliges Anmelden zu verwenden, stellen Sie sicher, dass sowohl der Connectorserver als auch der Anwendungsserver in derselben Domäne oder in vertrauenswürdigen Domänen eingebunden sind. Der Connectordienst wird unter dem lokalen Systemkonto ausgeführt und sollte keine benutzerdefinierte Identität verwenden. Weitere Informationen finden Sie unter KCD für Single Sign-On.

• DNS-Einträge für URLs

  • Bevor Sie benutzerdefinierte Domänen im Anwendungsproxy verwenden, müssen Sie einen CNAME-Eintrag im öffentlichen Domain Name System (DNS) erstellen, sodass Clients die benutzerdefinierte definierte externe URL in die vordefinierte Anwendungsproxyadresse auflösen können. Fehler beim Erstellen eines CNAME-Eintrags für eine Anwendung, die eine benutzerdefinierte Domäne verwendet, verhindert, dass Remotebenutzer eine Verbindung mit der Anwendung herstellen. Die erforderlichen Schritte zum Hinzufügen von CNAME-Einträgen können von DNS-Anbieter zu DNS-Anbieter variieren. Es ist daher ratsam, dass Sie sich über das Verwalten von DNS-Einträgen und -Ressourceneintragssätzen im Microsoft Entra Admin Center informieren.

  • Entsprechend müssen Connectorhosts die interne URL von veröffentlichten Anwendungen auflösen können.

• Administratorrechte und -rollen

  • Für die Connectorinstallation werden lokale Administratorrechte für den Windows-Server benötigt, auf dem die Installation durchgeführt wird. Darüber hinaus ist für die Authentifizierung und Registrierung der Connectorinstanz bei Ihrem Microsoft Entra-Mandanten mindestens die Rolle Anwendungsadministrator erforderlich.

  • Für die Anwendungsveröffentlichung und -verwaltung wird die Rolle Anwendungsadministrator benötigt. Anwendungsadministratoren können alle Anwendungen im Verzeichnis verwalten, einschließlich Registrierungen, SSO-Einstellungen, Benutzer- und Gruppenzuweisungen und -lizenzierung, Anwendungsproxyeinstellungen und Zustimmung. Durch diese Rolle kann der bedingte Zugriff nicht verwaltet werden. Die Rolle " Cloudanwendungsadministrator " verfügt über alle Funktionen des Anwendungsadministrators, mit der Ausnahme, dass die Verwaltung von Anwendungsproxyeinstellungen nicht zulässig ist.

• Lizenzierung: Der Anwendungsproxy ist über ein P1- oder P2-Abonnement für Microsoft Entra ID verfügbar. Eine vollständige Liste mit Lizenzierungsoptionen und -funktionen finden Sie auf der Seite mit den Microsoft Entra-Preisen.

Anwendungsermittlung

Erstellen Sie eine Bestandsliste mit allen relevanten Anwendungen, die per Anwendungsproxy veröffentlicht werden, indem Sie die folgenden Informationen erfassen:

Informationstyp	Zu erfassende Information
Diensttyp	Beispiel: SharePoint, SAP, CRM, benutzerdefinierte Webanwendung, API
Anwendungsplattform	Beispiel: Windows Internet Information Services (IIS), Apache unter Linux, Tomcat, NGINX
Domänenmitgliedschaft	Vollqualifizierter Domänenname (FQDN) des Webservers
Speicherort der Anwendung	Ort des Webservers bzw. der Farm in Ihrer Infrastruktur
Interner Zugriff	Die genaue URL für den internen Zugriff auf die Anwendung. Bei einer Farm: Welche Art von Lastenausgleich wird verwendet? Nutzt die Anwendung nicht nur eigene Inhalte, sondern auch aus anderen Quellen? Ermitteln Sie, ob die Anwendung über WebSockets betrieben wird.
Externer Zugriff	Die Anbieterlösung, über die die Anwendung möglicherweise bereits extern verfügbar gemacht wird. Die URL, die Sie für den externen Zugriff verwenden möchten. Stellen Sie bei SharePoint sicher, dass alternative Zugriffszuordnungen gemäß der Anleitung konfiguriert sind. Wenn nicht, müssen Sie externe URLs definieren.
Öffentliches Zertifikat	Beschaffen Sie bei Verwendung einer benutzerdefinierten Domäne ein Zertifikat mit einem entsprechenden Antragstellernamen. Bei Vorhandensein eines Zertifikats: Notieren Sie sich die Seriennummer und den Ort, von dem es beschafft werden kann.
Authentifizierungsart	Die Authentifizierungsart, die von der Anwendung unterstützt wird, z. B. Einfach, Integrierte Windows-Authentifizierung, Formularbasiert, Headerbasiert und Ansprüche. Wenn die Anwendung für die Ausführung unter einem bestimmten Domänenkonto konfiguriert ist, sollten Sie sich den vollqualifizierten Domänennamen (FQDN) des Dienstkontos notieren. Notieren Sie sich bei „SAML-basiert“ den Bezeichner und die Antwort-URLs. Bei „Headerbasiert“: die Anbieterlösung und die spezifische Anforderung für den Umgang mit der Authentifizierungsart.
Name der Connectorgruppe	Der logische Name für die Gruppe von Connectoren, die als Verbindungskanal und Single-Sign-On (SSO) für die Back-End-Anwendung vorgesehen sind.
Benutzer-/Gruppenzugriff	Die Benutzer oder Benutzergruppen, denen externer Zugriff auf die Anwendung gewährt wird.
Weitere Anforderungen	Beachten Sie alle weiteren Remotezugriffs- oder Sicherheitsanforderungen, die in die Veröffentlichung der Anwendung berücksichtigt werden sollten.

Sie können die Anwendungsinventartabelle herunterladen, um Ihre Apps zu inventarisieren.

Definieren der Anforderungen der Organisation

Für die folgenden Bereiche sollten Sie die geschäftlichen Anforderungen Ihrer Organisation definieren. Jeder Bereich enthält Beispiele für Anforderungen.

Zugriff

• Remotebenutzer*innen mit in Domänen oder in Microsoft Entra eingebundenen Geräten können sicher per nahtlosem einmaligen Anmelden auf veröffentlichte Anwendungen zugreifen.

• Remotebenutzer mit genehmigten persönlichen Geräten können sicher auf veröffentlichte Anwendungen zugreifen, sofern sie bei MFA registriert sind und die Microsoft Authenticator-App auf ihrem Mobiltelefon als Authentifizierungsmethode registriert sind.

Governance

• Administratoren können den Lebenszyklus von Benutzerzuweisungen zu Anwendungen, die per Anwendungsproxy veröffentlicht werden, definieren und überwachen.

Sicherheit

• Nur Benutzer, die Anwendungen über die Gruppenmitgliedschaft oder individuell zugewiesen sind, können auf diese Anwendungen zugreifen.

Leistung

• Es gibt keine Beeinträchtigung der Anwendungsleistung im Vergleich zum Zugriff auf Die Anwendung über das interne Netzwerk.

Benutzerfreundlichkeit

• Benutzer wissen, wie sie auf ihre Anwendungen zugreifen können, weil sie auf allen Geräteplattformen vertraute Unternehmens-URLs verwenden können.

Überwachung

• Administratoren können die Zugriffsaktivitäten von Benutzern überwachen.

Bewährte Methoden für einen Pilotversuch

Ermitteln Sie die erforderliche Zeit und den Aufwand für die vollständige Einrichtung einer einzelnen Anwendung für den Remotezugriff mit einmaligem Anmelden (SSO). Führen Sie hierzu einen Pilotversuch durch, bei dem die anfängliche Ermittlung, die Veröffentlichung und ein allgemeiner Test berücksichtigt werden. Die Verwendung einer einfachen IIS-basierten Webanwendung, die bereits vorkonfiguriert für die integrierte Windows-Authentifizierung (IWA) ist, würde dazu beitragen, einen Basisplan einzurichten, da das Setup minimale Anstrengungen erfordert, um den Remotezugriff und SSO erfolgreich zu pilotieren.

Mit den folgenden Entwurfselementen erhöhen sich die Erfolgschancen Ihrer direkten Pilotimplementierung in einem Produktionsmandanten.

Connectorverwaltung:

Connectors spielen eine wichtige Rolle, wenn es um die Bereitstellung des lokalen Kommunikationskanals für Ihre Anwendungen geht. Die Verwendung der Connectorgruppe Standard ist für anfängliche Pilottests für veröffentlichte Anwendungen geeignet, bevor diese in der Produktion in Betrieb genommen werden. Anwendungen, die erfolgreich getestet wurden, können dann in Connectorgruppen in der Produktion verlagert werden.

Anwendungsverwaltung:

Ihre Mitarbeiter können sich am besten an eine externe URL erinnern, wenn diese vertraut und relevant ist. Vermeiden Sie die Veröffentlichung Ihrer Anwendung mit unseren vordefinierten msappproxy.net oder onmicrosoft.com Suffixen. Geben Sie stattdessen eine vertraute verifizierte Top-Level-Domain an, der ein logischer Hostname vorangestellt wird, z. B. intranet.<kunden_domain>.com.

Schränken Sie die Sichtbarkeit des Pilotanwendungssymbols für eine Pilotgruppe ein, indem Sie das Startsymbol im Azure MyApps-Portal ausblenden. Wenn Sie bereit für den Einsatz sind, können Sie die App entweder im selben Vorproduktionsmandanten auf die jeweilige Zielgruppe ausrichten oder die Anwendung in Ihrem Produktionsmandanten veröffentlichen.

Einstellungen für einmaliges Anmelden: Einige Einstellungen für einmaliges Anmelden verfügen über spezifische Abhängigkeiten, deren Einrichtung zeitaufwendig sein kann. Vermeiden Sie daher Verzögerungen bei der Änderungssteuerung, indem Sie sicherstellen, dass die Einrichtung der Abhängigkeiten rechtzeitig geregelt wird. Der Prozess umfasst Domänenbeitritts-Connector-Hosts, um SSO mithilfe der eingeschränkten Kerberos-Delegierung (Kerberos Constrained Delegation, KCD) durchzuführen und weitere zeitaufwändige Aktivitäten zu erledigen.

TLS zwischen Connectorhost und Zielanwendung: Da die Sicherheit an oberster Stelle steht, sollte zwischen dem Connectorhost und den Zielanwendungen immer TLS verwendet werden. Dies gilt vor allem, wenn die Webanwendung für die formularbasierte Authentifizierung (FBA) konfiguriert wird, da die Benutzeranmeldeinformationen dann auf effektive Weise als Klartext übertragen werden.

Inkrementelles Implementieren und Testen jedes Schritts: Führen Sie grundlegende funktionsbezogene Tests durch, nachdem Sie eine Anwendung veröffentlicht haben, um sicherzustellen, dass alle Benutzer- und Geschäftsanforderungen erfüllt sind:

Testen und überprüfen Sie den allgemeinen Zugriff auf die Webanwendung mit deaktivierter Vorauthentifizierung. Wenn dies erfolgreich ist, aktivieren Sie die Vorauthentifizierung und weisen Sie Aufgaben Benutzern und Gruppen zu. Testen und überprüfen Sie dann den Zugriff. Fügen Sie als Nächstes die SSO-Methode für Ihre Anwendung hinzu, und testen Sie erneut, um den Zugriff zu überprüfen. Wenden Sie abschließend nach Bedarf Richtlinien für bedingten Zugriff und MFA an. Testen und überprüfen Sie den Zugriff.

Problembehandlungstools: Starten Sie die Problembehandlung, indem Sie den Zugriff auf die veröffentlichte Anwendung direkt über den Browser auf dem Connectorhost überprüfen. Stellen Sie sicher, dass die Anwendung erwartungsgemäß funktioniert. Vereinfachen Sie Das Setup, um Probleme zu isolieren, z. B. die Verwendung eines einzelnen Connectors und das Deaktivieren von SSO. Tools wie Teleriks Fiddler können beim Debuggen von Zugriffs- oder Inhaltsproblemen helfen, indem der Datenverkehr nachverfolgt wird, einschließlich für mobile Plattformen wie iOS und Android. Weitere Informationen finden Sie im Leitfaden zur Problembehandlung.

Implementieren Ihrer Lösung

Bereitstellen des Anwendungsproxys

Die Schritte zum Bereitstellen Des Anwendungsproxys werden im Lernprogramm zum Hinzufügen einer lokalen Anwendung für den Remotezugriff behandelt. Falls die Installation nicht erfolgreich ist, wählen Sie im Portal die Option für die Problembehandlung für den Anwendungsproxy aus, oder verwenden Sie den Leitfaden für Probleme beim Installieren des Anwendungsproxy-Agent-Connectors.

Veröffentlichen von Anwendungen mit dem Anwendungsproxy

Das Veröffentlichen von Anwendungen setzt voraus, dass alle Voraussetzungen erfüllt sind und dass Sie über mehrere Connectors verfügen, die als registriert und aktiv auf der Seite des Anwendungsproxies angezeigt werden.

Sie können Anwendungen auch mit PowerShell veröffentlichen.

Bewährte Methoden zum Veröffentlichen einer Anwendung:

• Verwenden Sie Connectorgruppen: Weisen Sie eine Connectorgruppe zu, die für die Veröffentlichung jeder jeweiligen Anwendung festgelegt ist. Um Hochverfügbarkeit und Skalierung zu gewährleisten, sollten jeder Connectorgruppe mindestens zwei Connectors zugewiesen werden. Wenn Sie drei Anschlüsse haben, ist das optimal, falls Sie zu einem beliebigen Zeitpunkt eine Maschine warten müssen. Lesen Sie auch den Artikel Grundlegendes zu privaten Microsoft Entra-Netzwerkconnectorgruppen. Dort wird beschrieben, wie Sie Ihre Connectors mithilfe von Connectorgruppen nach Netzwerk oder Standort segmentieren.

• Set Back-End Application Timeout: Die Einstellung ist in Szenarien hilfreich, in denen die Anwendung möglicherweise mehr als 75 Sekunden zum Verarbeiten einer Clienttransaktion benötigt. Wenn z. B. ein Client eine Abfrage an eine Webanwendung sendet, die als Front-End an eine Datenbank fungiert. Das Front-End sendet die Abfrage an den Back-End-Datenbankserver und wartet auf eine Antwort, aber nach dem Zeitpunkt, zu dem sie eine Antwort empfängt, wird die Clientseite der Unterhaltung timeout. Das Festlegen des Timeouts auf "Long" stellt 180 Sekunden für längere Transaktionen zur Verfügung.

• Verwenden von geeigneten Cookietypen

  • HTTP-Only Cookie: Bietet zusätzliche Sicherheit, indem der Anwendungsproxy das HTTPOnly-Flag in Set-Cookie-HTTP-Antwortheadern enthält. Die Einstellung trägt dazu bei, Exploits wie websiteübergreifendes Skripting (XSS) zu minimieren. Lassen Sie "Nein" für Clients/Benutzer-Agents gesetzt, die Zugriff auf das Sitzungscookie erfordern. Beispiel: Verbindungsherstellung eines RDP/MTSC-Clients mit einem Remotedesktopgateway, das per Anwendungsproxy veröffentlicht wird.

  • Sicheres Cookie: Wenn ein Cookie mit dem Secure-Attribut festgelegt wird, enthält der Benutzer-Agent (clientseitige App) nur das Cookie in HTTP-Anforderungen, wenn die Anforderung über einen TLS-gesicherten Kanal übertragen wird. Die Einstellung trägt dazu bei, das Risiko zu verringern, dass ein Cookie über Klartextkanäle kompromittiert wird. Daher sollte dies aktiviert werden.

  • Beständiges Cookie: ermöglicht es, das Sitzungscookie des Anwendungsproxys zwischen Browserschließungen beizubehalten, indem es gültig bleibt, bis es abläuft oder gelöscht wird. Wird für Szenarien verwendet, in denen eine umfangreiche Anwendung, z. B. Office, auf ein Dokument innerhalb einer veröffentlichten Webanwendung zugreift, ohne dass der Benutzer zur Authentifizierung erneut aufgegriffen wird. Aktivieren Sie dies jedoch mit Vorsicht, da persistente Cookies letztendlich einen Dienst einem Risiko für unbefugten Zugriff aussetzen können, wenn sie nicht mit anderen ausgleichenden Schutzmaßnahmen verwendet werden. Diese Einstellung sollte nur für ältere Anwendungen verwendet werden, bei denen keine Cookies zwischen Prozessen freigegeben werden können. Es ist besser, Ihre Anwendung zu aktualisieren, um die Freigabe von Cookies zwischen Prozessen zu ermöglichen, anstatt die Einstellung zu nutzen.

• Übersetzen von URLs in Headern: Sie aktivieren die Einstellung für Szenarien, in denen interne DNS nicht so konfiguriert werden kann, dass sie mit dem öffentlichen Namespace (a.k.a Split DNS) der Organisation übereinstimmen. Wenn Ihre Anwendung den ursprünglichen Hostheader in der Clientanforderung nicht benötigt, lassen Sie den Wert auf "Ja" festgelegt. Die Alternative besteht darin, für den Connector den FQDN in der internen URL zu verwenden, um den eigentlichen Datenverkehr weiterzuleiten, und den FQDN in der externen URL als Hostheader. In den meisten Fällen sollte die Alternative es ermöglichen, dass die Anwendung bei einem Fernzugriff normal funktioniert, aber Ihre Benutzer verlieren die Vorteile einer einheitlichen internen und externen URL.

• URLs übersetzen in Anwendungstext: Aktivieren Sie für eine App die Option zum Übersetzen von Links im Anwendungstext, wenn Sie möchten, dass Links dieser App in Antworten an den Client übersetzt werden. Wenn diese Option aktiviert ist, versucht die Funktion, alle internen Links zu übersetzen, die der Anwendungsproxy in HTML- und CSS-Antworten findet, die an Clients zurückgegeben werden. Es ist nützlich, wenn Apps veröffentlicht werden, die entweder hartcodierte absolute oder NetBIOS-Kurznamenlinks in den Inhalten enthalten, oder Apps mit Inhalten, die mit anderen lokalen Anwendungen verknüpft sind.

Aktivieren Sie in Szenarien, in denen eine veröffentlichte App Links zu anderen veröffentlichten Apps enthält, die Linkübersetzung für jede Anwendung, damit Sie die Benutzeroberfläche auf App-Ebene steuern können.

Angenommen, Sie haben drei Anwendungen, die über den Anwendungsproxy veröffentlicht werden und miteinander verknüpft sind: Vorteile, Ausgaben und Reisen. Dazu gibt es eine vierte Anwendung, Feedback, die nicht über den Anwendungsproxy veröffentlicht wird.

Wenn die Linkübersetzung für die Vorteile-App aktiviert ist, werden Links zu den Ausgaben- und Reise-Apps zu ihren externen URLs umgeleitet, sodass externe Benutzer darauf zugreifen können. Links von Ausgaben und Reisen zu Leistungen funktionieren jedoch nicht, es sei denn, die Linkübersetzung ist auch für diese Apps aktiviert. Der Link zur Feedback-App wird nicht umgeleitet, da ihm eine externe URL fehlt. Dies verhindert, dass externe Benutzer über die Benefits-App darauf zugreifen können. Weitere Informationen finden Sie unter Linkübersetzung und Umleitungsoptionen.

Zugreifen auf Ihre Anwendung

Verwalten Sie den Zugriff auf veröffentlichte Ressourcen des Anwendungsproxys, indem Sie den Ansatz auswählen, der Ihrem Szenario und ihren Skalierbarkeitsanforderungen am besten entspricht. Allgemeine Methoden umfassen die Synchronisierung lokaler Gruppen über Microsoft Entra Connect, das Erstellen dynamischer Gruppen in Microsoft Entra ID basierend auf Benutzerattributen, das Aktivieren von Self-Service-Gruppen, die von Ressourcenbesitzern verwaltet werden, oder die Kombination dieser Strategien. Erkunden Sie die verknüpften Ressourcen, um die Vorteile der einzelnen Methoden zu verstehen.

Die einfachste Vorgehensweise beim Zuweisen des Zugriffs auf eine Anwendung für Benutzer ist die Verwendung der Optionen unter Benutzer und Gruppen im linken Bereich Ihrer veröffentlichten Anwendung und die direkte Zuweisung von Gruppen oder Einzelpersonen.

Sie können Benutzern auch den Self-Service-Zugriff auf Ihre Anwendung ermöglichen, indem Sie eine Gruppe zuweisen, in der die Benutzer derzeit nicht Mitglied sind, und die Self-Service-Optionen konfigurieren.

Wenn diese Option aktiviert ist, melden sich Benutzer beim MyApps-Portal an, um Den Zugriff anzufordern. Sie werden entweder automatisch genehmigt und der Self-Service-Gruppe hinzugefügt oder benötigen eine Genehmigung von einem benannten Genehmigenden.

Gastbenutzer können auch eingeladen werden, auf interne Anwendungen zuzugreifen, die per Anwendungsproxy über Microsoft Entra B2B veröffentlicht wurden.

Für lokale Anwendungen, auf die normalerweise anonym zugegriffen werden kann und keine Authentifizierung erforderlich ist, sollten Sie die Option in den Eigenschaften der Anwendung deaktivieren.

Wenn die Option auf "Nein" festgelegt ist, können Benutzer über den Microsoft Entra-Anwendungsproxy ohne Berechtigungen auf die lokale Anwendung zugreifen. Verwenden Sie daher vorsichtsvoll.

Nachdem Ihre Anwendung veröffentlicht wurde, sollte der Zugriff darauf möglich sein, indem die entsprechende externe URL in einem Browser eingegeben oder das Symbol unter https://myapps.microsoft.com verwendet wird.

Aktivieren der Vorauthentifizierung

Vergewissern Sie sich, dass anhand der externen URL über den Anwendungsproxy auf Ihre Anwendung zugegriffen werden kann.

1. Navigieren Sie zu Entra ID Enterprise-Apps>>Alle Anwendungen, und wählen Sie die App aus, die Sie verwalten möchten.

2. Wählen Sie Anwendungsproxy.

3. Wählen Sie im Feld Vorauthentifizierung in der Dropdownliste die Option Microsoft Entra ID und dann Speichern. Wenn die Vorauthentifizierung aktiviert ist, authentifiziert die Microsoft Entra-ID zuerst Benutzer. Wenn einmaliges Anmelden eingerichtet ist, überprüft die Back-End-Anwendung den Benutzer auch, bevor der Zugriff gewährt wird. Durch das Wechseln des Vorauthentifizierungsmodus von Passthrough zu Microsoft Entra ID wird die externe URL mit HTTPS gesichert, wodurch sichergestellt wird, dass jede Anwendung, die zunächst HTTP verwendet, jetzt über HTTPS arbeitet.

Einmaliges Anmelden aktivieren

SSO verbessert die Benutzererfahrung und Sicherheit, indem Benutzer sich einmal mit microsoft Entra-ID anmelden können. Nach der Vorauthentifizierung meldet sich der private Netzwerkconnector bei der lokalen Anwendung für den Benutzer an, sodass er so aussieht, als ob sich der Benutzer direkt angemeldet hat.

Bei Auswahl der Option Passthrough können Benutzer auf die veröffentlichte Anwendung zugreifen, ohne sich gegenüber Microsoft Entra ID authentifizieren zu müssen.

Um SSO zu aktivieren, muss Ihre Anwendung Benutzer mit Microsoft Entra-ID vorab authentifizieren. Ohne Vorauthentifizierung sind SSO-Optionen nicht verfügbar.

Lesen Sie Einmaliges Anmelden bei Anwendungen in Microsoft Entra ID, damit Sie beim Konfigurieren Ihrer Anwendungen die am besten geeignete SSO-Methode wählen können.

Arbeiten mit anderen Arten von Anwendungen

Der Microsoft Entra-Anwendungsproxy unterstützt Anwendungen, die mit der Microsoft Authentication Library (MSAL) erstellt wurden. Es verarbeitet systemeigene Client-Apps mithilfe von Microsoft Entra-ID-Token in Clientanforderungsheadern, um Benutzer vorab zu authentifizieren.

Erfahren Sie mehr über die verfügbaren Konfigurationen des Anwendungsproxys. Lesen Sie über die Veröffentlichung von nativen und mobilen Client-Apps sowie anspruchsbasierte Anwendungen.

Stärkung der Sicherheit mit bedingtem Zugriff

Für die Anwendungssicherheit sind erweiterte Sicherheitsfunktionen erforderlich, mit denen der Schutz vor und die Reaktion auf komplexe Bedrohungen in der lokalen Umgebung und in der Cloud sichergestellt werden kann. Verwenden Sie Richtlinien für bedingten Zugriff, um den Zugriff auf Ihre Anwendungen basierend auf vielen Bedingungen wie Standort, Risiko, Gerätetyp, Gerätekompatibilität und mehr zu steuern. Beispiele für Richtlinien, die Sie bereitstellen können, finden Sie im Artikel Vorlagen für bedingten Zugriff.

Die folgenden Funktionen können verwendet werden, um den Microsoft Entra-Anwendungsproxy zu unterstützen:

• Benutzer- und standortbasierter bedingter Zugriff: Schützen Sie vertrauliche Daten, indem Sie den Benutzerzugriff per geografischem Standort oder über eine IP-Adresse mit Richtlinien für den standortbasierten bedingten Zugriff einschränken.

• Gerätebasierter bedingter Zugriff: Stellen Sie per gerätebasiertem bedingtem Zugriff sicher, dass nur registrierte, genehmigte und konforme Geräte auf Unternehmensdaten zugreifen können.

• Anwendungsbasierter bedingter Zugriff: Wenn sich ein Benutzer außerhalb des Unternehmensnetzwerks befindet, muss ihn das nicht von der Arbeit abhalten. Schützen Sie den Zugriff auf die Cloud- und lokalen Apps des Unternehmens, und behalten Sie mit bedingtem Zugriff die Kontrolle.

• Risikobasierter bedingter Zugriff: Schützen Sie Ihre Daten vor böswilligen Hackern, indem Sie eine risikobasierte Richtlinie für bedingten Zugriff verwenden, die auf alle Apps und Benutzer angewendet werden kann – lokal und in der Cloud.

• „Meine Apps“ in Microsoft Entra: Nachdem Sie Ihren Anwendungsproxydienst bereitgestellt und die Anwendungen sicher veröffentlicht haben, können Sie für Ihre Benutzer einen einfachen Hub einrichten, über den sie alle ihre Anwendungen erkennen und auf sie zugreifen können. Steigern Sie über Meine Apps die Produktivität mit Self-Service-Funktionen, z. B. der Möglichkeit zum Anfordern des Zugriffs auf neue Apps und Gruppen oder zum Verwalten des Zugriffs auf diese Ressourcen im Namen von anderen Personen.

Verwalten Ihrer Implementierung

Erforderliche Rollen

Microsoft empfiehlt die Vorgehensweise, bei der jeweils die geringstmöglichen Rechte gewährt werden, die für die Erledigung der erforderlichen Aufgaben mit Microsoft Entra ID benötigt werden. Informieren Sie sich über die unterschiedlichen verfügbaren Azure-Rollen, und wählen Sie die passende Rolle aus, um die jeweiligen Anforderungen der einzelnen Personen zu erfüllen. Einige Rollen müssen vorübergehend angewendet und entfernt werden, nachdem die Bereitstellung abgeschlossen wurde.

Geschäftliche Rolle	Geschäftsaufgaben	Microsoft Entra-Rollen
Helpdesk-Administrator	Behandelt grundlegende Benutzerunterstützungsaufgaben wie das Zurücksetzen von Kennwörtern, das Ungültigstellen von Aktualisierungstoken und das Überprüfen des Dienststatus.	Helpdeskadministrator
Identitätsadministrator	Lesen von Microsoft Entra-Anmeldeberichten und -Überwachungsprotokollen zum Debuggen von Problemen, die sich auf den Anwendungsproxy beziehen.	Sicherheitsleseberechtigter
Anwendungsbesitzer	Erstellen und Verwalten aller Aspekte von Unternehmensanwendungen, Anwendungsregistrierungen und Anwendungsproxyeinstellungen.	Anwendungsadministrator
Infrastrukturadministrator	Zertifikatrollover-Besitzer	Anwendungsadministrator

Die Minimierung der Anzahl von Personen, die Zugriff auf sichere Informationen oder Ressourcen haben, tragen dazu bei, die Wahrscheinlichkeit zu verringern, dass ein böswilliger Akteur nicht autorisierten Zugriff erhält oder ein autorisierter Benutzer versehentlich eine sensible Ressource beeinflusst.

Um den administrativen Zugriff effektiv zu verwalten und eine ordnungsgemäße Überwachung sicherzustellen, empfehlen wir die Verwendung des Just-in-Time-Zugriffs (JIT) mit Privileged Identity Management. Dieses Vorgehen ermöglicht privilegierten Zugriff auf Azure-Ressourcen und Microsoft Entra ID nur bei tatsächlichem Bedarf.

Berichterstellung und Überwachung

Die Microsoft Entra-ID bietet weitere Einblicke in die Anwendungsnutzung und den Betriebsstatus Ihrer Organisation durch Überwachungsprotokolle und Berichte. Der Anwendungsproxy erleichtert auch das Überwachen von Connectors aus dem Microsoft Entra Admin Center und Windows-Ereignisprotokollen.

Überwachungsprotokolle für Anwendungen

Diese Protokolle enthalten ausführliche Informationen zu Anmeldungen bei Anwendungen, die mit einem Anwendungsproxy konfiguriert sind, sowie zum Gerät und dem Benutzer, das bzw. der auf die Anwendung zugreift. Überwachungsprotokolle stehen im Microsoft Entra Admin Center und in der Überwachungs-API zum Export bereit. Außerdem sind Nutzungs- und Insights-Berichte für Ihre Anwendung verfügbar.

Überwachung des privaten Netzwerkanschlusses

Die Connectors und der Dienst führen alle Aufgaben in Bezug auf Hochverfügbarkeit aus. Sie können den Status Ihrer Connectors auf der Seite „Anwendungsproxy“ im Microsoft Entra Admin Center überwachen. Weitere Informationen zur Connectorwartung finden Sie unter Grundlegendes zu Microsoft Entra Private Netzwerk-Connectors.

Windows-Ereignisprotokolle und -Leistungsindikatoren

Connectors verfügen über Administrator- und Sitzungsprotokolle. Die Administratorprotokolle enthalten wichtige Ereignisse und die dazugehörigen Fehler. Die Sitzungsprotokolle enthalten alle Transaktionen und die dazugehörigen Verarbeitungsdetails. Protokolle und Zähler befinden sich in den Windows-Ereignisprotokollen. Weitere Informationen finden Sie unter Verstehen Sie die privaten Microsoft Entra-Netzwerkanschlüsse. Folgen Sie dem Lernprogramm zum Konfigurieren von Ereignisprotokolldatenquellen in Azure Monitor.

Leitfaden zur Problembehandlung und zu den Schritten

Erfahren Sie mehr zu häufigen Problemen und ihrer Lösung, indem Sie unseren Leitfaden zur Problembehandlung für Fehlermeldungen verwenden.

Verwandte Inhalte

In den folgenden Artikeln werden allgemeine Szenarien behandelt, die Sie auch zum Erstellen eigener Problembehandlungsleitfäden für Ihren Support verwenden können.

• Links auf der Anwendungsseite, die nicht funktionieren, beheben
• Öffnen von Ports für meine App
• Einmaliges Anmelden konfigurieren
• Konfigurieren der eingeschränkten Kerberos-Delegierung
• Konfigurieren mit PingAccess
• Problembehandlung beim Zugriff auf die Unternehmensanwendung
• Problembehandlung beim Installieren des Anwendungsproxy-Agent-Connectors
• Fehlerbehebung bei Anmeldeproblemen