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

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 et appareils et créent leurs propres stratégies, le tout au sein d’un seul locataire Microsoft Intune.

Il n’y a pas de bonne ou de mauvaise réponse sur le nombre d’administrateurs que vous devriez avoir dans votre client. L’article se concentre sur les locataires qui ont de nombreux administrateurs locaux.

L’informatique distribuée est nécessaire dans les organisations où un grand nombre d’administrateurs locaux se connectent à un seul locataire Intune. Par exemple, certains systèmes scolaires sont organisés de façon à ce que vous ayez un administrateur local pour chaque école du système ou de la région. Parfois, cet environnement distribué peut inclure plus de 15 administrateurs locaux différents qui sont cumulés vers le même système central ou le même client Microsoft Intune.

Chaque administrateur local peut configurer des groupes en fonction des besoins de son organisation locale. L’administrateur local crée généralement des groupes et organise plusieurs utilisateurs ou périphériques 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.

Termes utilisés dans cet article

  • Privilège minimum : la sécurisation des accès à votre organisation est une étape de sécurité essentielle. Intune utilise des contrôles d’accès basés sur des rôles (RBAC) pour attribuer aux utilisateurs administratifs des autorisations au sein d’Intune pour administrer différentes tâches. Avec le principe de l’accès au moindre privilège , vos administrateurs peuvent effectuer les tâches qui leur sont attribuées uniquement sur les utilisateurs et les appareils qu’ils doivent être habilités à gérer.

  • Équipe centrale : l’équipe ou le groupe central comprend les administrateurs principaux de votre client. Ces administrateurs peuvent superviser tous les administrateurs locaux et leur fournir des conseils.

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

Contrôle d'accès basé sur les rôles

La sécurisation des accès à votre organisation est une étape de sécurité essentielle. Intune utilise des contrôles d’accès basés sur les rôles pour accorder des autorisations granulaires à vos administrateurs afin de contrôler qui a accès aux ressources de votre organisation et ce qu’ils peuvent faire avec ces ressources. En attribuant des rôles RBAC Intune et en respectant les principes de l’accès au moindre privilège, vos administrateurs peuvent effectuer les tâches qui leur sont affectées uniquement sur les utilisateurs et les appareils qu’ils doivent être habilités à gérer.

Les sections suivantes décrivent brièvement différents modèles, accompagnés de lignes directrices pour chaque modèle de 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évolu
  • Modèle hybride

Modèle de délégation partielle

Le modèle de délégation partielle propose les lignes directrices suivantes pour la gestion des politiques 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 d’attribution aux administrateurs locaux.

✔️ Réutiliser

  • Les stratégies, profils d’inscription et applications couramment configurés doivent être mis à la disposition des administrateurs locaux pour être réutilisés, 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.
  • En tant qu’administrateurs locaux, ils doivent examiner les politiques existantes et les réutiliser si nécessaire.

✔️ Exceptions

  • L’équipe centrale peut créer de nouvelles 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 les deux domaines suivants :

Instructions de groupe et d’affectation pour les administrateurs locaux : Quelles sont les meilleures pratiques que les administrateurs locaux peuvent adopter lors de l’organisation de groupes pour la gestion des périphériques via Microsoft Intune ? Pour le savoir, voir le regroupement, le ciblage et le filtrage d’Intune : Recommandations pour de meilleures performances - blog de la 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 avec des autorisations spécifiques pour les différentes fonctionnalités. Pour plus d’informations, consultez les instructions spécifiques aux fonctionnalités dans cet article.

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

Le modèle de délégation complète propose les lignes directrices suivantes pour la gestion des politiques 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, mettre à jour ou supprimer, accordez-lui un rôle avec des autorisations de lecture et d’attribution et évitez de lui attribuer un autre rôle avec les autorisations totales. Avec cette approche, vous pouvez éviter de combiner des autorisations entre des balises d’étendue.
  • Parfois, les administrateurs locaux peuvent avoir besoin de créer leurs propres stratégies, profils et applications tout en partageant certaines stratégies, profils et applications communs. Dans ce cas, créez un groupe spécial et attribuez les stratégies, profils et applications courants à ce groupe. Ce groupe ne doit pas être inclus dans l’étendue (groupe) d’une attribution de rôle RBAC Intune pour un administrateur local. Cette approche empêche les autorisations de création, de mise à jour et de suppression affecté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’administrateurs locaux (parent) gère plusieurs organisations enfants. Des facteurs tels que la géographie, l’unité commerciale ou la taille peuvent être utilisés pour regrouper des 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 standardiser les affectations entre les administrateurs locaux et placer tous leurs appareils dans un seul groupe Microsoft Entra pour l’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 différentes affectations.

  • 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 des groupes Microsoft Entra courants dans l’étendue de l’équipe d’administration locale d’origine.

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

Modèle dévolu

