Environnement informatique distribué avec de nombreux administrateurs dans le même locataire Microsoft Intune

  • Article

De nombreuses organisations utilisent un environnement informatique distribué où elles ont un seul locataire Microsoft Intune avec plusieurs administrateurs locaux. Cet article décrit une façon de mettre à l’échelle Microsoft Intune pour prendre en charge plusieurs administrateurs locaux qui gèrent leurs propres utilisateurs, appareils et créent leurs propres stratégies au sein d’un seul locataire Microsoft Intune. Il n’existe aucune bonne ou mauvaise réponse sur le nombre d’administrateurs que vous pouvez avoir dans votre locataire. L’article se concentre sur les locataires qui ont de nombreux administrateurs locaux.

L’informatique distribuée est nécessaire dans les systèmes où un grand nombre d’administrateurs locaux se connectent à un seul locataire Intune. Par exemple, certains systèmes scolaires sont organisés de sorte que vous disposez d’un administrateur local pour chaque école du système ou de la région. Parfois, cet environnement distribué peut être composé d’au moins 15 administrateurs locaux différents qui se cumulent vers le même système central ou Microsoft Intune locataire.

Chaque administrateur local peut configurer des groupes en fonction de ses besoins organisationnels. L’administrateur local crée généralement des groupes et organise plusieurs utilisateurs ou appareils par emplacement géographique, service ou caractéristiques matérielles. Les administrateurs locaux utilisent également ces groupes pour gérer les tâches à grande échelle. Par exemple, les administrateurs locaux peuvent définir des stratégies pour de nombreux utilisateurs ou déployer des applications sur un ensemble d’appareils.

Rôles que vous devez connaître

  • Équipe centrale : l’équipe ou le groupe central inclut les administrateurs généraux ou les administrateurs principaux de votre locataire. Ces administrateurs peuvent superviser tous les administrateurs locaux et fournir des conseils aux administrateurs locaux.

  • Administrateurs locaux : les administrateurs locaux sont locaux et se concentrent sur les stratégies et les profils pour leurs emplacements spécifiques. des écoles, des hôpitaux, etc.

Contrôle d’accès en fonction du rôle

Cette section décrit brièvement les différents modèles et propose des instructions sous chaque modèle pour la gestion des stratégies, des profils et des applications entre l’équipe centrale et les administrateurs locaux. Les modèles sont les suivants :

  • Modèle de délégation partielle
  • Modèle de délégation complète
  • Modèle central
  • Modèle démenti
  • Modèle hybride

Modèle de délégation partielle

Le modèle de délégation partielle propose les instructions suivantes pour la gestion des stratégies entre l’équipe centrale et les administrateurs locaux.

✔️ Autorisations

  • Les autorisations de création, de mise à jour et de suppression pour les stratégies, les profils d’inscription et les applications doivent être détenues par l’équipe centrale.
  • Accordez uniquement des autorisations de lecture et attribuez-les aux administrateurs locaux.

✔️ Réutiliser

  • Les stratégies, les profils d’inscription et les applications couramment configurés doivent être mis à la disposition des administrateurs locaux pour les réutiliser autant que possible.
  • Microsoft Intune utilise de nombreuses configurations courantes qui appartiennent à quelques catégories. Passez en revue les recommandations répertoriées pour les stratégies de protection des applications.
  • À mesure que les administrateurs locaux s’intègrent, ils doivent examiner les stratégies existantes et les réutiliser en fonction des besoins.

✔️ Exceptions

  • L’équipe centrale peut créer certaines stratégies, profils d’inscription et applications en tant qu’exceptions, si nécessaire, pour le compte des administrateurs locaux. En règle générale, ces exceptions incluent tout type de profil qui nécessite des paramètres uniques.

Un modèle de délégation partielle est proposé dans ces deux domaines :

