Forum Aux Questions sur la Gestion des applications mobiles (GAM) et la protection des applications

Vue d’ensemble de gam

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. Une stratégie peut être une règle qui est appliquée lorsque l’utilisateur tente d’accéder à des données « d’entreprise » ou de les déplacer, ou s’il tente un ensemble d’actions interdites ou surveillées lorsqu’il se trouve dans l’application.

Consultez les paramètres de stratégie de protection des applications Android et les paramètres de stratégie de protection des applications iOS/iPadOS pour obtenir des informations détaillées sur chaque paramètre de stratégie de protection des applications.

Si vous appliquez une stratégie GAM à l’utilisateur sans définir l’état de gestion des appareils, l’utilisateur obtient la stratégie GAM sur l’appareil BYOD et sur l’appareil géré par Intune. Vous pouvez également appliquer une stratégie GAM en fonction de l’état de gestion des appareils. Par conséquent, lorsque vous créez une stratégie de protection des applications, en regard de Cibler les applications sur tous les types d’appareils, vous sélectionnez Non. Ensuite, choisissez entre les deux solutions suivantes :

• Appliquer une stratégie de gestion MAM moins stricte aux appareils gérés par Intune et une autre plus stricte aux appareils non inscrits à la gestion MDM.
• Appliquez une stratégie GAM tout aussi stricte aux appareils gérés par Intune qu’aux appareils gérés par un tiers.
• Appliquer une stratégie de gestion MAM aux appareils non inscrits exclusivement.

Pour plus d’informations, consultez Guide pratique pour surveiller les stratégies de protection des applications.

Toute application qui a été intégrée au SDK d’application Intune ou encapsulée par le App Wrapping Tool Intune peut être gérée à l’aide de stratégies de protection des applications Intune. Consultez la liste des applications gérées par Intune disponibles.

• L’utilisateur final doit disposer d’un compte Microsoft Entra. Consultez Ajouter des utilisateurs et accorder des autorisations d’administration à Intune pour savoir comment créer des utilisateurs Intune dans Microsoft Entra ID.

• L’utilisateur final doit disposer d’une licence pour Microsoft Intune attribuée à son compte Microsoft Entra. Consultez la section Gérer les licences Intune pour apprendre à attribuer des licences Intune à des utilisateurs finaux.

• L’utilisateur final doit appartenir à un groupe de sécurité ciblé par une stratégie de protection d’application. La même stratégie de protection d’application doit cibler l’application spécifique utilisée. Protection d'applications stratégies peuvent être créées et déployées dans le centre d’administration Microsoft Intune. Des groupes de sécurité peuvent actuellement être créés dans le centre d’administration Microsoft 365.

• L’utilisateur final doit se connecter à l’application à l’aide de son compte Microsoft Entra.

L’équipe de développement du SDK Intune teste et maintient activement la prise en charge des applications générées avec les plateformes Android, iOS/iPadOS (Obj-C, Swift), Xamarin et Xamarin.Forms natives. Bien que certains clients aient réussi à intégrer le SDK Intune à d’autres plateformes telles que React Native et NativeScript, nous ne fournissons pas de conseils ou de plug-ins explicites aux développeurs d’applications utilisant autre chose que nos plateformes prises en charge.

Le SDK d’application Intune peut utiliser la bibliothèque d’authentification Microsoft pour ses scénarios d’authentification et de lancement conditionnel. Il s’appuie également sur MSAL pour inscrire l’identité de l’utilisateur auprès du service GAM pour la gestion sans scénarios d’inscription d’appareil.

• L’application mobile Outlook doit être installée sur son appareil pour l’utilisateur final.

• L’utilisateur final doit disposer d’une boîte aux lettres et d’une licence Microsoft 365 Exchange Online liées à son compte Microsoft Entra.

  Remarque

  Actuellement, l’application mobile Outlook prend uniquement en charge Intune App Protection pour les Microsoft Exchange Online et les Exchange Server avec l’authentification moderne hybride et ne prend pas en charge Exchange dans Office 365 Dedicated.

• L’utilisateur final doit disposer d’une licence pour Applications Microsoft 365 pour les PME ou entreprise liée à son compte Microsoft Entra. L’abonnement doit inclure les applications Office sur des appareils mobiles et peut inclure un compte de stockage cloud avec OneDrive Entreprise. Les licences Microsoft 365 peuvent être attribuées via le Centre d’administration Microsoft 365 en suivant ces instructions.

