Intégration d'Azure Active Directory avec GPM

Azure Active Directory est le plus grand service de gestion des identités cloud d’entreprise au monde. Il est utilisé par les organisations pour accéder aux applications Office 365 et métier à partir de Microsoft et de fournisseurs SaaS (Software as a Service) tiers. La plupart des expériences de Windows 10 enrichies pour les utilisateurs de l’organisation (comme l’accès au magasin ou l’itinérance de l’état du système d’exploitation) utilisent Azure AD comme infrastructure d’identité sous-jacente. Windows s’intègre à Azure AD, ce qui permet aux appareils d’être inscrits dans Azure AD et inscrits dans GPM dans un flux intégré.

Une fois qu’un appareil est inscrit dans GPM, le GPM :

  • Peut appliquer la conformité aux stratégies de l’organisation, ajouter ou supprimer des applications, etc.
  • Peut signaler la conformité d’un appareil dans Azure AD.
  • Azure AD peut autoriser l’accès aux ressources ou applications de l’organisation sécurisées par Azure AD aux appareils conformes aux stratégies.

Pour prendre en charge ces expériences enrichies avec leur produit MDM, les fournisseurs GPM peuvent s’intégrer à Azure AD. Cet article décrit les étapes impliquées.

Se connecter à AzureAD

Plusieurs façons de connecter vos appareils :

Pour les appareils appartenant à l’entreprise :

  • Joindre Windows à un domaine Active Directory traditionnel
  • Joindre Windows à Azure AD

Pour les appareils personnels (BYOD) :

  • Ajouter un compte professionnel Microsoft à Windows

Joindre Azure AD

Les appareils appartenant à l’entreprise sont traditionnellement joints au domaine Active Directory local de l’organisation. Ces appareils peuvent être gérés à l’aide d’stratégie de groupe ou d’un logiciel de gestion d’ordinateur tel que Microsoft Configuration Manager. Dans Windows 10, il est également possible de gérer des appareils joints à un domaine avec un GPM.

Windows 10 introduit une nouvelle façon de configurer et de déployer des appareils Windows appartenant à l’organisation. Ce mécanisme est appelé Jointure Azure AD. Comme la jonction de domaine traditionnelle, la jonction Azure AD permet aux appareils de devenir connus et gérés par une organisation. Toutefois, avec Azure AD Join, Windows s’authentifie auprès d’Azure AD au lieu de s’authentifier auprès d’un contrôleur de domaine.

Azure AD Join permet également aux appareils appartenant à l’entreprise d’être automatiquement inscrits et gérés par un GPM. En outre, la jonction Azure AD peut être effectuée sur un PC acheté en magasin, dans le cadre de l’expérience OOBE (out-of-box experience), ce qui aide les organisations à rationaliser leur déploiement d’appareils. Un administrateur peut exiger que les utilisateurs appartenant à un ou plusieurs groupes inscrivent leurs appareils pour la gestion avec un GPM. Si un utilisateur est configuré pour exiger l’inscription automatique lors de la jonction Azure AD, cette inscription devient une étape obligatoire pour configurer Windows. Si l’inscription mdm échoue, l’appareil n’est pas joint à Azure AD.

Important

Chaque utilisateur activé pour l’inscription GPM automatique avec Azure AD Join doit se voir attribuer une licence Azure Active Directory Premium valide.

Scénario BYOD

Windows 10 introduit également un moyen plus simple de configurer les appareils personnels pour accéder aux applications et ressources professionnelles. Les utilisateurs peuvent ajouter leur compte professionnel Microsoft à Windows et bénéficier d’un accès plus simple et plus sûr aux applications et ressources de l’organisation. Pendant ce processus, Azure AD détecte si l’organisation a configuré un GPM. Si tel est le cas, Windows tente d’inscrire l’appareil dans mdm dans le cadre du flux « ajouter un compte ». Dans le cas byOD, les utilisateurs peuvent rejeter les conditions d’utilisation mdm. L’appareil n’est pas inscrit dans GPM et l’accès aux ressources de l’organisation est généralement limité.

Inscription et expérience utilisateur mdm intégrées

Deux scénarios d’inscription à La gestion des appareils mobiles Azure AD :

  • Jonction d’un appareil à Azure AD pour les appareils appartenant à l’entreprise
  • Ajout d’un compte professionnel à un appareil personnel (BYOD)

Dans les deux scénarios, Azure AD authentifie l’utilisateur et l’appareil. Il fournit un identificateur d’appareil unique vérifié qui peut être utilisé pour l’inscription mdm.

Dans les deux scénarios, le flux d’inscription permet au service MDM de restituer sa propre interface utilisateur à l’aide d’une vue web. Les fournisseurs GPM doivent utiliser l’interface utilisateur pour afficher les conditions d’utilisation (TOU), qui peuvent être différentes pour les appareils d’entreprise et BYOD. Les fournisseurs GPM peuvent également utiliser l’affichage web pour afficher d’autres éléments d’interface utilisateur, comme demander un code confidentiel à usage unique.

Dans le scénario prête à l’emploi, l’affichage web est 100 % plein écran, ce qui permet au fournisseur GPM de peindre une expérience de bord à bord. Avec une grande puissance vient une grande responsabilité! Il est important que les fournisseurs GPM qui s’intègrent à Azure AD respectent les instructions de conception Windows. Cette étape inclut l’utilisation d’une conception web réactive et le respect des directives d’accessibilité de Windows. Par exemple, incluez les boutons Avant et Précédent qui sont correctement câblés à la logique de navigation. Plus d’informations sont fournies plus loin dans cet article.

Pour que l’inscription Azure AD fonctionne pour un compte Azure AD adossé aux services fédérés Active Directory (AD FS), vous devez activer l’authentification par mot de passe pour l’intranet sur le service ADFS. Pour plus d’informations, consultez la solution #2 dans Configurer Azure MFA en tant que fournisseur d’authentification avec AD FS.

