Häufig gestellte Fragen zum Microsoft Entra-Anwendungsproxy

Nein, die folgenden Konfigurationselemente werden vom App-Proxy verwendet und sollten nicht geändert oder gelöscht werden:

• Aktivieren/Deaktivieren von „Allow public clients flows“ (Öffentliche Clientflows zulassen).
• CWAP_AuthSecret (geheime Clientschlüssel).
• API-Berechtigungen. Wenn Sie eines der oben genannten Konfigurationselemente auf der Seite für die App-Registrierung ändern, wird die Vorauthentifizierung für den Microsoft Entra Anwendungsproxy unterbrochen.

Nein, Sie sollten eine Anwendungsproxy-App aus dem Bereich Unternehmensanwendungen im Microsoft Entra Admin Center löschen. Wenn Sie die Anwendungsproxy-App aus dem Bereich App-Registrierungen im Microsoft Entra Admin Center löschen, können Probleme auftreten.

Um Microsoft Entra-Anwendungsproxy verwenden zu können, benötigen Sie eine Microsoft Entra-ID P1 oder P2-Lizenz. Weitere Informationen zu den Preisen finden Sie unter Preise von Microsoft Entra

Wenn Ihre Lizenz abgelaufen ist, wird der Anwendungsproxy automatisch deaktiviert. Ihre Anwendungsinformationen werden bis zu einem Jahr gespeichert.

Stellen Sie sicher, dass Sie mindestens über eine P1- oder P2-Lizenz für Microsoft Entra ID verfügen und ein privater Microsoft Entra-Netzwerkconnector installiert ist. Nachdem Sie den ersten Connector erfolgreich installiert haben, wird der Microsoft Entra-Anwendungsproxydienst automatisch aktiviert.

Ja, der private Microsoft Entra-Netzwerkconnector wird vom Anwendungsproxy und vom Microsoft Entra-Privatzugriff verwendet. Weitere Informationen zum Connector finden Sie unter Privater Microsoft Entra-Netzwerkconnector. Informationen zur Problembehandlung bei der Connectorkonfiguration finden Sie unter Beheben von Problemen bei der Installation des privaten Netzwerkconnectors.

Wenngleich diese Suffixe in der Suffixliste angezeigt werden, sollten Sie sie nicht verwenden. Diese Domänensuffixe sind nicht für die Verwendung mit dem Microsoft Entra-Anwendungsproxy vorgesehen. Wenn Sie diese Domänensuffixe verwenden, funktioniert die erstellte Microsoft Entra Anwendungsproxyanwendung nicht. Sie können entweder das Standarddomänensuffix msappproxy.net oder eine benutzerdefinierte Domäne verwenden.

Microsoft Entra ID verfügt über einen Anwendungsproxydienst, mit dem Benutzer und Benutzerinnen auf lokale Anwendungen zugreifen können, indem sie sich mit ihrem Microsoft Entra-Konto anmelden. Wenn Sie Connectors in verschiedenen Regionen installiert haben, können Sie den Datenverkehr optimieren, indem Sie die nächstgelegene Clouddienstregion des Anwendungsproxys für jede Connectorgruppe auswählen. Weitere Informationen finden Sie unter Optimieren des Datenverkehrsflusses mit dem Microsoft Entra-Anwendungsproxy.

Nachdem Sie das SSL-Zertifikat hochgeladen haben, erhalten Sie im Portal die Meldung „Invalid certificate, possible wrong password“ (Ungültiges Zertifikat, möglicherweise falsches Kennwort).

So können Sie diesen Fehler z. B. beheben:

• Überprüfen Sie, ob Probleme mit dem Zertifikat vorliegen. Installieren Sie es auf Ihrem lokalen Computer. Wenn keine weiteren Probleme auftreten, ist das Zertifikat in Ordnung.
• Stellen Sie sicher, dass das Kennwort keine Sonderzeichen enthält. Das Kennwort sollte nur die Zeichen 0-9, A-Z und a-z enthalten.
• Wenn das Zertifikat mit Microsoft Software Key Storage Provider erstellt wurde, muss der RSA-Algorithmus verwendet werden.

Die Standarddauer beträgt 85 Sekunden. Die „lange“ Einstellung beträgt 180 Sekunden. Das Timeoutlimit kann nicht verlängert werden.

Nein, dies wird derzeit nicht unterstützt.

