Limiter l'accès à un locataire

Les organisations de grande taille qui se préoccupent de la sécurité souhaitent adopter des services cloud, comme Microsoft 365, tout en s’assurant que leurs utilisateurs ne pourront accéder qu’à des ressources approuvées. En général, pour gérer l’accès, les entreprises limitent les noms de domaine ou les adresses IP. Cette approche échoue dans un monde où les applications software as a service (ou SaaS) sont hébergées dans un cloud public et s’exécutent sur des noms de domaine partagés comme outlook.office.com et login.microsoftonline.com. Le fait de bloquer ces adresses empêche les utilisateurs d’accéder à Outlook sur le web entièrement, au lieu de restreindre simplement leur accès à des identités et des ressources approuvées.

La solution Microsoft Entra consiste en une fonctionnalité appelée Restrictions liées au locataire. Grâce aux restrictions liées au locataire, les organisations peuvent contrôler l’accès aux applications cloud SaaS, en fonction du locataire Microsoft Entra utilisé par les applications pour l’authentification unique. Par exemple, vous souhaitez peut-être autoriser l’accès aux applications Microsoft 365 de votre organisation, tout en empêchant l’accès aux instances d’autres organisations de ces mêmes applications.

Avec les restrictions de locataire, les organisations peuvent spécifier la liste des locataires auxquels les utilisateurs de leur réseau sont autorisés à accéder. Microsoft Entra ID accorde alors uniquement l’accès à ces locataires autorisés. Tous les autres locataires sont bloqués, même ceux auxquels vos utilisateurs peuvent être invités.

Cet article est axé sur les restrictions liées au locataire pour Microsoft 365, mais la fonctionnalité protège toutes les applications qui dirigent l’utilisateur vers Microsoft Entra ID à des fins d’authentification unique. Si vous utilisez des applications SaaS avec un locataire Microsoft Entra différent du locataire utilisé par votre instance de Microsoft 365, vérifiez que tous les locataires nécessaires sont autorisés. (Par exemple, dans les scénarios B2B Collaboration). Pour plus d’informations sur les applications cloud SaaS, consultez Active Directory Marketplace.

La fonctionnalité des restrictions liées au locataire prend également en charge le blocage de l’utilisation de toutes les applications grand public Microsoft (applications MSA) comme OneDrive, Hotmail et Xbox.com. Cette option utilise un en-tête distinct pour le point de terminaison login.live.com et est détaillée à la fin de cet article.

Fonctionnement

La solution comprend les composants suivants :

1. Microsoft Entra ID : si l’en-tête Restrict-Access-To-Tenants: <permitted tenant list> est présent, Microsoft Entra émet uniquement des jetons de sécurité pour les locataires autorisés.

2. Infrastructure de serveur proxy locale : cette infrastructure est un appareil proxy capable d’inspection TLS (Transport Layer Security). Vous devez configurer le serveur proxy de façon à insérer l’en-tête contenant la liste des locataires autorisés dans le trafic destiné à Microsoft Entra ID.

3. Logiciel client : pour prendre en charge les restrictions liées au locataire, le logiciel client doit demander des jetons directement à Microsoft Entra ID, afin que l’infrastructure du proxy puisse intercepter le trafic. Actuellement, les applications Microsoft 365 basées sur navigateur prennent en charge les restrictions liées au locataire, comme les clients Office qui utilisent l’authentification moderne (comme OAuth 2.0).

4. Authentification moderne : les services cloud doivent utiliser l’authentification moderne pour utiliser les restrictions liées au locataire et bloquer l’accès à tous les locataires non autorisés. Vous devez configurer les services cloud Microsoft 365 pour qu’ils utilisent les protocoles d’authentification moderne par défaut. Pour plus d’informations sur la prise en charge de l’authentification moderne par Microsoft 365, consultez Updated Office 365 modern authentication.

