Planifier la connectivité de Microsoft 365 vers SharePoint Server

S’APPLIQUE À :  yes-img-13 2013  yes-img-16 2016  yes-img-19 2019  yes-img-se Subscription Edition  yes-img-sop SharePoint in Microsoft 365

Cet article est conçu pour vous aider à planifier et préparer la configuration de la connectivité entrante de Microsoft 365 pour les entreprises à SharePoint Server via un périphérique proxy inverse. Ceci est requis pour les environnements hybrides suivants :

  • Recherche hybride entrante (affichage des résultats de recherche à partir SharePoint Server dans Microsoft 365)

  • Business Connectivity Services hybride

Dans cet article, nous vous présentons les informations que vous devez connaître, telles que les conditions préalables, et une feuille de calcul pour collecter les informations nécessaires avant de commencer le processus de configuration.

Cette rubrique vous aidera à :

  • Comprendre les conditions préalables et les conditions requises pour la connectivité entrante

  • Planifier l’architecture de votre application web

  • Planifier les certificats SSL

  • Enregistrer les décisions clés et les informations

Collecter et enregistrer les informations du journal de feuille de calcul et de build

Feuille de calcul. Pendant le processus de planification, vous devez collecter des informations et des fichiers. Il est important d’utiliser la feuille de SharePoint hybride pour suivre les informations de planification et de déploiement à référencer et pour les partager avec d’autres membres de votre équipe de déploiement. Nous ne pouvons pas souligner suffisamment l’importance de l’utilisation de cette feuille de calcul pour organiser vos informations avant de commencer le processus de configuration.

Créez un journal de build. Comme dans tout projet d’implémentation complexe, un enregistrement détaillé de chaque décision de conception, configuration du serveur, procédure, sortie de commande et erreur est une référence très importante pour la résolution des problèmes, la prise en charge et la sensibilisation. Nous vous recommandons vivement de documenter minutieusement votre processus de déploiement.

Attention

Pour des raisons de sécurité, stockez la feuille de calcul et le journal de build dans un endroit sécurisé, comme un partage de fichiers ou des SharePoint sécurisés dans une bibliothèque de documents Microsoft 365, et accordez des autorisations uniquement aux administrateurs impliqués dans le processus de déploiement et qui doivent connaître ces informations.

Collecter et enregistrer des informations sur l’URL et le nom d’hôte

Dans cette section, vous enregistrez des informations sur les URL et les noms d’hôte dans votre environnement. Vous utiliserez ces informations pendant le processus de déploiement.

  • Enregistrez le nom de domaine DNS public de votre entreprise (par exemple, adventureworks.com).

  • Enregistrez l’URL du point de terminaison public du périphérique de proxy inverse que vous utiliserez pour SharePoint hybride. Il s’agit de l’URL externe. Si ce point de terminaison n’existe pas encore, vous devez déterminer quelle sera cette URL.

  • Enregistrez l’adresse IP du point de terminaison externe du périphérique de proxy inverse.

  • Assurez-vous qu’un enregistrement A (également connu sous le nom d’enregistrement hôte) existe dans la zone de recherche d’accès avant DNS publique pour votre domaine public qui mappait l’URL externe à l’adresse IP du point de terminaison connecté à Internet sur le périphérique de proxy inverse. Si vous n’avez pas encore cet enregistrement A, créez-le maintenant.

  • Assurez-vous qu’un enregistrement A existe dans la zone de recherche avant DNS intranet qui mapille le nom d’hôte de votre batterie de serveurs SharePoint à son adresse IP. Si vous n’avez pas encore cet enregistrement A, créez-le maintenant.

    Important

    Si vous configurez des URL internes pour accéder à une application web pendant le processus de déploiement, veillez à également créer des enregistrements A pour ces URL dans la zone de recherche avant DNS intranet et à les enregistrer dans la feuille de calcul.

   
