Très souvent, la sécurité d’un périmètre ou d’un environnement focalise une attention particulière aux processus d’authentification ainsi qu’aux moyens mis à disposition aux utilisateurs pour y parvenir. Quelles méthodes, quelles conditions, quels protocoles mettre en place ? La MFA est un principe de base maintenant acquis pour tous et set présent dans une majorité de systèmes, mais le mot de passe reste alors encore de la partie.
Qu’est-ce que le Passwordless ?
Le concept de Passwordless (sans mot de passe) désigne une méthode d’authentification qui permet aux utilisateurs de se connecter à des systèmes ou des services sans avoir à utiliser un mot de passe traditionnel.
Autrement dit, le concept de Passwordless regroupe plusieurs méthodes d’authentification différentes, comme :
Passkey via Microsoft Authenticator
Push via Microsoft Authenticator
FIDO2
Windows Hello
SmartCard
Pourquoi vouloir se débarrasser du mot de passe ?
L’objectif principal du Passwordless est de réduire les risques de compromission liés aux mots de passe traditionnels, comme les attaques par hameçonnage (phishing), les vols de mot de passe, ou encore les mauvaises pratiques liées à la gestion des mots de passe (mots de passe faibles ou réutilisés).
Passwordless vs MFA ?
Passwordless et MFA (Multi-Factor Authentication) sont 2 méthodes d’authentification sécurisée, mais elles diffèrent dans leur approche et leur mise en œuvre.
Des fonctionnalités telles que l’authentification multifacteur (MFA) sont un excellent moyen de sécuriser votre organisation, mais les utilisateurs sont souvent frustrés par la couche de sécurité supplémentaire en plus de devoir mémoriser leurs mots de passe.
Les méthodes d’authentification sans mot de passe sont plus pratiques, car le mot de passe est supprimé et remplacé par quelque chose que vous avez ou quelque chose que vous êtes ou connaissez.
Combinaison de mot de passe + SMS, email, biométrie
Exemples d’utilisation
Connexion par empreinte digitale, lien magique
Connexion par mot de passe + code SMS ou app Authenticator
Dans cet article, je vous propose de mettre en place et de tester l’authentification Passwordless via l’application Microsoft Authenticator sur smartphone pour une identité 365 :
Pour réaliser cet exercice sur la méthode Passwordless de Microsoft, il vous faudra disposer de :
Un tenant Microsoft
Un smartphone sous iOS ou Android ayant la dernière version de Microsoft Authenticator
Important : à l’issue de cette démonstration, gardez en tête que votre smartphone sera enregistré (mais non managé) dans chaque tenant Microsoft où il sera utilisé pour se connecter en Passwordless.
Commençons par activer le service Passwordless sur le tenant 365.
Etape I – Configuration du tenant :
Pour cela, rendez-vous dans la section suivante de votre portail Entra, puis cliquez sur Microsoft Authenticator :
Si ce n’est pas encore le cas, activez la méthode d’authentification Microsoft Authenticator :
Définissez le périmètre des utilisateurs concernés en laissant le mode d’authentification à Any ou Passwordless :
Basculez sur le second onglet afin d’activer ou non Microsoft Authenticator OTP :
Afin de comprendre le fonctionnement du processus depuis l’enrôlement de départ de Microsoft Authenticator, il est préférable de créer un utilisateur de test.
Etape II – Configuration du l’utilisateur :
Toujours sur votre portail Entra, cliquez ici pour créer un nouvel utilisateur sur votre tenant Microsoft :
Renseignez-lui un UPN, un nom d’affichage, ainsi qu’un mot de passe temporaire, puis lancez la validation Entra :
Une fois la validation Entra réussie, lancez la création de votre utilisateur des test :
Une fois l’utilisateur créé, ouvrez le navigateur internet de votre choix en mode privé :
Rendez-vous sur la page office.com, puis cliquez ici pour vous authentifier :
Saisissez le nom de compte de votre utilisateur de test ainsi que son mot de passe provisoire :
Définissez un nouveau mot de passe :
Cliquez sur Oui :
Notre environnement 365 et notre utilisateur sont maintenant créé.
Passons maintenant à l’étape suivante qui consiste à associer Microsoft Authenticator à notre compte de test.
Etape III – Configuration MFA :
En haut à droite, cliquez ici pour afficher les propriétés de votre compte 365 :
Dans l’onglet dédié aux informations de sécurité, ajoutez une nouvelle méthode d’authentification :
Choisissez la méthode suivante pour configurer Microsoft Authenticator :
Installez au besoin l’application Microsoft Authenticator depuis un store d’applications, puis cliquez sur Suivant :
Cliquez sur Suivant :
Choisissez le type Compte professionnel ou scolaire :
Cliquez ici pour utiliser l’appareil photo afin de scanner le QR code :
Scanner le QR code présenté par Microsoft :
Une fois scanné, cliquez sur Suivant :
Une notification est alors envoyée à votre smartphone :
Saisissez le nombre précédemment affiché, puis cliquez sur Oui :
Confirmez votre identité sur le smartphone via un code PIN ou une empreinte digitale :
La méthode Microsoft Authenticator est maintenant correctement configurée sur votre compte de test, cliquez alors sur Suivant :
La méthode Microsoft Authenticator apparaît alors sur votre compte en tant que méthode dite MFA :
L’utilisateur de test est maintenant correctement configuré avec un mot de passe traditionnel et une méthode de sécurité de type MFA.
Etape IV – Configuration Passwordless :
Afin d’activer la méthode Passwordless, nous allons transformer le compte de test enregistré sur l’application Microsoft Authenticator.
Pour cela, ouvrez l’application Microsoft Authenticator, sélectionnez votre compte de test, puis cliquez ici pour activer la fonctionnalité Passwordless :
Microsoft vous informe que l’appareil sera inscrit dans le tenant ID correspondant, cliquez sur Continuer
Sur l’application Microsoft Authenticator, renseignez le mot de passe de votre compte de test :
Un nombre apparaît alors sur la fenêtre, ainsi qu’une notification Microsoft Authenticator, vous demandant de ressaisir ce dernier :
Confirmez votre identité sur le smartphone via un code PIN ou une empreinte digitale :
Cliquez ici pour confirmer l’enregistrement de votre smartphone sur le tenant ID concerné :
Microsoft Authenticator vous confirme le succès des opérations et de l’activation de la fonctionnalité Passwordless, cliquez alors sur Terminer :
Retournez sur le portail Entra afin de constater l’apparition de votre smartphone en tant que périphérique enregistré :
De retour sur les éléments de sécurité de votre utilisateur de test, la méthode Microsoft Authenticator s’est transformée de MFA à Passwordless :
Tout notre environnement de test est maintenant configuré. Il ne nous reste qu’à tester que la méthode Passwordless fonctionne correctement à la place du mot de passe.
Etape V – Test du Passwordless :
Rouvrez à nouveau un navigateur internet en mode privée :
Rendez-vous à nouveau sur la page office.com, puis cliquez ici pour vous authentifier :
Saisissez le nom de compte de votre utilisateur de test, puis, au lieu de renseigner son mot de passe, cliquez sur le choix suivant :
Microsoft envoie alors une notification sur le smartphone configuré comme Passwordless :
Ouvrez la notification Microsoft Authenticator, puis ressaisissez le nombre précédemment indiqué par Microsoft :
De retour sur votre navigateur, confirmez votre souhait de rester authentifié en cliquant sur Oui :
La page d’accueil d’Office 365 s’ouvre bien, l’utilisateur s’est correctement authentifié sans mot de passe :
Côté traçabilité, il est possible de retrouver des logs des authentifications Passwordless dans plusieurs écrans de Microsoft :
Côté Administrateur, via la vue des logs d’un utilisateur sur Entra ID :
Ou via une requête KQL après l’activation Log Analytics sur Entra ID :
SigninLogs
| where AuthenticationDetails has "passwordless"
| project TimeGenerated, UserPrincipalName, AuthenticationDetails , ResultDescription
| order by TimeGenerated desc
Conclusion
En conclusion, l’adoption du Passwordless avec Microsoft Authenticator constitue une avancée significative dans la sécurisation des environnements numériques tout en améliorant l’expérience utilisateur.
En éliminant la nécessité de mémoriser et de gérer des mots de passe, cette méthode réduit les risques liés aux compromissions, telles que les attaques de phishing ou le vol de mots de passe.
De plus, elle simplifie les processus d’authentification, rendant l’accès aux services plus fluide. Pour les entreprises, c’est une opportunité d’offrir un meilleur équilibre entre sécurité et facilité d’utilisation, tout en renforçant la confiance des utilisateurs dans la protection de leurs données.
Les stratégies de connexion entre des réseaux Cloud et/ou sur site sont déjà possibles grâce aux appairages, aux passerelles VPN et encore bien d’autres. Mais force est de constater qu’Azure WAN simplifie la mise en œuvre d’une architecture multi-réseaux. Et bien figurez-vous que j’ai justement pu enfin trouver le temps pour le tester cet Azure WAN ! 😎
Avant vous parler du test que j’ai réalisé sur ce service, commençons d’abord par quelques notions sur Azure WAN.
Qu’est-ce qu’Azure WAN ?
Azure WAN facilite la connexion des sites distants, des succursales ou des utilisateurs via un réseau centralisé. Cela permet d’intégrer plusieurs réseaux locaux (LAN) sur un WAN global, améliorant ainsi la connectivité et la gestion.
Azure WAN est un concentré de services réseaux déjà disponibles sur le Cloud Microsoft. Il propose de mettre en place et de gérer de façon simple et rapide différents types de liaison dans le Cloud et/ou sur site.
Mais seulement cette simplicité n’est pas un synonyme d’économie : Azure WAN propose dès les premiers liens des puissances assez grandes. Et qui dit performances, dit coûts.
Azure Virtual WAN est un service de mise en réseau qui combine un grand nombre de fonctionnalités de mise en réseau, de sécurité et de routage pour fournir une interface opérationnelle unique.
Grâce à son interface unique et centralisée, les administrateurs réseau peuvent configurer et surveiller facilement l’ensemble du réseau WAN, incluant les connexions des utilisateurs, les VPN, et les passerelles virtuelles. Cela simplifie donc l’administration des réseaux complexes.
Dans quel cas considérer Azure WAN ?
Le service est idéal pour les environnements hybrides ou multicloud, en offrant une connectivité fluide entre les réseaux sur site et divers fournisseurs de cloud.
Azure WAN est avant tout une boîte à outils où les liaisons entre ressources Azure et/ou sur sites sont vraiment très simples à mettre en œuvre.
Quels SKUs sont disponibles pour Azure WAN ?
Azure WAN permet de réduire les coûts en diminuant la nécessité d’équipements réseau sur site. L’approche as-a-service signifie que les entreprises paient uniquement pour ce qu’elles utilisent, réduisant ainsi les coûts d’infrastructure.
A ce jour, 2 SKUs sont déjà disponibles pour Azure WAN. Microsoft nous expose via le tableau ci-dessous les différences :
Type de Virtual WAN
Type de Hub
Configurations disponibles
De base
De base
VPN de site à site uniquement
standard
standard
ExpressRoute VPN utilisateur (point à site) VPN (site à site) Transit de hub à hub et de réseau virtuel à réseau virtuel via le hub virtuel Pare-feu Azure NVA est un WAN virtuel
Autrement dit, l’Azure WAN de base, bien que gratuit (base + traffic), apportera seulement les connexions VPN site à site et aux réseaux virtuels Azure, mais certaines liaisons sont manquantes comme :
Connexion entre les hubs
Connectivité ExpressRoute
Connectivité VPN utilisateur/point à site
Connectivité de réseau virtuel à réseau virtuel Azure
Azure Firewall
Enfin, Il est malgré tout possible de migrer depuis le SKU Basic vers Standard, mais pas l’inverse :
Quels sont les autres coûts liés au services Azure WAN ?
La tarification du service Azure WAN est très fragmenté. La facturation dépendra des différents trafics réseaux, et donc se divisera potentiellement en une myriade de petits frais.
J’ai installé Azure VPN sur mes 2 PCs situés en mobilité :
La configuration VPN établie par mon WAN repose sur un FQDN unique. Cela permet d’établir la connexion Point à Site vers le hub le plus proche de façon transparente et automatique :
Poste 1 :
Poste 2 :
Une fois la connexion VPN cliente établie, les informations sont visibles sur le hub :
Mon environnement WAN est maintenant en place, il ne me reste plus qu’à tester les accès et la transitivité de l’infrastructure toute entière.
Tests des accès :
Pour cela, j’ai installé le service Azure Bastion sur le réseau virtuel contenant un PC en mobilité :
J’ai démarré la connexion Point à Site via Azure VPN en utilisant le SSO de l’OS :
J’ai pu ouvrir avec succès des connexions RDP vers toutes les machines virtuelles de mon WAN :
Second PC en mobilité ayant une connexion Point à Site ouverte sur l’autre hub
Serveur ayant une connexion Site à Site ouverte sur le même hub
Serveur ayant une connexion Site à Site ouverte sur l’autre hub
Serveurs ayant un appairage de réseau virtuel sur le même hub
Serveurs ayant un appairage de réseau virtuel sur l’autre hub
Le routage vers toutes les machines s’est donc effectuée sans aucun autre composant additionnel qu’Azure WAN lui-même 💪
Surveillance des liaisons :
Une fois le WAN en place, la surveillance des liaisons est indispensable afin d’y remédier au plus vite car ces dernières sont souvent critiques pour un ou plusieurs services de l’entreprise.
Pour cela des métriques sont disponibles via le menu Insights de mon Azure WAN :
De plus, Azure WAN peut s’appuyer sur le service Connection Monitor disponible sous Network Watcher afin d’établir des tests de connectivité et des règles d’alerte.
J’ai configuré Connection Monitor afin d’effectuer des tests ICMP vers Azure, mais aussi vers mes 2 sites physiques :
A peine les tests créés, Connection Monitor affiche les résultats :
Différentes informations sont disponibles sur ces tests :
Afin de simuler une panne, j’ai simplement éteint une machine virtuelle Azure sur site :
A peinte la machine virtuelle éteinte, Connection Monitor indique déjà des échecs dans les tests concernés :
Le détail du test en défaut nous affiche également le routage et même le lieu exact du blocage de la liaison :
Azure Monitor affiche également les 2 alerte déclenchée :
Grâce au groupe d’action configuré sur la règle de l’alerte créée par Connection Monitor, une notification par e-mail me parvient immédiatement :
Afin de retrouver une situation opérationnelle, je rallume la machine virtuelle sur site précédemment éteinte :
Quelques minutes plus tard, les alertes générées sont automatiquement résolues :
De retour sur Connection Monitor, tous les tests repassent alors en vert :
Conclusion
En résumé, Azure WAN offre une solution robuste, sécurisée et évolutive pour connecter et gérer les réseaux distribués à travers le monde. Il simplifie la gestion des infrastructures réseau tout en garantissant des performances et une sécurité optimales, ce qui en fait une option précieuse pour les entreprises cherchant à moderniser leurs infrastructures réseau.
De mon côté, l’aventure IT a commencé en décembre 1995 avec mon tout premier ordinateur : un 486 SX-33 développé par Intel. Je ne saurais me rappeler de sa quantité de mémoire vive, mais je pense que je pouvais les compter sur les doigts d’une seule main 🤣.
Plus sérieusement, que ce passe-t-il si une application métier, toujours fonctionnelle et devant perdurer, doit être migrée au plus vite pour une raison X ?
Microsoft a peut-être une réponse grâce au le service Azure Migrate :
Azure Migrate offre un service simplifié de migration, de modernisation et d’optimisation pour Azure. Toutes les étapes de pré-migration telles que la détection, les évaluations et le dimensionnement des ressources locales sont incluses pour l’infrastructure, les données et les applications. L’infrastructure extensible d’Azure Migrate permet d’intégrer des outils tiers, ce qui augmente l’étendue des cas d’utilisation pris en charge.
Pour vous faire une meilleure idée d’Azure Migrate, un atelier exercice dédié à la migration vers Azure conçu par Microsoft avait déjà été détaillé sur ce blog juste ici.
Comme le montre le schéma ci-dessous, l’objectif de cet exercice est de migrer plusieurs serveurs virtuels gérés sous un serveur Hyper-V vers le Cloud Azure :
Qu’est-ce que Disk2vhd ?
Il s’agit d’un petit utilitaire très pratique développé par Mark Russinovich et disponible dans la suite Sysinternals :
Disk2vhd est un utilitaire qui crée des versions VHD (Virtual Hard Disk – Microsoft’s Virtual Machine disk format) de disques physiques à utiliser dans Microsoft Virtual PC ou Microsoft Hyper-V virtual machines (VMs). La différence entre Disk2vhd et d’autres outils physiques à virtuels est que vous pouvez exécuter Disk2vhd sur un système en ligne.
Disk2vhd utilise la capacité d’instantané de volume de Windows, introduite dans Windows XP, pour créer des instantanés cohérents à un instant donné des volumes que vous souhaitez inclure dans une conversion. Vous pouvez même demander à Disk2vhd de créer les VHD sur des volumes locaux, même ceux en cours de conversion (bien que les performances soient meilleures lorsque le VHD se trouve sur un disque différent de ceux en cours de conversion).
Au travers de ce nouvel article, je souhaitais tester avec vous la copie de plusieurs serveurs physiques fonctionnant sous d’anciens OS afin de tester un portage rapide et simple vers Azure :
Windows XP Professional
Windows 7 Professional x64
Windows 10 Enterprise x64
Windows Server 2008 R2 x64
Windows Server 2012 R2 x64
Windows Server 2016 x64
Pour cela, cet article repose sur la méthode de préparation d’un fichier VHD proposée par Microsoft et exposée juste ici, dont les principales commandes de préparation sont disponibles sur mon GitHub.
Pour réaliser cet exercice de migration individuelle, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
N’ayant pas d’anciens serveurs physiques à disposition, j’ai choisi de les simuler grâce à un environnement virtualisé Hyper-V recréé sous Azure.
Il est en effet possible dans Azure d’imbriquer de la virtualisation. Cela demande malgré tout quelques exigences, comme le SKU de la machine virtuelle Hyper-V, mais aussi sa génération.
Etape I – Préparation de la machine virtuelle hôte (Hyper-V) :
Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :
Cliquez-ici pour créer votre machine virtuelle hôte (Hyper-V) :
Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :
Choisissez une taille de machine virtuelle présent dans la famille Dsv3, puis cliquez sur Suivant :
Rajoutez un second disque pour stocker la ou les futures machines virtuelles invitées :
Conservez les options par défaut, puis cliquez sur OK :
Cliquez ensuite sur Suivant :
Retirez l’adresse IP publique pour des questions de sécurité, puis lancez la validation Azure :
Une fois la validation réussie, lancez la création des ressources Azure :
Quelques minutes plus tard, cliquez-ici pour voir votre machine virtuelle hôte (Hyper-V) :
Ensuite, cliquez-ici pour déployer le service Azure Bastion :
Attendez quelques minutes la fin du déploiement d’Azure Bastion, indispensable pour continuer les prochaines opérations :
Peu après, constatez le déploiement réussi d’Azure Bastion, puis renseignez les identifiants renseignés lors de la création de votre VM hôte (Hyper-V) :
Une fois connecté sur votre machine virtuelle hôte (Hyper-V), ouvrez Windows PowerShell :
Exécutez la commande suivante pour installer les deux rôles suivants :
Ouvrez le Gestionnaire de disques depuis le menu démarrer afin de configurer le disque de données ajouté sur votre VM hôte (Hyper-V) :
Dès l’ouverture du Gestionnaire de disques, cliquez sur OK pour démarrer l’initialisation du disque de données :
Sur celui-ci, créez un nouveau volume :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Terminer :
L’environnement Hyper-V est maintenant en place. Nous allons maintenant pouvoir créer ensemble une ou plusieurs machines virtuelles invitées.
Etape II – Création de la machine virtuelle invitée :
Pour cela, il est nécessaire de récupérer l’image au format ISO afin de créer la machine virtuelle invitée, puis d’y installer l’OS. Pour ma part, je suis passé par mon abonnement Visual Studio :
Stockez le fichier ISO sur le disque F de votre VM hôte (Hyper-V) :
Depuis votre VM hôte (Hyper-V), ouvrez votre console Hyper-V Manager :
Cliquez-ici pour créer votre machine virtuelle invitée :
Cliquez sur Suivant :
Modifier les informations suivantes pour pointer vers le nouveau lecteur créé sur la VM hôte (Hyper-V), puis cliquez sur Suivant :
Choisissez Génération 1 :
Modifier la taille de la mémoire vive allouée à la VM invitée, puis cliquez sur Suivant :
Utilisez le switch créé précédemment, puis cliquez sur Suivant :
Cliquez sur Suivant :
Utilisez le fichier ISO téléchargé précédemment, puis cliquez sur Suivant :
Cliquez sur Terminer pour finaliser la création de votre machine virtuelle invitée :
Une fois la machine virtuelle invitée créée, modifiez sa configuration comme ceci :
Modifiez le nombre de processeurs virtuels afin d’accélérer l’installation de Windows, puis cliquez sur OK :
Répétez les mêmes opérations pour les autres OS dont vous souhaitez tester la migration vers Azure :
Double-cliquez sur votre machine virtuelle invitée :
Cliquez-ici pour lancer le démarrage de la VM invitée :
Choisissez les informations de langue qui vous correspondent, puis cliquez sur Suivant :
Lancez l’installation de Windows :
Attendez que le démarrage de l’installation se lance, puis cliquez-ici pour ne pas renseigner de clef de licence Windows :
Choisissez une version Desktop de Windows, puis cliquez sur Suivant :
Acceptez les termes et conditions de Microsoft, puis cliquez sur Suivant :
Sélectionnez l’installation personnalisée de Windows :
Validez l’installation sur le seul disque disponible, puis cliquez sur Suivant :
Attendez maintenant que l’installation de Windows commence :
Lancez le redémarrage de la machine virtuelle invitée :
Donnez à nom si nécessaire à votre compte local Windows et un mot de passe :
La machine virtuelle invitée avec l’ancien OS Windows est maintenant en place. Comme pour une machine physique, nous allons maintenant générer un fichier VHD afin de pouvoir préparer l’OS à être remonté sur Azure.
Avant cela, quelques modifications sont nécessaires.
Etape III – Génération du fichier VHD :
Sur votre VM hôte (Hyper-V), créez un nouveau dossier contenant une ou plusieurs versions de l’outil Disk2vhd selon l’ancienneté de l’OS concerné :
Créez un second dossier dédié au VHD généré par l’outil Disk2vhd, puis partagez ce dossier sur le réseau :
Depuis la machine virtuelle invitée, ouvrez l’application Disk2vhd depuis le premier partage, puis sauvegardez votre fichier VHD sur le second partage :
Le traitement VSC peut prendre entre 5 minutes et 2 heures :
Le message de succès apparaît alors à la fin du traitement :
Effectuez ces mêmes opérations de génération du fichier VHD pour chacun des OS comme ceci :
Fermez la session utilisateur de votre machine virtuelle invitée :
Eteignez également votre machine virtuelle invitée :
Effectuez ces opérations d’arrêt pour chacune des machines virtuelles invitées :
Les machines virtuelles de départ sont maintenant toutes éteintes. Avant de pouvoir transférer le fichier VHD vers Azure, il est nécessaire d’effectuer plusieurs opérations au niveau de l’OS, mais également du fichier VHD.
Etape IV – Préparation du fichier VHD :
Pour cela, nous allons recréer de nouvelles machines virtuelles identiques, dans lesquelles nous allons passer plusieurs commandes PowerShell.
Toujours sur Hyper-V Manager, cliquez-ici pour créer une nouvelle machine virtuelle invitée :
Cliquez sur Suivant :
Modifier les informations suivantes, puis cliquez sur Suivant :
Choisissez Génération 1 :
Modifier la taille de la mémoire vive allouée à la VM invitée, puis cliquez sur Suivant :
Utilisez le même switch que précédemment, puis cliquez sur Suivant :
Rattachez le nouveau disque VHD généré via Disk2vhd, puis cliquez sur Suivant :
Cliquez sur Terminer pour finaliser la création de votre machine virtuelle invitée :
Une fois la machine virtuelle invitée créée, modifiez le nombre de processeurs virtuels, puis cliquez sur OK :
Répétez les mêmes opérations pour les autres OS, puis double-cliquez sur une nouvelle machine virtuelle invitée :
Cliquez-ici pour lancer le démarrage de la VM invitée :
Depuis le menu Démarrer, recherchez Windows PowerShell ISE en mode administrateur :
Confirmez le risque sécuritaire en cliquant sur Oui :
Ouvrez le fichier de script suivant, disponible sur mon GitHub :
Lancez la commande System File Checker (SFC) afin de vérifier les fichiers systèmes Windows :
sfc.exe /scannow
Quelques minutes plus tard, SFC vous confirme le succès du contrôle :
Lancez la commande netsh afin de réinitialiser les paramètre proxy :
netsh.exe winhttp reset proxy
Ouvrez via CMD en mode administrateur afin de lancez l’utilitaire Diskpart :
Retournez sur le groupe de ressources Azure créé précédemment, constatez la présence d’un disque managé, puis cliquez dessus :
Cliquez ici pour créer la machine virtuelle :
Renseignez les informations de base :
Choisissez la taille de votre VM, puis cliquez sur Suivant :
Sur l’onglet Réseau, reprenez le même réseau virtuel que celui utilisé pour votre machine virtuelle Hyper-V, puis lancez la validation Azure :
Une fois la validation Azure passée, lancez la création des ressources :
Attendez quelques minutes le succès de la création de votre VM, puis cliquez ici :
Attendez quelques minutes le démarrage complet de votre VM :
Vérifiez le bon démarrage de votre VM en actualisant si besoin plusieurs fois le screenshot suivant :
Constatez la présence de l’avertissement Azure suivant :
Renseignez les identifiants renseignés lors de la création de votre VM invitée :
Constatez la bonne ouverture de session Windows :
Une fois la session Windows ouverte, installez l’agent pour les machines virtuelles Azure disponible sur cette page GitHub :
Exécutez le fichier MSI d’installation depuis une session PowerShell avec les droits administrateurs :
Cliquez sur Suivant :
Acceptez les termes et conditions, puis cliquez sur Suivant :
Attendez quelques minutes la fin de l’installation de l’agent :
Cliquez sur Terminer :
Quelques minutes plus tard, constatez la disparition de l’alerte Azure sur votre VM :
Vérifiez la bonne relation entre le management Azure et votre VM via le menu suivant :
La commande suivante doit vous retourner la configuration IP renseignée sur votre VM :
Effectuez un test d’arrêt de votre machine virtuelle :
Confirmez votre action en cliquant sur Oui :
Effectuez un test de démarrage de votre machine virtuelle :
Vérifiez le succès des 2 opérations via les notifications Azure :
Cliquez-ici pour rouvrir la session Windows ouverte précédemment via Azure Bastion :
Effectuez les mêmes opérations pour les autres anciens OS à tester :
Conclusion
Par cette démonstration, un portage rapide et en urgence de certaines anciennes versions Windows, client ou serveur, est parfaitement possible. Quelques manipulations de préparation sont nécessaires, mais ces dernières sont fonctionnelles pour les OS suivants :
La vérification faciale est une solution qui existe chez plusieurs éditeurs et qui compare des visages tout en respectant la vie privée. Elle aide les entreprises à vérifier l’identité des personnes de manière sécurisée et efficace. Par exemple, une banque peut l’utiliser pour s’assurer que la personne ouvrant un compte est bien celle qu’elle prétend déclarer. Mais peut-on combiner cette fonctionnalisé avec Entra Verified ID ?
La réponse est oui :
La correspondance faciale est alimentée par Azure AI services. En partageant uniquement les résultats de correspondance et non les données d’identité sensibles, Vérification faciale protège la confidentialité des utilisateurs tout en permettant aux organisations de s’assurer que la personne est bien qui elle prétend être.
Combinée à Entra Verified ID, Face check permettra alors une expérience plus rapide dans le partage d’une identité :
La documentation Microsoft explique d’ailleurs très bien le concept et l’intégration dans une application, mais également une FAQ disponible juste ici.
Vérification faciale vs Face ID ?
Face ID est une offre d’option de sécurité biométrique basée sur la vision pour les produits Apple pour déverrouiller un appareil en vue d’accéder à une application mobile. Vérification faciale est une fonctionnalité de Vérification d’identité Microsoft Entra qui utilise également la technologie IA basée sur la vision, mais compare l’utilisateur au justificatif Vérification d’identité présenté… Les deux mécanismes requièrent que l’utilisateur soit face à une caméra dans le processus, mais fonctionne de différentes manières.
Les données ne sont ni stockées ni conservées par aucun des services Microsoft Authenticator, Vérification d’identité ou Azure AI. En outre, les images ne sont pas non plus partagées avec l’application de vérificateur. L’application de vérificateur obtient uniquement le score de confiance en retour.
Dans un système basé sur l’IA, le score de confiance est la réponse de pourcentage de probabilité pour une requête au système. Pour ce scénario, le score de confiance est la probabilité que la photo du justificatif de l’utilisateur Vérification d’identité corresponde à la capture de l’utilisateur sur l’appareil mobile.
Pour cette démonstration de Face Check, choisissez la configuration rapide :
Si votre tenant contient plusieurs domaines personnalisés, choisissez celui que vous souhaitez mettre en place pour ce service d’identité vérifiée, puis cliquez sur Sauvegarder :
La configuration sur votre tenant se met alors en place, Entra vous invite à patienter environ 1 minute :
Une fois la configuration automatique terminée, la notification suivante apparaît :
Afin de configurer Face Check, nous avons besoin de créer un groupe de ressources Azure. Rendez-vous sur le portail Azure, puis cliquez ici :
Cliquez ici pour créer un nouveau groupe de ressources Azure :
Renseignez les informations de base pour ce groupe de ressources, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création du groupe de ressources :
Retournez sur le portail d’Entra ID afin d’activer l’addon Face Check :
Prenez le temps de lire les conditions tarifaires de Face Check, dont le prix sera appliqué à partir du 12 août 2024 :
Renseignez vos informations Azure concernant le groupe de ressources créé précédemment, puis cliquez sur Valider :
Une fois la validation Azure réussie, cliquez sur Activer :
La notification Entra suivante apparaît alors :
La configuration du service Verified ID destiné à Face Check est maintenant terminée. Nous allons avoir maintenant besoin de créer un utilisateur de test.
Etape II – Création d’un utilisateur de test :
Toujours sur le portail Entra, créez un nouvel utilisateur Entra ID :
Renseignez les informations de base de cet utilisateur, puis cliquez sur Suivant :
Renseignez également une adresse de messagerie :
Renseignez également un pays de localisation, puis lancez la validation Entra :
Lancez la création de votre utilisateur de test :
La notification Entra suivante apparaît alors :
Une fois l’utilisateur de test créé, ajoutez une photo de vous sur le profil de ce dernier :
Ouvrez le navigateur de votre choix en mode privé :
Ouvrez la page Mon compte de Microsoft, puis authentifiez-vous avec votre utilisateur de test :
A votre première connexion, personnalisez son mot de passe :
Cliquez ici afin d’obtenir une identité vérifiée :
Microsoft génère alors un QR code pour générer et stocker une identité vérifiée dans l’application Microsoft Authenticator de votre smartphone :
Sur votre smartphone, ouvrez Microsoft Authenticator, puis cliquez ici pour scanner le QR Code :
Confirmez l’ajout de votre identité vérifiée en cliquant sur Ajouter :
Sur votre smartphone, un clic sur votre identité vérifiée affiche les informations stockées dans cette dernière, dont votre photo :
Une première activité correspondante à la réception de cette identité vérifiée est visible juste ici :
Cette nouvelle identité vérifiée rejoint les autres déjà en place dans Microsoft Authenticator :
La prochaine étape sera de créer une application de test pour vérifier le bon fonctionnement de Face Check pour notre nouvel utilisateur.
Sur la portail Entra, copiez votre DID afin de la configurer plus tard dans l’application :
Rendez-vous sur la page GitHub suivante, puis déployez l’application sur votre tenant par ce lien :
Renseignez les 2 champs suivants, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création des ressources :
Attendez environ 5 minutes la fin du déploiement Azure, qui devrait peut-être présenter l’erreur non bloquante suivante, puis cliquez ici pour continuer :
Vérifiez que l’application déployée dispose bien de sa propre identité :
Copiez le script ci-dessous dans un éditeur de texte en prenant soin de renseigner les deux informations suivantes propres à votre déploiement :
Toujours sur le portail Azure, ouvrez par ce bouton Azure Cloud Shell :
Exécutez le script précédemment modifié, puis attendez le résultat suivant :
Retournez sur le portail Entra, puis recherchez votre application de test :
Vérifiez la présence de la permission suivante nécessaire à la gestion des identités vérifiées :
Tout est maintenant en place, il nous reste qu’à tester notre application.
Etape IV – Test application via Face Check :
Retournez sur le portail Azure afin de copier l’URL web de votre application de test :
Ouvrez un nouvel onglet vers cette URL de test, puis cliquez ici :
Votre application génère alors un QR code à scanner :
Depuis votre smartphone, ouvrez Microsoft Authenticator afin de scanner le QR code :
Confirmez votre action de partage de votre identité vérifiée avec votre application de test en cliquant sur Suivant :
Cliquez sur Suivant pour démarrer la vérification avec votre visage :
Suivez les indications de l’application afin de valider l’opération Face Check :
Le message suivant vous confirme le succès de la vérification Face Check :
Cliquez à nouveau sur Partager pour confirmer l’action :
Votre application web vous confirme bien le succès du partage et le score retourné par la fonction Face Check :
Une nouvelle activité Woordgrove Helpdesk s’ajoute sur votre identité vérifiée :
Quelques informations supplémentaires sur ce partage sont disponibles :
Conclusion
L’identité décentralisée promet de redonner le contrôle des données aux utilisateurs, en assurant une gestion sécurisée et privée des identités numériques :
Contrôle et Sécurité : Les utilisateurs gèrent leurs propres identifiants et données, réduisant les risques de violations et d’usurpation d’identité.
Confidentialité : Les données personnelles sont partagées uniquement avec consentement explicite, sans intermédiaires centralisés.
Interopérabilité : Utilisation de normes ouvertes (comme les DID et justificatifs vérifiables), permettant une intégration fluide avec divers systèmes.
Fiabilité : Justificatifs émis par des entités de confiance, validés de manière sécurisée et infalsifiable.
Pour continuer sur le sujet des identités vérifiées disponibles sur Microsoft Entra (dont un premier article est disponible juste ici), je vous propose dans ce second de suivre un tutoriel élaboré par Microsoft qui est assez intéressant : Il s’agit de créer votre propre système d’identité vérifié personnalisé.
Apprenez à émettre et à vérifier des informations d’identification à l’aide du même locataire Microsoft Entra… Dans ce tutoriel, vous passez en revue les étapes nécessaires à la présentation et à la vérification de votre premier justificatif vérifiable : une carte d’expert en justificatif vérifié.
Microsoft nous montre au travers de ce schéma le fonctionnement d’une application tierce et des interactions avec le service Entra Verified ID de notre tenant :
Comme toujours, je vous propose de suivre ensemble ce pas à pas dans le but de tester ce tutoriel :
Pour cette démonstration, choisissez la Configuration rapide :
Si votre tenant contient plusieurs domaines personnalisés, choisissez celui que vous souhaitez mettre en place pour votre service d’identité vérifiée, puis cliquez sur Sauvegarder :
La configuration sur votre tenant se met alors en place, Microsoft Entra vous invite à patienter environ 1 minute :
Une fois la configuration automatique terminée, la notification suivante apparaît :
Téléchargez puis installez la version 6.0 de .NET, disponible via ce lien officiel :
Afin de publier votre application sur une URL internet, téléchargez ngrok, puis inscrivez-vous chez eux avec un compte gratuit :
Sur leur site, téléchargez l’installateur de ngrok :
Copiez la commande suivante affichée sous l’installateur pour configurer votre ngrok :
Depuis le dossier de téléchargement, ouvrez une invite de commande, puis lancez celle-ci afin de préparer votre configuration ngrok :
Le poste local et le tenant Microsoft sont maintenant correctement configurés, la prochaine étape consiste à créer une justificatif vérifiable personnalisé (pouvant générer des identités vérifiées) sur votre tenant.
Etape III – Création d’un justificatif vérifiable personnalisé :
Depuis le portail Microsoft Entra, cliquez ici pour ajouter un Justificatif vérifiable personnalisé :
Sélectionnez Informations d’identification personnalisée, puis cliquez sur Suivant :
Nommez votre Justificatif vérifiable comme ceci :
Dans la première section destinée aux propriétés d’affichage, remplacez le code existant par celui-ci :
{
"locale": "en-US",
"card": {
"title": "Verified Credential Expert",
"issuedBy": "Microsoft",
"backgroundColor": "#000000",
"textColor": "#ffffff",
"logo": {
"uri": "https://didcustomerplayground.blob.core.windows.net/public/VerifiedCredentialExpert_icon.png",
"description": "Verified Credential Expert Logo"
},
"description": "Use your verified credential to prove to anyone that you know all about verifiable credentials."
},
"consent": {
"title": "Do you want to get your Verified Credential?",
"instructions": "Sign in with your account to get your card."
},
"claims": [
{
"claim": "vc.credentialSubject.firstName",
"label": "First name",
"type": "String"
},
{
"claim": "vc.credentialSubject.lastName",
"label": "Last name",
"type": "String"
}
]
}
Dans la seconde section destinée à la Définition de règles, remplacez le code existant par celui-ci, puis cliquez sur Créer :
Une fois la configuration terminée, une notification Microsoft Entra apparaît :
Le Justificatif vérifiable est maintenant créé. Ses informations de base sont disponibles sur cette page :
Copiez l’URL du manifeste afin de la configurer plus tard dans votre application :
Copiez votre DID afin de la configurer plus tard dans votre application :
Copiez votre tenant ID afin de la configurer plus tard dans votre application :
L’environnement côté Microsoft Entra est maintenant en place. Pour que notre application fonctionne, il est nécessaire renseigner les informations de connexion précédemment copiées.
Etape IV – Création de l’application :
Téléchargez l’archive ZIP de l’application de test disponible sur ce lien GitHub :
Une fois l’archive ZIP téléchargée, débloquez cette dernière par un clic droit sur celle-ci, puis cliquez sur OK :
Lancez l’extraction de l’archive dans le répertoire de votre choix :
Retournez sur le portail de Microsoft Entra ID afin de créer une nouvelle inscription d’application :
Nommez votre application comme ceci, configurez la pour fonctionner uniquement sur votre tenant, puis cliquez sur Enregistrer :
Cliquez sur le menu suivant afin d’ajouter des permissions à votre application :
Ajoutez la permission API suivante utilisée par votre organisation :
Sélectionnez cette permission API, puis cliquez sur Ajouter :
Ajoutez un consentement global de l’administrateur pour votre tenant :
Confirmez votre action en cliquant sur Oui :
Copiez l’ID de votre d’application afin de la configurer plus tard dans votre application :
Cliquez sur le menu suivant afin de créer un secret pour votre application :
Nommez votre secret, puis cliquez sur Ajouter :
Une fois créé, copiez la valeur de votre secret afin de la configurer plus tard dans votre application :
Ouvrez votre éditeur de code local :
Ouvrez le dossier correspondant au dossier contenant l’extraction de l’archive ZIP :
Confirmez votre confiance dans ce répertoire :
Dans le dossier 1.asp-net-core-api-idtokenhint, ouvrez le fichier appsettings.json, puis mettez à jour les propriétés suivantes avec les informations que vous avez copiées lors des étapes précédentes :
Manifeste des informations d’identification : l’URL de votre manifeste
ID de locataire : votre ID de votre tenant
ID client : votre ID de votre inscription d’application
Secret client : votre secret client de votre inscription d’application
DidAuthority : votre identificateur décentralisé
Retirez les 2 commentaires présents dans ce même fichier :
Sauvegardez le fichier appsettings.json:
Ouvrez une première fenêtre Windows Terminal, positionnez-vous dans le dossier contenant l’extraction de l’archive ZIP, puis saisissez la commande suivante :
Une fois la compilation terminée, démarrez votre application via la commande suivante :
dotnet run
Une fois l’application démarrée, ouvrez une seconde fenêtre Windows Terminal, puis saisissez la commande suivante afin d’exposer votre application locale au travers de ngrok :
.\ngrok http 5000
Une fois votre application exposée, copiez l’URL générée par ngrok :
Tout l’environnement de test est maintenant en place, il nous reste qu’à tester le fonctionnement du service personnalisé d’identité vérifiée.
Etape V – Test d’émission d’une identité vérifiée :
Ouvrez un navigateur privé, collez l’URL ngrok précédemment copiée, puis confirmez la navigation en cliquant ici :
Votre application doit ressembler à ceci :
Cliquez ici afin d’obtenir une identité vérifiée :
Confirmez votre action en cliquant ici :
L’application génère alors un QR code pour stocker une identité vérifiée dans l’application Microsoft Authenticator de votre smartphone :
Sur votre smartphone, ouvrez Microsoft Authenticator, puis cliquez ici pour scanner le QR Code :
Saisissez le code de vérification visible sous le QR code de votre application, puis cliquez sur Suivant :
Confirmez l’ajout de votre identité vérifiée en cliquant sur Ajouter :
L’application confirme bien le stockage sur l’application Microsoft Authenticator de votre smartphone :
Sur votre smartphone, un clic sur votre identité vérifiée affiche les informations stockées dans cette dernière :
Une première activité correspondante à la réception de cette identité vérifiée est visible juste ici :
Cette nouvelle identité vérifiée rejoint les autres déjà en place dans Microsoft Authenticator :
La prochaine étape consiste à vérifier sa validité au travers de la seconde fonctionnalité de votre application.
Etape VI – Test de la vérification d’une identité vérifiée :
Retournez sur page principale de votre application, puis cliquez ici :
Cliquez ici pour confirmer votre action :
La vérification d’une identité vérifiée passe par le scan d’un QR code :
Ouvrez Microsoft Authenticator sur votre smartphone, puis utilisez la fonction suivante pour scanner le QR code généré par votre application :
Votre application vous indique que la vérification de l’identité vérifiée a bien fonctionné :
Conclusion
L’identité décentralisée promet de redonner le contrôle des données aux utilisateurs, en assurant une gestion sécurisée et privée des identités numériques :
Contrôle et Sécurité : Les utilisateurs gèrent leurs propres identifiants et données, réduisant les risques de violations et d’usurpation d’identité.
Confidentialité : Les données personnelles sont partagées uniquement avec consentement explicite, sans intermédiaires centralisés.
Interopérabilité : Utilisation de normes ouvertes (comme les DID et justificatifs vérifiables), permettant une intégration fluide avec divers systèmes.
Fiabilité : Justificatifs émis par des entités de confiance, validés de manière sécurisée et infalsifiable.
Vous commencez enfin à maîtriser le service Autopilot de Microsoft et vous vous en servez déjà pour déployer vos postes ? Cela tombe très bien ! Microsoft vient justement de sortir il y a quelques mois la Préparation de l’appareil Windows Autopilot. Peut-on parler de cette nouvelle fonctionnalité comme d’un Autopilot en version 2 ? Oui et non, mais cela va encore plus démocratiser Intune auprès des services IT.
Quelles sont les différences entre Autopilot v1 et Autopilot v2 ?
Le fait de les appeler v1 et v2 un choix personnel afin de gagner en clarté, ce qui ne veut pas dire que la seconde est un remplacement complet de la première. Voici d’ailleurs une comparaison v1/v2 rédigée par Microsoft :
Fonctionnalité
Windows Autopilot préparation de l’appareil (Autopilot v2)
Windows Autopilot (Autopilot v1)
Fonctionnalités
Prise en charge des environnements Government Community Cloud High (GCCH) et ministère de la Défense (DoD). Expérience d’approvisionnement plus rapide et plus cohérente. Informations de surveillance et de résolution des problèmes en quasi-temps réel.
Prise en charge de plusieurs types d’appareils (HoloLens, Salle de réunion Teams). De nombreuses options de personnalisation pour l’expérience d’approvisionnement.
Rejoindre Microsoft Entra. Jointure hybride Microsoft Entra.
Inscription de l’appareil requise ?
Non.
Oui.
Que doivent configurer les administrateurs ?
Stratégie de préparation des appareils Windows Autopilot. Groupe de sécurité de l’appareil avec le client d’approvisionnement Intune en tant que propriétaire.
Profil de déploiement Windows Autopilot. Page d’état d’inscription (ESP).
Quelles configurations peuvent être fournies lors de l’approvisionnement ?
Basé sur l’appareil uniquement pendant l’expérience out-of-box (OOBE).Jusqu’à 10 applications essentielles (métier), Win32, Microsoft Store, Microsoft 365). Jusqu’à 10 scripts PowerShell essentiels.
Basé sur l’appareil pendant l’ESP de l’appareil. Basé sur l’utilisateur pendant l’ESP utilisateur. N’importe quel nombre d’applications.
Résolution des problèmes de création de rapports &
Rapport de déploiement de la préparation de l’appareil Windows Autopilot : Affiche tous les déploiements de préparation des appareils Windows Autopilot. Davantage de données disponibles. Quasiment en temps réel.
Rapport de déploiement Windows Autopilot : Affiche uniquement les appareils inscrits sur Windows Autopilot. Pas en temps réel.
Prend en charge les applications métier et Win32 dans le même déploiement ?
Oui.
Non.
Versions prises en charge de Windows
Windows 11, version 23H2 avec KB5035942 ou version ultérieure. Windows 11, version 22H2 avec KB5035942 ou version ultérieure.
Comme le rappel l’excellent billet écrit sur le site de Synapsys, Microsoft a souhaité faire évoluer son service Autopilot créé en 2017 afin de pouvoir supporter un plus grand nombre d’appareils. Cela va permettre de gérer le provisionnement des Cloud PC Windows 365 ou pour des clients dont le tenant est sur une instance Gov du Cloud Microsoft :
Windows Autopilot Device Preparation vise à simplifier encore plus le déploiement des périphériques, en optimisant le temps global de préparation de celui-ci et en améliorant notamment la résolution des problématiques qui peuvent survenir pendant le déploiement ainsi que le reporting.
La grosse nouveauté comparée à Windows Autopilot est qu’il n’est plus nécessaire d’importer le hash matériel pour pouvoir bénéficier du service. Autre nouveauté, le profil de déploiement sera à déployer sur un profil utilisateur et non machine.
Ai-je besoin de licences spécifiques pour Autopilot v2 ?
Comme il est rappelé dans la documentation Microsoft, Autopilot v2 a besoin des mêmes licences que pour Autopilot v1. Voici une liste non exhaustive de licences ou combinaison de licences possibles :
Licence Microsoft 365 Business Premium
Licence Microsoft 365 F1 ou F3
Licence Microsoft 365 Academic A1, A3 ou A5
Licence Microsoft 365 Entreprise E3 ou E5
Licence Enterprise Mobility + Security E3 ou E5
Licence Intune pour l’éducation
Licence ID Microsoft Entra P1 ou P2 + Licence Microsoft Intune
Afin de se faire une meilleure idée sur Autopilot v2, je vous propose un petit exercice à réaliser sur une souscription Azure.
Dans cet exercice, nous allons effectuer les étapes suivantes :
Microsoft a même mis à disposition un très bon tutoriel pour Autopilot v2 juste ici :
Etape 0 – Rappel des prérequis :
Afin de tester la fonctionnalité d’intégration proposée via Autopilot v2, nous allons avoir besoin de :
Un tenant Microsoft
Une souscription Azure valide
Une ou des licences contenant Intune et Azure AD Premium P1
Une Image OS de Windows 11, version 22H2 ou 23H2 générée après avril 2024 ou avec le KB5035942
Etape I – Configurer l’inscription automatique Windows à Intune :
Commençons par la configuration sur Entra ID.
Pour que la préparation des appareils Windows Autopilot (Autopilot v2) fonctionne, les appareils doivent être en mesure de s’inscrire automatiquement dans Intune. L’inscription automatique des appareils dans Intune peut être configurée automatiquement dans le portail Azure
La méthode d’inscription à Intune avec Autopilot v2 ne diffère pas de la première : il est nécessaire de configurer une inscription automatique à Intune depuis le portail Entra ID.
Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis cliquez sur cela :
Définissez le périmètre de l’inscription automatique MDM à Intune, puis cliquez sur Sauvegarder :
Restons sur le portail d’Entra ID afin d’autoriser les utilisateurs à joindre des machines à Intune.
Etape II – Autoriser les utilisateurs à joindre des appareils :
Pour rappel, il existe plusieurs types de jointures possibles à Entra ID, dont voici un lien vers un précédent article. Avec Autopilot v2, les utilisateurs ont toujours besoin d’être autorisé à joindre des postes à Entra ID.
Pour que la préparation des appareils Windows Autopilot fonctionne, les utilisateurs doivent être autorisés à joindre des appareils à l’ID Microsoft Entra.
Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis activez cette option :
Continuons avec la création d’un premier groupe Entra ID dédié aux postes Intune.
Etape III – Créer un groupe d’appareils Entra ID :
La préparation des appareils Windows Autopilot utilise un groupe d’appareils dans le cadre de la stratégie de préparation des appareils Windows Autopilot. Le groupe d’appareils spécifié dans la stratégie de préparation des appareils Windows Autopilot est le groupe d’appareils dans lequel les appareils sont ajoutés automatiquement pendant le déploiement de la préparation de l’appareil Windows Autopilot
Pour cela, rendez-vous dans le menu suivant d’Entra ID, puis créer un groupe dédié aux appareils automatiquement inscrits par Autopilot v2 :
Ajoutez le propriétaire Intune Provisioning Client ou avec son principal de service dont l’ID est le suivant : f1346770-5b25-470b-88bd-d5744ab7952c :
N’ajoutez aucun membre manuellement, puis cliquez sur Créer :
Continuons avec la création d’un second groupe Entra ID dédié aux utilisateurs Intune.
Etape IV – Créer un groupe d’utilisateurs Entra ID :
La préparation de l’appareil Windows Autopilot utilise un groupe d’utilisateurs dans le cadre de la stratégie de préparation des appareils Windows Autopilot. Les utilisateurs membres du groupe d’utilisateurs spécifié dans la stratégie de préparation de l’appareil Windows Autopilot sont les utilisateurs qui reçoivent le déploiement de la préparation de l’appareil Windows Autopilot.
Pour cela, restez sur le même menu qui précédemment d’Entra ID, puis créer un second groupe cette fois dédié aux utilisateurs concernés par le processus Autopilot v2 :
Ajoutez des membres manuellement ou dynamiquement en correspondance avec vos utilisateurs Autopilot v2, puis cliquez sur Créer :
Continuons avec la configuration de postes sous Intune.
Etape V – Affectation de la configuration Intune :
Pendant l’expérience OOBE (out-of-box experience) avant que l’utilisateur final ne soit connecté pour la première fois, la préparation de l’appareil Windows Autopilot permet de déployer jusqu’à :
10 applications managées
10 scripts PowerShell
Pour que les applications s’installent et que les scripts PowerShell fonctionnent correctement, ils doivent être affectés au groupe d’appareils créé pour la préparation des appareils Windows Autopilot.
J’ai souhaité dans mon cas créer différents scénarios d’installation d’applications :
Applications intégrées au processus Autopilot v2 :
Microsoft Company Portal (Windows Store)
Global Secure Access (EXE)
Applications obligatoires pour les postes Intune :
Google Chrome (MSI)
Microsoft 365 Apps (Microsoft 365 Apps)
Applications disponibles pour les utilisateurs Intune :
Adobe Acrobat Reader DC (Windows Store)
Mozilla Firefox (Windows Store)
Notepad X (Windows Store)
Pour cela, rendez-vous dans le menu suivant d’Intune, puis rajoutez vos applications concernées :
J’ai également rajouté un script PowerShell, mais que je ne souhaite pas intégrer dans le processus Autopilot v2 car les applications installées ou les scripts PowerShell qui s’exécuteront systématiquement dans un contexte système.
Il ne nous reste maintenant qu’à créer la stratégie de préparation des appareils Windows Autopilot.
Etape VI – Création de la stratégie de préparation des appareils Windows Autopilot :
La stratégie Autopilot spécifie la façon dont l’appareil est configuré pendant l’installation de Windows et ce qui est affiché pendant l’expérience OOBE (out-of-box experience).
Pour cela, rendez-vous dans le menu suivant d’Intune, puis cliquez sur le menu suivant :
Cliquez sur Créer :
Cliquez sur Suivant :
Nommez votre profil, puis cliquez sur Suivant :
Ajoutez le groupe dédié aux postes Intune via Autopilot v2, puis cliquez sur Suivant :
Définissez les paramètres de configuration Autopilot v2 :
Personnalisez l’expérience OOBE :
Ajoutez les applications intégrées dans le processus Autopilot v2 :
Ajoutez si besoin les scripts intégrés dans le processus Autopilot v2, puis cliquez sur Suivant :
Modifiez les tags au besoin, puis cliquez sur Suivant :
Ajoutez le groupe dédié aux utilisateurs Intune via Autopilot v2, puis cliquez sur Suivant :
Cliquez sur Sauvegarder :
La configuration Autopilot v2 est maintenant terminée, il ne nous reste qu’à créer une machine virtuelle Hyper-V sur Azure pour ensuite créer des machines sous Windows 11.
Etape VII – Préparation de la machine virtuelle hôte Hyper-V :
Depuis le portail Azure, commencez par rechercher le service des machines virtuelles :
Cliquez ici pour créer votre machine virtuelle hôte (Hyper-V) :
Renseignez tous les champs, en prenant soin de bien sélectionner les valeurs suivantes :
Choisissez une taille de machine virtuelle présente dans la famille Dsv3, puis cliquez sur Suivant :
Rajoutez un second disque pour stocker la machine virtuelle Windows 11,créée plus tard dans notre machine virtuelle hôte (Hyper-V) :
Conservez les options par défaut, puis cliquez sur OK :
Cliquez ensuite sur Suivant :
Retirez l’adresse IP publique (pour des questions de sécurité), puis lancez la validation Azure :
Une fois la validation réussie, lancez la création des ressources Azure :
Quelques minutes plus tard, cliquez ici pour voir votre machine virtuelle Hyper-V :
Ensuite, cliquez-ici pour déployer le service Azure Bastion :
Attendez quelques minutes la fin du déploiement d’Azure Bastion, indispensable pour continuer les prochaines opérations :
Peu après, constatez le déploiement réussi d’Azure Bastion via la notification Azure suivante :
Renseignez les identifiants renseignés lors de la création de votre VM hôte (Hyper-V) :
Autorisez le fonctionnement du presse-papier pour Azure Bastion :
Une fois connecté sur votre machine virtuelle hôte (Hyper-V), ouvrez Windows PowerShell :
Exécutez la commande suivante pour installer les 2 rôles suivants :