Le schéma suivant illustre le flux de trafic de niveau supérieur. Les restrictions liées au locataire nécessitent l’inspection TLS uniquement pour le trafic vers Microsoft Entra ID, pas pour le trafic vers les services cloud Microsoft 365. Cette distinction est importante, car le volume de trafic pour l’authentification auprès de Microsoft Entra ID est généralement beaucoup plus faible que le volume de trafic vers les applications SaaS comme Exchange Online et SharePoint Online.

Configurer les restrictions liées au locataire

Deux étapes sont nécessaires pour bien démarrer avec les restrictions liées au locataire. Premièrement, assurez-vous que vos locataires peuvent se connecter aux adresses correctes. Deuxièmement, configurez l’infrastructure de votre proxy.

URL et adresses IP

Pour utiliser des restrictions liées aux locataires, vos clients doivent être en mesure de se connecter aux URL Microsoft Entra suivantes pour s’authentifier :

• login.microsoftonline.com
• login.microsoft.com
• login.windows.net

En outre, pour accéder à Office 365, vos locataires doivent également être en mesure de se connecter aux noms de domaine complets (FQDN)/URL et adresses IP définis dans URL et plages d’adresses IP Office 365.

Configuration du proxy et conditions requises

La configuration suivante est nécessaire pour activer les restrictions liées au locataire dans l’infrastructure de votre proxy. Ce guide est générique, donc consultez la documentation du fabricant de votre proxy pour obtenir les étapes d’implémentation spécifiques.

Prérequis

• Le proxy doit être en mesure d’effectuer l’interception TLS, l’insertion d’en-tête HTTP et de filtrer les destinations à l’aide des noms de domaine complets/URL.

• Les clients doivent approuver la chaîne de certificat présentée par le proxy pour les communications TLS. Par exemple, si des certificats d’une infrastructure à clé publique interne sont utilisés, le certificat d’autorité de certificat racine émetteur interne doit être approuvé.

• Les licences Microsoft Entra ID P1 ou P2 1 sont requises pour l’utilisation des restrictions liées aux locataires.

Configuration

Pour chaque requête sortante sur login.microsoftonline.com, login.microsoft.com et login.windows.net, insérez deux en-têtes HTTP : Restrict-Access-To-Tenants et Restrict-Access-Context.

Les éléments suivants doivent être inclus dans les en-têtes :

• Pour Restrict-Access-To-Tenants, utilisez une valeur de <permitted tenant list> (liste de locataires autorisés), qui est une liste séparée par des virgules des locataires auxquels vous souhaitez que les utilisateurs puissent accéder. N’importe quel domaine qui est inscrit auprès d’un locataire peut être utilisé pour identifier le locataire dans cette liste et l’ID de répertoire proprement dit. Pour obtenir un exemple des trois façons de décrire un locataire, la paire nom/valeur pour autoriser Contoso, Fabrikam et Microsoft ressemble à ceci : Restrict-Access-To-Tenants: contoso.com,fabrikam.onmicrosoft.com,aaaabbbb-0000-cccc-1111-dddd2222eeee

• Pour Restrict-Access-Context, utilisez une valeur d’ID de répertoire unique, déclarant quel locataire définit les restrictions liées au locataire. Par exemple, pour déclarer Contoso en tant que locataire qui définit la stratégie de restrictions liées au locataire, la paire nom/valeur ressemble à ceci : Restrict-Access-Context: bbbbcccc-1111-dddd-2222-eeee3333ffff. Vous devez utiliser ici votre propre ID d’annuaire afin d’obtenir des journaux pour ces authentifications. Si vous utilisez un ID d’annuaire différent du vôtre, ces journaux de connexion s’affichent dans le locataire d’une autre personne, avec toutes les informations personnelles supprimées. Pour plus d’informations, consultez Expérience administrateur.

Pour rechercher votre ID d’annuaire :

1. Connectez-vous au centre d’administration Microsoft Entra en tant que Lecteur global.
2. Accédez à Identité>Vue d’ensemble>Vue d’ensemble.
3. Copiez la valeur de l’ID de locataire.