Une fois qu’un utilisateur dispose d’un compte Azure AD ajouté à Windows et inscrit à GPM, l’inscription peut être gérée par le biais de Paramètres > Comptes > Accès professionnel. La gestion des appareils de la jonction Azure AD pour les scénarios d’organisation ou les scénarios BYOD est similaire.

Notes

Les utilisateurs ne peuvent pas supprimer l’inscription de l’appareil via l’interface utilisateur d’accès professionnel, car la gestion est liée à Azure AD ou au compte professionnel.

Points de terminaison GPM impliqués dans l’inscription intégrée à Azure AD

L’inscription À la gestion des appareils mobiles Azure AD est un processus en deux étapes :

  1. Affichez les conditions d’utilisation et recueillez le consentement de l’utilisateur.

    Ce consentement est un flux passif dans lequel l’utilisateur est redirigé dans un contrôle de navigateur (vue web) vers l’URL des conditions d’utilisation du GPM.

  2. Inscrivez l’appareil.

    Cette étape est un flux actif dans lequel l’agent DM Windows OMA appelle le service MDM pour inscrire l’appareil.

Pour prendre en charge l’inscription Azure AD, les fournisseurs GPM doivent héberger et exposer un point de terminaison de conditions d’utilisation et un point de terminaison d’inscription GPM.

Point de terminaison des conditions d’utilisation Utilisez ce point de terminaison pour informer les utilisateurs des façons dont leur appareil peut être contrôlé par leur organisation. La page Conditions d’utilisation est responsable de la collecte du consentement de l’utilisateur avant le début de la phase d’inscription réelle.

Il est important de comprendre que le flux des conditions d’utilisation est une « zone opaque » pour Windows et Azure AD. L’ensemble de la vue web est redirigé vers l’URL des conditions d’utilisation. L’utilisateur doit être redirigé après avoir approuvé ou rejeté les Conditions. Cette conception permet au fournisseur GPM de personnaliser ses conditions d’utilisation pour différents scénarios. Par exemple, différents niveaux de contrôle sont appliqués sur les appareils BYOD par rapport aux appareils appartenant à l’organisation. Ou, implémentez le ciblage basé sur l’utilisateur/groupe, comme les utilisateurs dans certaines zones géographiques peuvent avoir des stratégies de gestion des appareils plus strictes.

Le point de terminaison des conditions d’utilisation peut implémenter davantage de logique métier, comme la collecte d’un code confidentiel à usage unique fourni par le service informatique pour contrôler l’inscription des appareils. Toutefois, les fournisseurs GPM ne doivent pas utiliser le flux conditions d’utilisation pour collecter les informations d’identification de l’utilisateur, ce qui peut être une expérience utilisateur dégradée. Il n’est pas nécessaire, car une partie de l’intégration MDM garantit que le service MDM peut comprendre les jetons émis par Azure AD.

Point de terminaison d’inscription GPM Une fois que les utilisateurs acceptent les conditions d’utilisation, l’appareil est inscrit dans Azure AD. L’inscription GPM automatique commence.

Le diagramme suivant illustre le flux de haut niveau impliqué dans le processus d’inscription réel. L’appareil est d’abord inscrit auprès d’Azure AD. Ce processus affecte un identificateur d’appareil unique à l’appareil et présente à l’appareil la possibilité de s’authentifier auprès d’Azure AD (authentification de l’appareil). Ensuite, l’appareil est inscrit pour la gestion auprès du GPM. Cette étape appelle le point de terminaison d’inscription et demande l’inscription pour l’utilisateur et l’appareil. À ce stade, l’utilisateur a été authentifié et l’appareil a été inscrit et authentifié auprès d’Azure AD. Ces informations sont disponibles pour la gestion des appareils mobiles sous la forme de revendications dans un jeton d’accès présenté au point de terminaison d’inscription.

Flux d’inscription azure ad.

La gestion des appareils mobiles doit utiliser ces informations sur l’appareil (ID d’appareil) pour signaler la conformité de l’appareil à Azure AD à l’aide du API Graph Microsoft. Un exemple pour signaler la conformité des appareils est fourni plus loin dans cet article.

Faire de la gestion des appareils mobiles une partie fiable d’Azure AD

Pour participer au flux d’inscription intégré décrit dans la section précédente, la gestion des appareils mobiles doit consommer des jetons d’accès émis par Azure AD. Pour signaler la conformité avec Azure AD, le GPM doit s’authentifier auprès d’Azure AD et obtenir l’autorisation sous la forme d’un jeton d’accès qui lui permet d’appeler microsoft API Graph.

Ajouter un GPM basé sur le cloud

Une GPM basée sur le cloud est une application SaaS qui fournit des fonctionnalités de gestion des appareils dans le cloud. Il s’agit d’une application mutualisée. Cette application est inscrite auprès d’Azure AD dans le locataire d’origine du fournisseur MDM. Lorsqu’un administrateur informatique décide d’utiliser cette solution MDM, une instance de cette application est rendue visible dans le locataire du client.

Le fournisseur GPM doit d’abord inscrire l’application dans son locataire d’origine et la marquer comme une application multilocataire. Voici un exemple de code de GitHub qui explique comment ajouter des applications multilocataires à Azure AD, WepApp-WebAPI-MultiTenant-OpenIdConnect-DotNet.

Notes

Pour le fournisseur MDM, si vous n’avez pas de locataire Azure AD existant avec un abonnement Azure AD que vous gérez, suivez le guide pas à pas dans Ajouter un locataire Azure AD et un abonnement Azure AD pour configurer un locataire, ajouter un abonnement et le gérer via le portail Azure.

L’application MDM utilise des clés pour demander des jetons d’accès à Azure AD. Ces clés sont gérées dans le locataire du fournisseur GPM et ne sont pas visibles par les clients individuels. La même clé est utilisée par l’application MDM multilocataire pour s’authentifier auprès d’Azure AD, quel que soit le locataire du client auquel appartient l’appareil géré.

