Planification de la connectivité à partir d’Office 365 à SharePoint Portal Server

**Sapplique à :**SharePoint Online, SharePoint Server 2013, SharePoint Server 2016

**Dernière rubrique modifiée :**2017-06-20

Résumé : Planifier et préparer la configuration de la connectivité entrante à partir d’Office 365 à l’environnement hybride de SharePoint Server.

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

• Recherche hybride entrant (affichage des résultats de la recherche à partir de SharePoint Server dans Office 365 )

• Business Connectivity Services hybride

Dans cet article, nous vous offrons les informations dont vous avez besoin de savoir, 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 à effectuer les opérations suivantes :

• Comprendre les conditions préalables et les exigences associées à la connectivité entrante

• Planifier l’architecture de votre application web

• Planifier les certificats SSL

• Enregistrer les informations et décisions essentielles

Collecter et enregistrer les informations de journal de génération et de feuille de calcul

Feuille de calcul. Au cours du processus de planification, vous devez recueillir des informations et des fichiers. Il est important que vous utilisiez la feuille de calcul hybride SharePoint pour suivre les informations de déploiement et de planification pour référence, et pour les partager avec les autres membres de votre équipe de déploiement. Nous ne pourrons jamais assez insister sur l’importance de l’utilisation de cette feuille de calcul pour vous aider à organiser vos informations avant de commencer le processus de configuration.

Créer un journal de génération. Comme dans tout projet d’implémentation complexe, un enregistrement détaillé de chaque décision relative à la conception, configuration de 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 connaissance. Nous vous recommandons vivement de documenter soigneusement votre processus de déploiement.

Collecter et enregistrer les informations d’URL et de nom d’hôte

Dans cette section, vous allez enregistrer les informations sur les URL et les noms d’hôte dans votre environnement. Vous utiliserez ces informations au cours du 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 l’environnement hybride SharePoint. Il s’agit de l’URL externe. Si ce point de terminaison n’existe pas encore, vous devrez déterminer 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 d’hôte) existe dans la zone de recherche directe du DNSpublic pour votre domaine public qui mappe l’URL externe avec l’adresse IP du point de terminaison accessible sur Internet sur le périphérique de proxy inverse. Si cet enregistrement A n’existe pas encore, créez-le maintenant.

• Vérifiez l’existence d’un enregistrement A dans la zone de recherche directe DNS intranet qui mappe le nom d’hôte de votre batterie de SharePoint Server à son adresse IP. Si cet enregistrement A n’est pas encore, créez-le maintenant.

  Important

  Si vous configurez des URL internes pour accéder à une application web au cours du processus de déploiement, veillez à créer également des enregistrements A pour ces URL dans la zone de recherche directe du DNS intranet et enregistrez-les dans la feuille de calcul.

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

Pour plus d’informations sur la relation entre les URL et les noms d’hôte dans un environnement hybride, regardez la vidéo Présentation des URL et des noms d’hôte. Durée : 6 minutes.

Planifier l’architecture de votre application web

Cette section vous permet de planifier l’architecture des applications web SharePoint Server que vous allez utiliser dans votre environnement hybride.

Connectivité entrante requiert un canal de communication sécurisé entre la batterie de serveurs sur les sites SharePoint Server et SharePoint Online. Échange des données entre une collection de sites dans SharePoint Online et d’une application web de locaux sur ce canal de communication.

SharePoint Online envoie des demandes à un serveur proxy inverse qui transmet les demandes à une application web spécifique dans la batterie de serveurs sur site SharePoint Server qui est configuré pour SharePoint hybride. Nous faisons référence à ce que l' application web principale.

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

L’administrateur SharePoint associe les services et les objets de connexion qui sont nécessaires pour prendre en charge des solutions hybrides qui sont déployées avec l’application web principale. Connexions sortantes est possible à partir d’applications web sur site SharePoint Server en utilisant les configurations spécifiques à la fonctionnalité.

Uneapplication webSharePoint Server est composé 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 autre site Web IIS qui dispose d’un pool d’application unique ou partagées, 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 alternative (AAM). Une application web donnée est associée à une seule base de données de contenu et est configurée pour utiliser une méthode spécifique d’authentification pour se connecter à la base de données. Plusieurs applications web peuvent être configurées pour utiliser les différentes méthodes d’authentification et éventuellement de la AAMs, pour fournir l’accès à une base de données de contenu unique.

Les URL publique d’une application web est toujours utilisée comme l’URL de la racine de tous les liens aux sites et au contenu accédé via l’application web. Imaginez une application web avec l' URL publique https://spexternal.adventureworks.com qui a une URL interne https://sharepoint configuré dans AAM. Lorsque vous accédez à l’https://sharepoint URL interne, SharePoint Server renvoie au site Web avec l’URL https://spexternal.adventureworks.com, et tous les liens du site aura des URL basées sur ce chemin d’accès.