Instructions de groupe et d’affectation pour les administrateurs locaux : Quelles sont les meilleures pratiques que les administrateurs locaux doivent adopter lors de l’organisation des groupes pour la gestion des appareils via Microsoft Intune ? Pour le savoir, lisez l’article Regroupement, ciblage et filtrage Intune : recommandations pour de meilleures performances - Microsoft Tech Community

Instructions spécifiques aux fonctionnalités : Comment les stratégies/profils/applications sont-ils gérés entre une autorité centrale et les administrateurs locaux disposant d’autorisations spécifiques pour les différentes fonctionnalités. Pour plus d’informations, consultez la section Instructions spécifiques aux fonctionnalités.

Modèle de délégation complète

Le modèle de délégation complet propose les instructions suivantes pour la gestion des stratégies entre l’équipe centrale et les administrateurs locaux.

  • Chaque administrateur local doit avoir sa propre balise d’étendue pour séparer chaque objet qu’il gère entièrement.
  • Lorsque l’administrateur local n’a pas besoin de créer, de mettre à jour ou de supprimer, accordez à l’administrateur local un rôle avec des autorisations de lecture et d’attribution, et évitez de lui attribuer un autre rôle disposant d’autorisations complètes. Avec cette approche, vous pouvez éviter de combiner des autorisations entre les balises d’étendue.
  • Parfois, les administrateurs locaux doivent créer leurs propres stratégies, profils et applications tout en partageant des stratégies, des profils et des applications courants. Dans ce cas, créez un groupe spécial et attribuez les stratégies, profils et applications communs à ce groupe. Ce groupe ne doit pas être inclus dans le groupe d’étendues pour un administrateur local. Groupe d’étendues. Cette approche empêche les autorisations de création, de mise à jour et de suppression attribuées aux administrateurs locaux de s’appliquer à ces stratégies, profils et applications courants.

Modèle central

Dans le modèle central, une seule équipe d’administration locale (parent) gère plusieurs organisations enfants. Des facteurs tels que la géographie, l’unité commerciale ou la taille peuvent lier les organisations enfants.

  • Une seule balise d’étendue est utilisée pour couvrir tous les administrateurs locaux gérés.

  • Si possible, l’équipe d’administration locale doit normaliser les affectations entre les administrateurs locaux et placer tous leurs appareils dans un seul groupe de Microsoft Entra pour affectation. Lorsqu’il n’est pas possible de créer un seul groupe Microsoft Entra, l’équipe d’administration locale peut créer différents groupes Microsoft Entra pour effectuer des affectations différentes.

  • Si une autre équipe d’administration locale gère ou déplace une organisation, les étapes suivantes doivent être effectuées :

    • Tous les appareils et utilisateurs de l’organisation doivent être extraits de groupes de Microsoft Entra communs dans l’étendue de l’équipe d’administration locale d’origine.

    • Toutes les stratégies/applications/profils attribués de manière unique à cette organisation doivent avoir leur balise d’étendue mise à jour pour la nouvelle équipe d’administration locale.

Modèle démenti

Dans le modèle démenti, plusieurs administrateurs locaux (enfants) sont gérés à la fois par leur administrateur local dédié et également supervisés par une équipe d’administration locale intermédiaire. Les administrateurs parents et enfants ont leurs propres balises d’étendue pour représenter les limites de gestion.

  • S’il y a moins de 50 administrateurs enfants, l’équipe d’administration locale intermédiaire peut se voir accorder l’accès en affectant toutes les balises d’étendue des enfants à l’attribution de rôle RBAC des équipes d’administration locales intermédiaires.
  • S’il y a plus de 50 administrateurs enfants, l’équipe d’administration locale intermédiaire doit recevoir sa propre balise d’étendue pour représenter l’ensemble des administrateurs enfants qu’elle supervise.
  • Les nouvelles stratégies créées sous les balises d’étendue de l’administrateur enfants doivent avoir la balise intermédiaire ajoutée par un rôle d’administrateur général pour empêcher l’équipe d’administration locale intermédiaire de perdre de visibilité.