Notes

Toutes les applications MDM doivent implémenter des jetons Azure AD V2 avant de certifier que l’intégration fonctionne. En raison des modifications apportées à la plateforme d’application Azure AD, l’utilisation de jetons Azure AD V2 est une exigence essentielle. Pour plus d’informations, consultez Plateforme d'identités Microsoft jetons d’accès.

Procédez comme suit pour inscrire une application MDM basée sur le cloud auprès d’Azure AD. À ce stade, vous devez travailler avec l’équipe d’ingénierie Azure AD pour exposer cette application via la galerie d’applications Azure AD.

  1. Connectez-vous au portail de gestion Azure à l’aide d’un compte d’administrateur dans votre locataire d’origine.

  2. Dans le volet de navigation de gauche, sélectionnez Active Directory.

  3. Sélectionnez le locataire d’annuaire dans lequel vous souhaitez inscrire l’application.

    Vérifiez que vous êtes connecté à votre locataire d’origine.

  4. Sélectionnez l’onglet Applications .

  5. Dans le tiroir, sélectionnez Ajouter.

  6. Sélectionnez Ajouter une application que mon organisation développe.

  7. Entrez un nom convivial pour l’application, par exemple ContosoMDM, sélectionnez Application web et ou API web, puis sélectionnez Suivant.

  8. Entrez l’URL de connexion de votre service MDM.

  9. Pour ID d’application, entrez https://<your_tenant_name>/ContosoMDM, puis sélectionnez OK.

  10. Toujours dans le Portail Azure, sélectionnez l’onglet Configurer de votre application.

  11. Marquez votre application comme multilocataire.

  12. Recherchez la valeur d’ID client et copiez-la.

    Vous aurez besoin de cet ID ultérieurement lors de la configuration de votre application. Cet ID client est utilisé lors de l’obtention de jetons d’accès et de l’ajout d’applications à la galerie d’applications Azure AD.

  13. Générez une clé pour votre application et copiez-la.

    Vous avez besoin de cette clé pour appeler le API Graph Microsoft afin de signaler la conformité de l’appareil. Ces informations sont traitées dans la section suivante.

Pour plus d’informations sur l’inscription d’un exemple d’application auprès d’Azure AD, consultez les étapes d’inscription de l’API web TodoListService dans NativeClient-DotNet.

Ajouter un GPM local

Une application GPM locale est différente d’une GPM cloud. Il s’agit d’une application monolocataire qui est présente de manière unique au sein du locataire du client. Les clients doivent ajouter l’application directement dans leur propre locataire. En outre, chaque instance d’une application MDM locale doit être inscrite séparément et avoir une clé distincte pour l’authentification auprès d’Azure AD.

Pour ajouter une application GPM locale au locataire, utilisez le service Azure AD, en particulier sous Mobilité (MDM et GAM) > Ajouter une application. Les administrateurs peuvent configurer les URL requises pour l’inscription et les conditions d’utilisation.

Votre produit GPM local doit exposer une expérience de configuration dans laquelle les administrateurs peuvent fournir l’ID client, l’ID d’application et la clé configurée dans leur répertoire pour cette application MDM. Vous pouvez utiliser cet ID client et cette clé pour demander des jetons à Azure AD lorsque vous signalez la conformité de l’appareil.

Pour plus d’informations sur l’inscription d’applications auprès d’Azure AD, consultez Principes de base de l’inscription d’une application dans Azure AD.

Instructions relatives à la gestion et à la sécurité des clés

Les clés d’application utilisées par votre service GPM sont une ressource sensible. Ils doivent être protégés et restaurés régulièrement pour une plus grande sécurité. Les jetons d’accès obtenus par votre service MDM pour appeler microsoft API Graph sont des jetons du porteur et doivent être protégés pour éviter toute divulgation non autorisée.

Pour connaître les meilleures pratiques en matière de sécurité, consultez Windows Azure Security Essentials.

Vous pouvez remplacer les clés d’application utilisées par un service GPM basé sur le cloud sans nécessiter d’interaction client. Il existe un ensemble unique de clés pour tous les locataires clients qui sont gérés par le fournisseur MDM dans leur locataire Azure AD.

Pour la gestion des appareils mobiles local, les clés d’authentification Azure AD se trouvent dans le locataire du client et doivent être restaurées par l’administrateur du client. Pour améliorer la sécurité, fournissez des conseils aux clients sur le basculement et la protection des clés.

Publier votre application MDM dans la galerie d’applications Azure AD

Les administrateurs informatiques utilisent la galerie d’applications Azure AD pour ajouter un GPM à utiliser par leur organisation. La galerie d’applications est un magasin riche avec plus de 2 400 applications SaaS intégrées à Azure AD.

L’image suivante montre comment les applications MDM s’affichent dans la galerie d’applications Azure.

azure ad ajoute une application pour la gestion des appareils mobiles.

Ajouter la gestion des appareils mobiles basé sur le cloud à la galerie d’applications

Notes

Vous devez travailler avec l’équipe d’ingénierie Azure AD si votre application MDM est basée sur le cloud et doit être activée en tant qu’application MDM multilocataire

Le tableau suivant présente les informations requises pour créer une entrée dans la galerie d’applications Azure AD.

Élément Description
ID de l’application ID client de votre application MDM configurée au sein de votre locataire. Cet ID est l’identificateur unique de votre application multilocataire.
Éditeur Chaîne qui identifie l’éditeur de l’application.
URL de l’application URL vers la page d’accueil de votre application où vos administrateurs peuvent obtenir plus d’informations sur l’application MDM et contient un lien vers la page d’accueil de votre application. Cette URL n’est pas utilisée pour l’inscription réelle.
Description Brève description de votre application MDM, qui doit comporter moins de 255 caractères.
Icônes Ensemble d’icônes de logo pour l’application MDM. Dimensions : 45 x 45, 150 x 122, 214 x 215