Mappage des accès de substitution (AAM) est nécessaire uniquement lorsque vous configurez la connectivité entrante à l’aide d’une collection basée sur le chemin d’accès de site avec une URL publique qui est différente de l’URL externe. Le logiciel AAM vous permet d’associer l’URL externe avec l’URL interne d’un site SharePoint à l’intérieur de votre organisation. Cela permet de SharePoint Server pour router les demandes d’URL internes configurés dans AAM pour l’application web principale correspondante.

Pour plus d’informations sur les applications web basées sur les revendications, voir Create claims-based web applications in 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 conditions requises en matière de configuration que l’application web et la collection de sites doivent remplir pour prendre en charge la fonctionnalité hybride. Utilisez les informations fournies dans cette section pour déterminer votre stratégie de création d’une application web ou 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.

Conditions requises pour les applications web hybrides

Les applications web utilisées pour la fonctionnalité hybride doivent remplir l’ensemble des conditions suivantes :

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

  Le protocole OAuth fournit l’autorisation à l’utilisateur dans les solutions SharePoint hybrides. L’en-tête de demande Hôte dans toutes les communications SharePoint Online vers SharePoint sur site contient l’URL vers laquelle la demande a initialement été envoyée. Afin d’authentifier les demandes entrantes à partir de SharePoint Online, le service d’authentification SharePoint sur site doit pouvoir faire correspondre cette URL dans tout le trafic à partir de SharePoint Online à 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 qu’il vous est possible de la configurer afin qu’elle utilise la même URL que l’URL externe. Cela évite d’avoir à configurer le mappage des 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 d’application. Pour plus d’informations, voir Planifier l’authentification de serveur à serveur dans SharePoint Server.

  

Conditions requises pour les configurations de collection de sites spécifiques

Les collections de sites utilisées pour la fonctionnalité hybride doivent remplir toutes ces conditions et doivent également exister ou être créées dans une application web qui remplit les conditions requises 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. Il est impossible d’activer cette fonctionnalité après la création de l’application web.

    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 condition requise d’application web, elle est répertoriée ici car elle s’applique uniquement aux environnements possédant des collections de sites nommées par l’hôte.

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

    Important

    Le périphérique 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 à la batterie de 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 sur site doit être configuré avec un DNS fractionné. Vous devez créer une zone de recherche directe pour le domaine de l’Internet Public utilisé pour l’URL de votre public et un d’un enregistrement dans la zone de recherche directe qui a l’adresse IP du serveur SharePoint Server et le nom d’hôte de l’URL externe.

    Important

    Le périphérique 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 à la batterie de SharePoint Server.

    Il s’agit d’un moyen simple de configurer une application web pour un environnement hybride SharePoint. Le but 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 connue sous le nom d’URL externe.

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

    Vous devez configurer un mappage des accès de substitution afin de relayer les demandes entrantes à partir de SharePoint Online

    Étendez l’application web principale et utilisez l’URL externe en tant qu’URL publique. Ensuite, créez une URL interne (via l’option Ajouter des URL internes) dans la même zone de sécurité que l’application web étendue à utiliser en tant qu’URL de pontage. Vous configurerez également le périphérique de proxy inverse de sorte qu’il relaie les demandes entrantes à partir de SharePoint Online vers cette URL de pontage.

    Souvenez-vous, le mappage des accès de substitution est nécessaire uniquement lors de la configuration d’une connectivité entrante à l’aide d’une collection de sites basée sur le chemin d’accès avec une URL publique différente de l’URL externe.

Enregistrez votre choix de stratégie de collection de sites sur la feuille de calcul dans la ligne Site collection strategy du tableau 2.

Choisir un pool d’applications existant ou en créer un

Vous pouvez utiliser une application web existante ou en créer une afin de l’utiliser en tant qu’application web principale.

Si vous préférez gérer l’application web utilisée pour la fonctionnalité hybride de façon indépendante ou si votre application web existante ne remplit pas les conditions requises répertoriées à la section Choisir une stratégie de collection de sites, vous devez créer une application web.

Enregistrez votre décision dans la ligne New or existing web application 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, recueillez l’URL de l’application web principale et l’URL de la collection de sites de niveau supérieur, et répertoriez-les sur la feuille de calcul.

Enregistrez les informations suivantes sur 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 Primary web application URL 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 Host-named site collection URL du tableau 5a.

Après avoir enregistré ces informations, accédez à la section Planifier les certificats SSL.

Planifer la création d’une application web