Icône Modifier Enregistrez les informations suivantes dans le tableau 3 de la feuille de SharePoint hybride :
Nom de domaine du domaine DNS d’entreprise public dans la ligne Nom de domaine Internet public.
URL du point de terminaison public du périphérique de proxy inverse dans la ligne URL externe.
Adresse IP du point de terminaison externe du périphérique de proxy inverse dans l’adresse IP de la ligne de point de terminaison externe.

Planifier l’architecture de votre application web

Cette section vous aide à planifier l’architecture des applications web SharePoint Server que vous utiliserez dans votre environnement hybride.

La connectivité entrante nécessite un canal de communication sécurisé entre la batterie de serveurs SharePoint locale et SharePoint dans Microsoft 365. Les données sont échangées entre une collection de sites dans SharePoint dans Microsoft 365 et une application web locale sur ce canal de communication.

SharePoint dans Microsoft 365 envoie des demandes à un serveur proxy inverse qui relaie les demandes à une application web spécifique dans la batterie de serveurs SharePoint Server sur site configurée pour SharePoint hybride. Nous l'appellerons application web principale.

Conseil

Quel que soit le nombre de solutions hybrides que vous prévoyez de configurer, vous n’utiliserez généralement qu’une seule application web principale. Vous n’avez pas besoin de créer des applications web principales supplémentaires pour chaque solution hybride supplémentaire.

L’application web principale et une collection de sites unique au sein de l’application web principale doivent être configurées pour accepter les connexions entrantes à partir de SharePoint dans Microsoft 365.

L’administrateur SharePoint associe les services et les objets de connexion nécessaires pour prendre en charge les solutions hybrides déployées avec l’application web principale. Les connexions sortantes peuvent être réalisées à partir de n’importe quelle application web SharePoint Server en utilisant les configurations propres aux fonctionnalités.

Une application web SharePoint Server se compose d’un site web Internet Information Services (IIS) qui agit comme une unité logique pour les collections de sites que vous créez. Chaque application web est représentée par un site web IIS différent qui possède un pool d’applications unique ou partagé, qui possède une URL publique unique et qui peut également être configuré pour utiliser jusqu’à cinq URL internes à l’aide du mappage des accès de remplacement. Une application web donnée est associée à une base de données de contenu unique et est configurée pour utiliser une méthode d’authentification spécifique pour se connecter à la base de données. Plusieurs applications web peuvent être configurées pour utiliser différentes méthodes d’authentification, et éventuellement des AAM, pour fournir l’accès à une seule base de données de contenu.

L’URL publique d’une application web est toujours utilisée comme URL racine dans tous les liens vers les sites et le contenu accessibles via l’application web. Envisagez une application web avec l’URL publique dont https://spexternal.adventureworks.com l’URL interne https://sharepoint est configurée dans AAM. Lorsque vous accédez à l’URL interne, SharePoint Server renvoie le site web avec l’URL et tous les liens au sein du site auront des URL https://sharepoint https://spexternal.adventureworks.com basées sur ce chemin d’accès.

Le mappage des accès de remplacement n’est nécessaire que lorsque vous configurez la connectivité entrante à l’aide d’une collection de sites basée sur des chemins d’accès avec une URL publique différente de l’URL externe. AAM vous permet d’associer l’URL externe à l’URL interne d’un SharePoint dans Microsoft 365 site au sein de votre organisation. Cela permet à SharePoint server de router les demandes d’URL internes configurées dans AAM vers l’application web principale correspondante.

Pour plus d’informations sur les applications web basées sur les revendications, voir Créer des applications web baséessur les revendications dans SharePoint Server .

Pour plus d’informations sur l’extension d’une application web, voir Étendre les applications web baséessur les revendications dans SharePoint .

Pour plus d’informations sur les collections de sites, voir Vue d’ensemble des sites et des collections de sites dans SharePoint Server.

Choisir une stratégie de collection de sites