Dans le modèle décentralisé, plusieurs administrateurs locaux (enfants) sont gérés à la fois par leur administrateur local dédié et également supervisés par une équipe d’administrateurs locaux intermédiaires. 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 du rôle RBAC des équipes d’administrateurs locales intermédiaires.
  • S’il y a plus de 50 administrateurs enfants, l’équipe d’administration locale intermédiaire doit disposer de sa propre balise d’étendue pour représenter l’ensemble des administrateurs enfants qu’elle supervise.
  • Les stratégies nouvellement créées sous les balises d’étendue de l’administrateur enfants doivent avoir l’étiquette intermédiaire ajoutée par un utilisateur avec un rôle approprié pour éviter que l’équipe d’administration locale intermédiaire ne perde sa visibilité.

Modèle hybride

Dans le modèle hybride, le même administrateur parent est utilisé à la fois dans le modèle central et le modèle dévolu. Il n’existe aucune recommandation particulière pour ce modèle.

Instructions spécifiques aux fonctionnalités

En fonction des besoins de l’entreprise pour chaque fonctionnalité, les recommandations fournies dans cette section peuvent vous recommander de créer des stratégies par administrateur local et éventuellement de déléguer les autorisations nécessaires à la création d’objets aux administrateurs locaux.

Remarque

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

Stratégie de protection d’applications

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 Stratégies de protection des applications.

Les recommandations relatives aux stratégies de protection d’applications sont réparties entre l’équipe centrale et les administrateurs locaux comme suit :

Équipe centrale - Tâches

  • Passez en revue la sécurité et les besoins métier dans l’ensemble de l’organisation et générez un ensemble de stratégies de Protection d’applications communes 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 de protection d’applications.
  • Disposer d’une méthode établie pour les administrateurs locaux pour 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 satisfaites avec les stratégies communes existantes.
  • Pour obtenir des recommandations spécifiques sur chaque niveau de configuration et le minimum d’applications à protéger, voir Infrastructure de protection des données à l’aide de stratégies de protection d’applications.

Administrateurs locaux - Autorisations et tâches

  • Fournir des autorisations de lecture et d’attribution aux administrateurs locaux, mais pas aux autorisations de création, de mise à jour ou de suppression sur les applications gérées. Cette configuration des autorisations les empêche de créer leurs propres stratégies de protection d’applications.
  • Fournir, lire et attribuer des autorisations pour l’attribution de stratégie de configuration d’application à leurs applications.
  • Accorder, lire et attribuer des autorisations 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 de proposer une seule stratégie pour les deux, la stratégie de configuration des applications n’est pas nécessaire.
  • Si une stratégie de configuration d’application est utilisée, nous vous recommandons 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 de protection des 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. La conformité peut être exigée avant qu’un appareil puisse être utilisé pour accéder aux ressources de votre organisation. Pour plus d’informations sur les stratégies de conformité, voir Utiliser des stratégies de conformité pour définir des règles pour les appareils que vous gérez avec Intune.

Équipe centrale

L’équipe centrale doit créer des stratégies de conformité communes parmi lesquelles les administrateurs locaux peuvent choisir et, si nécessaire, créer des stratégies d’exception. Pour plus d’informations, voir Utiliser des stratégies de conformité pour définir des règles pour les appareils que vous gérez avec Intune. 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é, voir Créer une stratégie de conformité dans Microsoft Intune.

Administrateurs locaux

Fournissez aux administrateurs locaux des autorisations de lecture et d’affectation, mais pas des autorisations de création, de mise à jour ou de suppression sur les stratégies 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 attribuer à leurs utilisateurs et appareils.

Configuration des appareils

Dans cette section :

  • Restrictions d’appareils 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’appareils 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 lignes de base de sécurité dans la mesure du possible, 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 général, l’équipe centrale doit essayer de surveiller de manière centralisée le contenu des configurations et, si possible, remplacer les profils en double 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 recommandons que les anneaux de mise à jour Windows soient gérés de manière centralisée. L’équipe centrale doit créer autant de stratégies de mise à jour Windows courantes que nécessaire pour prendre en charge les variations 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 volumineux et difficile à gérer. Les bonnes pratiques varient pour chaque fonctionnalité. Pour plus d’informations, voir 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 les autorisations fournies par l’équipe centrale pour intégrer et déconnecter des connecteurs en fonction des besoins. Intégrer des connecteurs pour chaque administrateur local afin de prendre en charge l’émission de certificats.

  • N’accordez pas aux administrateurs locaux l’autorisation de mettre à jour ou de supprimer des connecteurs.

Applications

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

Dans cette section :

  • Programme d’achat en volume d’Apple

  • Windows

  • Android

Pour plus d’informations, consultez Gérer les applications.

Programme d’achat en volume d’Apple