Modèle hybride

Dans le modèle hybride, le même administrateur parent est utilisé en même temps dans le modèle central et dans le modèle démeséré. Il n’existe aucune recommandation spéciale pour ce modèle.

Instructions spécifiques aux fonctionnalités

Selon les besoins métier de chaque fonctionnalité, les instructions fournies dans cette section peuvent vous recommander de créer des stratégies par administrateur local et/ou de déléguer les autorisations nécessaires à la création d’objets aux administrateurs locaux.

Remarque

Les conseils fournis dans cette section ne traitent pas de toutes les fonctionnalités, mais couvrent uniquement les domaines pour lesquels nous avons des instructions spéciales.

Protection d'applications stratégie

Les stratégies de protection des applications sont des règles qui garantissent que les données d’une organisation sont sécurisées ou restent dans une application gérée. Pour plus d’informations, consultez Protection d'applications stratégies.

Les instructions pour les stratégies Protection d'applications sont réparties entre l’équipe centrale et les administrateurs locaux comme suit :

Équipe centrale - Tâches

  • Passez en revue les besoins de sécurité et d’entreprise dans l’ensemble des organization et générez un ensemble de stratégies de Protection d'applications courantes pour les administrateurs locaux.
  • Passez en revue les recommandations répertoriées pour identifier les contrôles de sécurité appropriés avant de créer des stratégies Protection d'applications.
  • Disposer d’une méthode établie permettant aux administrateurs locaux de demander des stratégies de Protection d'applications personnalisées, si nécessaire, pour des besoins métier spécifiques où les exigences métier ne peuvent pas être atteintes avec les stratégies communes existantes.
  • Pour obtenir des recommandations spécifiques sur chaque niveau de configuration et les applications minimales qui doivent être protégées, consultez Infrastructure de protection des données à l’aide de stratégies de Protection d'applications, accédez à Protection d'applications stratégies

Administrateurs locaux - Autorisations et tâches

  • Fournissez des autorisations de lecture et d’attribution, mais pas des autorisations de création, de mise à jour ou de suppression sur les applications gérées, afin qu’elles ne puissent pas créer leurs propres stratégies Protection d'applications.
  • Fournissez des autorisations de lecture et d’attribution de stratégie de configuration d’application à leurs applications.
  • Fournissez des autorisations de lecture et d’attribution uniquement lorsqu’il existe des stratégies de protection différentes pour les appareils gérés et les appareils non gérés. Si l’équipe centrale choisit d’offrir une seule stratégie pour les deux, la stratégie de configuration de l’application n’est pas nécessaire.
  • Si la stratégie de configuration d’application est utilisée, il est recommandé d’affecter la stratégie de configuration d’application à toutes les instances d’application sans exception.
  • Choisissez parmi les stratégies de Protection d'applications courantes. Les administrateurs locaux peuvent demander à l’équipe centrale de créer des stratégies de protection des applications personnalisées en tant qu’exception, et uniquement si nécessaire.
  • Pour plus d’informations, consultez stratégies Protection d'applications

Stratégie de conformité

Les stratégies de conformité dans Intune définissent les règles et les paramètres que les utilisateurs et les appareils doivent respecter pour être conformes. Pour plus d’informations sur les stratégies de conformité, accédez à Stratégies de conformité.

Équipe centrale

L’équipe centrale doit créer des stratégies de conformité courantes parmi lesquelles les administrateurs locaux peuvent choisir et uniquement, si nécessaire, créer des stratégies d’exception. Pour plus d’informations, consultez Stratégies de conformité. La création de stratégies inclut la création de scripts de stratégie de conformité personnalisés, car ils sont soumis à la même échelle que la stratégie de conformité normale.

Pour plus d’informations sur la création d’une stratégie de conformité, consultez Stratégies de conformité.

Administrateurs locaux