• L’utilisateur final doit avoir configuré un emplacement géré à l’aide de la fonctionnalité granulaire Enregistrer sous, qui se trouve sous le paramètre de stratégie de protection des applications « Enregistrer des copies des données de l’organisation ». Par exemple, si l’emplacement géré est OneDrive, l’application OneDrive doit être configurée dans l’application Word, Excel ou PowerPoint de l’utilisateur final.

• Si l'emplacement géré est OneDrive, l'application doit être ciblée par la politique de protection des applications déployée pour l'utilisateur final.

  Remarque

  Les applications mobiles Office ne prennent actuellement en charge que SharePoint Online et non SharePoint sur site.

Intune marque toutes les données de l’application comme « d’entreprise » ou « personnelles ». Les données sont considérées comme « d’entreprise » lorsqu’elles proviennent d’un emplacement commercial. Pour les applications Office, Intune considère les sites d’entreprise suivants : e-mail (Exchange) ou stockage cloud (application OneDrive avec un compte OneDrive Entreprise).

Voir les conditions requises pour les licences de Skype Entreprise. Pour Skype Entreprise (SfB) hybrides et locales, consultez Authentification moderne hybride pour SfB et Exchange en disponibilité générale et Authentification moderne pour SfB locale avec Microsoft Entra ID, respectivement.

La prise en charge de plusieurs identités est la possibilité pour le SDK d’application Intune d’appliquer uniquement des stratégies de protection des applications au compte professionnel ou scolaire connecté à l’application. Si un compte personnel est connecté à l'application, les données ne sont pas modifiées.

La prise en charge de plusieurs identités permet aux applications destinées à des publics « d’entreprise » et grand public (c’est-à-dire les applications Office) d’être publiées publiquement avec les fonctionnalités de protection des applications Intune pour les comptes « d’entreprise ».

Étant donné qu’Outlook dispose d’une vue combinée des e-mails personnels et « d’entreprise », l’application Outlook invite à entrer le code confidentiel Intune au lancement.

Le numéro d'identification personnel (PIN) est un code de passe utilisé pour vérifier que le bon utilisateur accède aux données de l'organisation dans une application.

Intune n’invite l’utilisateur à saisir le code PIN de l’application que s’il est sur le point d’accéder à des données « d’entreprise ». Dans les applications multi-identités telles que Word/Excel/PowerPoint, l’utilisateur est invité à entrer son code confidentiel lorsqu’il tente d’ouvrir un document ou un fichier « d’entreprise ». Dans les applications à identité unique, telles que les applications métier gérées à l’aide de l’App Wrapping Tool Intune, le code confidentiel est invité au lancement, car le SDK d’application Intune sait que l’expérience de l’utilisateur dans l’application est toujours « d’entreprise ».

L’administrateur informatique peut définir le paramètre de stratégie de protection des applications Intune « Revérifier les exigences d’accès après (minutes) » dans le Centre d’administration Microsoft Intune. Ce paramètre spécifie la durée pendant laquelle les exigences d’accès sont vérifiées sur l’appareil et l’écran du code confidentiel de l’application s’affiche à nouveau. Cependant, les détails importants concernant le PIN qui affectent la fréquence à laquelle l'utilisateur sera sollicité sont :

• Le code confidentiel est partagé entre les applications du même éditeur pour améliorer la facilité d’utilisation : Sur iOS/iPadOS, un code pin d’application est partagé entre toutes les applications du même éditeur d’application. Sur Android, un même code PIN d’application est partagé entre toutes les applications.
• Le comportement « Revérifier les exigences d’accès après (minutes) » après un redémarrage de l’appareil : Un « minuteur de code confidentiel » effectue le suivi du nombre de minutes d’inactivité qui déterminent quand afficher ensuite le code confidentiel de l’application Intune. Sur iOS/iPadOS, le minuteur de code confidentiel n’est pas affecté par le redémarrage de l’appareil. Ainsi, le redémarrage de l’appareil n’a aucun effet sur le nombre de minutes pendant lesquelles l’utilisateur a été inactif à partir d’une application iOS/iPadOS avec une stratégie de code confidentiel Intune. Sur Android, le minuteur du code confidentiel est réinitialisé au redémarrage de l’appareil. Par conséquent, les applications Android avec une stratégie de code confidentiel Intune demanderont probablement un code confidentiel d’application, quelle que soit la valeur du paramètre « Revérifier les conditions d’accès après (minutes) » après un redémarrage de l’appareil.
• Nature propagée du minuteur associé au code confidentiel : Une fois qu’un code confidentiel est entré pour accéder à une application (application A) et que l’application quitte le premier plan (main focus d’entrée) sur l’appareil, le minuteur du code confidentiel est réinitialisé pour ce code confidentiel. Toute application (application B) qui partage ce code confidentiel n’invite pas l’utilisateur à entrer le code confidentiel, car le minuteur a été réinitialisé. L’invite réapparaît une fois que la valeur de « Revérifier les exigences d’accès après (minutes) » est à nouveau atteinte.

