Veröffentlichen von Anwendungen mit SharePoint, Exchange und RDG

Diese Inhalte sind für die lokale Version des Webanwendungsproxys relevant. Eine Anleitung zum Einrichten des sicheren Zugriffs auf lokale Anwendungen über die Cloud finden Sie in den Inhalten zum Microsoft Entra-Anwendungsproxy.

In diesem Thema werden die Aufgaben beschrieben, die zum Veröffentlichen von SharePoint Server, Exchange Server oder Remotedesktopgateway (RDG) über Webanwendungsproxy erforderlich sind.

Veröffentlichen von SharePoint Server

Sie können eine SharePoint-Website über Webanwendungsproxy veröffentlichen, wenn die SharePoint-Website für die anspruchsbasierte Authentifizierung oder integrierte Windows-Authentifizierung konfiguriert ist. Falls Active Directory-Verbunddienste (AD FS) für die Vorauthentifizierung genutzt werden soll, müssen Sie mithilfe eines Assistenten eine vertrauende Seite konfigurieren.

• Wenn die SharePoint-Website die anspruchsbasierte Authentifizierung verwendet, müssen Sie den Assistenten zum Hinzufügen der Vertrauensstellung der vertrauenden Seite für die Anwendung verwenden.

• Wenn die SharePoint-Website die integrierte Windows-Authentifizierung verwendet, müssen Sie den nicht anspruchsbasierten Assistenten zum Hinzufügen der Vertrauensstellung der vertrauenden Seite für die Anwendung verwenden. IWA kann mit einer anspruchsbasierten Webanwendung genutzt werden, sofern KDC entsprechend konfiguriert ist.

  Der Webanwendungsproxy-Server muss in eine Domäne eingebunden werden, um Benutzern die Authentifizierung mithilfe der integrierten Windows-Authentifizierung zu erlauben.

  Sie müssen die Anwendung zur Unterstützung der eingeschränkten Kerberos-Delegierung konfigurieren. Diese Konfiguration kann auf dem Domänencontroller für jede Anwendung vorgenommen werden. Sie kann die Anwendung auch direkt auf dem Back-End-Server konfigurieren, sofern dieser unter Windows Server 2012 R2 oder Windows Server 2012 ausgeführt wird. Weitere Informationen finden Sie unter What's New in Kerberos Authentication. Sie müssen zudem sicherstellen, dass die Webanwendungsproxy-Server für die Delegierung an die Dienstprinzipalnamen der Back-End-Server konfiguriert sind. Eine exemplarische Vorgehensweise zum Konfigurieren des Webanwendungsproxys zum Veröffentlichen einer Anwendung mithilfe der integrierten Windows-Authentifizierung finden Sie unter Konfigurieren einer Website für die integrierte Windows-Authentifizierung.

Wenn die SharePoint-Website mithilfe alternativer Zugriffszuordnungen (AAM) oder hostbenannter Websitesammlungen konfiguriert ist, können Sie jeweils verschiedene URLs der externen und Back-End-Server zur Veröffentlichung Ihrer Anwendung verwenden. Wenn die SharePoint-Website jedoch nicht mithilfe von AAM oder hostbenannten Websitesammlungen konfiguriert ist, müssen Sie jeweils die gleichen externen und Back-End-Server-URLs verwenden.

Veröffentlichen von Exchange Server

In der folgenden Tabelle werden die Exchange-Dienste, die Sie über Webanwendungsproxy veröffentlichen können, und die unterstützte Vorauthentifizierung für diese Dienste beschrieben:

Um Outlook Web App mithilfe der integrierten Windows-Authentifizierung zu veröffentlichen, müssen Sie den nicht anspruchsbasierten Assistenten zum Hinzufügen der Vertrauensstellung der vertrauenden Seite für die Anwendung verwenden.

Der Webanwendungsproxy-Server muss in eine Domäne eingebunden werden, um Benutzern die Authentifizierung mithilfe der eingeschränkte Kerberos-Delegierung zu erlauben.