Ajouter la gestion des appareils mobiles locaux à la galerie d’applications

Il n’existe aucune exigence particulière pour l’ajout de mdm local à la galerie d’applications. Il existe une entrée générique permettant à l’administrateur d’ajouter une application à son locataire.

Toutefois, la gestion des clés est différente pour la gestion des appareils mobiles local. Vous devez obtenir l’ID client (ID d’application) et la clé attribuées à l’application MDM au sein du locataire du client. L’ID et la clé obtiennent l’autorisation d’accéder au API Graph Microsoft et de signaler la conformité des appareils.

Thèmes

Les pages rendues par la gestion des appareils mobiles dans le processus d’inscription intégré doivent utiliser des modèles Windows (Télécharger les modèles Windows et les fichiers CSS (1.1.4)). Ces modèles sont importants pour l’inscription pendant l’expérience de jonction Azure AD dans OOBE, où toutes les pages sont des pages HTML de bord à bord. N’essayez pas de copier les modèles, car vous n’obtiendrez jamais le bon positionnement du bouton.

Il existe trois scénarios distincts :

  1. Inscription mdm dans le cadre de la jonction Azure AD dans Windows OOBE.
  2. Inscription MDM dans le cadre de la jonction Azure AD, après Windows OOBE à partir des paramètres.
  3. Inscription MDM dans le cadre de l’ajout d’un compte professionnel Microsoft sur un appareil personnel (BYOD).

Ces scénarios prennent en charge les clients Windows Pro, Entreprise et Éducation.

Les fichiers CSS fournis par Microsoft contiennent des informations de version et nous vous recommandons d’utiliser la dernière version. Il existe des fichiers CSS distincts pour les appareils clients Windows, les expériences OOBE et post-OOBE. Téléchargez les modèles Windows et les fichiers CSS (1.1.4).

  • Pour Windows 10, utilisez oobe-desktop.css
  • Pour Windows 11, utilisez oobe-light.css

Utilisation de thèmes

Une page MDM doit respecter un thème prédéfini en fonction du scénario affiché. Par exemple, si l’en-tête CXH-HOSTHTTP est FRX, qui est le scénario OOBE, la page doit prendre en charge un thème sombre avec une couleur d’arrière-plan bleue, qui utilise le fichier WinJS Ui-dark.css ver 4.0 et oobe-desktop.css version 1.0.4.

CXH-HOST (EN-TÊTE HTTP) Scénario Thème d’arrière-plan WinJS Scénario CSS
Frx OOBE Thème foncé + couleur d’arrière-plan bleu Nom de fichier : Ui-dark.css Nom de fichier : oobe-dekstop.css
MOSET Paramètres/Post OOBE Thème clair Nom de fichier : Ui-light.css Nom de fichier : settings-desktop.css

Sémantique du protocole conditions d’utilisation

Le point de terminaison conditions d’utilisation est hébergé par le serveur MDM. Pendant le flux du protocole de jointure Azure AD, Windows effectue une redirection en page complète vers ce point de terminaison. Cette redirection permet au GPM d’afficher les conditions générales qui s’appliquent. Il permet à l’utilisateur d’accepter ou de rejeter les conditions associées à l’inscription. Une fois que l’utilisateur a accepté les conditions, la gestion des appareils mobiles est redirigée vers Windows pour que le processus d’inscription se poursuive.

Rediriger vers le point de terminaison Conditions d’utilisation

Cette redirection est une redirection en page complète vers le point de terminaison Conditions de l’utilisateur hébergé par le GPM. Voici un exemple d’URL, https://fabrikam.contosomdm.com/TermsOfUse.

Les paramètres suivants sont passés dans la chaîne de requête :

Élément Description
redirect_uri Une fois que l’utilisateur a accepté ou rejeté les conditions d’utilisation, l’utilisateur est redirigé vers cette URL.
client-request-id GUID utilisé pour mettre en corrélation les journaux à des fins de diagnostic et de débogage. Utilisez ce paramètre pour journaliser ou suivre l’état de la demande d’inscription afin de trouver la cause racine des échecs.
api-version Spécifie la version du protocole demandée par le client. Cette valeur fournit un mécanisme pour prendre en charge les révisions de version du protocole.
mode Spécifie que l’appareil appartient à l’organisation lorsque mode=azureadjoin. Ce paramètre n’est pas présent pour les appareils BYOD.

Jeton d'accès

Azure AD émet un jeton d’accès du porteur. Le jeton est passé dans l’en-tête d’autorisation de la requête HTTP. Voici un format classique :

Autorisation : Porteur CI6MTQxmCF5xgu6yYcmV9ng6vhQfaJYw...

Les revendications suivantes sont attendues dans le jeton d’accès passé par Windows au point de terminaison conditions d’utilisation :

Élément Description
ID d’objet Identificateur de l’objet utilisateur correspondant à l’utilisateur authentifié.
Upn Revendication contenant le nom d’utilisateur principal (UPN) de l’utilisateur authentifié.
Tid Revendication représentant l’ID de locataire du locataire. Dans l’exemple ci-dessus, il s’agit de Fabrikam.
Ressource URL aseptisée représentant l’application MDM. Exemple : https://fabrikam.contosomdm.com

Notes

Il n’existe aucune revendication d’ID d’appareil dans le jeton d’accès, car l’appareil n’est peut-être pas encore inscrit pour l’instant.

Pour récupérer la liste des appartenances aux groupes de l’utilisateur, vous pouvez utiliser microsoft API Graph.

Voici un exemple d’URL.

https://fabrikam.contosomdm.com/TermsOfUse?redirect_uri=ms-appx-web://ContosoMdm/ToUResponse&client-request-id=34be581c-6ebd-49d6-a4e1-150eff4b7213&api-version=1.0
Authorization: Bearer eyJ0eXAiOi