Avant de décider d’utiliser une application web existante ou d’en créer une nouvelle, vous devez comprendre les exigences de configuration que l’application web et la collection de sites doivent respecter pour prendre en charge la fonctionnalité hybride. Utilisez les informations de cette section pour déterminer votre stratégie de création d’une application web et d’une collection de sites ou pour déterminer si une collection de sites dans une application web existante peut être utilisée dans votre environnement hybride.

La figure suivante illustre le flux de décision permettant de déterminer votre stratégie de collection de sites.

Les trois stratégies de collection de sites possibles pour une topologie d’authentification hybride entrante ou SharePoint à sens double.

Conditions requises pour les applications web hybrides

Les applications Web utilisées pour les fonctionnalités hybrides doivent répondre à toutes les conditions requises :

  • L’URL publique de l’application web doit être identique à l’URL externe.

    Le protocole OAuth fournit l’autorisation utilisateur dans SharePoint solutions hybrides. L’en-tête de demande hôte dans toutes les SharePoint dans Microsoft 365 communications vers SharePoint local contient l’URL à laquelle la demande a été envoyée à l’origine. Pour authentifier les demandes entrantes provenant de SharePoint dans Microsoft 365, le service d’authentification SharePoint local doit être en mesure de faire correspondre cette URL dans tout le trafic entre SharePoint en Microsoft 365 et l’URL publique de l’application web principale. Il s’agit de l’URL externe. L’un des avantages de l’utilisation d’une collection de sites nommée par l’hôte pour les environnements hybrides SharePoint est que vous pouvez configurer une collection de sites nommée par l’hôte pour utiliser la même URL que l’URL externe. Cela élimine la nécessité de configurer le mappage des accès de remplacement.

  • L’application web doit être configurée pour utiliser l’authentification Windows’authentification intégrée à l’aide de NTLM.

    L’Windows authentification intégrée à l’aide de NTLM est requise pour les applications web déployées dans des scénarios qui prendre en charge l’authentification de serveur à serveur et l’authentification d’application. Pour plus d'informations, voir Planifier l'authentification de serveur à serveur dans SharePoint Server.

    Types d’authentification de revendication pour un environnement SharePoint hybride

Configuration requise pour des configurations de collection de sites spécifiques

Les collections de sites utilisées pour les fonctionnalités hybrides doivent répondre à toutes ces exigences et doivent également exister dans une application web ou être créées dans celle-ci :

  • Collections de sites nommées par l’hôte

    • L’application web doit prendre en charge les collections de sites nommées par l’hôte.

      Pour créer une collection de sites nommée par l’hôte, l’application web doit être créée pour les activer. Vous ne pouvez pas activer cette fonctionnalité une fois l’application web créée.

      Pour plus d’informations sur la création d’une collection de sites nommée par l’hôte, voir architecture et déploiement d’une collection de sites nommée par l’hôte dans SharePoint Server.

      Notes

      Bien qu’il s’agit d’une exigence d’application web, elle est répertoriée ici, car elle s’applique uniquement aux environnements qui ont des collections de sites nommées par l’hôte.

    • Votre serveur DNS local doit être configuré avec le DNS fractioné. Vous devez créer une zone de recherche avant pour le domaine Internet public que vous avez utilisé pour votre URL publique et un enregistrement A (hôte) dans la zone de recherche avant qui a l’adresse IP du serveur SharePoint et le nom d’hôte de votre URL externe.

      Important

      Le périphérique de proxy inverse doit être en mesure de résoudre les noms d’hôtes dans cette zone de recherche avant pour relayer les demandes entrantes vers la batterie SharePoint Server.

  • Collections de sites basées sur des chemins d’accès

    • Si l’URL publique est identique à l’URL externe :

      Votre serveur DNS local doit être configuré avec le DNS fractioné. Vous devez créer une zone de recherche avant pour le domaine Internet public que vous avez utilisé pour votre URL publique et un enregistrement A dans la zone de recherche avant qui a l’adresse IP du serveur SharePoint et le nom d’hôte de votre URL externe.

      Important

      Le périphérique de proxy inverse doit être en mesure de résoudre les noms d’hôtes dans cette zone de recherche avant pour relayer les demandes entrantes vers la batterie SharePoint Server.

      Il s’agit d’un moyen simple de configurer une application web pour une SharePoint hybride. L’objectif est de faire correspondre le champ URL publique de la nouvelle application web à l’URL du point de terminaison public sur le proxy inverse, également appelé URL externe.

    • Si l’URL publique est différente de l’URL externe :

      Vous devez configurer un mappage des accès de remplacement (AAM) pour relayer les demandes entrantes en provenance SharePoint dans Microsoft 365.

      Étendez l’application web principale et utilisez l’URL externe en tant qu’URL publique. Créez ensuite une URL interne (via Ajouter des URL internes) dans la même zone de sécurité que l’application web étendue à utiliser comme URL de pontage. Vous allez également configurer le périphérique de proxy inverse pour relayer les demandes entrantes de SharePoint dans Microsoft 365 vers cette URL de pontage.

      N’oubliez pas que le mappage des accès de remplacement n’est nécessaire que lorsque vous configurez la connectivité entrante à l’aide d’une collection de sites basée sur des chemins d’accès avec une URL publique différente de l’URL externe.

