Publication d’applications avec SharePoint, Exchange et la passerelle des services Bureau à distance

Article
10/06/2023

S’applique à : Windows Server 2022, Windows Server 2019, Windows Server 2016

Ce contenu concerne la version locale du Proxy d’application Web. Pour permettre un accès sécurisé aux applications locales via le cloud, consultez le contenu du proxy d'application Microsoft Entra.

Cette rubrique décrit les tâches nécessaires pour publier avec SharePoint Server, Exchange Server, la passerelle des services Bureau à distance ou via web Proxy d'application.

Notes

Ces informations sont fournies telles qu’elles sont. Les services Bureau à distance prennent en charge et recommandent l’utilisation du proxy Azure App pour fournir un accès à distance sécurisé aux applications locales.

Publication SharePoint Server

Vous pouvez publier un site SharePoint à l'aide du Proxy d’application Web quand le site SharePoint est configuré pour l'authentification basée sur les revendications ou l'authentification Windows intégrée. Si vous souhaitez utiliser les services de fédération Active Directory (AD FS) pour la pré-authentification, vous devez configurer une partie de confiance à l’aide de l’un des Assistants.

Si le site SharePoint utilise l’authentification basée sur les revendications, vous devez utiliser l’Assistant Ajouter une approbation de partie de confiance afin de configurer l’approbation pour l’application.
Si le site SharePoint utilise l’authentification Windows intégrée, vous devez utiliser l’Assistant Ajouter une approbation de partie de confiance non basée sur les revendications afin de configurer l’approbation pour l’application. Vous pouvez utiliser IWA avec une application web basée sur les revendications du moment que vous configurez le contrôleur de domaine Kerberos (KDC).

Pour permettre aux utilisateurs de s'authentifier à l'aide de l'authentification Windows intégrée, le serveur Proxy d’application Web doit être joint à un domaine.

Vous devez configurer l’application pour prendre en charge la délégation contrainte Kerberos. Vous pouvez effectuer cette opération sur le contrôleur de domaine de n’importe quelle application. Vous pouvez également configurer l’application directement sur le serveur principal s’il s’exécute sur Windows Server 2012 R2 ou Windows Server 2012. Pour plus d’informations, voir Nouveautés de l’authentification Kerberos. Vous devez vous assurer que les serveurs du Proxy d’application Web sont configurés pour la délégation des noms de principal de service des serveurs principaux. Pour obtenir une procédure de configuration du Proxy d’application Web pour publier une application à l’aide de l’authentification Windows intégrée, voir Configurer un site pour l'utilisation de l’authentification Windows intégrée.

Si votre site SharePoint est configuré à l’aide des mappages d’accès de substitution (AAM) ou des collections de sites de noms d’hôtes, vous pouvez utiliser différentes URL du serveur externe et principal pour publier votre application. Toutefois, si vous ne configurez pas votre site SharePoint à l’aide de AAM ou des collections de sites hôtes, vous devez utiliser les mêmes URL de serveur externe et principal.

Publication Exchange Server

Le tableau suivant décrit les services Exchange que vous pouvez publier avec le Proxy d’application Web, ainsi que la pré-authentification prise en charge pour ces services :

Service Exchange	Pré-authentification	Notes
Outlook Web App	- AD FS utilisant l’authentification non basée sur les revendications - Pass-through - AD FS à l’aide de l’authentification basée sur les revendications pour Exchange 2013 Service Pack 1 (SP1) sur site	Pour plus d’informations, voir : Utiliser l’authentification basée sur les revendications AD FS avec Outlook Web App et le CAE
Panneau de configuration Exchange	Requête directe
Outlook Anywhere	Requête directe	Vous devez publier trois URL supplémentaires pour que Outlook Anywhere fonctionne correctement : - URL de découverte automatique, EWS et OAB (en cas de mode cache Outlook). - Nom d’hôte externe du serveur Exchange, autrement dit, l’URL configurée pour que les clients s’y connectent. - Nom de domaine complet interne du serveur Exchange.
Exchange ActiveSync	Requête directe AD FS à l’aide du protocole d’autorisation HTTP Basic
Exchange Web Services	Requête directe
Découverte automatique	Requête directe
Carnet d’adresses en mode hors connexion	Requête directe

Pour publier Outlook Web App à l’aide de l’authentification Windows intégrée, vous devez utiliser l’Assistant Ajouter une approbation de partie de confiance non basée sur les revendications afin de configurer l’approbation pour l’application.

Pour permettre aux utilisateurs de s’authentifier à l’aide de la délégation contrainte Kerberos, le serveur Proxy d’application Web doit être joint à un domaine.

Vous devez configurer l’application pour prendre en charge la délégation contrainte Kerberos. En outre, vous devez inscrire un nom de principal de service (SPN) sur le compte sous lequel le service web s’exécute. Vous pouvez le faire sur le contrôleur de domaine ou sur les serveurs principaux. Dans un environnement Exchange à charge équilibrée, cela nécessite l’utilisation du compte de service secondaire. Consultez Configuration de l’authentification Kerberos pour les serveurs d’accès au client à charge équilibrée