Le GPM est censé valider la signature du jeton d’accès pour s’assurer qu’il a été émis par Azure AD et s’assurer que le destinataire est approprié.

Contenu des conditions d’utilisation

Le GPM peut effectuer d’autres redirections si nécessaire avant d’afficher le contenu des conditions d’utilisation à l’utilisateur. Le contenu des conditions d’utilisation approprié doit être retourné à l’appelant (Windows) afin qu’il puisse être affiché à l’utilisateur final dans le contrôle du navigateur.

Le contenu des conditions d’utilisation doit contenir les boutons suivants :

  • Accepter : l’utilisateur accepte les conditions d’utilisation et procède à l’inscription.
  • Refuser : l’utilisateur refuse et arrête le processus d’inscription.

Le contenu des conditions d’utilisation doit être cohérent avec le thème utilisé pour les autres pages affichées pendant ce processus.

Conditions d’utilisation de la logique de traitement du point de terminaison

À ce stade, l’utilisateur se trouve sur la page Conditions d’utilisation affichée pendant l’OOBE ou à partir des expériences De paramètre. L’utilisateur dispose des options suivantes sur la page :

  • L’utilisateur clique sur le bouton Accepter : le GPM doit rediriger vers l’URI spécifié par le paramètre redirect_uri dans la requête entrante. Les paramètres de chaîne de requête suivants sont attendus :
    • IsAccepted : cette valeur booléenne est obligatoire et doit être définie sur true.
    • OpaqueBlob : paramètre obligatoire si l’utilisateur accepte. La gestion des appareils mobiles peut utiliser cet objet blob pour mettre certaines informations à la disposition du point de terminaison d’inscription. La valeur conservée ici est rendue disponible inchangée au niveau du point de terminaison d’inscription. La gestion des appareils mobiles peut utiliser ce paramètre à des fins de corrélation.
    • Voici un exemple de redirection : ms-appx-web://MyApp1/ToUResponse?OpaqueBlob=value&IsAccepted=true
  • L’utilisateur clique sur le bouton Refuser : la GPM doit rediriger vers l’URI spécifié dans redirect_uri dans la requête entrante. Les paramètres de chaîne de requête suivants sont attendus :
    • IsAccepted : cette valeur booléenne est obligatoire et doit être définie sur false. Cette option s’applique également si l’utilisateur a ignoré les conditions d’utilisation.
    • OpaqueBlob : ce paramètre n’est pas censé être utilisé. L’inscription est arrêtée avec un message d’erreur affiché à l’utilisateur.

Les utilisateurs ignorent les conditions d’utilisation lorsqu’ils ajoutent un compte professionnel Microsoft à leur appareil. Toutefois, ils ne peuvent pas l’ignorer pendant le processus de jonction Azure AD. N’affichez pas le bouton Refuser dans le processus de jonction Azure AD. L’inscription mdm ne peut pas être refusée par l’utilisateur si elle est configurée par l’administrateur pour la jonction Azure AD.

Nous vous recommandons d’envoyer les paramètres client-request-id dans la chaîne de requête dans le cadre de cette réponse de redirection.

Gestion des erreurs des conditions d’utilisation

Si une erreur se produit pendant le traitement des conditions d’utilisation, la gestion des appareils mobiles peut retourner deux paramètres : une erreur et un paramètre error_description dans sa demande de redirection vers Windows. L’URL doit être encodée et le contenu de l’erreur_description doit être en texte brut anglais. Ce texte n’est pas visible par l’utilisateur final. Par conséquent, la localisation du texte de description de l’erreur n’est pas un problème.

Voici le format d’URL :

HTTP/1.1 302
Location:
<redirect_uri>?error=access_denied&error_description=Access%20is%20denied%2E

Example:
HTTP/1.1 302
Location: ms-appx-web://App1/ToUResponse?error=access_denied&error_description=Access%20is%20denied%2E

Le tableau suivant présente les codes d’erreur.

Cause État HTTP Erreur Description
api-version 302 invalid_request version non prise en charge
Les données client ou utilisateur sont manquantes ou les autres conditions préalables requises pour l’inscription des appareils ne sont pas remplies 302 unauthorized_client utilisateur ou locataire non autorisé
Échec de la validation du jeton Azure AD 302 unauthorized_client unauthorized_client
erreur de service interne 302 server_error erreur de service interne

Protocole d’inscription avec Azure AD

Avec l’inscription MDM intégrée à Azure, il n’y a pas de phase de découverte et l’URL de découverte est directement transmise au système à partir d’Azure. Le tableau suivant présente la comparaison entre les inscriptions traditionnelles et Azure.

Détail Inscription GPM traditionnelle Azure AD Join (appareil appartenant à l’organisation) Azure AD ajoute un compte professionnel (appareil appartenant à l’utilisateur)
Détection automatique MDM à l’aide d’une adresse e-mail pour récupérer l’URL de découverte MDM Inscription Non applicable
URL de découverte provisionnée dans Azure
Utilise l’URL de découverte MDM Inscription
Renouvellement de l’inscription
ROBO
Inscription
Renouvellement de l’inscription
ROBO
Inscription
Renouvellement de l’inscription
ROBO
L’inscription mdm est-elle obligatoire ? Oui Oui Non
L’utilisateur peut refuser.
Type d’authentification OnPremise
Fédérés
Certificat
Fédérés Fédérés
EnrollmentPolicyServiceURL Facultatif (toutes les authentifications) Facultatif (toutes les authentifications) Facultatif (toutes les authentifications)
EnrollmentServiceURL Obligatoire (toutes les authentifications) Utilisé (toutes les authentifications) Utilisé (toutes les authentifications)
EnrollmentServiceURL inclut la version du système d’exploitation, la plateforme du système d’exploitation et d’autres attributs fournis par l’URL de découverte MDM Fortement recommandé Fortement recommandé Fortement recommandé
AuthenticationServiceURL utilisé Utilisé (authentification fédérée) Ignoré Ignoré
BinarySecurityToken Personnalisé par GPM Jeton émis par Azure AD Jeton émis par Azure AD
EnrollmentType Complet Appareil Complet
Type de certificat inscrit Certificat utilisateur Certificat d’appareil Certificat utilisateur
Magasin de certificats inscrit Mon/Utilisateur Mon/Système Mon/Utilisateur
Nom de l’objet CSR Nom d’utilisateur principal ID de l’appareil Nom d’utilisateur principal
Objet blob binaire de conditions d’utilisation EnrollmentData en tant qu’AdditionalContext pour EnrollmentServiceURL Non pris en charge Pris en charge Pris en charge
Fournisseurs de services de configuration accessibles lors de l’inscription Windows 10 prise en charge :
- DMClient
- CertificateStore
- RootCATrustedCertificates
- ClientCertificateInstall
- EnterpriseModernAppManagement
- PassportForWork
-Politique
- application w7