Pour les appareils iOS/iPadOS, même si le code confidentiel est partagé entre des applications de différents éditeurs, l’invite s’affiche à nouveau lorsque la valeur Revérifier les exigences d’accès après (minutes) est à nouveau remplie pour l’application qui n’est pas le main focus d’entrée. Par exemple, un utilisateur a application A de l’éditeur X et l’application B de l’éditeur Y, et ces deux applications partagent le même code PIN. L’utilisateur travaille avec l’application A (au premier plan) et l’application B est réduite. Une fois que la valeur de Revérifier les spécifications requises pour l’accès après (minutes) est atteinte et que l’utilisateur passe à l’application B, celui-ci doit entrer le code PIN.

Le code pin Intune fonctionne sur la base d’un minuteur basé sur l’inactivité (la valeur de « Revérifier les exigences d’accès après (minutes) »). Ainsi, les invites PIN d'Intune s'affichent indépendamment des invites PIN des applications intégrées pour Outlook et OneDrive, qui sont souvent liées au lancement de l'application par défaut. Si l’utilisateur reçoit en même temps les deux demandes de code PIN, le comportement attendu doit être que le code PIN Intune est prioritaire.

Le code PIN sert à autoriser uniquement les utilisateurs adéquats à accéder aux données de leur organisation dans l’application. Par conséquent, un utilisateur final doit se connecter avec son compte professionnel ou scolaire pour pouvoir définir ou réinitialiser son code PIN d’application Intune. Cette authentification est gérée par Microsoft Entra ID via l’échange de jetons sécurisé et n’est pas transparente pour le SDK d’application Intune. Du point de vue de la sécurité, la meilleure manière de protéger les données professionnelles ou scolaires consiste à les chiffrer. Le chiffrement n’est pas lié au code confidentiel de l’application, mais il s’agit de sa propre stratégie de protection des applications.

Dans le cadre de la stratégie de code PIN d’application, l’administrateur peut définir un nombre maximal de tentatives d’authentification de son code PIN avant le verrouillage de l’application. Une fois que le nombre de tentatives a été atteint, le SDK d’application Intune peut réinitialiser les données « d’entreprise » dans l’application.

Mam (sur iOS/iPadOS) autorise actuellement le code confidentiel au niveau de l’application avec des caractères alphanumériques et spéciaux (appelés « code secret ») qui nécessite la participation d’applications (par exemple, WXP, Outlook, Managed Browser, Yammer) pour intégrer le SDK d’application Intune pour iOS/iPadOS. Sans cela, les paramètres de code secret ne sont pas correctement appliqués pour les applications ciblées. Il s’agit d’une fonctionnalité publiée dans le Kit de développement logiciel (SDK) Intune pour iOS/iPadOS v. 7.1.12.

Afin de prendre en charge cette fonctionnalité et d'assurer la rétrocompatibilité avec les versions précédentes du kit SDK Intune pour iOS/iPadOS, tous les codes PIN (qu'il s'agisse de codes numériques ou de codes de passe) dans la version 7.1.12+ sont traités séparément du code PIN numérique dans les versions précédentes du kit SDK. Par conséquent, si un appareil a des applications avec le SDK Intune pour les versions iOS/iPadOS antérieures à la version 7.1.12 ET après la version 7.1.12 du même éditeur, ils doivent configurer deux codes confidentiels.

Cela dit, les deux codes confidentiels (pour chaque application) ne sont pas liés de quelque manière que ce soit, c’est-à-dire qu’ils doivent respecter la stratégie de protection des applications appliquée à l’application. Ainsi, uniquement si les applications A et B ont les mêmes stratégies appliquées (en ce qui concerne le PIN), l'utilisateur peut configurer le même PIN deux fois.