Notes

N’oubliez pas que l’URL externe est l’URL du point de terminaison connecté à Internet du périphérique de proxy inverse.

   
Icône Modifier Enregistrez votre choix de stratégie de collection de sites dans la feuille de calcul de la ligne Stratégie de collection de sites du tableau 2.

Choisir une application web existante ou en créer une nouvelle

Vous pouvez utiliser une application web existante ou en créer une à utiliser comme application web principale.

Si vous préférez gérer l’application web utilisée pour la fonctionnalité hybride de manière indépendante ou si votre application web existante ne répond pas aux exigences répertoriées dans la section Choisir une stratégie de collection de sites, vous devez créer une application web.

   
Icône Modifier Enregistrez votre décision dans la ligne Application web Nouvelle ou existante du tableau 2.

Planifier l’utilisation d’une application web existante

Si vous décidez d’utiliser une application web existante en tant qu’application web principale, rassemblez l’URL de l’application web principale et l’URL de la collection de sites de niveau supérieur et réseinsez-la dans la feuille de calcul.

   
Icône Modifier Enregistrez les informations suivantes dans la feuille de calcul :
Selon votre stratégie de collection de sites, enregistrez l’URL de l’application web principale dans la ligne URL de l’application web principale du tableau 5a, 5b ou 5c.
Si vous utilisez une collection de sites nommée par l’hôte existante, enregistrez l’URL de la collection de sites de niveau supérieur dans la ligne URL de la collection de sites nommée par l’hôte dans le tableau 5a.

Planifier la création d’une application web

Si vous décidez de créer une application web, nous vous orienterons sur la façon de le faire lorsque vous configurez la topologie hybride.

Planifier les certificats SSL

Les certificats SSL établissent l’identité du serveur et fournissent une authentification de certificat pour plusieurs services et connexions différents dans un environnement SharePoint hybride. Vous devez avoir deux certificats SSL : un certificat SSL de canal sécurisé et un certificat STS.

Pour plus d’informations sur l’utilisation des certificats SSL dans les environnements hybrides SharePoint, voir SharePoint 2013 Hybrid Topology: Certificate and Authentication Model.

Notes

Si vous choisissez de sécuriser votre batterie de serveurs SharePoint sur site avec SSL, vous aurez également besoin d’un certificat SSL pour l’application web principale. Il n’existe aucune considération spécifique à l’environnement hybride pour ce certificat. Vous pouvez donc suivre les meilleures pratiques générales pour configurer SharePoint Server avec SSL.

Notes

« Canal sécurisé » n’est pas une classe de certificat ; Nous utilisons le terme comme moyen de différencier ce certificat particulier des autres certificats SSL utilisés dans l’environnement.

À propos des certificats SSL de canal sécurisé