Protocole de gestion avec Azure AD

Il existe deux types d’inscription mdm différents qui s’intègrent à Azure AD et utilisent des identités d’utilisateur et d’appareil Azure AD. Selon le type d’inscription, le service MDM peut avoir besoin de gérer un ou plusieurs utilisateurs.

Gestion de plusieurs utilisateurs pour les appareils joints à Azure AD Dans ce scénario, l’inscription MDM s’applique à chaque utilisateur Azure AD qui se connecte à l’appareil joint à Azure AD. Appelez ce type d’inscription une inscription d’appareil ou une inscription multi-utilisateur. Le serveur d’administration peut déterminer l’identité de l’utilisateur, déterminer les stratégies ciblées pour cet utilisateur et envoyer les stratégies correspondantes à l’appareil. Pour permettre au serveur d’administration d’identifier l’utilisateur actuel qui est connecté à l’appareil, le client OMA DM utilise les jetons utilisateur Azure AD. Chaque session de gestion contient un en-tête HTTP supplémentaire qui contient un jeton utilisateur Azure AD. Ces informations sont fournies dans le package DM envoyé au serveur d’administration. Toutefois, dans certains cas, le jeton utilisateur Azure AD n’est pas envoyé au serveur d’administration. Un tel scénario se produit immédiatement après la fin des inscriptions GPM pendant le processus de jointure Azure AD. Tant que le processus de jointure Azure AD n’est pas terminé et que l’utilisateur Azure AD ne se connecte à la machine, le jeton utilisateur Azure AD n’est pas disponible pour le processus OMA-DM. En règle générale, l’inscription mdm se termine avant que l’utilisateur Azure AD se connecte à la machine et que la session de gestion initiale ne contient pas de jeton utilisateur Azure AD. Le serveur d’administration doit vérifier si le jeton est manquant et envoyer uniquement des stratégies d’appareil dans ce cas. Une autre raison possible d’un jeton Azure AD manquant dans la charge utile OMA-DM est lorsqu’un utilisateur invité est connecté à l’appareil.

Ajout d’un compte professionnel et d’une inscription GPM à un appareil Dans ce scénario, l’inscription MDM s’applique à un seul utilisateur qui a initialement ajouté son compte professionnel et inscrit l’appareil. Dans ce type d’inscription, le serveur d’administration peut ignorer les jetons Azure AD qui peuvent être envoyés pendant la session de gestion. Que le jeton Azure AD soit présent ou manquant, le serveur d’administration envoie des stratégies d’utilisateur et d’appareil à l’appareil.

Évaluation des jetons utilisateur Azure AD Le jeton Azure AD se trouve dans l’en-tête d’autorisation HTTP au format suivant :

Authorization:Bearer <Azure AD User Token Inserted here>

D’autres revendications peuvent être présentes dans le jeton Azure AD, par exemple :

  • Utilisateur : utilisateur actuellement connecté
  • Conformité de l’appareil : valeur définissez le service MDM dans Azure
  • ID de l’appareil : identifie l’appareil qui est en cours d’archivage
  • ID du client

Les jetons d’accès émis par Azure AD sont des jetons web JSON (JWT). Un jeton JWT valide est présenté par Windows au niveau du point de terminaison d’inscription MDM pour démarrer le processus d’inscription. Il existe deux options pour évaluer les jetons :

  • Utilisez l’extension gestionnaire de jetons JWT pour WIF afin de valider le contenu du jeton d’accès et d’extraire les revendications requises pour l’utilisation. Pour plus d’informations, consultez Classe JwtSecurityTokenHandler.
  • Reportez-vous aux exemples de code d’authentification Azure AD pour obtenir un exemple d’utilisation des jetons d’accès. Pour obtenir un exemple, consultez NativeClient-DotNet.

Alerte d’appareil 1224 pour jeton utilisateur Azure AD

Une alerte est envoyée lorsque la session DM démarre et qu’un utilisateur Azure AD est connecté. L’alerte est envoyée dans OMA DM pkg#1. Voici un exemple:

Alert Type: com.microsoft/MDM/AADUserToken

Alert sample:
<SyncBody>
 <Alert>
  <CmdID>1</CmdID>
  <Data>1224</Data>
  <Item>
   <Meta>
    <Type xmlns=”syncml:metinf”>com.microsoft/MDM/AADUserToken</Type>
   </Meta>
   <Data>UserToken inserted here</Data>
  </Item>
 </Alert>
 … other XML tags …
</SyncBody>

Déterminer quand un utilisateur est connecté via l’interrogation

Une alerte est envoyée au serveur MDM dans le package DM#1.

  • Type d’alerte - com.microsoft/MDM/LoginStatus
  • Format d’alerte - chr
  • Données d’alerte : fournissez des informations d’état de connexion pour l’utilisateur actif connecté.
    • Utilisateur connecté disposant d’un compte Azure AD - texte prédéfini : utilisateur.
    • Utilisateur connecté sans compte Azure AD - texte prédéfini : autres.
    • Aucun utilisateur actif - texte prédéfini : aucun

