Planifier la connectivité de Microsoft 365 vers SharePoint Server
S’APPLIQUE À :
2013 2016 2019 Édition d’abonnement SharePoint dans 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 vers SharePoint Server via un appareil proxy inverse. Cela est requis pour les environnements hybrides suivants :
Recherche hybride entrante (affichage des résultats de recherche à partir de SharePoint Server dans Microsoft 365)
Business Connectivity Services hybride
Dans cet article, nous vous donnons les informations que vous devez connaître, telles que les prérequis, et une feuille de calcul pour collecter les informations nécessaires avant de commencer le processus de configuration.
Cette rubrique vous aidera à effectuer les opérations suivantes :
Comprendre les prérequis et les exigences pour la connectivité entrante
Planifier l’architecture de votre application web
Planifier des certificats SSL
Enregistrer les décisions clés et les informations
Collecter et enregistrer des informations de feuille de calcul et de journal de génération
Feuille de calcul. Pendant le processus de planification, vous devez collecter des informations et des fichiers. Il est important d’utiliser la feuille de calcul hybride SharePoint pour suivre les informations de planification et de déploiement à des fins de référence et pour les partager avec d’autres membres de votre équipe de déploiement. Nous ne soulignerons pas assez l’importance d’utiliser cette feuille de calcul pour organiser vos informations avant de commencer le processus de configuration.
Créez un journal de génération. 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, le support 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 emplacement sécurisé, tel qu’un partage de fichiers sécurisé ou SharePoint dans la bibliothèque de documents Microsoft 365, et accordez des autorisations uniquement aux administrateurs qui sont 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 de l’appareil 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écider de ce que sera cette URL.
Enregistrez l’adresse IP du point de terminaison externe du périphérique proxy inverse.
Assurez-vous qu’un enregistrement A (également appelé enregistrement hôte) existe dans la zone de recherche directe DNS publique pour votre domaine public qui mappe l’URL externe à l’adresse IP du point de terminaison accessible sur Internet sur l’appareil proxy inverse. Si vous n’avez pas encore cet enregistrement A, créez-le maintenant.
Vérifiez qu’un enregistrement A existe dans la zone de recherche directe DNS intranet qui mappe le nom d’hôte de votre batterie de serveurs SharePoint Server à son adresse IP. Si vous n’avez pas encore cet enregistrement A, créez-le maintenant.
Importante
Si vous configurez des URL internes pour accéder à une application web pendant le processus de déploiement, veillez à créer également des enregistrements A pour ces URL dans la zone de recherche directe DNS intranet et à les enregistrer dans la feuille de calcul.
|
Enregistrez les informations suivantes dans le tableau 3 de la feuille de calcul 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 de l’appareil proxy inverse dans la ligne URL externe . Adresse IP du point de terminaison externe du périphérique 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 Server 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 via ce canal de communication.
SharePoint dans Microsoft 365 envoie des demandes à un serveur proxy inverse qui les transmet à une application web spécifique dans la batterie de serveurs SharePoint Server locale configurée pour SharePoint hybride. Nous l'appellerons application web principale.
Conseil
Quel que soit le nombre de solutions hybrides que vous envisagez 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és 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 établies à partir de n’importe quelle application web SharePoint Server locale à l’aide des configurations spécifiques aux fonctionnalités.
Une application web SharePoint Server est composée d’un site web IIS (Internet Information Services) 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 a un pool d’applications unique ou partagé, qui a une URL publique unique et qui peut également être configuré pour utiliser jusqu’à cinq URL internes à l’aide du mappage d’accès alternatif (AAM). 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 AAMs, pour fournir l’accès à une base de données de contenu unique.
L’URL publique d’une application web est toujours utilisée comme URL racine dans tous les liens vers des sites et du contenu accessibles via l’application web. Prenons l’exemple d’une application web avec l’URL https://spexternal.adventureworks.com publique qui a une URL https://sharepoint interne configurée dans AAM. Lorsque vous accédez à l’URL https://sharepointinterne , SharePoint Server retourne le site web avec l’URL https://spexternal.adventureworks.com, et tous les liens au sein du site ont des URL basées sur ce chemin.
Le mappage d’accès alternatif (AAM) est nécessaire uniquement lorsque vous configurez la connectivité entrante à l’aide d’une collection de sites basée sur un chemin 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 site SharePoint dans Microsoft 365 au sein de votre organisation. Cela permet à SharePoint Server d’acheminer 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ées sur des revendications dans SharePoint Server.
Pour plus d’informations sur l’extension d’une application web, voir Étendre des applications web basées sur des 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, vous devez comprendre les exigences de configuration que l’application web et la collection de sites doivent respecter pour prendre en charge les fonctionnalités hybrides. 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 montre le flux de décision pour déterminer votre stratégie de collection de sites.
Configuration requise pour les applications web hybrides
Les applications web utilisées pour les fonctionnalités hybrides doivent répondre à toutes les exigences suivantes :
L’URL publique de l’application web doit être identique à l’URL externe.
Le protocole OAuth fournit l’autorisation utilisateur dans les solutions hybrides SharePoint. L’en-tête de demande d’hôte dans toutes les communications SharePoint de Microsoft 365 vers SharePoint locale contient l’URL à laquelle la demande a été envoyée à l’origine. Pour authentifier les demandes entrantes à partir de SharePoint dans Microsoft 365, le service d’authentification SharePoint local doit être en mesure de faire correspondre cette URL dans tout le trafic de SharePoint dans Microsoft 365 à 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 d’accès de substitution.
L’application web doit être configurée pour utiliser l’authentification Windows intégrée à l’aide de NTLM.
L’authentification Windows intégrée à l’aide de NTLM est requise pour les applications web déployées dans des scénarios qui prennent en charge l’authentification de serveur à serveur et l’authentification des applications. Pour plus d'informations, voir Planifier l'authentification de serveur à serveur dans SharePoint Server.
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 ou être créées dans une application web qui répond aux exigences de l’application web :
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’agisse 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 un DNS fractionné. Vous devez créer une zone de recherche directe pour le domaine Internet public que vous avez utilisé pour votre URL publique et un enregistrement A (hôte) dans la zone de recherche directe qui a l’adresse IP de SharePoint Server et le nom d’hôte de votre URL externe.
Importante
L’appareil de proxy inverse doit être en mesure de résoudre les noms d’hôte dans cette zone de recherche directe pour relayer les demandes entrantes vers la batterie de serveurs 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 un DNS fractionné. Vous devez créer une zone de recherche directe pour le domaine Internet public que vous avez utilisé pour votre URL publique et un enregistrement A dans la zone de recherche directe qui a l’adresse IP de SharePoint Server et le nom d’hôte de votre URL externe.
Importante
L’appareil de proxy inverse doit être en mesure de résoudre les noms d’hôte dans cette zone de recherche directe pour relayer les demandes entrantes vers la batterie de serveurs SharePoint Server.
Il s’agit d’un moyen simple de configurer une application web pour un 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 d’accès alternatif (AAM) pour relayer les demandes entrantes à partir de SharePoint dans Microsoft 365.
Étendez l’application web principale et utilisez l’URL externe comme 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 l’appareil de proxy inverse pour relayer les demandes entrantes de SharePoint dans Microsoft 365 vers cette URL de pontage.
N’oubliez pas que le mappage d’accès alternatif (AAM) est nécessaire uniquement lorsque vous configurez la connectivité entrante à l’aide d’une collection de sites basée sur un chemin 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 accessible sur Internet du périphérique de proxy inverse.
|
|
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 les fonctionnalités hybrides 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.
|
|
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 comme 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épertoriez-les dans la feuille de calcul.
|
|
Enregistrez les informations suivantes dans la feuille de calcul : En fonction de 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 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 indiquerons comment procéder lors de la configuration de la topologie hybride.
Planifier des certificats SSL
Les certificats SSL établissent l’identité du serveur et fournissent l’authentification par certificat pour plusieurs services et connexions différents dans un environnement hybride SharePoint. Vous devez disposer de 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 Topologie hybride SharePoint 2013 : certificat et modèle d’authentification.
Notes
Si vous choisissez de sécuriser votre batterie de serveurs SharePoint locale avec SSL, vous aurez également besoin d’un certificat SSL pour l’application web principale. Il n’y a pas de considérations spécifiques à l’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 un 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 du canal de communication sécurisé entre l’appareil de proxy inverse et Microsoft 365, agissant à la fois comme un certificat serveur et un certificat client. Il vérifie également l’identité du point de terminaison de proxy inverse utilisé pour publier la collection de sites SharePoint Server locale.
Ce certificat doit être un caractère générique ou un certificat 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ôte de l’espace de noms. Il doit utiliser au moins un chiffrement de 2 048 bits.
Importante
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 https://spexternal.public.adventureworks.com, l’objet de votre certificat générique doit être *.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 nécessaire pour effectuer les opérations suivantes :
Chiffrez le trafic sur le canal de sécurité.
Activez l’appareil proxy inverse pour authentifier les connexions entrantes à l’aide de l’authentification par certificat.
Autoriser SharePoint dans Microsoft 365 à identifier et approuver le point de terminaison externe.
Pendant le déploiement, vous allez installer le certificat SSL à la fois sur l’appareil de proxy inverse et dans une application cible SharePoint dans microsoft 365 Secure Store. Vous le configurerez lorsque vous configurez l’infrastructure de l’environnement hybride.
Obtenir un certificat SSL de canal sécurisé
Obtenez un caractère générique SSL de canal sécurisé ou un certificat SAN (autre nom de l’objet) 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 être d’au moins 2 048 bits. Les certificats expirent généralement à des intervalles d’un an. Il est donc important de planifier à l’avance les renouvellements de certificat afin d’éviter les interruptions de service. Les administrateurs SharePoint doivent planifier un rappel pour le remplacement du certificat qui vous donne suffisamment de temps pour empêcher un arrêt de travail.
À propos des certificats STS
Le certificat STS de la batterie de serveurs SharePoint locale nécessite un certificat par défaut pour valider les jetons entrants. Dans un environnement hybride SharePoint, l’ID Microsoft Entra agit comme un service de signature de jeton 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 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 (ID Microsoft Entra exposé dans l’annuaire Microsoft 365). Ces comptes ont des autorisations et des appartenances de groupe ou de rôle différentes. Certains des comptes sont utilisés pour déployer et configurer des logiciels, tandis que 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.
Accédez à Comptes nécessaires pour la configuration et les tests hybrides pour obtenir une explication complète des comptes d’utilisateur requis, y compris des remarques sur les rôles et les fournisseurs d’identité.
Enregistrez les informations de compte requises dans la feuille de calcul comme indiqué.
Revenez à cet article de planification une fois cette étape terminée.
É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.