Déploiement d’une Passerelle de Gestion Cloud (Cloud Management Gateway)
Le contexte
Les derniers mois ont démontré toute la complexité de gérer les postes de travail lorsqu’ils sont déconnectés du réseau d’entreprise ou connecté avec un client VPN. Bon nombre d’entreprises n’étaient pas préparées à ce type de situation et les administrateurs systèmes et réseaux ont dû passer de longues heures à déployer des solutions de connectivité pour « récupérer » leurs ordinateurs lâchés dans la nature et ainsi pouvoir continuer à les gérer.
Microsoft EndPoint Manager Configuration Manager est traditionnellement identifié comme étant le composant « on-premise » de la suite Microsoft EndPoint Manager et Microsoft EndPoint Manager Intune comme le pendant « cloud » de cet ensemble d’outils.
Cela peut être schématisé de la sorte mais, depuis la version 1610 (4 ans déjà !), une infrastructure SCCM (on l’appellera encore longtemps comme cela) peut être complétée d’une passerelle de gestion cloud (CMG) pour la gestion des postes en mode Internet.
Nous allons donc décrire dans cet article la finalité de ce composant, comment le déployer et ensuite nous positionner côté client pour valider le bon fonctionnement.
Mais au fait : à quoi ça sert ?
Mais pourquoi vouloir déployer une Cloud Management Gateway me direz-vous ? Si vous vous intéressez à la gestion des postes de travail et que vous n’êtes pas restés dans une grotte les 5 dernières années, on vous a rabâché le discours suivant : « si vous voulez gérer des postes sur Internet, vous avez Intune mon bon monsieur ! »
OUI, MEM Intune est un formidable outil de management, multi-plateformes, en capacité à prendre en charge beaucoup de cas d’usages MAIS quand vous avez investi depuis plusieurs années sur SCCM, vous n’allez pas mettre à la poubelle toutes vos applications, vos scripts, vos séquences de tâches pour tout basculer dans MEM Intune.
Au delà de l’effort et des coûts engendrés, MEM Intune ne recouvre pas le même périmètre fonctionnel que MEM Configuration Manager et ne le fera jamais (je m’avance peut-être un peu là).
Donc, pourquoi vouloir déployer une CMG (à partir de maintenant, j’emploierai cet acronyme) ? Pour fournir un grand nombre de fonctionnalités disponibles depuis MEM CM « on-premise ».
Pour plus d’information, voir cet article : https://docs.microsoft.com/fr-fr/mem/configmgr/core/clients/manage/cmg/plan-cloud-management-gateway#support-for-configuration-manager-features
Note : ces fonctionnalités s’enrichissent à chaque nouvelle version. C’est bien là un signe, selon nous, de la volonté de Microsoft de pousser les entreprises à adopter cette fonctionnalité qui repose sur les services fournis par Azure.
Déploiement de la CMG depuis la console EndPoint Manager
Nous allons vous présenter les grandes étapes du déploiement d’une CMG et ensuite vous montrer comment cela se matérialise du côté du client MEMCM.
Au final, notre infrastructure de gestion ressemblera à cela :
Prérequis
Abonnement Azure (pas d’abonnement CSP)
Il est nécessaire de disposer d’une souscription Azure pour déployer la Cloud Management Gateway. Pour l’heure, pas d’abonnement Azure en mode CSP (Cloud Solution Provider). En Technical Preview MEMCM 2009 ; vers une disponibilité générale en version MEMCM 2010 ?
Certificat (public dans notre cas)
Idéalement, un certificat signé par une autorité de confiance de type Wildcard (*.<nomdomaine>) limitera le risque d’indisponibilité du nom choisi pour le Cloud Service.
Compte Administrateur général Azure AD & compte ayant le rôle Propriétaire d’abonnement Azure
L’administrateur général est nécessaire pour intégrer le site avec Azure AD. Le rôle Propriétaire d’Abonnement est requis pour pouvoir déployer des ressources.
Fournisseurs de ressources Microsoft.ClassicCompute & Microsoft.Storage inscrits dans l’abonnement Azure
La Passerelle de Gestion Cloud s’appuie sur des ressources de type Classic Compute et Storage. Si ces ressources ne sont pas inscrites dans l’abonnement, le déploiement échouera.
Nous allons maintenant décrire les étapes nécessaires pour le déploiement de la CMG. La majorité des actions s’effectuent depuis la console EndPoint Manager.
Note : toutes les captures d’écran sont effectuées depuis une console en anglais car cela facilite la recherche ultérieure d’information… au cas où cela ne fonctionnerait pas !
Activation de la fonctionnalité
Par défaut, Configuration Manager n’active pas cette fonctionnalité facultative. Vous devez activer cette fonctionnalité avant de l’utiliser.
Pour ce faire, depuis la console EndPoint Manager, dans l’onglet Administration>Update and Servicing>Features :
Vous aurez à confirmer cette activation :
Une fois cette confirmation acquittée, vous verrez apparaitre dans le dossier Cloud Services, un nouvel icône Cloud Management Gateway, juste en dessous de Cloud Distribution Points :
Déploiement et configuration de la Cloud Management Gateway
En cliquant sur l’icône Create Cloud Management Gateway, nous allons démarrer le processus de déploiement de la CMG.
- La première étape consiste à se connecter à l’environnement Azure :
- Une fois authentifié, la ou les souscriptions Azure répertoriées dans le tenant Azure Active Directory sont listées et l’application Azure AD et le nom du tenant Azure AD sont présentées :
- Cliquer sur Next>
- En tout premier lieu, il faut sélectionner le certificat wilcard permettant d’authentifier le service vis-à-vis des clients.
Note : dès lors que vous allez sélectionner un certificat de type wilcard (*.<nomdomaine>), un message d’avertissement vous indiquera que le certificat wildcard a été détecté :
L’avantage d’utiliser un certificat wildcard est qu’il permet de définir le nom du service « à la volée » et ne nécessite pas de demander au fournisseur de certificat de « coder » le nom du service cloud Azure au risque que le nom ne soit plus disponible au niveau de la souscription Azure (si, si ça arrive, je parle en connaissance de cause).
Passons en revue les informations de cet écran (du haut vers le bas) :
- Certificate file : certificat pour authentifier le service Cloud
- Service Name : nom qui sera donné au service (nom FQDN de la CMG en fait)
- Deployment name : champ rempli automatiquement sur la base du nom du service renseigné au dessus. Comme la CMG est un Cloud Service Azure, son extension est en .cloudapp.net
- Description : champ texte permettant de décrire le service
- Region : région Azure dans laquelle la CMG sera déployée
- Resource Group : groupe de ressource Azure dans lequel les composants de la CMG seront déployées (VNet, Cloud Service, Stockage…)
- VM Instance : nombre (entre 1 et 16) de machines virtuelles (de type Standard A2_V2) associées au Cloud Service (pour des éléments de dimensionnement : https://docs.microsoft.com/fr-fr/mem/configmgr/core/clients/manage/cmg/plan-cloud-management-gateway#performance-and-scale)
- Verify Client Certificate Revocation : pour de plus amples renseignements (https://docs.microsoft.com/fr-fr/archive/blogs/ieinternals/understanding-certificate-revocation-checks). En résumé, on s’assure que le client vérifie la validité du certificat avant d’accéder au service
- Enforce TLS 1.2 : forcer la communication à l’aide du protocole TLS 1.2
- Allow CMG to function… : si coché, la CMG fera aussi office de Cloud Distribution Point et hébergera donc le contenu des applications, scripts et définition des updates comme le ferait un Cloud Distribution Point. Cela permet d’économiser une machine virtuelle dans Azure. Rien n’empêche cependant de déployer ensuite d’autres Cloud DP pour répartir les sources géographiquement.
- Cliquer ensuite sur Next>
Un nouveau panneau de configuration s’affiche, il permet de configurer les alertes de consommation au niveau des échanges sortants (outbound data transfer) et du stockage.
Le service peut automatiquement être stoppé lorsqu’un des seuils Critique est atteint en cochant la case « Stop this service… »
- Cliquer sur Next>
- Un panneau présentant le résumé des informations saisies s’affiche avant de déclencher le déploiement en cliquant sur Next>
Le déploiement de la Cloud Management Gateway est maintenant lancé, la progression du provisionnement peut s’effectuer depuis la console. Le premier statut sera Provisioning :
Lorsque le provisionnement est terminé, le statut passera en Ready :
La Cloud Management Gateway est maintenant opérationnelle dans Azure MAIS elle n’est pas exploitable par l’infrastructure MEM Configuration Manager car aucun serveur ne peut communiquer avec elle. C’est ce que nous allons faire dans les prochaines étapes de la procédure.
Création du Point de connexion de service pour la communication avec la CMG
Afin que l’infrastrucure MEM Configuration Manager puisse « dialoguer » avec la Cloud Management Gateway que nous venons de déployer, il est nécessaire de déployer un nouveau rôle dans notre environnement : il s’agit du rôle Cloud management gateway service connection point (n°4 dans le schéma ci-dessous). Ce rôle servira à établir et maintenir le canal de communication sécurisé entre notre environnement on-premise et l’environnement Cloud.
Il est nécessaire de disposer d’au moins 1 service connection point mais, à des fins de haute-disponibilité, il est possible d’en déployer plusieurs.
Une fois de plus, pour toute interrogation sur le fonctionnement, je vous renvoie vers la documentation Microsoft : https://docs.microsoft.com/fr-fr/mem/configmgr/core/clients/manage/cmg/plan-cloud-management-gateway#ports-and-data-flow.
L’image suivante schématise le fonctionnement de ce rôle et son importance :
Conclusion
Notre Passerelle de Gestion Cloud est maintenant opérationnelle. Pour autant, les postes de travail ne sont pas encore en mesure de se connecter dessus. Il est nécessaire de procéder à la configuration des paramètres du client, d’associer éventuellement la CMG à un groupe de limites (Boundary Group), de distribuer des sources sur le Cloud Distribution Point qu’elle renferme…