Sie müssen die Anwendung zur Unterstützung der Kerberos-Authentifizierung konfigurieren. Darüber hinaus müssen Sie einen Dienstprinzipalnamen (Service Principal Name, SPN) im Konto registrieren, unter dem der Webdienst ausgeführt wird. Dies kann auf dem Domänencontroller oder den Back-End-Servern erfolgen. In einer Exchange-Umgebung mit Lastenausgleich erfordert dies das alternative Dienstkonto. Weitere Informationen finden Sie unter Konfigurieren der Kerberos-Authentifizierung für Clientzugriffsserver mit Lastenausgleich.

Sie können die Anwendung auch direkt auf dem Back-End-Server konfigurieren, sofern dieser unter Windows Server 2012 R2 oder Windows Server 2012 ausgeführt wird. Weitere Informationen finden Sie unter What's New in Kerberos Authentication. Sie müssen zudem sicherstellen, dass die Webanwendungsproxy-Server für die Delegierung an die Dienstprinzipalnamen der Back-End-Server konfiguriert sind.

Veröffentlichen von Remotedesktopgateway über Webanwendungsproxy

Wenn Sie den Zugriff auf Ihre Remotezugriffsgateway-Instanz (RDG) einschränken und die Vorauthentifizierung für den Remotezugriff hinzufügen möchten, können Sie dafür Webanwendungsproxy nutzen. Dies ist eine wirklich gute Möglichkeit, um sicherzustellen, dass Sie über eine umfassende Vorabauthentifizierung für das RDG einschließlich MFA verfügen. Die Veröffentlichung ohne Vorauthentifizierung ist ebenfalls eine Option und bietet einen zentralen Einstiegspunkt in Ihre Systeme.

Veröffentlichen einer Anwendung in RDG mithilfe von Webanwendungsproxy mit Passthrough-Authentifizierung

1. Die Installation unterscheidet sich je nachdem, ob sich die Rollen „Web Access für Remotedesktop“ (/rdweb) und „RD-Gateway“ (rpc) auf demselben oder unterschiedlichen Servern befinden.

2. Wenn die Rollen „Web Access für Remotedesktop“ und „RD-Gateway“ auf demselben RDG-Server gehostet werden, können Sie einfach den Stamm-FQDN in Webanwendungsproxy veröffentlichen, wie z. B. https://rdg.contoso.com/.

   Sie können die beiden virtuellen Verzeichnisse auch einzeln veröffentlichen, z. B. https://rdg.contoso.com/rdweb/ und https://rdg.contoso.com/rpc/.

3. Wenn „Web Access für Remotedesktop“ und „RD-Gateway“ auf separaten RDG-Servern gehostet werden, müssen Sie die beiden virtuellen Verzeichnisse einzeln veröffentlichen. Sie können dieselben oder andere externe FQDNs verwenden, z. B. https://rdweb.contoso.com/rdweb/ und https://gateway.contoso.com/rpc/.

4. Wenn sich die externen und internen FQDNs unterscheiden, sollten Sie die Übersetzung des Anforderungsheaders für die RDWeb-Veröffentlichungsregel nicht deaktivieren. Dies kann durch Ausführen des folgenden PowerShell-Skripts auf dem Webanwendungsproxy-Server erfolgen, sie sollte jedoch standardmäßig aktiviert sein.

   Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableTranslateUrlInRequestHeaders:$false
   

   Hinweis

   Wenn Sie Clients wie RemoteApp und Desktopverbindungen oder iOS-Remotedesktopverbindungen unterstützen müssen, wird von diesen keine Vorabauthentifizierung unterstützt, sodass Sie RDG mithilfe der Passthrough-Authentifizierung veröffentlichen müssen.

Veröffentlichen einer Anwendung in RDG mithilfe von Webanwendungsproxy mit Vorauthentifizierung