Fournissez aux administrateurs locaux des autorisations de lecture et d’attribution, mais pas des autorisations de création, de mise à jour ou de suppression sur la stratégie de conformité. Les autorisations de lecture et d’attribution leur permettent de choisir parmi les stratégies de conformité courantes créées par l’équipe centrale et de les affecter à leurs utilisateurs et appareils.

Configuration des appareils

Dans cette section :

  • Restrictions d’appareil et configuration générale
  • Accès aux ressources
  • Anneaux de mise à jour Windows
  • Mises à jour de fonctionnalités
  • Mises à jour de qualité.

Restrictions d’appareil et configuration générale

  • Accordez aux administrateurs locaux l’autorisation de créer, mettre à jour et supprimer dans leur propre étendue.

  • Utilisez le catalogue de paramètres et les bases de référence de sécurité au maximum, au lieu des profils créés dans la liste Profils de configuration, pour atténuer la mise à l’échelle dans le centre d’administration Microsoft Intune.

  • En règle générale, l’équipe centrale doit essayer de surveiller de manière centralisée le contenu des configurations et de remplacer un grand nombre de profils dupliqués si possible par un profil partagé.

Accès aux ressources

Le modèle de délégation complète est recommandé.

Anneaux de mise à jour Windows

  • Nous vous recommandons de gérer les anneaux de mise à jour Windows de manière centralisée. L’équipe centrale doit créer autant de stratégies d’anneau de mise à jour Windows courantes que nécessaire pour prendre en charge la variance des administrateurs locaux.
  • Les administrateurs locaux ne doivent pas créer leurs propres anneaux de mise à jour Windows. Lorsque vous déléguez à un grand nombre d’administrateurs, le nombre total d’objets peut devenir important et difficile à gérer. Les bonnes pratiques varient pour chaque fonctionnalité. Pour plus d’informations, consultez Anneaux de mise à jour Windows.

Mises à jour de fonctionnalités

Le modèle de délégation complète est recommandé.

Mises à jour de qualité.

Le modèle de délégation complète est recommandé.

Certificats

  • Nous vous recommandons d’utiliser des autorisations via l’équipe centrale pour intégrer/désactiver les connecteurs en fonction des besoins. Intégrez des connecteurs pour chaque administrateur local afin de prendre en charge l’émission de certificats.

  • N’accordez pas aux administrateurs locaux l’autorisation d’accès aux connecteurs UPDATE ou DELETE.

Applications

Accordez aux administrateurs locaux des autorisations complètes pour gérer les applications dans l’étendue de leur portée.

Dans cette section :

  • Programme d’achat en volume Apple

  • Windows

  • Android

Pour plus d’informations, accédez à Gérer les applications.

Programme d’achat en volume Apple

Actuellement, il n’existe aucun problème de mise à l’échelle pour le nombre de jetons du programme d’achat en volume pris en charge. Pour plus d’informations, consultez Combien de jetons puis-je charger..

Windows