Der auch als CWAP_AuthSecret bezeichnete geheime Clientschlüssel wird dem Anwendungsobjekt (App-Registrierung) automatisch hinzugefügt, wenn die Microsoft Entra-Anwendungsproxy-App erstellt wird.

Der geheime Clientschlüssel ist ein Jahr lang gültig. Vor Ablauf des derzeit gültigen geheimen Clientschlüssels wird automatisch ein neuer geheimer Clientschlüssel erstellt. Drei geheime Clientschlüssel (CWAP_AuthSecret) sind jederzeit im Anwendungsobjekt gespeichert.

Nein, Sie müssen die ursprüngliche Fallbackdomäne verwenden.

Erwähnter Artikel: Hinzufügen und Ersetzen Ihrer onmicrosoft.com Fallbackdomäne in Microsoft 365

Auf der Seite „Anwendungsregistrierungen“ können Sie die Homepage-URL in die gewünschte externe URL der Landing Page ändern. Die angegebene Seite wird geladen, wenn die Anwendung über „Meine Apps“ oder das Office 365-Portal gestartet wird. Die Konfigurationsschritte finden Sie unter Festlegen einer benutzerdefinierten Startseite für veröffentlichte Apps mithilfe eines Microsoft Entra-Anwendungsproxys

Wenn die Microsoft Entra-Vorauthentifizierung konfiguriert ist und die Anwendungs-URL beim ersten Versuch, auf die Anwendung zuzugreifen, ein Nummernzeichen („#“) enthält, werden Sie zur Authentifizierung zu Microsoft Entra ID (login.microsoftonline.com) umgeleitet. Nachdem Sie die Authentifizierung abgeschlossen haben, werden Sie an den URL-Teil vor dem Rautezeichen umgeleitet, und der Teil nach dem Rautezeichen wird scheinbar ignoriert bzw. entfernt. Wenn die URL beispielsweise https://www.contoso.com/#/home/index.html lautet, wird der Benutzer nach Abschluss der Microsoft Entra-Authentifizierung zu https://www.contoso.com/ umgeleitet. Dies ist das vorgesehene Verhalten aufgrund der Verarbeitung des Rautezeichens durch den Browser.

Mögliche Lösungen/Alternativen:

• Richten Sie eine Umleitung von https://www.contoso.com zu https://contoso.com/#/home/index.html ein. Der Benutzer muss zuerst auf https://www.contoso.com zugreifen.
• Die für den ersten Zugriffsversuch verwendete URL muss das Rautezeichen (#) in codierter Form (%23) enthalten. Dies wird vom veröffentlichten Server möglicherweise nicht akzeptiert.
• Konfigurieren Sie den Vorauthentifizierungstyp „Passthrough“ (nicht empfohlen).

Nein, es gibt keine IIS-Anforderung für Anwendungen, die veröffentlicht werden. Sie können Webanwendungen veröffentlichen, die auf Servern ausgeführt werden, die nicht auf Windows Server basieren. Abhängig davon, ob der Webserver die Aushandlung (Kerberos-Authentifizierung) unterstützt, können Sie jedoch möglicherweise keine Vorauthentifizierung bei einem Nicht-Windows-Server verwenden. IIS ist nicht auf dem Server erforderlich, auf dem der Connector installiert ist.

Der Anwendungsproxy fügt HTTPS-Antworten nicht automatisch den HTTP Strict-Transport-Security-Header hinzu, behält jedoch den Header bei, wenn er sich in der ursprünglichen von der veröffentlichten Anwendung gesendeten Antwort befindet. Die Suche nach einer Einstellung zur Aktivierung dieser Funktion ist in Planung.

Nein, wenn das Protokoll http in der externen URL konfiguriert ist, akzeptiert der Microsoft Entra-Anwendungsproxy-Endpunkt eingehende Anforderungen an TCP-Port 80. Bei Verwendung des Protokolls https wird TCP-Port 443 verwendet.

Ja. Beispiele für interne URLs mit Ports sind http://app.contoso.local:8888/, https://app.contoso.local:8080/ und https://app.contoso.local:8081/test/.

Einige Antworten, die von den veröffentlichten Webanwendungen gesendet werden, können hartcodierte URLs enthalten. In diesem Fall muss mithilfe einer Linkübersetzungslösung sichergestellt werden, dass der Client immer die richtige URL verwendet. Lösungen für die Linkübersetzung können komplex sein und funktionieren möglicherweise nicht in allen Szenarios. Unsere dokumentierten Lösungen für die Linkübersetzung finden Sie hier.

Als bewährte Methode wird empfohlen, identische externe und interne URLs zu verwenden. Externe und interne URLs werden als identisch betrachtet, wenn protocol://hostname:port/path/ in beiden URLs identisch ist.

Dies kann mithilfe des Features Benutzerdefinierte Domänen erreicht werden.

Beispiele:

Identisch:

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com/test/

Nicht identisch:

External URL: https://app1.contoso.com/test/
Internal URL: http://app1.contoso.com/test/

External URL: https://app1.contoso.com/test/
Internal URL: https://app1.contoso.com:8080/test/

External URL: https://app1.msappproxy.net/test/
Internal URL: https://app1.contoso.com:/test/

Wenn die interne URL einen nicht standardmäßigen Port (nicht TCP 80/443) enthält, ist es nicht möglich, identische externe und interne URLs zu verwenden.

In einigen Szenarios müssen Änderungen an der Konfiguration der Web-App vorgenommen werden.

Die „PrincipalsAllowedToDelegateToAccount“-Methode wird verwendet, wenn sich Connectorserver in einer anderen Domäne befinden als das Webanwendungsdienstkonto. Dafür muss die ressourcenbasierte eingeschränkte Delegierung verwendet werden. Wenn sich die Connectorserver und das Webanwendungsdienstkonto in derselben Domäne befinden, können Sie „Active Directory-Benutzer und -Computer“ verwenden, um die Delegierungseinstellungen für die einzelnen Connectorcomputerkonten zu konfigurieren, sodass sie an den Ziel-SPN delegiert werden können.

Wenn sich die Connectorserver und das Webanwendungsdienstkonto in unterschiedlichen Domänen befinden, wird die ressourcenbasierte Delegierung verwendet. Die Delegierungsberechtigungen werden für den Zielwebserver und das Webanwendungsdienstkonto konfiguriert. Diese Methode der eingeschränkten Delegierung ist relativ neu. Die Methode wurde in Windows Server 2012 eingeführt. Dieses Betriebssystem unterstützt die domänenübergreifende Delegierung, indem der Besitzer der Ressource (des Webdiensts) steuern kann, welche Computer- und Dienstkonten die Delegierung ausführen können. Es gibt keine Benutzeroberfläche, die Sie bei dieser Konfiguration unterstützt, daher müssen Sie PowerShell verwenden. Weitere Informationen finden Sie im Whitepaper Grundlegendes zur eingeschränkten Kerberos-Delegierung mit dem Anwendungsproxy.

Die NTLM-Authentifizierung kann nicht als Vorauthentifizierung oder SSO-Methode verwendet werden. Die NTLM-Authentifizierung kann nur verwendet werden, wenn sie direkt zwischen dem Client und der veröffentlichten Webanwendung ausgehandelt werden kann. Bei Verwendung der NTLM-Authentifizierung wird in der Regel eine Anmeldeaufforderung im Browser angezeigt.

Nein, sie funktioniert nicht, da ein Gastbenutzer in Microsoft Entra ID nicht über das Attribut verfügt, das von den oben erwähnten Anmeldeidentitäten benötigt wird.

In diesem Fall wird ein Fallback auf „Benutzerprinzipalname“ durchgeführt. Weitere Details zum B2B-Szenario finden Sie unter Gewähren des Zugriffs auf lokale Anwendungen für B2B-Benutzer in Microsoft Entra ID.

Richtlinien für bedingten Zugriff werden nur für erfolgreich vorauthentifizierte Benutzer in Microsoft Entra ID erzwungen. Die Passthrough-Authentifizierung löst keine Microsoft Entra-Authentifizierung aus. Daher können keine Richtlinien für bedingten Zugriff erzwungen werden. Bei der Passthrough-Authentifizierung müssen MFA-Richtlinien auf dem lokalen Server implementiert werden (sofern möglich) oder durch Aktivieren der Vorauthentifizierung mit dem Microsoft Entra-Anwendungsproxy.

Nein, dieses Szenario wird nicht unterstützt, da der Anwendungsproxy den TLS-Datenverkehr beendet.

Entsprechende Informationen finden Sie unter Veröffentlichen des Remotedesktops per Microsoft Entra-Anwendungsproxy.

Nein, dieses Szenario wird nicht unterstützt.

Ja, das entspricht dem erwarteten Verhalten. Für das Szenario der Vorauthentifizierung ist ein ActiveX-Steuerelement erforderlich, das in Browsern von Drittanbietern nicht unterstützt wird.

Ja, dieses Szenario befindet sich derzeit in der öffentlichen Vorschau. Entsprechende Informationen finden Sie unter Veröffentlichen des Remotedesktops per Microsoft Entra-Anwendungsproxy.

Ja, das entspricht dem erwarteten Verhalten. Wenn der Computer des Benutzers Microsoft Entra eingebunden ist, meldet sich der Benutzer automatisch bei Microsoft Entra ID an. Der Benutzer muss seine Anmeldeinformationen nur auf dem RDWeb-Anmeldeformular angeben.

Mit dieser Option kann der Benutzer die RDP-Datei herunterladen und über einen anderen RDP-Client verwenden (außerhalb des Remotedesktop-Webclients). In der Regel können andere RDP-Clients (etwa der Microsoft-Remotedesktopclient) die Vorauthentifizierung nicht nativ verarbeiten. Deshalb funktioniert das Szenario nicht.

Entsprechende Informationen finden Sie unter Aktivieren des Remotezugriffs auf SharePoint per Microsoft Entra-Anwendungsproxy.

Die mobile SharePoint-App unterstützt derzeit keine Microsoft Entra-Vorauthentifizierung.

Nein, der Microsoft Entra-Anwendungsproxy ist für die Arbeit mit Microsoft Entra ID konzipiert und erfüllt nicht die Anforderungen, um als AD FS-Proxy fungieren zu können.

Nein, das wird nicht unterstützt.

Anwendungen, die das WebSocket-Protokoll verwenden, z. B. QlikSense und Remotedesktop-Webclient (HTML5), werden jetzt unterstützt. Es gelten die folgenden bekannten Einschränkungen:

• Der Anwendungsproxy verwirft das Cookie, das in der Serverantwort festgelegt ist, während die WebSocket-Verbindung geöffnet wird.
• Auf die WebSocket-Anforderung wird kein einmaliges Anmelden (Single Sign-On, SSO) angewendet.
• Die Features (Ereignisprotokolle, PowerShell und Remotedesktopdienste) im Windows Admin Center (WAC) funktionieren nicht über den Microsoft Entra-Anwendungsproxy.

Die WebSocket-Anwendung hat keine eindeutigen Veröffentlichungsanforderungen und kann auf dieselbe Weise wie alle anderen Anwendungsproxyanwendungen veröffentlicht werden.

Ja. Die Verwendung der Linkübersetzung wirkt sich auf die Leistung aus. Der Anwendungsproxydienst überprüft die Anwendung auf hartcodierte Links und ersetzt diese durch die entsprechenden veröffentlichten externen URLs, bevor sie Benutzern angezeigt werden.

Um eine optimale Leistung zu erzielen, empfiehlt sich die Verwendung von identischen internen und externen URLs durch die Konfiguration benutzerdefinierter Domänen. Wenn die Verwendung benutzerdefinierter Domänen nicht möglich ist, können Sie die Leistung der Linkübersetzung durch Verwenden der Erweiterung zur sicheren Anmeldung bei „Meine Apps“ oder des Microsoft Edge-Browsers auf mobilen Geräten verbessern. Weitere Informationen finden Sie unter Umleiten von hartcodierten Links für Apps, die mit Microsoft Entra-Anwendungsproxy veröffentlicht wurden.

Dieses Szenario wird nicht direkt unterstützt. Sie haben bei diesem Szenario die folgenden Möglichkeiten:

1. Veröffentlichen Sie die HTTP-URL und die HTTPS-URL als separate Anwendungen mit einem Platzhalter, aber weisen Sie diesen jeweils eine andere benutzerdefinierte Domäne zu. Diese Konfiguration funktioniert, weil unterschiedliche externe URLs verwendet werden.

2. Veröffentlichen Sie die HTTPS-URL über eine Platzhalteranwendung. Veröffentlichen Sie die HTTP-Anwendungen separat mithilfe der folgenden PowerShell-Cmdlets für den Anwendungsproxy:

   • Verwaltung von Anwendungsproxyanwendungen
   • Verwaltung privater Netzwerkconnectors