Voici un exemple:

<SyncBody>
 <Alert>
  <CmdID>1</CmdID>
  <Data>1224</Data>
  <Item>
   <Meta>
    <Type xmlns=”syncml:metinf”>com.microsoft/MDM/LoginStatus</Type>
   </Meta>
   <Data>user</Data>
  </Item>
 </Alert>
 … other XML tags …
</SyncBody>

Signaler la conformité des appareils à Azure AD

Une fois qu’un appareil est inscrit auprès du GPM pour la gestion, les stratégies d’organisation configurées par l’administrateur informatique sont appliquées sur l’appareil. La conformité de l’appareil avec les stratégies configurées est évaluée par la gestion des appareils mobiles, puis signalée à Azure AD. Cette section décrit l’appel API Graph que vous pouvez utiliser pour signaler l’état de conformité d’un appareil à Azure AD.

Pour obtenir un exemple illustrant comment un GPM peut obtenir un jeton d’accès à l’aide du type d’octroi client_credentials OAuth 2.0, consultez Daemon_CertificateCredential-DotNet.

  • GPM basée sur le cloud : si votre produit est un service GPM multilocataire basé sur le cloud, vous disposez d’une clé unique configurée pour votre service au sein de votre locataire. Pour obtenir l’autorisation, utilisez cette clé pour authentifier le service MDM auprès d’Azure AD.
  • GPM local : si votre produit est un GPM local, les clients doivent configurer votre produit avec la clé utilisée pour s’authentifier auprès d’Azure AD. Cette configuration de clé est due au fait que chaque instance locale de votre produit MDM a une clé différente propre au locataire. Par conséquent, vous devrez peut-être exposer une expérience de configuration dans votre produit MDM qui permet aux administrateurs de spécifier la clé à utiliser pour s’authentifier auprès d’Azure AD.

Utiliser Microsoft API Graph

L’exemple d’appel d’API REST suivant illustre la façon dont un GPM peut utiliser microsoft API Graph pour signaler l’état de conformité d’un appareil géré par elle.

Notes

Cette API s’applique uniquement aux applications GPM approuvées sur les appareils Windows 10.

Sample Graph API Request:

PATCH https://graph.windows.net/contoso.com/devices/db7ab579-3759-4492-a03f-655ca7f52ae1?api-version=beta HTTP/1.1
Authorization: Bearer eyJ0eXAiO………
Accept: application/json
Content-Type: application/json
{  "isManaged":true,
   "isCompliant":true
}

Où:

  • contoso.com : cette valeur est le nom du locataire Azure AD auquel l’appareil a été joint.
  • db7ab579-3759-4492-a03f-655ca7f52ae1 : cette valeur est l’identificateur de l’appareil dont les informations de conformité sont signalées à Azure AD.
  • eyJ0eXAiO......... – Cette valeur est le jeton d’accès du porteur émis par Azure AD au GPM qui autorise le GPM à appeler le API Graph Microsoft. Le jeton d’accès est placé dans l’en-tête d’autorisation HTTP de la requête.
  • isManaged et isCompliant : ces attributs booléens indiquent l’état de conformité.
  • api-version : utilisez ce paramètre pour spécifier la version de l’API de graphe demandée.

Réponse:

  • Réussite : HTTP 204 sans contenu.
  • Échec/erreur : HTTP 404 introuvable. Cette erreur peut être retournée si l’appareil ou le locataire spécifié est introuvable.

Perte de données lors de la désinscription d’Azure Active Directory Join

Lorsqu’un utilisateur est inscrit à mdm via Azure Active Directory Join, puis déconnecte l’inscription, il n’y a aucun avertissement indiquant que l’utilisateur perd des données Windows Information Protection (WIP). Le message de déconnexion n’indique pas la perte de données WIP.

aadj unnrollment.

Codes d’erreur