1. Die Vorauthentifizierung von Webanwendungsproxy mit RDG funktioniert, indem das von Internet Explorer abgerufene Vorauthentifizierungscookie an den Remotedesktopverbindungs-Client (mstsc.exe) übergeben wird. Es wird anschließend vom Remotedesktopverbindungs-Client (mstsc.exe) verwendet. Dieses wird dann vom Remotedesktopverbindungs-Client als Authentifizierungsnachweis verwendet.

   Das folgende Verfahren weist den Sammlungsserver an, die erforderlichen benutzerdefinierten RDP-Eigenschaften in die RDP-Dateien der Remote-App einzuschließen, die an Clients gesendet werden. Diese teilen dem Client mit, dass eine Vorauthentifizierung erforderlich ist und dass er die Cookies für die Adresse des Vorauthentifizierungsservers an den Remotedesktopverbindungs-Client (mstsc.exe) übergeben soll. In Verbindung mit der Deaktivierung des Features HttpOnly in der Anwendung „Webanwendungsproxy“ kann der Remotedesktopverbindungs-Client (mstsc.exe) das über den Browser abgerufene Webanwendungsproxy-Cookie verwenden.

   Für die Authentifizierung beim „Web Access für Remotedesktop“-Server wird weiterhin die „Web Access für Remotedesktop“-Formularanmeldung verwendet. Diese stellt die geringste Anzahl von Benutzerauthentifizierungsaufforderungen bereit, da das „Web Access für Remotedesktop“-Anmeldeformular einen clientseitigen Anmeldeinformationsspeicher erstellt, der dann vom Remotedesktopverbindungs-Client (mstsc.exe) für jeden nachfolgenden Start einer Remote-App verwendet werden kann.

2. Erstellen Sie zunächst in AD FS eine manuelle Vertrauensstellung der vertrauenden Seite, als ob Sie eine für Ansprüche aktivierte App veröffentlichen würden. Dies bedeutet, dass Sie eine Pseudovertrauensstellung der vertrauenden Seite erstellen müssen, die zum Erzwingen der Vorauthentifizierung vorhanden ist, damit Sie eine Vorabauthentifizierung ohne eingeschränkte Kerberos-Delegierung auf dem veröffentlichten Server erreichen. Sobald sich ein Benutzer authentifiziert hat, wird alles andere durchgeleitet.

   Warnung

   Die Delegierung ist zwar auf den ersten Blick empfehlenswert, aber sie erfüllt die SSO-Anforderungen von mstsc nicht vollständig. Außerdem gibt es Probleme bei der Delegierung an das Verzeichnis „/rpc“, da der Client erwartet, dass er die RD-Gateway-Authentifizierung selbst vornimmt.

3. Führen Sie zum Erstellen einer manuellen Vertrauensstellung der vertrauenden Seite in der AD FS-Verwaltungskonsole diese Schritte aus:

   1. Verwenden Sie den Assistenten zum Hinzufügen der Vertrauensstellung der vertrauenden Seite.

   2. Wählen Sie Daten über diese vertrauende Seite manuell eingeben aus.

   3. Übernehmen Sie alle Standardeinstellungen.

   4. Geben Sie für den Bezeichner „Vertrauensstellung der vertrauenden Seite“ den externen FQDN ein, den Sie für den RDG-Zugriff verwenden, z. B https://rdg.contoso.com/.

      Dies ist die Vertrauensstellung der vertrauenden Seite, die Sie beim Veröffentlichen der App in Webanwendungsproxy verwenden.