Vous pouvez également configurer l’application directement sur le serveur principal s’il s’exécute sur Windows Server 2012 R2 ou Windows Server 2012. Pour plus d’informations, voir Nouveautés de l’authentification Kerberos. Vous devez vous assurer que les serveurs du Proxy d’application Web sont configurés pour la délégation des noms de principal de service des serveurs principaux.

Publication de la passerelle Bureau à distance via le Proxy d'application web

Si vous souhaitez restreindre l’accès à votre passerelle d’accès à distance et ajouter une pré-authentification pour l’accès à distance, vous pouvez la déployer via le Proxy d’application Web. Il s’agit d’un bon moyen de s’assurer que vous disposez d’une pré-authentification complète pour RDG, y compris l’authentification multifacteur. La publication sans pré-authentification est également une option qui fournit un point d’entrée unique dans vos systèmes.

Comment publier une application dans RDG à l’aide de l’authentification directe Proxy d'application web

L’installation sera différente selon que vos rôles d’accès Web Bureau à distance (/rdweb) et de passerelle Bureau à distance (rpc) se trouvent sur le même serveur ou sur des serveurs différents.
Si les rôles Accès Web Bureau à distance et Passerelle Bureau à distance sont hébergés sur le même serveur RDG, vous pouvez simplement publier le nom de domaine complet racine dans le Proxy d’application Web, comme https://rdg.contoso.com/.

Vous pouvez également publier les deux répertoires virtuels individuellement, par exemplehttps://rdg.contoso.com/rdweb/ et https://rdg.contoso.com/rpc/.
Si l’accès Web Bureau à distance et la passerelle Bureau à distance sont hébergés sur des serveurs RDG distincts, vous devez publier les deux répertoires virtuels individuellement. Vous pouvez utiliser le même FQDN externe ou un différent, par exemple https://rdweb.contoso.com/rdweb/ et https://gateway.contoso.com/rpc/.
Si les FQDN externes et internes sont différents, vous ne devez pas désactiver la traduction d’en-tête de requête sur la règle de publication RDWeb. Pour ce faire, vous pouvez exécuter le script PowerShell suivant sur le serveur Proxy d’application Web, mais il doit être activé par défaut.
```
Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableTranslateUrlInRequestHeaders:$false
```
Notes

Si vous devez prendre en charge des clients riches tels que les connexions RemoteApp et Bureau à distance ou les connexions Bureau à distance iOS, ceux-ci ne prennent pas en charge la pré-authentification. Vous devez donc publier RDG à l’aide de l’authentification directe.

Comment publier une application dans RDG à l’aide du Proxy d'application Web avec une pré-authentification

Le Proxy d'application web pré-authentification avec RDG fonctionne en transmettant le cookie de pré-authentification obtenu par Internet Explorer passé au client de connexion Bureau à distance (mstsc.exe). Il est ensuite utilisé par le client de connexion Bureau à distance (mstsc.exe). Il est ensuite utilisé par le client de connexion Bureau à distance comme preuve d’authentification.

La procédure suivante indique au serveur de collection d’inclure les propriétés RDP personnalisées nécessaires dans les fichiers RDP d’application distante envoyés aux clients. Ceux-ci indiquent au client que la pré-authentification est requise et de transmettre les cookies pour l’adresse du serveur de pré-authentification au client de connexion Bureau à distance (mstsc.exe). Conjointement avec la désactivation de la fonctionnalité HttpOnly sur l’application web Proxy d'application, cela permet au client de connexion Bureau à distance (mstsc.exe) d’utiliser le cookie Proxy d’application Web obtenu via le navigateur.

L’authentification auprès du serveur d’accès web Bureau à distance utilise toujours l’ouverture de session du formulaire Accès Web Bureau à distance. Cela fournit le moins d’invites d’authentification utilisateur, car le formulaire d’ouverture de session Accès Web Bureau à distance crée une banque d’informations d’identification côté client qui peut ensuite être utilisé par le client de connexion Bureau à distance (mstsc.exe) pour tout lancement ultérieur de l’application à distance.
Tout d’abord, créez une approbation manuelle de partie de confiance dans AD FS comme si vous publiiez une application prenant en charge les revendications. Cela signifie que vous devez créer une approbation de partie de confiance factice qui est là pour appliquer la pré-authentification, afin d’obtenir une pré-authentification sans délégation Kerberos contrainte au serveur publié. Une fois qu’un utilisateur s’est authentifié, tout le reste est transmis.

Avertissement