Ce comportement est spécifique au code PIN sur les applications iOS/iPadOS activées avec la gestion des applications mobiles Intune. Au fil du temps, à mesure que les applications adoptent les versions ultérieures du SDK Intune pour iOS/iPadOS, devoir définir deux fois un code PIN sur les applications d’un même éditeur pose moins de problèmes. Veuillez consulter la note ci-dessous pour un exemple.

Les administrateurs informatiques peuvent déployer une stratégie de protection des applications qui exige que les données des applications soient cryptées. Dans le cadre de la stratégie, l'administrateur informatique peut également préciser quand le contenu est crypté.

Pour plus d’informations sur le paramètre de chiffrement de stratégie de protection des applications, consultez Paramètres de stratégie de protection des applications Android et Paramètres de stratégie de protection des applications iOS/iPadOS.

Seules les données marquées comme « d’entreprise » sont chiffrées en fonction de la stratégie de protection des applications de l’administrateur. Les données sont considérées comme « d’entreprise » lorsqu’elles proviennent d’un emplacement de l’entreprise. Pour les applications Office, Intune considère les sites d’entreprise suivants : e-mail (Exchange) ou stockage cloud (application OneDrive avec un compte OneDrive Entreprise). Pour les applications métier gérées par le App Wrapping Tool Intune, toutes les données d’application sont considérées comme « d’entreprise ».

Intune peut réinitialiser les données d’application de trois manières différentes : réinitialisation complète de l’appareil, réinitialisation sélective pour GPM et réinitialisation sélective GAM. Pour plus d'informations sur l'effacement à distance pour MDM, reportez-vous à la section Supprimer des appareils en utilisant l'effacement ou le retrait. Pour plus d'informations sur l'effacement sélectif à l'aide de MAM, voir l'action Retirer et Comment effacer uniquement les données d'entreprise des applications.

La réinitialisation supprime toutes les données et paramètres utilisateur de l’appareil en restaurant l’appareil à ses paramètres d’usine par défaut. L'appareil est supprimé d'Intune.

Voir Supprimer les appareils – retraite pour en savoir plus sur la suppression des données de l'entreprise.

L'effacement sélectif pour MAM supprime simplement les données d'une application de l'entreprise. La demande est lancée à l’aide du centre d’administration Microsoft Intune. Pour savoir comment effectuer une demande de réinitialisation, consultez la section Guide pratique pour effacer uniquement les données d’entreprise des applications.

Si l’utilisateur utilise l’application lorsque la réinitialisation sélective est lancée, le SDK d’application Intune vérifie toutes les 30 minutes une demande de réinitialisation sélective du service GAM Intune. Il vérifie également l'effacement sélectif lorsque l'utilisateur lance l'application pour la première fois et se connecte avec son compte professionnel ou scolaire.

La protection des applications Intune dépend de l’identité de l’utilisateur pour qu’elle soit cohérente entre l’application et le SDK d’application Intune. La seule façon de le garantir est de recourir à une authentification moderne. Il existe des scénarios dans lesquels les applications peuvent fonctionner avec une configuration locale, mais ils ne sont ni cohérents ni garantis.

Oui. L’administrateur informatique peut déployer et définir la stratégie de protection des applications pour l’application Microsoft Edge. L’administrateur informatique peut exiger l’ouverture de tous les liens web dans les applications gérées par Intune à l’aide de l’application Microsoft Edge.

Protection des applications du portail de l'entreprise et des applications Intune

Les stratégies de protection des applications Intune pour l’accès sont appliquées dans un ordre spécifique sur les appareils des utilisateurs finaux à mesure qu’ils tentent d’accéder à une application ciblée à partir de leur compte d’entreprise. En général, un bloc est prioritaire, puis un avertissement ignoré. Par exemple, si cela s’applique à l’utilisateur/application en question, un paramètre de version de correctif Android minimale qui signale à un utilisateur qu’il doit effectuer une mise à niveau de correctif sera appliqué après le paramètre de version de correctif Android minimale qui bloque l’accès à l’utilisateur. Ainsi, dans le scénario où l’administrateur informatique configure la version de correctif Android minimale sur 2018-03-01 et la version de correctif Android minimale (Avertissement uniquement) sur 2018-02-01, alors que l’appareil qui tente d’accéder à l’application utilise une version de correctif 2018-01-01, l’utilisateur final est bloqué sur la base du paramètre le plus restrictif pour la version de correctif Android minimale qui provoque un blocage de l’accès.