Android

  • Les administrateurs locaux doivent choisir parmi les applications du Store existantes ou demander à l’équipe centrale d’ajouter de nouvelles applications Android Store. Les administrateurs locaux ne doivent pas créer de nouvelles applications du Store Android. Le nombre total d’objets peut devenir important et difficile à gérer.

  • Les administrateurs locaux peuvent créer des applications métier Android, selon les besoins, dans la limite multiplateforme, métier et lien web.

  • L’équipe centrale doit ajouter des applications Google Play gérées.

    • L’équipe centrale peut uniquement voir les applications Google Play gérées disponibles dans le pays/la région de son locataire. Si l’équipe centrale a besoin d’une application Google Play gérée disponible uniquement dans certains pays/régions, elle peut avoir besoin de travailler avec le développeur de l’application pour qu’elle soit répertoriée correctement.
    • L’équipe centrale doit gérer tout le contenu lié aux applications Google Play gérées, y compris les applications privées, les applications web et les collections. Par exemple, si un client envisage d’utiliser l’iframe Google Play managé pour publier des applications privées, il doit le faire avec un seul compte de développeur appartenant à l’équipe centrale.
    • L’équipe centrale peut sélectionner une seule balise d’étendue comme balise d’étendue Google Play gérée. Il comporte une liste déroulante spéciale dans la page du connecteur Google Play géré. La balise d’étendue s’applique à toutes les applications Google Play gérées une fois que l’équipe centrale les ajoute à la console, mais ne s’applique pas rétroactivement aux applications qui ont déjà été ajoutées. Il est vivement recommandé que l’équipe centrale définisse la balise d’étendue avant d’ajouter des applications, puis attribue à chaque équipe régionale cette balise d’étendue. Dans le cas contraire, les administrateurs régionaux risquent de ne pas pouvoir voir leurs applications Google Play gérées.

  • Une seule stratégie OEMConfig est prise en charge par appareil, à l’exception des appareils Zebra. Avec les appareils Zebra, il est fortement recommandé d’avoir le plus petit nombre de stratégies possible, car le temps nécessaire pour appliquer la stratégie est additif. Par exemple, si vous affectez six stratégies avec l’hypothèse qu’elles vont se superposer les unes aux autres, il faut environ 6 fois plus de temps pour commencer à travailler sur l’appareil qu’une seule stratégie.

Remarque

Faites preuve d’extrême considération et de prudence lors de la définition du mode de mise à jour à priorité élevée sur de nombreuses applications et groupes différents. Cela pour plusieurs raisons :

  • Bien que de nombreuses applications puissent être définies en mode haute priorité, une seule mise à jour d’application peut être installée à la fois. Une mise à jour d’application volumineuse peut potentiellement bloquer de nombreuses mises à jour plus petites jusqu’à ce que l’installation de la grande application soit terminée.
  • Selon le moment où les applications publient de nouvelles mises à jour, il peut y avoir un pic soudain dans votre utilisation réseau si les versions d’application coïncident. Si Wi-Fi n’est pas disponible sur certains appareils, il peut également y avoir un pic d’utilisation des téléphones cellulaires.
  • Bien que des expériences utilisateur perturbatrices aient déjà été mentionnées, le problème augmente à mesure que de plus en plus d’applications sont configurées en mode de mise à jour à priorité élevée.

Pour plus d’informations sur les problèmes de mise à l’échelle concernant les mises à jour des applications Google Play gérées à l’aide du mode de mise à jour à priorité élevée, consultez cet article Techcommunity.

Profils d’inscription

Dans cette section :

  • Autopilot
  • Page de status d’inscription (ESP)
  • Apple Business Manager (ABM)
  • Profils Android Entreprise
  • Restrictions d’inscription
  • Catégories d’appareils

Autopilot

  • Accordez aux administrateurs locaux les autorisations nécessaires pour lire les appareils Autopilot et charger de nouveaux appareils Autopilot.
  • Les administrateurs locaux ne doivent pas créer de profils Autopilot. Lorsque vous déléguez à un grand nombre d’administrateurs, le nombre total d’objets peut devenir important et difficile à gérer. La meilleure pratique varie selon le domaine de fonctionnalité. Pour plus d’informations sur Autopilot, consultez Utiliser Autopilot pour inscrire des appareils Windows dans Intune.

Page Statut de l’inscription

  • Les administrateurs locaux doivent sélectionner parmi les profils de page Inscription status existants à attribuer, ou ils doivent demander à l’équipe centrale de créer un profil d’exception, uniquement si nécessaire.
  • Les administrateurs locaux ne doivent pas créer de profils de page d’inscription status. Lorsque vous déléguez à un grand nombre d’administrateurs, le nombre total d’objets peut devenir important et difficile à gérer. La meilleure pratique varie selon le domaine de fonctionnalité. Pour plus d’informations sur la page Status d’inscription, accédez à Configurer la page État de l’inscription.

Apple Business Manager