Un certificat SSL de canal sécurisé fournit l’authentification et le chiffrement pour le canal de communication sécurisé entre le périphérique proxy inverse et Microsoft 365, agissant à la fois comme un serveur et un certificat client. Il vérifie également l’identité du point de terminaison du proxy inverse utilisé pour publier la collection de sites SharePoint Server sur site.

Ce certificat doit être un certificat générique ou san et être émis par une autorité de certification racine publique. Le champ objet de ce certificat doit contenir le nom d’hôte du point de terminaison externe du serveur proxy inverse ou une URL générique qui couvre tous les noms d’hôtes dans l’espace de noms. Il doit utiliser au moins un chiffrement 2 048 bits.

Important

Les certificats génériques ne peuvent sécuriser qu’un seul niveau d’un espace de noms DNS. Par exemple, si votre URL externe est , l’objet de votre certificat générique doit être https://spexternal.public.adventureworks.com *.public.adventureworks.com, et non *.adventureworks.com.

Dans les scénarios où SharePoint dans Microsoft 365 est configuré pour demander des informations à SharePoint Server, un certificat SSL est requis pour :

  • Chiffrez le trafic sur le canal de sécurité.

  • Activez le périphérique de proxy inverse pour authentifier les connexions entrantes à l’aide de l’authentification par certificat.

  • Autorisez SharePoint dans Microsoft 365 pour identifier et faire confiance au point de terminaison externe.

Lors du déploiement, vous installerez le certificat SSL à la fois sur le périphérique proxy inverse et dans une SharePoint dans Microsoft 365'application cible de la Secure Store. Vous le configurerez lors de la configuration de l’infrastructure de l’environnement hybride.

Obtenir un certificat SSL de canal sécurisé

Obtenez un certificat san ou générique SSL de canal sécurisé pour votre domaine public local auprès d’une autorité de certification connue, par exemple, DigiCert, VeriSign, Thawte ou GeoTrust.

Notes

Ce certificat doit prendre en charge plusieurs noms et doit avoir au moins 2 048 bits. Les certificats expirent généralement à intervalles d’un an. Il est donc important de planifier à l’avance les renouvellements de certificats afin d’éviter les interruptions de service. SharePoint administrateurs doivent planifier un rappel pour le remplacement de certificat qui vous donne suffisamment de temps de avance pour empêcher un arrêt de travail.

À propos des certificats STS

Le certificat STS de la batterie de serveurs SharePoint local nécessite un certificat par défaut pour valider les jetons entrants. Dans un environnement SharePoint hybride, Azure Active Directory sert de service de signature de jetons approuvé et utilise le certificat STS comme certificat de signature. Si vous choisissez d’utiliser un certificat autre que le certificat STS par défaut (par exemple, un certificat provenant d’une autorité de certification publique), remplacez le certificat par défaut avant de commencer le processus de configuration hybride.

Enregistrer les comptes nécessaires pour la configuration et le test

Une configuration d’environnement hybride SharePoint nécessite plusieurs comptes d’utilisateur dans votre annuaire Active Directory local et dans l’annuaire Microsoft 365 (Azure Active Directory qui est indiqué dans l’annuaire Microsoft 365). Ces comptes ont des autorisations et des appartenances de groupe ou de rôle différentes. Certains comptes sont utilisés pour déployer et configurer des logiciels, et d’autres sont nécessaires pour tester des fonctionnalités spécifiques afin de garantir que les systèmes de sécurité et d’authentification fonctionnent comme prévu.

  • Go to Accounts needed for hybrid configuration and testing for a complete explanation of the required user accounts, including notes about roles and identity providers.

  • Enregistrez les informations de compte requises dans la feuille de calcul comme indiqué.

  • Revenir à cet article de planification après avoir terminé cette étape.

Étapes suivantes

À ce stade, vous devez avoir rempli la feuille de calcul requise pour la connectivité entrante et être prêt à démarrer le processus de configuration. L’étape suivante consiste à choisir une feuille de route de configuration.