Lors du traitement de différents types de paramètres, une exigence de version d’application est prioritaire, suivie de l’exigence de version de système d’exploitation Android, puis de l’exigence de version de correctif Android. Ensuite, les avertissements éventuels pour tous les types de paramètres dans le même ordre sont vérifiés.

Le service Intune contactera Google Play à un intervalle non configurable déterminé par la charge du service. Toute action configurée par l’administrateur informatique pour le paramètre d’intégrité de l’appareil de Google Play case activée sera effectuée en fonction du dernier résultat signalé au service Intune au moment du lancement conditionnel. Si le résultat de l’intégrité de l’appareil de Google est conforme, aucune action n’est effectuée. Si le résultat de l’intégrité de l’appareil de Google n’est pas conforme, l’action configurée par l’administrateur informatique est immédiatement effectuée. Si la demande adressée à l’case activée d’intégrité de l’appareil google play échoue pour une raison quelconque, le résultat mis en cache de la requête précédente sera utilisé pendant jusqu’à 24 heures ou le prochain redémarrage de l’appareil, qui arrive en premier. À ce moment-là, les stratégies De protection des applications Intune bloquent l’accès jusqu’à ce qu’un résultat actuel puisse être obtenu.

Les instructions sur la façon de procéder varient légèrement selon l’appareil. Le processus général implique d’accéder au Google Play Store, de cliquer sur Mes jeux et applications, puis de cliquer sur le résultat de la dernière analyse de l’application afin d’accéder au menu Play Protect. Assurez-vous que la case à cocher Scanner un appareil pour les menaces de sécurité est activée.

Intune s’appuie sur les API d’intégrité Google Play pour ajouter à nos vérifications de détection racine existantes pour les appareils non inscrits. Google a développé et géré cet ensemble d’API pour les applications Android à adopter si elles ne veulent pas que leurs applications s’exécutent sur des appareils rootés. L’application Android Pay a par exemple incorporé cette fonctionnalité. Bien que Google ne partage pas publiquement l’intégralité des vérifications de détection racine qui se produisent, nous nous attendons à ce que ces API détectent les utilisateurs qui ont rooté leurs appareils. L’accès de ces utilisateurs peut alors être bloqué, ou leurs comptes professionnels supprimés des applications pour lesquelles une stratégie est activée. « Vérifier l’intégrité de base » vous indique l’intégrité générale de l’appareil. Les appareils enracinés, les émulateurs, les appareils virtuels et les appareils présentant des signes d'altération manquent l'intégrité de base. « Vérifier l’intégrité de base & appareils certifiés » vous indique la compatibilité de l’appareil avec les services google. Seuls les appareils non modifiés qui ont été certifiés par Google peuvent passer ce contrôle. Les appareils suivants échoueront :

• Appareils qui échouent aux tests d’intégrité de base
• Appareils ayant un chargeur de démarrage déverrouillé
• Appareils ayant une image système/ROM personnalisée
• Appareils pour lesquels le fabricant n’a pas demandé ou obtenu la certification Google
• Appareils dotés d'une image système construite directement à partir des fichiers sources du programme Android Open Source
• Appareils ayant une image système en préversion bêta/développeur

Pour plus d’informations techniques, consultez la documentation de Google sur l’API Play Integrity .

Les vérifications de l’API d’intégrité Google Play nécessitent que l’utilisateur final soit en ligne, au-dessus de la durée d’exécution du « aller-retour » pour déterminer les résultats de l’attestation. Si l’utilisateur final est hors connexion, l’administrateur informatique peut toujours s’attendre à ce qu’un résultat soit appliqué à partir du paramètre « appareils jailbreakés/rootés ». Cela dit, si l’utilisateur final est hors connexion depuis trop longtemps, la valeur « Période de grâce hors connexion » entre en jeu et tout accès aux données professionnelles ou scolaires est bloqué une fois que cette valeur du minuteur est atteinte, jusqu’à ce que l’accès réseau soit disponible. L’activation des deux paramètres permet une approche en couches pour maintenir l’intégrité des appareils des utilisateurs finaux, ce qui est important lorsque les utilisateurs finaux accèdent à des données professionnelles ou scolaires sur mobile.