Si possible, les administrateurs locaux ne doivent pas se voir accorder d’autorisations de création, de mise à jour ou de suppression sur les profils d’inscription. Si les administrateurs locaux disposent d’autorisations pour créer des profils Apple Business Manager, cela leur donne également des autorisations de création, de mise à jour et de suppression dans Autopilot. Toutefois, les administrateurs locaux ne doivent pas créer de profils Autopilot.

Lorsque vous déléguez à un grand nombre d’administrateurs, le nombre total d’objets peut devenir important et difficile à gérer. La meilleure pratique varie selon le domaine de fonctionnalité. Pour plus d’informations, consultez Utiliser Apple Business Manager pour inscrire des appareils Apple dans Intune.

Profils Android Entreprise

  • L’équipe centrale doit créer des profils d’inscription d’appareils android enterprise dédiés appartenant à l’entreprise pour chaque administrateur local pour le regroupement d’appareils.
  • Si possible, les administrateurs locaux ne doivent pas se voir accorder d’autorisations de création, de mise à jour ou de suppression sur les appareils Android Enterprise. Ces restrictions empêchent les administrateurs locaux de modifier les paramètres Android Entreprise à l’échelle du locataire et le profil d’inscription global entièrement managé.

Restrictions d’inscription

  • Le même ensemble d’autorisations régissent à la fois la configuration de l’appareil et les restrictions d’inscription. Lorsque vous accordez des autorisations de création pour la configuration de l’appareil, vous accordez également des autorisations de création pour les restrictions d’inscription. Toutefois, les administrateurs locaux ne doivent pas être autorisés à créer des profils de restriction d’inscription. Par conséquent, ils doivent être invités à ne pas créer de nouveaux profils de restrictions d’inscription.

  • Les restrictions de limite d’appareils d’inscription définissent le nombre d’appareils que chaque utilisateur peut inscrire. Les restrictions de limite d’appareils d’inscription doivent couvrir toutes les limites d’appareils possibles que les administrateurs locaux peuvent partager. Pour plus d’informations, consultez Que sont les restrictions d’inscription.

  • L’équipe centrale doit standardiser autant que possible les restrictions de type d’appareil et ajouter de nouvelles restrictions, mais uniquement en tant qu’exceptions spéciales après qu’un administrateur local a examiné les restrictions existantes.

Catégories d’appareils

La fonctionnalité Catégories d’appareils (Catégories d’appareils>) n’a pas sa propre famille d’autorisations. Au lieu de cela, ses autorisations sont régies par les autorisations définies sous Organisation. Accédez à Rôles d’administration > des locataires. Sélectionnez un rôle personnalisé ou intégré, puis sélectionnez Propriétés. Ici, vous pouvez attribuer des autorisations, l’une d’entre elles étant Organisation. Par conséquent, si vous avez besoin d’autorisations de lecture pour les catégories d’appareils, définissez des autorisations de lecture dans Organisation.

Les équipes centrales peuvent créer des catégories d’appareils. Toutefois, les administrateurs locaux ne doivent pas être autorisés à créer, mettre à jour ou supprimer des catégories d’appareils, car cela nécessiterait leur accorder des autorisations sur l’organisation, leur donnant accès à d’autres fonctionnalités au niveau du locataire régies par les autorisations de l’organisation.

Pour plus d’informations, consultez Catégories d’appareils.

Analyse des points de terminaison

  • L’équipe centrale doit créer autant de bases de référence d’analyse des points de terminaison courantes que nécessaire pour prendre en charge la variance des administrateurs locaux.
  • Si possible, les administrateurs locaux ne doivent pas créer leurs propres bases de référence Endpoint Analytics. Lorsque vous déléguez à un grand nombre d’administrateurs, le nombre total d’objets peut devenir important et difficile à gérer. La meilleure pratique varie selon le domaine de fonctionnalité.
  • Pour plus d’informations, consultez Configuration des paramètres dans Analyse des points de terminaison.