Pour vérifier qu’un ID d’annuaire ou un nom de domaine fait référence au même locataire, utilisez cet ID ou ce domaine à la place de <tenant> dans cette URL : https://login.microsoftonline.com/<tenant>/v2.0/.well-known/openid-configuration. Si les résultats avec le domaine et l’ID sont identiques, ils font référence au même locataire.

Pour empêcher les utilisateurs d’insérer leur propre en-tête HTTP avec des locataires non approuvés, le proxy doit remplacer l’en-tête Restrict-Access-To-Tenants si celui-ci est déjà présent dans la requête entrante.

Les clients doivent être forcés à utiliser le proxy pour toutes les requêtes sur login.microsoftonline.com, login.microsoft.com et login.windows.net. Par exemple, si des fichiers PAC sont utilisés pour indiquer aux locataires d’utiliser le proxy, les utilisateurs finaux ne doivent pas être en mesure de modifier ou de désactiver les fichiers PAC.

Expérience utilisateur

Cette section décrit l’expérience des utilisateurs finaux et des administrateurs.

Expérience de l’utilisateur final

Par exemple, un utilisateur sur le réseau Contoso tente d’accéder à l’instance Fabrikam d’une application SaaS partagée comme Outlook Online. Si Fabrikam est un locataire non autorisé pour l’instance Contoso, l'utilisateur reçoit un message de refus d'accès. Le message de refus indique que vous essayez d'accéder à une ressource appartenant à une organisation non approuvée par votre service informatique.

Expérience d’administrateur

Bien que la configuration des restrictions de locataire soit effectuée sur l’infrastructure du proxy d’entreprise, les administrateurs peuvent accéder aux rapports sur les restrictions de locataire directement dans le centre d’administration Microsoft Entra. Pour afficher les rapports :

1. Connectez-vous au centre d’administration Microsoft Entra en tant que Lecteur global.
2. Accédez à Identité>Vue d’ensemble>Restrictions de locataire.

L’administrateur du locataire spécifié en tant que locataire Restricted-Access-Context peut utiliser ce rapport pour afficher les connexions bloquées en raison de la stratégie de restrictions liées au locataire, notamment l’identité utilisée et l’ID du répertoire cible. Les connexions sont incluses si le client définissant la restriction est le client de l’utilisateur, ou le client de la ressource pour la connexion.

Le rapport peut contenir des informations limitées, telles que l’ID de répertoire cible, lorsqu’un utilisateur situé dans un locataire autre que le locataire Restricted-Access-Context se connecte. Dans ce cas, les informations d’identification de l’utilisateur, comme le nom et le nom d’utilisateur principal, sont masquées pour protéger les données utilisateur dans d’autres locataires (par exemple "{PII Removed}@domain.com" or 00000000-0000-0000-0000-000000000000 à la place des noms d’utilisateur et des ID d’objet, le cas échéant).

Comme pour les autres rapports dans le centre d’administration Microsoft Entra, vous pouvez utiliser des filtres pour spécifier l’étendue de votre rapport. Vous pouvez filtrer par intervalle de temps, utilisateur, application, locataire ou état spécifique. Si vous sélectionnez le boulon Colonnes, vous pouvez choisir d’afficher les données avec n’importe quelle combinaison des champs suivants :

• Utilisateur : des données personnelles peuvent être supprimées dans ce champ, il est alors défini sur 00000000-0000-0000-0000-000000000000.
• Application
• État
• Date
• Date (UTC) : où UTC est le temps universel coordonné
• Adresse IP
• Client
• Nom d’utilisateur : des données personnelles peuvent être supprimées dans ce champ, il est alors défini sur {PII Removed}@domain.com
• Lieu
• ID du locataire cible

Support Microsoft 365

Les applications Microsoft 365 doivent répondre à deux critères pour prendre pleinement en charge les restrictions liées au locataire :