Les paramètres « Verdict de l’intégrité de la lecture » et « Analyse des menaces sur les applications » nécessitent que la version google des services Google Play fonctionne correctement. Étant donné qu’il s’agit de paramètres qui relèvent de la sécurité, l’utilisateur final est bloqué s’il a été ciblé avec ces paramètres et ne répond pas à la version appropriée des services Google Play ou n’a pas accès à Google Play Services.

Les stratégies de protection des applications Intune permettent de contrôler l'accès aux applications uniquement pour l'utilisateur titulaire d'une licence Intune. L’un des moyens de contrôler l’accès à une application est d’exiger un Touch ID ou un Face ID Apple sur les appareils pris en charge. Intune implémente un comportement dans lequel, en cas de modification de la base de données biométrique de l’appareil, Intune invite l’utilisateur à entrer un code confidentiel lorsque la valeur de délai d’inactivité suivante est atteinte. Les changements apportés aux données biométriques incluent l’ajout et la suppression d’une empreinte digitale ou d’un visage. Si l’utilisateur Intune n’a pas de code confidentiel défini, il est amené à configurer un code confidentiel Intune.

L’objectif est de continuer à sécuriser et à protéger les données de votre organization au sein de l’application. Cette fonctionnalité est disponible uniquement pour iOS/iPadOS et nécessite la participation d’applications qui intègrent le SDK d’application Intune pour iOS/iPadOS, version 9.0.1 ou ultérieure. L'intégration du SDK est nécessaire pour que le comportement puisse être appliqué aux applications ciblées. Cette intégration se produit en continu et repose sur les équipes d’application spécifiques. Certaines applications participantes incluent WXP, Outlook, Managed Browser et Yammer.

La stratégie de protection des applications Intune ne peut pas contrôler l’extension de partage iOS sans gérer l’appareil. Par conséquent, Intune chiffre les données « d’entreprise » avant qu’elles ne sont partagées en dehors de l’application. Vous pouvez valider cela en essayant d’ouvrir le fichier « d’entreprise » en dehors de l’application gérée. Le fichier doit être crypté et ne peut être ouvert en dehors de l'application gérée.

Les stratégies de protection des applications Intune pour l’accès sont appliquées dans un ordre spécifique sur les appareils des utilisateurs finaux à mesure qu’ils tentent d’accéder à une application ciblée à partir de leur compte d’entreprise. En général, une réinitialisation est prioritaire, suivie d’un bloc, puis d’un avertissement ignoré. Par exemple, si cela s’applique à l’utilisateur/application spécifique, un paramètre de système d’exploitation iOS/iPadOS minimal qui signale à un utilisateur qu’il doit mettre à niveau sa version d’iOS/iPadOS est appliqué après le paramètre de système d’exploitation iOS/iPadOS minimal qui bloque l’accès de l’utilisateur. Par conséquent, dans le scénario où l’administrateur informatique configure le système d’exploitation iOS/iPadOS minimal sur 11.0.0.0 et le système d’exploitation iOS/iPadOS minimal (avertissement uniquement) sur 11.1.0.0, alors que l’appareil essayant d’accéder à l’application se trouvait sur iOS/iPadOS 10, l’utilisateur final serait bloqué en fonction du paramètre plus restrictif pour la version minimale du système d’exploitation iOS/iPadOS qui entraîne un blocage de l’accès.

Lorsque vous traitez différents types de paramètres, une exigence de version du SDK d’application Intune est prioritaire, puis une exigence de version d’application, suivie de la configuration requise pour la version du système d’exploitation iOS/iPadOS. Ensuite, les avertissements éventuels pour tous les types de paramètres dans le même ordre sont vérifiés. Nous vous recommandons de configurer la configuration requise de la version du SDK d’application Intune uniquement sur les conseils de l’équipe produit Intune pour les scénarios de blocage essentiels.

Voir aussi

• Déployer Intune
• Créer un plan de lancement
• Paramètres de stratégie de gestion des applications mobiles Android dans Microsoft Intune
• Paramètres de stratégie de gestion des applications mobiles iOS/iPadOS
• actualisation de la stratégie des stratégies de Protection d'applications
• Valider vos stratégies de protection des applications
• Ajouter des stratégies de configuration des applications pour les applications gérées sans l’inscription des appareils
• Comment obtenir de l’aide dans Microsoft Intune