Si vous décidez de créer une application web, nous vous donnerons des indications lorsque vous configurerez la topologie hybride.

Planifier les 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

À propos des certificats SSL de canal sécurisé

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

Ce certificat doit être un certificat SAN ou générique et être émis par une autorité de certification racine publique. Le champ d’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 dans l’espace de noms. Il doit utiliser au minimum le chiffrement 2 048 bits.

Dans les scénarios où le SharePoint Online est configuré pour demander des informations à partir de SharePoint Server, un certificat SSL est requis pour effectuer les opérations suivantes :

• Chiffrer le trafic sur le canal sécurisé.

• Activer le périphérique de proxy inverse afin d’authentifier les connexions entrantes à l’aide de l’authentification de certificat.

• Autoriser SharePoint Online à identifier et à approuver le point de terminaison externe.

Au cours du déploiement, vous installerez le certificat SSL sur le périphérique de proxy inverse et dans une application cible Banque d’informations sécurisée de SharePoint Online. La configuration se fera 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 sur site à partir d’une autorité de certification connue telle que DigiCert, VeriSign, Thawte ou GeoTrust.

Enregistrez les éléments suivants sur la feuille de calcul dans le tableau 4b : Certificat SSL de canal sécurisé : Le nom et l’emplacement de stockage de ce certificat dans la ligne Secure Channel Certificate location and file name. Le nom convivial de ce certificat dans la ligne Secure Channel SSL Certificate Friendly Name. Spécifiez le type de certificat (générique ou SAN) dans la ligne Type de certificat. La date d’expiration du certificat dans la ligne Date d’expiration. Si le certificat possède une extension de nom de fichier .pfx, enregistrez le mot de passe du certificat dans la ligne Mot de passe du certificat SSL de canal sécurisé. N’oubliez pas de contribuer à protéger la feuille de calcul par mot de passe si vous la mettez à jour avec des informations de mot de passe.

À propos des certificats STS

Le certificat STS de la batterie de serveurs SharePoint sur site nécessite un certificat par défaut pour valider les jetons entrants. Dans un environnement hybride SharePoint, Azure Active Directory sert de service de signature de jetons approuvé et utilise le certificat STS en tant que certificat de signature. Azure Active Directory ne peut pas utiliser le certificat STS par défaut de SharePoint Server en tant que certificat de signature, car il ne peut pas vérifier la chaîne d’approbation.

Par conséquent, vous devez remplacer le certificat STS par défaut sur chaque serveur de la batterie SharePoint sur site par l’un des suivants :

• Un certificat émis par une autorité de certification publique approuvée par Azure Active Directory.

• Un certificat auto-signé

Le certificat STS par défaut est remplacé ultérieurement lorsque vous configurez l’infrastructure de gestion des identités.

Si vous choisissez d’utiliser un certificat auto-signé, vous devrez le créer pendant la configuration du déploiement. Les étapes de la création d’un certificat auto-signé pour SharePoint figurent dans la rubrique Configuration de l’authentification serveur à serveur dans SharePoint Online à partir de SharePoint Server.

Obtenir un certificat STS

Obtenez votre certificat STS avant de commencer le processus de configuration.

Enregistrez les éléments suivants sur la feuille de calcul dans le tableau 4a : Certificat STS : Nom convivial du certificat STS Chemin d’accès/nom de fichier du certificat STS (fichier *.pfx) Mot de passe du certificat STS Chemin d’accès/nom de fichier du certificat STS (fichier *.cer) Nom de l’objet Date de début du certificat STS Date de fin du certificat STS

Enregistrer les comptes nécessaires pour la configuration et les tests

La configuration d’un environnement hybride SharePoint nécessite plusieurs comptes d’utilisateurs dans votre annuaire Active Directory sur site et l’annuaire Office 365 (un annuaire Azure Active Directory exposé dans l’annuaire Office 365). Ces comptes disposent d’autorisations et d’appartenances de rôle ou de groupe distinctes. Certains de ces comptes sont utilisés pour le déploiement et la configuration du logiciel, et d’autres sont nécessaires pour le test de fonctionnalités spécifiques afin de garantir que les systèmes de sécurité et d’authentification fonctionnent comme prévu.

• Pour obtenir une explication complète des comptes d’utilisateurs requis, y compris des remarques sur les fournisseurs d’identité et de rôles, accédez à Comptes nécessaires pour la configuration et les tests d’un environnement hybride.

• Enregistrez les informations de compte requises dans la feuille de calcul en suivant les instructions.

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

Étapes suivantes

À ce stade, vous devez avoir fini de remplir la feuille de calcul requise pour votre connectivité entrante et être prêt à démarrer le processus de configuration. La prochaine étape consiste à choisir une feuille de route de configuration.