Considérations d'infrastructure

Réseau

Éviter les proxies

Le déploiement initial nécessite un accès direct à Internet. L'absence de proxy serait l'idéal, mais un proxy transparent devrait fonctionner correctement (s'il est véritablement transparent). Si un proxy est inévitable, comme exigence minimale les services/adresses suivants doivent être directement accessibles :

Pour une liste des plages d'IP correspondantes, cliquez sur le lien suivant :

Plages d'adresses IP et balises de service Azure – Cloud public

Ce fichier contient les plages d'adresses IP de calcul (y compris les plages SQL) utilisées par les centres de données Microsoft Azure. Un nouveau fichier xml sera téléchargé chaque mercredi (heure du Pacifique) avec les nouvelles plages d'adresses IP planifiées. Les nouvelles plages d'adresses IP entreront en vigueur le lundi suivant (heure du Pacifique). Téléchargez le nouveau fichier xml et effectuez les modifications nécessaires sur votre site avant le lundi.

URL et plages d'adresses IP d'Office 365

Cet article renvoie à un fichier contenant les plages d'adresses IP de calcul que vous devez inclure dans vos listes d'autorisation sortantes afin de garantir que vos ordinateurs puissent utiliser Office 365 avec succès.

Le filtrage basé uniquement sur les adresses IP n'est pas une solution complète en raison des dépendances aux services basés sur Internet tels que les services de noms de domaine (DNS), les réseaux de diffusion de contenu (CDN), les listes de révocation de certificats et d'autres services tiers ou dynamiques. Ces dépendances incluent des dépendances à d'autres services Microsoft tels que le réseau de diffusion de contenu Azure et se traduiront par des traces réseau ou des journaux de pare-feu indiquant des connexions vers des adresses IP appartenant à des tiers ou à Microsoft mais non répertoriées sur cette page. Ces adresses IP non répertoriées, qu'elles proviennent de services CDN et DNS tiers ou détenus par Microsoft, sont attribuées de manière dynamique et peuvent changer à tout moment.

Éviter les VLANs / WLAN et l'isolation de ports

Pour BranchCache pour être efficaces, les clients doivent pouvoir communiquer directement entre eux et ne doivent donc pas être séparés par différents VLANs, par l'isolation WLAN ou par l'isolation de ports. Pour des déploiements massifs, Serveurs BranchCache avec des caches préremplis sont recommandés. BranchCache est limité à un seul sous-réseau ; si un site comporte plusieurs sous-réseaux, les serveurs BranchCache doivent être placés dans le même sous-réseau que les clients pour être efficaces.

Points de terminaison de connexion RealmJoin

RealmJoin se connecte aux hôtes suivants (via HTTPS) qui pourraient être pris en compte dans vos règles de pare-feu :

• cdn.realmjoin.com

• x1.c.lencr.org

• client-api.realmjoin.com NOUVEAU !

• client-api-staging.realmjoin.com NOUVEAU !

• realmjoin-backend.azurewebsites.net

• realmjoin-backend-staging.azurewebsites.net

• packages.gkdatacenter.net

• nuget.realmjoin.com NOUVEAU !

• enterpriseregistration.windows.net

• gkrealmjoin.s3.amazonaws.com

• login.microsoftonline.com

• graph.microsoft.com

• realmjoinstaticcdn.azureedge.net (Notificateur)

Composants

BranchCache

Un problème souvent rencontré lors de la distribution de packages logiciels à un grand nombre d'appareils sur un WAN est la création d'un goulot d'étranglement et d'importantes charges réseau lors du téléchargement des logiciels depuis un serveur vers les appareils. Une solution à ce problème est la BranchCache technologie. Il existe deux modes BranchCache, hébergé et distribué cache. En mode cache hébergé, le contenu est mis en cache sur un ou plusieurs serveurs de cache hébergé, ce qui augmente la charge réseau, puisque le téléchargement de gros binaires depuis un serveur Internet n'est pas nécessaire. RealmJoin utilise BranchCache en mode de cache distribué :

Un problème fréquemment rencontré lors de la distribution de packages logiciels à de nombreux appareils sur un WAN est la création d'un goulot d'étranglement et d'importantes charges réseau lors du téléchargement des logiciels depuis un serveur vers les appareils. Une solution à ce problème est la BranchCache technologie.

Lorsqu'un appareil client télécharge des packages logiciels pour la première fois, les fichiers sont divisés en fragments sensiblement plus petits que le contenu d'origine et mis en cache sur l'appareil. Si le même package est ensuite demandé par un autre appareil client du même réseau, il télécharge des informations de contenu au lieu du contenu complet depuis le serveur. Les informations de contenu sont utilisées pour localiser le contenu souhaité sur d'autres appareils du réseau. Si elles sont trouvées, au lieu de télécharger les packages depuis le serveur, le contenu sous forme de fragments est transféré vers l'appareil client. Si le logiciel demandé est disponible sur plusieurs appareils, la charge est répartie entre eux.

Le serveur de publication RealmJoin doit fournir les identifiants de fragments et est donc hébergé en tant qu'une seule VM Azure Windows 2016 IIS avec un stockage Blob Azure. Pour plus d'informations sur BranchCache, consultez la documentation Microsoft BranchCache

Back-End

Hébergement

Le back-end RealmJoin est une application web Azure utilisant une base de données Azure SQL et les services Azure disponibles. Le back-end est hébergé sur un locataire Azure exclusivement utilisé pour RealmJoin. Tous les domaines clients au sein de ce locataire sont isolés les uns des autres.

Point de publication d'applications RealmJoin

Pour fournir le BranchCache mécanisme, le point de terminaison doit fournir les identifiants de fragments, fonctionnalité uniquement fournie par Microsoft Internet Information Services (IIS) serveurs. Pour offrir une scalabilité maximale, le point de publication est distribué sur plusieurs nœuds Azure hébergeant Windows 2016 IIS partageant un stockage blob Azure redondant.

Interface Web

L'interface web est accessible via le Portail classique RealmJoin. Après s'être connecté avec les identifiants fournis, l'administrateur peut gérer la distribution des packages dans son locataire et accéder à des informations détaillées.

Fonctionnalités de sécurité

Authentification client

Le client RealmJoin s'authentifie auprès d'Entra ID via une connexion HTTPS sécurisée, recevant un jeton d'identification. Avec ce jeton, le client peut désormais prouver son identité à l'API Microsoft Graph et au back-end RealmJoin. Après avoir identifié le client, la réponse du back-end au client est signée RSA. En utilisant la clé publique du serveur, le client et le service RealmJoin peuvent vérifier l'identité de la réponse du serveur back-end.