Code ID Message d’erreur
0x80180001 «idErrorServerConnectivity», // MENROLL_E_DEVICE_MESSAGE_FORMAT_ERROR Une erreur s’est produite lors de la communication avec le serveur. Vous pouvez réessayer ou contacter votre administrateur système avec le code d’erreur {0}
0x80180002 «idErrorAuthenticationFailure», // MENROLL_E_DEVICE_AUTHENTICATION_ERROR Un problème s’est produit lors de l’authentification de votre compte ou appareil. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .
0x80180003 «idErrorAuthorizationFailure», // MENROLL_E_DEVICE_AUTHORIZATION_ERROR Cet utilisateur n’est pas autorisé à s’inscrire. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .
0x80180004 «idErrorMDMCertificateError», // MENROLL_E_DEVICE_CERTIFCATEREQUEST_ERROR Une erreur de certificat s’est produite. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .
0x80180005 «idErrorServerConnectivity», // MENROLL_E_DEVICE_CONFIGMGRSERVER_ERROR Une erreur s’est produite lors de la communication avec le serveur. Vous pouvez réessayer ou contacter votre administrateur système avec le code d’erreur {0}
0x80180006 «idErrorServerConnectivity», // MENROLL_E_DEVICE_CONFIGMGRSERVER_ERROR Une erreur s’est produite lors de la communication avec le serveur. Vous pouvez réessayer ou contacter votre administrateur système avec le code d’erreur {0}
0x80180007 «idErrorAuthenticationFailure», // MENROLL_E_DEVICE_INVALIDSECURITY_ERROR Un problème s’est produit lors de l’authentification de votre compte ou appareil. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .
0x80180008 «idErrorServerConnectivity», // MENROLL_E_DEVICE_UNKNOWN_ERROR Une erreur s’est produite lors de la communication avec le serveur. Vous pouvez réessayer ou contacter votre administrateur système avec le code d’erreur {0}
0x80180009 «idErrorAlreadyInProgress», // MENROLL_E_ENROLLMENT_IN_PROGRESS Une autre inscription est en cours. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .
0x8018000A «idErrorMDMAlreadyEnrolled», // MENROLL_E_DEVICE_ALREADY_ENROLLED Cet appareil est déjà inscrit. Vous pouvez contacter votre administrateur système avec le code {0}d’erreur .
0x8018000D «idErrorMDMCertificateError», // MENROLL_E_DISCOVERY_SEC_CERT_DATE_INVALID Une erreur de certificat s’est produite. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .
0x8018000E «idErrorAuthenticationFailure», // MENROLL_E_PASSWORD_NEEDED Un problème s’est produit lors de l’authentification de votre compte ou appareil. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .
0x8018000F «idErrorAuthenticationFailure», // MENROLL_E_WAB_ERROR Un problème s’est produit lors de l’authentification de votre compte ou appareil. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .
0x80180010 «idErrorServerConnectivity», // MENROLL_E_CONNECTIVITY Une erreur s’est produite lors de la communication avec le serveur. Vous pouvez réessayer ou contacter votre administrateur système avec le code d’erreur {0}
0x80180012 «idErrorMDMCertificateError», // MENROLL_E_INVALIDSSLCERT Une erreur de certificat s’est produite. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .
0x80180013 «idErrorDeviceLimit», // MENROLL_E_DEVICECAPREACHED Il semble qu’il y ait trop d’appareils ou d’utilisateurs pour ce compte. Contactez votre administrateur système avec le code {0}d’erreur .
0x80180014 «idErrorMDMNotSupported», // MENROLL_E_DEVICENOTSUPPORTED Cette fonctionnalité n’est pas prise en charge. Contactez votre administrateur système avec le code {0}d’erreur .
0x80180015 «idErrorMDMNotSupported», // MENROLL_E_NOTSUPPORTED Cette fonctionnalité n’est pas prise en charge. Contactez votre administrateur système avec le code {0}d’erreur .
0x80180016 «idErrorMDMRenewalRejected», // MENROLL_E_NOTELIGIBLETORENEW Le serveur n’a pas accepté la demande. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .
0x80180017 «idErrorMDMAccountMaintenance», // MENROLL_E_INMAINTENANCE Le service est en maintenance. Vous pouvez réessayer ultérieurement ou contacter votre administrateur système avec le code {0}d’erreur .
0x80180018 «idErrorMDMLicenseError», // MENROLL_E_USERLICENSE Une erreur s’est produite avec votre licence. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .
0x80180019 «idErrorInvalidServerConfig», // MENROLL_E_ENROLLMENTDATAINVALID Il semble que le serveur n’est pas correctement configuré. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .
«rejectedTermsOfUse» «idErrorRe éjectéTermsOfUse» Votre organisation exige que vous acceptiez les conditions d’utilisation. Réessayez ou demandez à votre support technique d’obtenir plus d’informations.
0x801c0001 «idErrorServerConnectivity», // DSREG_E_DEVICE_MESSAGE_FORMAT_ERROR Une erreur s’est produite lors de la communication avec le serveur. Vous pouvez réessayer ou contacter votre administrateur système avec le code d’erreur {0}
0x801c0002 «idErrorAuthenticationFailure», // DSREG_E_DEVICE_AUTHENTICATION_ERROR Un problème s’est produit lors de l’authentification de votre compte ou appareil. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .
0x801c0003 «idErrorAuthorizationFailure», // DSREG_E_DEVICE_AUTHORIZATION_ERROR Cet utilisateur n’est pas autorisé à s’inscrire. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .
0x801c0006 «idErrorServerConnectivity», // DSREG_E_DEVICE_INTERNALSERVICE_ERROR Une erreur s’est produite lors de la communication avec le serveur. Vous pouvez réessayer ou contacter votre administrateur système avec le code d’erreur {0}
0x801c000B «idErrorUntrustedServer», // DSREG_E_DISCOVERY_REDIRECTION_NOT_TRUSTED Le serveur contacté n’est pas approuvé. Contactez votre administrateur système avec le code {0}d’erreur .
0x801c000C «idErrorServerConnectivity», // DSREG_E_DISCOVERY_FAILED Une erreur s’est produite lors de la communication avec le serveur. Vous pouvez réessayer ou contacter votre administrateur système avec le code d’erreur {0}
0x801c000E «idErrorDeviceLimit», // DSREG_E_DEVICE_REGISTRATION_QUOTA_EXCCEEDED Il semble qu’il y ait trop d’appareils ou d’utilisateurs pour ce compte. Contactez votre administrateur système avec le code {0}d’erreur .
0x801c000F «idErrorDeviceRequiresReboot», // DSREG_E_DEVICE_REQUIRES_REBOOT Un redémarrage est nécessaire pour terminer l’inscription de l’appareil.
0x801c0010 «idErrorInvalidCertificate», // DSREG_E_DEVICE_AIK_VALIDATION_ERROR Il semble que vous ayez un certificat non valide. Contactez votre administrateur système avec le code {0}d’erreur .
0x801c0011 «idErrorAuthenticationFailure», // DSREG_E_DEVICE_ATTESTATION_ERROR Un problème s’est produit lors de l’authentification de votre compte ou appareil. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .
0x801c0012 «idErrorServerConnectivity», // DSREG_E_DISCOVERY_BAD_MESSAGE_ERROR Une erreur s’est produite lors de la communication avec le serveur. Vous pouvez réessayer ou contacter votre administrateur système avec le code d’erreur {0}
0x801c0013 «idErrorAuthenticationFailure», // DSREG_E_TENANTID_NOT_FOUND Un problème s’est produit lors de l’authentification de votre compte ou appareil. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .
0x801c0014 «idErrorAuthenticationFailure», // DSREG_E_USERSID_NOT_FOUND Un problème s’est produit lors de l’authentification de votre compte ou appareil. Vous pouvez réessayer ou contacter votre administrateur système avec le code {0}d’erreur .