Il peut sembler que l’utilisation de la délégation est préférable, mais qu’elle ne résout pas entièrement les exigences de l’authentification unique mstsc et qu’il existe des problèmes lors de la délégation au répertoire /rpc, car le client s’attend à gérer l’authentification de passerelle Bureau à distance elle-même.
Pour créer une approbation manuelle de partie de confiance, suivez les étapes de la console de gestion AD FS :
1. Utilisez l’Assistant Ajout d'une partie de confiance
2. Sélectionnez Entrer manuellement les données sur la partie de confiance.
3. Acceptez tous les paramètres par défaut.
4. Pour l’identificateur d’approbation de partie de confiance, entrez le nom de domaine complet externe que vous utiliserez pour l’accès RDG, par exemple https://rdg.contoso.com/.
  
  Il s’agit de l’approbation de partie de confiance que vous allez utiliser lors de la publication de l’application dans web Proxy d'application.
Publiez la racine du site (par exemple, https://rdg.contoso.com/) dans le Proxy d’application Web. Définissez la pré-authentification sur AD FS et utilisez l’approbation de partie de confiance que vous avez créée ci-dessus. Cela permet à /rdweb et /rpc d’utiliser le même cookie d’authentification Proxy d’application Web.

Il est possible de publier /rdweb et /rpc en tant qu’applications distinctes et même d’utiliser différents serveurs publiés. Vous devez simplement vous assurer que vous publiez les deux à l’aide de la même approbation de partie de confiance que le jeton Proxy d’application Web est émis pour l’approbation de partie de confiance et est donc valide dans les applications publiées avec la même approbation de partie de confiance.
Si les FQDN externes et internes sont différents, vous ne devez pas désactiver la traduction d’en-tête de requête sur la règle de publication RDWeb. Pour ce faire, vous pouvez exécuter le script PowerShell suivant sur le serveur web Proxy d'application, mais il doit être activé par défaut :
```
Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableTranslateUrlInRequestHeaders:$true
```
Désactivez la propriété de cookie HttpOnly dans Proxy d’application Web sur l’application publiée RDG. Pour autoriser le contrôle ActiveX RDG à accéder au cookie d’authentification web Proxy d'application, vous devez désactiver la propriété HttpOnly sur le cookie Proxy d'application Web.

Pour cela, vous devez installer le correctif cumulatif de novembre 2014 pour Windows RT 8.1, Windows 8.1 et Windows Server 2012 R2 (KB3000850).

Après avoir installé le correctif logiciel, exécutez le script PowerShell suivant sur le serveur Proxy d’application Web en spécifiant le nom d’application approprié :
```
Get-WebApplicationProxyApplication applicationname | Set-WebApplicationProxyApplication -DisableHttpOnlyCookieProtection:$true
```
La désactivation de HttpOnly permet au contrôle ActiveX RDG d’accéder au cookie d’authentification Proxy d’application Web.
Configurez la collection RDG appropriée sur le serveur de collecte pour informer le client de connexion Bureau à distance (mstsc.exe) que la pré-authentification est requise dans le fichier rdp.
- Dans Windows Server 2012 et Windows Server 2012 R2, vous pouvez exécuter le cmdlet PowerShell suivant sur le serveur de collecte RDG :
```
Set-RDSessionCollectionConfiguration -CollectionName "<yourcollectionname>" -CustomRdpProperty "pre-authentication server address:s: <https://externalfqdn/rdweb/>`nrequire pre-authentication:i:1"
```
  Veillez à supprimer les crochets < et > lorsque vous remplacez par vos propres valeurs, par exemple :
```
Set-RDSessionCollectionConfiguration -CollectionName "MyAppCollection" -CustomRdpProperty "pre-authentication server address:s: https://rdg.contoso.com/rdweb/`nrequire pre-authentication:i:1"
```
- Dans Windows Server 2008 R2 :
  1. Connectez-vous à Terminal Server avec un compte disposant de privilèges d’administrateur.
  2. Accédez à Démarrer>Outils d’administration>Terminal Services>TS RemoteApp Manager.
  3. Dans le volet Vue d’ensemble de TS RemoteApp Manager, en regard de Paramètres RDP, cliquez sur Modifier.
  4. Sous l’onglet Paramètres RDP personnalisés, tapez les paramètres RDP suivants dans la zone Paramètres RDP personnalisés :
    
    pre-authentication server address: s: https://externalfqdn/rdweb/
    
    require pre-authentication:i:1
  5. Quand vous avez terminé, cliquez sur Appliquer.
    
    Cela indique au serveur de collection d’inclure les propriétés RDP personnalisées dans les fichiers RDP envoyés aux clients. Ceux-ci indiquent au client que la pré-authentification est requise et de transmettre les cookies pour l’adresse du serveur de pré-authentification au client de connexion Bureau à distance (mstsc.exe). Cela, conjointement avec la désactivation de HttpOnly sur l’application web Proxy d'application, permet au client de connexion Bureau à distance (mstsc.exe) d’utiliser le cookie d’authentification Proxy d’application Web obtenu via le navigateur.
    
    Pour plus d’informations sur RDP, consultez Configuration du scénario de mot de passe à usage unique de la passerelle TS.