1. Le locataire utilisé prend en charge l’authentification moderne.
2. L’authentification moderne est activée comme protocole d’authentification par défaut pour le service cloud.

Pour plus d’informations sur les clients Office qui prennent actuellement en charge l’authentification moderne, consultez Authentification moderne Office 365 mise à jour. Cette page inclut également des liens vers des instructions relatives à l’activation de l’authentification moderne sur des clients Exchange Online et Skype Entreprise Online spécifiques. SharePoint Online active déjà l’authentification moderne par défaut. Teams prend uniquement en charge l’authentification moderne et pas l’authentification héritée, ce problème ne s’applique donc pas à Teams.

Les applications Microsoft 365 basées sur navigateur (tel que le portail Office, Yammer, les sites SharePoint et Outlook sur le web) prennent actuellement en charge les restrictions liées au locataire. Les locataires lourds (Outlook, Skype Entreprise, Word, Excel, PowerPoint, etc.) peuvent appliquer des restrictions liées au locataire uniquement lorsque vous utilisez l’authentification moderne.

Les clients Outlook et Skype for Business qui prennent en charge l'authentification moderne peuvent encore utiliser des protocoles anciens contre des locataires pour lesquels l'authentification moderne n'est pas activée, ce qui permet de contourner les restrictions imposées aux locataires. Les restrictions imposées aux locataires peuvent bloquer les applications qui utilisent des protocoles anciens si elles contactent login.microsoftonline.com, login.microsoft.com ou login.windows.net pendant l'authentification.

Pour Outlook sur Windows, les clients peuvent choisir de mettre en œuvre des restrictions empêchant les utilisateurs finaux d'ajouter des comptes de messagerie non approuvés à leurs profils. Par exemple, consultez le paramètre de stratégie de groupe Empêcher l’ajout de comptes Exchange personnalisés.

Incompatibilité entre Azure RMS et le chiffrement de messages Office

Les fonctionnalités Azure Rights Management Service (Azure RMS) et Chiffrement de message Office ne sont pas compatibles avec les restrictions de tenant. Ces fonctionnalités reposent sur la signature de vos utilisateurs dans d’autres locataires pour obtenir les clés de déchiffrement des documents chiffrés. Étant donné que les restrictions de locataire bloquent l’accès aux autres locataires, le courrier chiffré et les documents envoyés à vos utilisateurs à partir de locataires non approuvés ne sont pas accessibles.

Test

Si vous souhaitez tester les restrictions liées au locataire avant de les implémenter pour l’ensemble de votre organisation, deux options sont à votre disposition : une approche basée sur l’hôte à l’aide d’un outil comme Fiddler ou un déploiement par étapes des paramètres du proxy.

Fiddler pour une approche basée sur hôte

Fiddler est un proxy de débogage web gratuit qui peut être utilisé pour capturer et modifier le trafic HTTP/HTTPS, notamment l’insertion d’en-têtes HTTP. Pour configurer Fiddler afin de tester les restrictions liées au locataire, procédez comme suit :

1. Téléchargez et installez Fiddler.

2. Configurez Fiddler pour déchiffrer le trafic HTTPS, conformément à la documentation d’aide de Fiddler.