À l’heure actuelle, il n’existe aucun problème d’échelle pour le nombre pris en charge de jetons du programme d’achat en volume. 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 du Store Android. Les administrateurs locaux ne doivent pas créer de nouvelles applications Android Store. 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, application 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 ou la région de leur locataire. Si l’équipe centrale a besoin d’une application Google Play gérée uniquement disponible dans des pays ou régions spécifiques, elle devra peut-être collaborer avec le développeur de l’application pour qu’elle apparaisse 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 prévoit d’utiliser l’iframe Google Play géré 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’appliquera à toutes les applications Google Play gérées après leur ajout à la console par l’équipe centrale, mais ne s’appliquera pas rétroactivement aux applications déjà ajoutées. Nous recommandons vivement à l’équipe centrale de définir la balise d’étendue avant d’ajouter des applications, puis d’affecter cette balise à chaque équipe régionale. Sinon, les administrateurs régionaux risquent de ne pas voir leurs applications Google Play gérées.

  • Une seule stratégie OEMConfig est prise en charge par appareil, sauf pour les appareils Zebra. Avec les appareils Zebra, nous vous recommandons d’avoir le plus petit nombre de stratégies possible, car le temps nécessaire à l’application de la stratégie est additif. Par exemple, si vous affectez six stratégies en partant du principe qu’elles se superposent, le fonctionnement sur l’appareil prend environ 6 fois plus de temps qu’une seule stratégie.

Remarque

Faites preuve d’une extrême considération et d’une extrême 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 sur le mode haute priorité, une seule mise à jour d’application peut être installée à la fois. Une mise à jour d’application importante peut potentiellement bloquer de nombreuses mises à jour mineures jusqu’à ce que l’installation de l’application volumineuse soit terminée.
  • Selon le moment où les applications publient de nouvelles mises à jour, il peut y avoir un pic soudain de l’utilisation de votre réseau si les versions d’applications coïncident. Si Wi-Fi n’est pas disponible sur certains appareils, il peut également y avoir un pic d’utilisation du cellulaire.
  • Bien que les expériences utilisateur perturbatrices aient déjà été mentionnées, le problème s’aggrave à mesure que de plus en plus d’applications sont définies en mode de mise à jour de haute priorité.

Pour plus d’informations sur les problèmes d’échelle concernant les mises à jour d’applications Google Play gérées à l’aide du mode de mise à jour de haute priorité, consultez le blog Techcommunity Meilleures pratiques pour la mise à jour de vos applications Android Enterprise.

Profils d’inscription

Dans cette section :

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

Windows Autopilot

  • Accordez aux administrateurs locaux les autorisations de lecture des appareils Windows Autopilot et de chargement de nouveaux appareils Windows Autopilot.
  • Les administrateurs locaux ne doivent pas créer de profils Windows Autopilot. Lorsque vous déléguez à un grand nombre d’administrateurs, le nombre total d’objets peut devenir volumineux et difficile à gérer. Les bonnes pratiques varient selon le domaine de fonctionnalité. Pour plus d’informations sur Windows Autopilot, consultez Utiliser Windows Autopilot pour inscrire des périphériques Windows dans Intune.

Page Statut de l’inscription

  • Les administrateurs locaux doivent sélectionner des profils de page de status d’inscription 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 de status d’inscription. Lorsque vous déléguez à un grand nombre d’administrateurs, le nombre total d’objets peut devenir volumineux et difficile à gérer. Les bonnes pratiques varient selon le domaine de fonctionnalité. Pour plus d’informations sur la page de status d’inscription, reportez-vous à la page Configurer la page État de l’inscription.

Apple Business Manager

Dans la mesure du possible, les administrateurs locaux ne doivent pas disposer d’autorisations de création, de mise à jour ou de suppression sur les profils d’inscription. Si les administrateurs locaux sont autorisés à créer des profils Apple Business Manager, cela leur donne également des autorisations de création, de mise à jour et de suppression dans Windows Autopilot. Toutefois, les administrateurs locaux ne doivent pas créer de profils Windows Autopilot.

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

Profils Android Enterprise

  • L’équipe centrale doit créer des profils d’inscription des appareils dédiés à l’entreprise Android Enterprise pour chaque administrateur local pour le regroupement d’appareils.
  • Dans la mesure du possible, les administrateurs locaux ne doivent pas bénéficier des 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 Enterprise à l’échelle du client et le profil d’inscription global entièrement géré.

Restrictions d’inscription

  • Le même jeu d’autorisations régit à la fois la configuration de l’appareil et les restrictions d’inscription. Lorsque vous accordez des autorisations de création pour la configuration des appareils, 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. Demandez-leur plutôt de 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, reportez-vous à la rubrique Quelles 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 d’appareils) ne possède 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 > clients. 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.

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 de leur accorder des autorisations sur l’organisation qui leur accorde l’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 que nécessaire pour prendre en charge les variations des administrateurs locaux.
  • Dans la mesure du 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 volumineux et difficile à gérer. Les bonnes pratiques varient selon le domaine de fonctionnalité.
  • Pour plus d’informations, consultez Configurer les paramètres dans l’analyse des points de terminaison.

Contenu connexe

  • Last updated on