4. Veröffentlichen Sie den Stamm der Website (z. B. https://rdg.contoso.com/) in Webanwendungsproxy. Legen Sie die Vorauthentifizierung auf AD FS fest, und verwenden Sie die Vertrauensstellung der vertrauenden Seite, die Sie oben erstellt haben. Dadurch können „/rdweb“ und „/rpc“ dasselbe Authentifizierungscookie von Webanwendungsproxy nutzen.

   Es ist möglich, „/rdweb“ und „/rpc“ als separate Anwendungen zu veröffentlichen und sogar verschiedene veröffentlichte Server einzusetzen. Sie müssen nur sicherstellen, dass Sie beide mit derselben Vertrauensstellung der vertrauenden Seite veröffentlichen, da das Webanwendungsproxy-Token für die Vertrauensstellung der vertrauenden Seite ausgestellt wird und daher für alle Anwendungen gültig ist, die mit derselben Vertrauensstellung der vertrauenden Seite veröffentlicht werden.

5. Wenn sich die externen und internen FQDNs unterscheiden, sollten Sie die Übersetzung des Anforderungsheaders für die RDWeb-Veröffentlichungsregel nicht deaktivieren. Dies kann durch Ausführen des folgenden PowerShell-Skripts auf dem Webanwendungsproxy-Server erfolgen, sie sollte jedoch standardmäßig aktiviert sein.

   Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableTranslateUrlInRequestHeaders:$true
   

6. Deaktivieren Sie die Cookieeigenschaft HttpOnly in Webanwendungsproxy für die veröffentlichte RDG-Anwendung. Um dem ActiveX-Steuerelement für RDG Zugriff auf das Authentifizierungscookie von Webanwendungsproxy zu gewähren, müssen Sie die Eigenschaft HttpOnly im Webanwendungsproxy-Cookie deaktivieren.

   Dazu müssen Sie das Updaterollup vom November 2014 für Windows RT 8.1, Windows 8.1 und Windows Server 2012 R2 (KB3000850) installieren.

   Führen Sie nach Installation des Hotfix das folgende PowerShell-Skript auf dem Webanwendungsproxy-Server aus, und geben Sie dabei den Namen der betreffenden Anwendung an:

   Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableHttpOnlyCookieProtection:$true
   

   Das Deaktivieren von HttpOnly ermöglicht dem ActiveX-Steuerelement für RDG Zugriff auf das Authentifizierungscookie von Webanwendungsproxy.

7. Konfigurieren Sie die relevante RDG-Sammlung auf dem Sammlungsserver, um dem Remotedesktopverbindungs-Client (mstsc.exe) mitzuteilen, dass eine Vorabauthentifizierung in der RDP-Datei erforderlich ist.

   • Unter Windows Server 2012 und Windows Server 2012 R2 können Sie dies erreichen, indem Sie das folgende PowerShell-Cmdlet auf dem RDG-Sammlungsserver ausführen:

     Set-RDSessionCollectionConfiguration -CollectionName "<yourcollectionname>" -CustomRdpProperty "pre-authentication server address:s: <https://externalfqdn/rdweb/>`nrequire pre-authentication:i:1"
     

     Achten Sie darauf, dass Sie die Klammern < und > entfernen, wenn Sie eine Ersetzung durch eigene Werte vornehmen wie z. B.:

     Set-RDSessionCollectionConfiguration -CollectionName "MyAppCollection" -CustomRdpProperty "pre-authentication server address:s: https://rdg.contoso.com/rdweb/`nrequire pre-authentication:i:1"
     

   • In Windows Server 2008 R2:

     1. Melden Sie sich beim Terminalserver mit einem Konto mit Administratorrechten an.

     2. Navigieren Sie zu Start>Verwaltungstools>Terminaldienste>TS-RemoteApp Manager.

     3. Klicken Sie im Bereich Übersicht von TS-RemoteApp Manager neben „RDP-Einstellungen“ auf Ändern.

     4. Geben Sie auf der Registerkarte Benutzerdefinierte RDP-Einstellungen die folgenden RDP-Einstellungen in das Feld „Benutzerdefinierte RDP-Einstellungen“ ein:

        pre-authentication server address: s: https://externalfqdn/rdweb/

        require pre-authentication:i:1

     5. Wenn Sie fertig sind, klicken Sie auf Übernehmen.

        Dadurch wird der Sammlungsserver angewiesen, die benutzerdefinierten RDP-Eigenschaften in die RDP-Dateien einzuschließen, die an Clients gesendet werden. Diese teilen dem Client mit, dass eine Vorauthentifizierung erforderlich ist und dass er die Cookies für die Adresse des Vorauthentifizierungsservers an den Remotedesktopverbindungs-Client (mstsc.exe) übergeben soll. In Verbindung mit der Deaktivierung des Features HttpOnly in der Anwendung „Webanwendungsproxy“ kann der Remotedesktopverbindungs-Client (mstsc.exe) das über den Browser abgerufene Authentifizierungscookie für Webanwendungsproxy verwenden.

        Weitere Informationen zu RDP finden Sie unter Konfigurieren des Szenarios mit Einmalkennwort für TS-Gateway.

Siehe auch

• Planen der Anwendungsveröffentlichung mithilfe des Webanwendungsproxy

• Problembehandlung: Webanwendungsproxy

• Handbuch mit exemplarischer Vorgehensweise für den Webanwendungsproxy