3. Configurez Fiddler pour insérer les en-têtes Restrict-Access-To-Tenants et Restrict-Access-Context à l’aide de règles personnalisées :

   1. Dans l’outil Fiddler Web Debugger, sélectionnez le menu Rules et sélectionnez Customize Rules... pour ouvrir le fichier CustomRules.

   2. Ajoutez les lignes suivantes dans la fonction OnBeforeRequest. Remplacez la <Liste des identificateurs de locataire> par un domaine inscrit à votre locataire (par exemple, contoso.onmicrosoft.com). Remplacez l’<ID d’annuaire> par l’identificateur GUID Microsoft Entra de votre locataire. Vous devez inclure l’identificateur GUID correct afin que les journaux apparaissent dans votre locataire.

    // Allows access to the listed tenants.
      if (
          oSession.HostnameIs("login.microsoftonline.com") ||
          oSession.HostnameIs("login.microsoft.com") ||
          oSession.HostnameIs("login.windows.net")
      )
      {
          oSession.oRequest["Restrict-Access-To-Tenants"] = "<List of tenant identifiers>";
          oSession.oRequest["Restrict-Access-Context"] = "<Your directory ID>";
      }
   
    // Blocks access to consumer apps
      if (
          oSession.HostnameIs("login.live.com")
      )
      {
          oSession.oRequest["sec-Restrict-Tenant-Access-Policy"] = "restrict-msa";
      }
   

   Si vous avez besoin d’autoriser plusieurs clients, utilisez une virgule pour séparer les noms des clients. Par exemple :

   oSession.oRequest["Restrict-Access-To-Tenants"] = "contoso.onmicrosoft.com,fabrikam.onmicrosoft.com";

4. Enregistrez et fermez le fichier CustomRules.

Après avoir configuré Fiddler, vous pouvez capturer le trafic en accédant au menu Fichier et en sélectionnant Capturer le trafic.

Déploiement par étapes des paramètres du proxy

En fonction des capacités de votre infrastructure de proxy, vous pourriez être en mesure d’étalonner le déploiement des paramètres pour vos utilisateurs. Pour plus d’informations, consultez les options générales suivantes :

1. Utilisez des fichiers PAC pour pointer les utilisateurs test vers une infrastructure de proxy test, tandis que les utilisateurs normaux continuent à utiliser l’infrastructure du proxy de production.
2. Certains serveurs proxy peuvent prendre en charge des configurations différentes à l’aide de groupes.

Pour obtenir des informations spécifiques, consultez la documentation de votre serveur proxy.

Blocage des applications grand public

Les applications de Microsoft qui prennent en charge les comptes de consommateurs et les comptes d’entreprises, comme OneDrive, peuvent parfois être hébergées sur la même URL. Cela signifie que les utilisateurs qui doivent accéder à cette URL à des fins professionnelles peuvent également y accéder à des fins personnelles, ce qui n’est peut-être pas autorisé dans le cadre de vos règles de fonctionnement. Cette option peut ne pas être autorisée dans le cadre de vos instructions d’exploitation.

Certaines organisations tentent de résoudre ce problème en bloquant login.live.com afin de bloquer l’authentification des comptes personnels. Cela a plusieurs inconvénients :

1. Le blocage de login.live.com bloque l’utilisation de comptes personnels dans les scénarios d’invité B2B, ce qui peut gêner les visiteurs et la collaboration.
2. Autopilot requiert l’utilisation de login.live.com pour se déployer. Les scénarios Intune et Autopilot peuvent échouer lorsque login.live.com est bloqué.
3. Les données de télémétrie de l’organisation et les mises à jour Windows qui s’appuient sur le service login.live.com pour les ID d’appareil cessent de fonctionner.

Configuration pour les applications grand public

Tandis que l’en-tête Restrict-Access-To-Tenants fonctionne comme une liste verte, le bloc de compte Microsoft (MSA) fonctionne comme un signal de refus, indiquant à la plateforme de compte Microsoft de ne pas permettre aux utilisateurs de se connecter aux applications grand public. Pour envoyer ce signal, l’en-tête sec-Restrict-Tenant-Access-Policy est injecté dans le trafic lors de la visite à login.live.com l’aide du même proxy d’entreprise ou du même pare-feu que mentionné dans la section Configuration du proxy et conditions requises de cet article. La valeur de l’en-tête doit être restrict-msa. Lorsque l’en-tête est présent et qu’une application grand public tente de connecter un utilisateur directement, cette connexion est bloquée.

Pour le moment, l’authentification auprès des applications grand public n’apparaît pas dans les journaux d’administration, car login.live.com est hébergé séparément de Microsoft Entra ID.

Ce qui est bloqué et non bloqué par l’en-tête

La stratégie restrict-msa bloque l’utilisation d’applications grand public, mais autorise plusieurs autres types de trafic et d’authentification :

1. Trafic sans utilisateur pour les appareils. Cela comprend le trafic pour Autopilot, Windows Update et les données de télémétrie de l’organisation.
2. Authentification B2B de comptes de consommateurs. Les utilisateurs disposant de comptes Microsoft qui sont invités à collaborer avec un locataire s’authentifient sur login.live.com pour accéder à un locataire de ressources.
   1. Cet accès est contrôlé à l’aide de l’en-tête Restrict-Access-To-Tenants pour autoriser ou refuser l’accès à ce locataire de ressources.
3. Authentification « PassThrough », utilisée par de nombreuses applications Azure et Office.com, où les applications utilisent Microsoft Entra ID pour connecter des utilisateurs consommateurs dans un contexte de consommateur.
   1. Cet accès est également contrôlé à l’aide de l’en-tête Restrict-Access-To-Tenants pour autoriser ou refuser l’accès au locataire « PassThrough » spécial (f8cdef31-a31e-4b4a-93e4-5f571e91255a). Si ce locataire n’apparaît pas dans votre liste Restrict-Access-To-Tenants de domaines autorisés, Microsoft Entra ID empêche les comptes de consommateurs de se connecter à ces applications.

Les plateformes qui ne prennent pas en charge l’interruption et l’inspection du trafic par TLS

Les restrictions de locataire dépendent de l’injection d’une liste de locataires autorisés dans l’en-tête HTTPS. Cette dépendance nécessite l’inspection TLSI (Transport Layer Security Inspection) pour interrompre et inspecter le trafic. Pour les environnements où le côté client n’est pas en mesure d’arrêter et d’inspecter le trafic pour ajouter des en-têtes, les restrictions de locataire ne fonctionnent pas.

Prenons l’exemple d’Android 7.0 et versions ultérieures. Android a modifié la façon dont il gère les autorités de certification approuvées pour fournir des valeurs par défaut plus sécurisées pour le trafic d’applications sécurisées. Pour plus d’informations, consultez Modifications apportées aux autorités de certification approuvées dans Android Nougat.

Après la recommandation de Google, les applications clientes Microsoft ignorent les certificats utilisateur par défaut. Cette stratégie rend ces applications incapables de fonctionner avec des restrictions de locataire, car les certificats utilisés par le proxy réseau sont installés dans le magasin de certificats utilisateur, que les applications clientes n’approuvent pas.

Pour les environnements qui ne peuvent pas interrompre et inspecter le trafic pour ajouter les paramètres de restrictions liées aux locataires à l’en-tête, d’autres fonctionnalités de Microsoft Entra ID peuvent fournir une protection. La liste suivante fournit plus d’informations sur ces fonctionnalités Microsoft Entra.

• Accès conditionnel : autoriser uniquement l’utilisation d’appareils gérés/conformes
• Accès conditionnel : gérer l’accès pour les utilisateurs invités/externes
• B2B Collaboration : restreindre les règles de trafic sortant par l’accès interlocataire pour les locataires répertoriés dans le paramètre « Restrict-Access-To-Tenants »
• B2B Collaboration : restreindre les invitations aux utilisateurs B2B aux mêmes domaines que ceux répertoriés dans le paramètre « Restrict-Access-To-Tenants »
• Gestion des applications : restreindre le consentement des utilisateurs aux applications
• Intune : appliquez la stratégie d’application via Intune pour limiter l’utilisation des applications gérées à l’UPN du compte qui a inscrit l’appareil. Consultez la section sous le sous-titre Autoriser uniquement les comptes d’organisation configurés dans les applications.

Toutefois, certains scénarios spécifiques peuvent uniquement être couverts à l’aide de restrictions de locataire.

Étapes suivantes

• En savoir plus sur l’authentification moderne Office 365 mise à jour
• Consultez les URL et plages d’adresses IP Office 365