Je suis sûr que certains d’entre vous ont déjà créé plusieurs dizaines de tenants Microsoft Entra, possiblement plus 💪. Mais certains d’autres n’ont peut-être jamais osé franchir le pas ! Rassurez-vous, rien de bien compliqué. En cette année 2024, je vous propose de repartir sur les basiques et de créer ensemble un nouveau tenant afin de comprendre les premiers paramètres appliqués par Microsoft.
Avant de commencer le petit exercice, reparcourons ensemble quelques notions essentielles.
Qu’est-ce qu’un tenant Microsoft Entra ?
C’est probablement une des premières questions à laquelle on tente de répondre quand on commence à s’intéresser au cloud de Microsoft. Inutile d’aller bien loin, Microsoft explique assez bien le concept :
Le locataire (tenant) Microsoft Entra est une limite de sécurité d’identité qui est sous le contrôle du service informatique de votre organization. Dans cette limite de sécurité, l’administration des objets (tels que les objets utilisateur) et la configuration des paramètres à l’échelle du locataire sont contrôlées par vos administrateurs informatiques.
A l’intérieur d’un tenant Microsoft Entra, on y retrouvera donc principalement :
un annuaire ou répertoire (= directory) contenant des identités humaines, machines ou applicatives
Des applications Microsoft comme la suite office 365
Des ressources comme des machines virtuelles sur Azure
Des applications tierces
Des configurations comme des droits, des polices ou mesures de sécurité
Cette vidéo est assez ancienne, mais elle explique assez bien le concept d’Azure Active Directory (Entra ID) et de ses différences avec Windows Server Active Directory :
Combien coûte un tenant Microsoft ?
Un tenant Microsoft en lui-même ne coûte rien, mais les services comme Office 365, les licences pour renforcer la sécurité de votre tenant, ou encore les ressource Azure déployées vont pour la plupart être payantes.
Quelle est la différence entre Microsoft Entra et Microsoft Entra ID ?
Microsoft Entra est une famille de plusieurs produits comprenant également Microsoft Entra ID. Le tableau suivant et disponible sur cette page montre certaines fonctionnalités disponible sur Microsoft Entra :
Ce portail complet est disponible à cette adresse :
Combien coûte Microsoft Entra ID ?
Le tableau ci-dessous et également disponible sur cette page Microsoft nous explique bien les différentes versions de Microsoft Entra ID :
La première colonne de gauche nous montre qu’il existe une version gratuite de Microsoft Entra ID comprenant des bases de sécurité suffisantes.
D’autres versions avec plus de fonctionnalités et des mesures de sécurité personnalisées sont disponibles sous forme de licences par utilisateur.
Afin de rentrer plus en détail dans le fonctionnement de Microsoft Entra, je vous propose de regarder l’excellente vidéo de Seyfallah Tagrerout :
Plusieurs méthodes de création d’un tenant Microsoft existent. Il est généralement possible de créer son propre nouveau tenant en partant d’une identité Cloud existante sans en perturber le fonctionnement.
Afin de vous faire une meilleure idée, je vous propose un petit exercice à ce sujet, et de voir certains éléments liés à votre création :
Pour réaliser mon exercice sur la création d’un nouveau tenant Microsoft, il vous faudra disposer de :
Un tenant Microsoft 🤣
La suite se passera directement par la création du nouveau tenant.
Etape I – Création du nouveau tenant :
Pour cela, rendez-vous sur la page de Microsoft Entra ID par ce lien, puis cliquez-ici pour lister les tenants vous étant accessibles :
Cliquez sur Créer pour démarrer la procédure :
Deux types de tenants sont possibles : B2C ou B2B (plus d’informations ici)
Choisissez le tenant B2B, puis cliquez sur Continuer :
Renseignez les 3 champs suivants puis cliquez sur Créer :
Réussissez le CAPTCHA, puis cliquez sur Soumettre :
La création de votre nouveau tenant Microsoft a commencé, attendez environ 5 minutes :
Environ 5 minutes plus tard, votre nouveau tenant Microsoft est maintenant prêt, cliquez-ici pour basculer sur celui-ci :
La bascule vers le nouveau tenant est également possible depuis le bouton de paramètre suivant :
Le nouveau tenant s’ouvre directement sur le portail Azure. Constatez la présence de ces 2 valeurs uniques qui définissent votre nouveau tenant :
Consultez les utilisateurs présents sur votre nouveau tenant par cette page.
A ce stade, le compte utilisateur du tenant initial devrait être le seul présent, cliquez sur son nom :
Prenez soin de vérifier l’origine de cette identité externe à votre nouveau tenant, puis cliquez-ici pour consulter ses rôles Entra ID :
Constatez la présence logique du rôle d’Administrateur Général, naturellement attribué au créateur du tenant :
Votre tenant fonctionne bien, mais est pour l’instant assez vide. Je vous propose donc de continuer en créant un premier utilisateur dans Entra ID.
Etape II – Création d’un nouvel utilisateur :
Créez votre premier utilisateur rattaché à votre nouveau tenant par le menu suivant :
Remplissez les champs obligatoires, puis cliquez sur Suivant :
Remplissez les champs que vous souhaitez, puis cliquez sur Suivant :
Cliquez ici pour lui un ajouter un rôle Entra ID :
Recherchez le rôle d’Administrateur général, puis cliquez sur Sélectionnez :
Lancez la validation de votre création :
Une fois la validation terminée, sauvegardez le mot de passe provisoire, puis lancez la création :
La notification suivante devrait apparaître :
Rafraichissez la page des utilisateurs Entra ID afin de voir votre création :
Ouvrez un navigateur privé, lancez la page web d’Entra ID, puis renseignez les identifiants de votre nouvel utilisateur :
A l’issue de cette première connexion, définissez un nouveau mot de passe à cet utilisateur :
Dans le but de supprimer l’utilisateur créateur du nouveau tenant dans ce dernier, retournez sur la page des utilisateurs, puis cliquez-ici :
Aucune inquiétude, votre utilisateur n’est pas supprimé sur votre tenant de départ.
Confirmez votre choix en cliquant sur OK :
Rafraichissez la page des utilisateurs Entra ID afin de voir uniquement votre nouveau compte :
Etape III – Création d’autres utilisateurs :
Vous pourriez créer ou inviter d’autres utilisateurs comme le montre les exemples d’identités visibles sur l’image ci-dessous :
Microsoft nous liste certaines identités sur cette page :
Voici un exemple de connexion d’un compte invité de type mail essayant de se connecter à un site SharePoint dont l’accès se fera via un code envoyé par email :
Intéressons-nous enfin à la sécurité de base d’un tenant Microsoft.
Etape IV – Paramètres de sécurité par défaut :
Depuis octobre 2019, les nouveaux tenants ont la sécurité par défaut d’activé. Microsoft le justifie par l’argument suivant :
Selon nos connaissances, plus de 99,9% de ces attaques liées à l’identité sont stoppées en utilisant l’authentification multifacteur et en bloquant l’authentification héritée. Notre but est de nous assurer que toutes les organisations ont activé au moins un niveau de sécurité de base, sans coût supplémentaire.
La sécurité par défaut est entièrement gérée par Microsoft. Elle fait sens dans le cadre de tenants dépourvus de licences Microsoft Entra ID payantes et agira sur les points suivants :
L’activation ou la désactivation de la sécurité par défaut est possible depuis l’écran suivant d’Entra ID :
Terminons cet exercice par un test de la sécurité par défaut d’activé d’Entra ID.
Etape V – Test des paramètres de sécurité par défaut :
Pour cela, connectez-vous avec un compte administrateur sur le portail Microsoft Entra ID depuis un navigateur privé :
Dans cet exemple, notre compte utilisateur est un administrateur et essaye d’accès à un ressource sensible.
Comme la MFA n’est pas encore configuré sur ce compte, nous sommes invités à y remédier en cliquant sur Suivant :
Afin de configurer Microsoft Authenticator, téléchargez l’application sur votre Smartphone, puis cliquez sur Suivant :
Cliquez sur Suivant :
Scannez le QR code depuis l’application installé sur votre Smartphone, puis cliquez sur suivant :
Saisissez sur votre Smartphone le nombre affiché à l’écran :
Une fois le nombre correctement saisi, cliquez sur Suivant :
Cliquez sur Terminer :
Cliquez sur Non :
Le portail de Microsoft Entra ID s’ouvre bien :
Refermer votre navigateur privé, puis réouvrez-le à nouveau.
Connectez-vous à nouveau avec le même compte administrateur sur le portail Microsoft Entra ID :
La MFA étant déjà configuré sur ce compte, saisissez à nouveau sur votre Smartphone le nombre affiché à l’écran :
Cliquez sur Non :
Le portail de Microsoft Entra ID s’ouvre bien une nouvelle fois :
Conclusion
Cet exercice nous montre qu’il n’y a vraiment rien de sorcier dans la création d’un nouveau tenant Microsoft Entra dans sa configuration de base, même si beaucoup d’autres paramétrages non montrés ici seront à configurer selon les cas. Enfin, d’autres mesures de sécurité très intéressantes à mettre en place devraient bientôt suivre dans de prochains articles 😎.
Anciennement appelé AADDS pour Azure Active Directory Domain Services, ce service a lui aussi subi le renommage d’Entra ID de 2023. Très facile à déployer et à maintenir, le domaine managé de Microsoft a tout pour plaire. Mais depuis quelques temps, peu d’évolutions lui ont été apportées. Dean Cefola de la Cloud Academy refait parler de lui et des possibles trusts pour notre plus grand plaisir.
Pour commencer, quelques notions intéressantes sur ce service managé par Microsoft :
Qu’est-ce que Microsoft Entra Domain Services ?
Grâce à Entra Domain Services, il va vous être possible de générer rapidement et facilement un domaine AD, au sens classique du terme, managé par Microsoft et à partir de votre Entra ID :
Microsoft Entra Domain Services offres des services de domaine managé, comme la jonction de domaine, la stratégie de groupe, le protocole LDAP et l’authentification Kerberos et NTLM. Vous utilisez ces services de domaine sans avoir à déployer, gérer et apporter des correctifs aux contrôleurs de domaine dans le cloud.
La partie de gauche de ce schéma nous montre le potentiel de synchronisation d’Entra Domain Services depuis des données stockées dans Entra ID :
Mais alors quelles sont les différences entre un AD DS classique, Entra ID et Entra Domain Services ?
Cet article ne date pas d’hier mais répond très bien à la question !
Afin de rentrer directement dans le vif du sujet, voici donc la vidéo de Dean ayant servi de base à cet article ainsi que le tutoriel officiel de Microsoft :
Vous l’aurez compris, le but est donc tester le trust entre un environnement on-premise et un domaine managé par Microsoft hébergé sous Azure. Grâce à cette approche séparée, chaque domaine impactera en premier lieu sa localité, tout en ayant des adhérences avec les annexes.
Afin de bien comprendre la mise en place du trust entre le domain Active Directory on-premise et le service managé Entra Domain Services, je vous propose de réaliser ce petit exercice :
Pour réaliser cet exercice de Trust, il vous faudra disposer de :
Un tenant Microsoft
Une souscription Azure valide
Afin de pouvoir tester cette fonctionnalité Azure, il est nécessaire de créer plusieurs ressources détaillées par la suite.
Etape I – Création du domaine managé Entra Domain Services :
Commençons par créer notre service de domaine active Directory managé. Pour cela, rechercher le service Microsoft Entra Domain Services sur votre portail Azure :
Cliquez-ici pour créer le service managé sur votre tenant :
Renseignez ses informations de base dont son nom et le SKU Enterprise, puis cliquez sur Suivant:
Validez ses propriétés réseaux, puis cliquez sur Suivant :
Adaptez au besoin les membres du groupe d’administrateurs créé par défaut à votre domaine managé, puis cliquez sur Suivant :
Définissez le périmètre de synchronisation, puis cliquez sur Suivant :
Parcourez les options liées à la sécurité de votre domaine managé, puis lancez la validation Azure :
Cliquez sur Créer pour lancez la création de toutes les ressources Azure :
Lisez bien l’avertissement sur le blocage de modification après création, puis cliquez sur OK :
La notification Azure suivante apparaît en haut à droite de votre portail :
Attendez environ 30 minutes la première phase de déploiement des ressources Azure :
Environ 30 minutes plus tard, cliquez-ici pour parcourir les ressources Azure liées à votre domaine managé :
Comme vous le constatez ici, une phase de post-déploiement prend le relai pendant encore 25 minutes environ :
Approximativement 25 minutes plus tard, la phase de post déploiement est maintenant terminée.
Cliquez-sur le message ci-dessous pour corriger le problème lié aux enregistrements DNS de votre réseau virtuel :
Lancez-le diagnostique en cliquant sur Lancer :
Corrigez l’adressage DNS de votre réseau virtuel en cliquant sur Réparer :
Confirmez votre choix en cliquant à nouveau sur Réparer :
Constatez la présence d’une notification Azure impactant votre réseau virtuel :
Vérifiez la disparition de la notification d’alerte sur votre domaine managé :
Afin de gérer plus facilement le partage côté domaine managé, vous pouvez créer une machine virtuelle Azure sur le même réseau que votre domaine managé avec la fonctionnalité suivante :
Notre domaine managé par Microsoft est configuré dans sa partie initiale.
Nous allons reproduire maintenant une seconde configuration pour notre domaine AD non managé et représentant un environnement on-premise.
Etape II – Création du domaine non managé Active Directory :
Pour cela, rechercher le service des Machines virtuelles sur votre portail Azure :
Cliquez-ici pour commencer la création de la machine virtuelle :
Renseignez les informations de base relatives à votre VM :
Choisissez la taille de votre VM, définissez un compte administrateur local, bloquez les ports entrants, puis cliquez sur Suivant :
Ajoutez un disque secondaire pour les dossiers systèmes AD, puis cliquez sur Suivant :
Prenez soin de définir un réseau virtuel différent du domaine managé, retirez l’adresse IP publique de votre VM, puis cliquez sur Suivant :
Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de la VM, puis attendez environ 2 minutes :
Une fois le déploiement terminé, cliquez-ici pour consulter votre machine virtuelle :
Cliquez-ici pour déclencher le déploiement du service Azure Bastion :
Retournez sur le réseau virtuel nouvellement créé par la machine virtuelle afin de renseigner l’adresse IP locale de votre VM en tant que serveur DNS, puis Sauvegardez :
Une fois que le service Azure Bastion est déployé, connectez-vous à votre machine virtuelle en utilisant le compte d’administrateur local :
Une fois connecté, rendez-vous dans le Gestionnaire des disques :
A l’ouverture du gestionnaire des disques, il vous est proposé d’initialiser le disque de données :
Par la suite créez un nouveau volume simple :
Puis formatez ce dernier en NTFS :
Continuez en ajoutant un nouveau rôle à votre Windows via Server Manager :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cochez les 2 rôles ci-dessous, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Installer :
Attendez environ 5 minutes que l’installation des 2 rôles se termine :
Démarrez la promotion de ce serveur en tant que contrôleur de domaine AD :
Créez une nouvelle forêt locale :
Définissez un mot de passe DSRM, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
Renseignez la lettre de votre disque de données, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Installer :
Quelques minutes plus tard, Windows vous avertit d’une déconnexion imminente :
Attendez quelques minutes qu’Azure Bastion vous reconnecte une fois la machine virtuelle redémarrée avec le compte administrateur de domaine :
Attendez la fin de l’initialisation pendant environ 5 minutes :
Vérifiez la présence de votre domaine AD dans la console Server Manager :
Enfin, créez une nouvelle OU ainsi qu’un nouvel utilisateur local à votre domaine AD :
Continuons la suite de l’exercice en reliant les deux réseaux virtuels Azure entre eux.
Etape III – Appairage des réseaux virtuels :
Sélectionnez le réseau virtuel contenant votre domaine managé par Microsoft :
Ajoutez un appairage de réseau virtuel comme ceci :
Configurez votre appairage comme-ci, puis cliquez sur Ajouter :
Les deux notifications Azure suivantes devraient apparaître :
Vérifiez le changement de statut de votre appairage :
Le lien réseau est maintenant opérationnel. La suite consiste à élaborer la relation de confiance entre les deux domaines Active Directory.
Etape IV – Mise en place du Trust Active Directory :
Copiez les 2 adresses IPs présentes sur votre domaine managé par Microsoft :
Sur votre contrôleur de domaine local, ouvrez l’outil DNS :
Ajoutez un nouveau transit conditionnel via un clic droit :
Reprenez le nom de votre domaine managé, ajoutez-y ses deux adresses IPs, cochez la case suivante, puis cliquez sur OK :
Testez le bon transfert des requêtes du domaine managé via la commande suivante :
nslookup jloudev.cloud
Toujours sur votre contrôleur de domaine, ouvrez le menu suivant :
Rendez-vous dans les propriétés de votre domaine :
Dans l’onglet suivant, cliquez sur Nouveau Trust :
Cliquez sur Suivant :
Reprenez le nom de votre domaine managé, puis cliquez sur Suivant :
Définissez le trust au niveau de la forêt, puis cliquez sur Suivant :
Activez le trust bidirectionnel, puis cliquez sur Suivant :
Configurez le trust simplement pour ce domaine, puis cliquez sur Suivant :
Cliquez sur Suivant :
Définissez un mot de passe trust, puis cliquez sur Suivant :
Cliquez sur Suivant :
Cliquez sur Suivant :
N’activez pas le trust sortant, puis cliquez sur Suivant :
Cliquez enfin sur Terminer :
Vérifiez la présence du lien dans le tableau des trusts :
Continuons avec la configuration de trust sur le domaine managé par Microsoft.
Etape V – Mise en place du Trust Entra Domain Services :
Pour cela, retournez sur la page Azure de votre domaine managé par Microsoft, puis ajoutez le trust par le menu suivant :
Renseignez les informations dont les adresses IP de vos serveurs DNS / AD, puis cliquez sur Sauvegarder :
Confirmez votre choix en cliquant sur OK :
Quelques minutes plus tard, le trust apparait bien comme côté Entra Domain Services :
La liaison Trust est maintenant opérationnelle des 2 côtés. Avant de tester les accès, il est nécessaire d’inscrire les droits sur les 2 partages de fichiers.
Etape VI – Configuration du partage Active Directory :
Retournez dans la gestion de l’Active Directory afin d’y créer un nouveau groupe contenant à la fois notre utilisateur AD et notre utilisateur Cloud comme ceci :
Créez un nouveau dossier sur votre serveur local, puis ajoutez ce nouveau groupe AD avec des droits en modification :
Sur l’onglet de Partage cliquez sur le Partage avancé :
Activez le partage, puis définissez les permissions :
Ajoutez le même groupe AD avec les droits suivants :
Il ne nous reste qu’à répéter cette opération sur le second partage Cloud.
Etape VII – Configuration du partage Entra Domain Services :
Retournez dans la gestion AD d’Entra Domain Services afin d’y créer là aussi un nouveau groupe contenant à la fois notre utilisateur AD et notre utilisateur Cloud comme ceci :
Créez un nouveau dossier sur votre serveur Cloud, puis ajoutez ce même groupe Cloud avec des droits en modification :
Sur l’onglet de Partage, cliquez sur le Partage avancé :
Activez le partage, puis définissez les permissions :
Ajoutez le même groupe Cloud avec les droits suivants :
Tout est enfin prêt pour passer aux tests utilisateurs. Croisons les doigts ! 🤞
Etape VIII – Test d’accès Active Directory :
Créez une nouvelle machine virtuelle sous Windows 11 et jointe au domaine Active Directory, puis ouvrez une session avec votre utilisateur de test via Azure Bastion :
Renseignez le chemin d’accès du partage réseau Cloud dans l’explorateur Windows, constatez la bonne authentification, puis créez une fichier pour vérifier les droits en écriture :
Effectuons maintenant un second test côté Entra Domain Services.
Etape IX – Test d’accès Entra Domain Services :
Créez une seconde machine virtuelle sous Windows 11 et jointe cette fois au domaine managé par Microsoft, puis ouvrez une session avec votre utilisateur de test via Azure Bastion :
Renseignez le chemin d’accès du partage réseau local dans l’explorateur Windows, constatez la bonne authentification, puis créez une fichier pour vérifier les droits en écriture :
Conclusion :
L’accès aux 2 partages de fichiers fonctionnent sans souci 😎 ! La mise en place de trust est grandement facilité depuis le service Entra Domain Services. Il s’agit d’une raison supplémentaire d’utiliser ce service, tout en prenant soin de mesurer ces différences juste ici.
Restons encore un peu dans la lignée des articles dédiés au Global Secure Access de Microsoft. Abordons cette fois-ci une fonction appelée Remote Network : la connexion d’un réseau local (distant) tout entier à un point Edge du réseau Microsoft. Cette approche est complémentaire aux Clients Global Secure Access installés sur les postes en situation de mobilité.
Si le sujet Global Secure Access vous passionne tout comme moi, je vous invite à lire mes précédents articles sur le sujet :
J’y détaille l’intérêt du service Global Secure Access et la démarche sécuritaire mise en avant par Microsoft.
Qu’est-ce qu’un réseau distant ?
A l’inverse de postes en mobilité, il faut voir ces réseaux comme des réseaux fixes d’une entreprise dont le nombre et la répartition est possiblement mondiale :
Les réseaux distants sont des emplacements distants 🤣 ou des réseaux qui nécessitent une connectivité Internet. Par exemple, de nombreuses organisations ont un siège social central et des filiales dans différentes zones géographiques. Ces filiales ont besoin d’accéder aux données et services d’entreprise. Elles ont besoin d’un moyen sécurisé de communiquer avec le centre de données, le siège social et les travailleurs à distance. La sécurité des réseaux distants est cruciale pour de nombreux types d’organisations.
Les réseaux distants, tels qu’un emplacement de branche, sont généralement connectés au réseau d’entreprise via un réseau étendu dédié (WAN) ou une connexion de réseau privé virtuel (VPN). Les employés de l’emplacement de branche se connectent au réseau à l’aide de l’équipement local du client (CPE).
Comment fonctionne la connectivité réseau à distance Global Secure Access ?
Comme pour une connexion VPN classique, une connexion sécurisée via le service Global Secure Access s’appuie sur un tunnel IP Sec :
Pour connecter un réseau distant à Global Secure Access, configurez un tunnel IPSec (Internet Protocol Security) entre votre équipement local et le point de terminaison Global Secure Access. Le trafic que vous spécifiez est acheminé via le tunnel IPSec vers le point de terminaison Global Secure Access le plus proche.
Pourquoi utiliser Global Secure Access pour nos réseaux ?
Global Secure Access propose une approche plus adaptée que les méthodes traditionnelle (WAN / MPLS) en faisant transiter la donnée via le backbone de Microsoft avec une tarification bien plus abordable que ces concurrents :
Il est de plus en plus difficile de maintenir la sécurité d’un réseau d’entreprise dans un monde de travail à distance et d’équipes distribuées. Security Service Edge (SSE) promet un monde de sécurité où les clients peuvent accéder à leurs ressources d’entreprise n’importe où dans le monde sans avoir à renvoyer leur trafic au siège social.
Qu’est-ce que le Zéro Trust Network Access (ZTNA) ?
L’accès au réseau sans confiance (ZTNA), également connu sous le nom de périmètre défini par logiciel (SDP), est un ensemble de technologies et de fonctionnalités qui permettent un accès sécurisé aux applications internes pour les utilisateurs distants. Il fonctionne sur la base d’un modèle de confiance adaptatif, où la confiance n’est jamais implicite et où l’accès est accordé en fonction du besoin de savoir, sur la base du moindre privilège défini.
De manière plus simple, ZTNA reprend l’approche de ZT en y intégrant en tant que signal d’entrée la couche réseau, afin de rendre les décisions d’accès ou d’interdiction encore plus précises et donc plus sécurisantes :
Afin de se faire une meilleure idée sur le Global Secure Access encore en préversion, je vous propose de réaliser un nouvel exercice. Voici quelques liens vers la documentation Microsoft :
Comme Microsoft, mon but est donc de mesurer l’impact dans l’accès aux services 365 en simulant un réseau distant sous Azure et directement connecté Global Secure Access. Les tâches que nous allons réaliser seront donc les suivantes :
Pour réaliser cet exercice, il vous faudra disposer des éléments suivants :
Un tenant Microsoft
Une souscription Azure valide
Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire de créer une machine virtuelle pour simuler un accès aux services 365 depuis notre réseau distant.
Etape I – Préparation de la VM de test :
Pour cela, rechercher le service Machines virtuelles sur le portail Azure :
Cliquez-ici pour commencer la création de la première machine virtuelle :
Renseignez les informations de base relatives à votre VM en choisissant une image sous Windows Server 2022 :
Choisissez la taille de votre VM, puis définissez un compte administrateur local :
Bloquez les ports entrants, puis cliquez sur Suivant :
Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :
Retirez l’IP publique, puis cliquez sur Suivant :
Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 2 minutes :
Une fois le déploiement terminé, cliquez-ici pour consulter votre première machine virtuelle :
Cliquez-ici pour déclencher le déploiement du service Azure Bastion :
Attendez environ 3 minutes que la notification Azure suivante apparaisse :
Notre machine virtuelle est maintenant opérationnelle. La prochaine étape consiste à préparer la connexion VPN côté Azure.
Etape II – Création de la passerelle VPN Azure :
Pour cela, nous allons avoir besoin d’une passerelle VPN Azure. Un ancien article parlait déjà de ce service Azure juste ici.
Recherchez le réseau virtuel créé avec la VM, puis notez sa plage d’adresses réseaux pour la suite :
Profitez-en pour lui ajouter un sous-réseau dédié à la future passerelle VPN :
Cliquez sur Sauvegarder :
Attendez environ 15 secondes que la notification suivante apparaisse :
Recherchez dans le menu Azure le service suivant pour créer la passerelle VPN :
Cliquez-ici pour créer votre passerelle VPN Azure :
Renseignez les informations de base, choisissez le SPU VpnGw1, puis le même réseau virtuel que précédemment :
Désactivez mode actif-actif, activez la fonction BGP, renseignez un numéro ASN valide, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de la passerelle VPN, puis attendez environ 30 minutes :
Une fois le déploiement terminé, cliquez-ici afin de récupérer quelques informations sur la passerelle VPN :
Allez dans l’onglet Configuration afin de copier ces informations :
Notre passerelle VPN côté Azure est maintenant en place. Nous devons maintenant configurer Global Secure Access d’Entra ID pour reconnaître les demandes de connexion depuis cette passerelle VPN.
Etape III – Configuration du réseau distant sur GSA :
Rendez-vous sur la page suivante du portail Entra, puis cliquez-ici pour mettre en place la connexion réseau côté Microsoft Entra :
Nommez votre connexion, choisissez la région Azure la plus proche de votre réseau distant, puis cliquez sur Suivant :
Ajoutez un lien réseau à votre connexion :
Renseignez les informations de base en reprenant les informations récupérées de la passerelle VPN, puis cliquez sur Suivant :
Conservez les options suivantes, puis cliquez sur Suivant :
Définissez une clef PSK et conservez-là, puis cliquez sur Suivant :
Cliquez sur suivant :
Cochez la seule case possible à ce jour : seul le traffic vers les services Microsoft 365 sera actuellement routé via cette connexion, puis lancez la validation Entra ID :
Une fois la validation Entra ID réussie, lancez la connexion réseau, puis attendez environ 1 minute :
Une notification Entra ID apparaît alors :
Consultez le menu suivant afin de constater la présence d’un réseau distant uniquement sur le profil Microsoft 365 :
Retournez sur le menu des connexions réseaux afin de récupérer des informations :
Récupérez les 3 informations suivantes pour continuer la configuration de la connexion à la passerelle VPN côté Azure :
La configuration réseau côté Global Secure Access est maintenant terminée. Avançons maintenant côté Azure afin que ce dernier reconnaisse également le réseau GSA.
Etape IV – Configuration du réseau GSA sur Azure :
Retournez sur le portail Azure afin de créer passerelle de réseau local correspondant à la connexion configurée sur Global Secure Access.
Pour cela, recherchez le service suivant sur le portail Azure :
Cliquez-ici pour commencer la création :
Renseignez les informations de base, reprenez l’IP publique récupérée sur Global Secure Access, puis cliquez sur Suivant :
Renseignez les autres informations suivantes provenant de Global Secure Access, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de la passerelle de réseau local, puis attendez environ 2 minutes :
Attendez que le déploiement de la passerelle de réseau local soit terminé :
Avant de finaliser la configuration VPN, il serait intéressant de tester une connexion vers les services 365 en y incluant une police d’accès conditionnel potentiellement bloquante.
Etape V – Global Secure Access + Accès Conditionnel :
La signalisation de Global Secure Access fournit des informations sur l’emplacement du réseau à l’accès conditionnel, ce qui permet aux administrateurs de créer des politiques qui limitent l’accès des utilisateurs à des applications spécifiques en fonction de leur utilisation du client Global Secure Access ou d’un réseau distant.
La combinaison de Global Secure Access et de l’Accès Conditionnel va donc permettre de restreindre l’accès à certains services si la connexion via Global Secure Access n’est pas établie.
Pour cela, créez une nouvelle police d’accès conditionnel par le menu suivant :
Spécifiez le groupe d’utilisateurs de test concerné :
Définissez la ou les applications à protéger :
Excluez de cette police les connexions faites via Global Secure Access :
Bloquez l’accès pour toutes les autres tentatives de connexion, activez la police puis sauvegardez-là :
Attendez quelques minutes, puis retournez sur votre VM de test via une session Azure Bastion :
Lancez un ping sur le site outlook.office.com afin de constater l’IP actuelle du service de messagerie de Microsoft :
Ouvrez Edge sur la page office.com afin de vous authentifiez avec un compte 365 de test :
Connectez-vous-y en utilisant l’identité Entra ID de votre compte de test :
Constatez le blocage de l’accès conditionnel mis en place précédemment :
Ce test nous confirme que la connexion GSA via un réseau distant ou le client est maintenant obligatoire pour accéder aux services 365.
Finalisons maintenant la connexion entre notre environnement Azure de test et GSA.
Etape VI – Connexion entre le réseau distant et GSA :
De retour sur le portail Azure, cliquez-ici pour mettre en place la connexion entre la passerelle VPN et Global Secure Access :
Définissez la connexion en IP Sec, puis cliquez sur Suivant :
Renseignez les informations de base dont la clef PSK, cochez la case BGP, puis lancez la validation Azure :
Une fois la validation Azure réussie, lancez la création de la connexion, puis attendez environ 1 minute :
Attendez que le déploiement de la connexion soit terminé, puis cliquez-ici :
Constatez le statut inconnu de celle-ci :
Retournez sur la page suivante de la passerelle VPN, puis rafraichissez périodiquement afin de constater une changement de status de la connexion :
Le statut devrait changer sous environ 3 minutes :
Consultez la page suivante pour voir les impacts de routage via les communications BGP :
L’environnement est maintenant opérationnel. Il ne reste plus qu’à refaire des tests sur notre machine virtuelle.
Etape VII – Global Secure Access + Accès Conditionnel v2 :
Lancez un ping sur le site outlook.office.com afin de constater la nouvelle IP du service de messagerie Microsoft :
Ouvrez Edge en navigation privée sur la page office.com afin de vous authentifiez avec un compte 365 de test :
Connectez-vous-y en utilisant l’identité Entra ID de votre compte de test :
Cliquez sur Non :
Constatez la bonne connexion au service de Microsoft 365 :
Afin de confirmer nos tests, retirez la connexion entre Azure et GSA pour retrouver le blocage initialement constaté à cause de la police d’accès conditionnelle.
Etape VIII – Retrait de la connexion VPN :
De retour sur le portail Azure, supprimez la connexion VPN Azure précédemment établie :
Confirmez votre choix en cliquant sur Oui :
Attendez que la notification Azure suivante apparaisse :
Lancez un ping sur le site outlook.office.com afin de constater la nouvelle IP du service de messagerie de Microsoft :
Constatez le retour du blocage de l’accès conditionnel mis en place précédemment :
Consultez l’évolution du status de la connexion Global Secure Access via le menu suivant :
Constatez le log de connexion vers les services Microsoft 365 ayant transité par le Global Secure Access via le menu suivant :
Conclusion
Ce nouveau test montre encore une fois la grande simplicité de la connexion entre l’on-premise et les services 365 de Microsoft. Aucun doute que ce service devrait connaître un grand succès une fois sorti de sa préversion et quand sa grille tarifaire sera dévoilée 🤣🙏
Le prochain article devrait parler de l’Accès Privé de Global Secure Access. John a déjà pris de l’avance sur moi 🤣
Le Global Secure Access continue de nous livrer tous ses secrets en ce début d’année 2024. Après la découverte de la sécurisation des accès aux services 365 déjà décrite dans cet article, je propose maintenant de nous intéresser à la sécurisation de l’accès internet.
Voici un petit rappel de quelques points intéressant sur le sujet :
Qu’est-ce que le Zéro Trust Network Access (ZTNA) ?
L’accès au réseau sans confiance (ZTNA), également connu sous le nom de périmètre défini par logiciel (SDP), est un ensemble de technologies et de fonctionnalités qui permettent un accès sécurisé aux applications internes pour les utilisateurs distants. Il fonctionne sur la base d’un modèle de confiance adaptatif, où la confiance n’est jamais implicite et où l’accès est accordé en fonction du besoin de savoir, sur la base du moindre privilège défini.
De manière plus simple, ZTNA reprend l’approche de ZT en y intégrant en tant que signal d’entrée la couche réseau, afin de rendre les décisions d’accès ou d’interdiction encore plus précises et donc plus sécurisantes :
Qu’est-ce que le Global Secure Access proposé par Microsoft ?
Voyant l’évolution des besoins de sécurité réseaux et la demande grandissante du Cloud, Microsoft a souhaité apporter sa propre solution SSE basée sur ZTNA :
Global Secure Access est l’emplacement unifié du centre d’administration Microsoft Entra et repose sur les principes fondamentaux de confiance zéro, d’utiliser le moindre privilège, de vérifier explicitement et de supposer une violation.
Pourquoi utiliser Global Secure Access pour le trafic Internet ?
Comme Global Secure Access est capable de sécuriser les accès Internet d’un poste sur un réseau d’entreprise ou en mobilité, le filtrage web devient une tâche plus facile de par son approche hybride :
La fonctionnalité d’introduction clé pour Microsoft Entra Internet Access pour toutes les applications est le filtrage de contenu web.
Cette fonctionnalité fournit un contrôle d’accès granulaire pour les catégories web et les noms de domaine complets. En bloquant explicitement les sites inappropriés, malveillants ou dangereux connus, vous protégez vos utilisateurs et leurs appareils contre toute connexion Internet, qu’ils se connectent à distance ou au sein du réseau d’entreprise.
Qu’est-ce qu’un Profil de sécurité sur Global Secure Access ?
Quelques éléments sur le profil de sécurité de Global Secure Access :
Dispose d’une priorité (ordonnancement) entre profils de sécurité
Agit comme un conteneur de stratégies de filtrage web avec priorité (ordonnancement)
Et associé à une ou plusieurs polices d’accès conditionnel Entra ID
Autrement dit, les profils de sécurité vont vous aider à organiser le filtrage au sein de votre entreprise et seront facilement adaptables selon les utilisateurs du tenant.
Qu’est-ce qu’une stratégie de filtrage de contenu web sur Global Secure Access ?
Le filtrage de contenu web vous permet d’implémenter des contrôles d’accès Internet granulaires pour votre organisation en fonction de la catégorisation du site web.
La fonctionnalité de filtrage web est actuellement limitée au filtrage de catégorie web basé sur le nom de domaine complet (FQDN) et au filtrage de noms de domaine complets qui prennent en compte les utilisateurs et le contexte.
Autrement dit, une stratégie de filtrage autorise ou interdit un trafic vers une ou plusieurs cibles web :
Nom de domaine complet (FQDN)
Catégories web
Pourquoi associer Global Secure Access à l’Accès Conditionnel d’Entra ID ?
L’intégration du filtrage Internet à l’accès conditionnel d’Entra ID va permettre de gérer différentes configurations selon les utilisateurs. Cette approche est souvent déjà utilisée pour gérer les accès aux applications 365.
Voici d’ailleurs un schéma créé par John Savill expliquant (à droite) la jonction de :
Voici d’ailleurs un excellent webinar animé par Seyfallah Tagrerout sur la sécurisation internet via Global Secure Access :
Et voici une autre vidéo sur le même sujet du très apprécié John Savill :
Comme précédemment, je vous propose de tester Global Secure Access, encore en préversion, par la réalisation d’un second exercice. Notre but sera de mesurer l’impact dans l’accès à des sites internet en simulant des postes utilisateurs ayant le client Windows Global Secure Access d’installé.
Les tâches que nous allons réaliser sont les suivantes :
Cliquez sur le service de votre choix pour en savoir un peu plus :
La documentation Microsoft correspondante s’ouvre alors dans un nouvel onglet :
De retour sur le portail d’Entra, continuer la configuration du Global Secure Access en cliquant sur Journalisation. Cette page nous informe que la Journalisation n’est pas encore activée sur Entra ID :
Activez la sauvegarde en passant par le menu suivant :
Configurez les Paramètres de diagnostic selon vos souhaits en cochant bien les logs nommées EnrichedOffice365AuditLogs :
Retournez sur la page de Journalisation de Global Secure Access afin de contrôler le bon changement :
La configuration de base de Global Secure Access est maintenant terminée.
Avant d’activer le service de Profil d’accès à Microsoft 365, nous allons créer 2 VMs dans Azure pour simuler des postes utilisateurs.
Etape II – Préparation de postes utilisateurs :
Depuis le portail Azure, créez 2 machines virtuelles sous Windows 11 sous un même réseau virtuel :
Sur ce réseau virtuel, déployer le service Azure Bastion afin de vous connecter à ces 2 VMs dépourvues d’IP publiques :
Joignez les deux machines virtuelles créées précédemment à Entra ID selon cet article, puis vérifiez leur présence sur cette page d’Entra ID :
Vérifiez également la présence de ces 2 VMs sur cette page de la console Intune :
Nos machines virtuelles de test sont prêtes.
Créez une premier groupe Entra ID contenant vos 2 utilisateurs de test :
Créez une second groupe Entra ID contenant vos 2 machines Azure de test :
L’environnement Azure est maintenant opérationnel. Retournons sur la configuration de Global Secure Access pour activer le profil dédié au trafic internet.
Etape III – Configuration du Profil d’accès à Internet :
Retournez sur cette page d’Entra ID, puis cochez la case suivante pour activer ce profil sur votre tenant :
Confirmez votre action en cliquant sur OK :
Attendez quelques secondes l’apparition de cette notification :
Vérifiez le changement de statut pour le Profil d’accès à Internet :
Continuons maintenant par l’installation du client Global Secure Access.
Etape IV – Déploiement du client Global Secure Access :
Ce client est nécessaire pour acheminer le trafic réseau vers le service Global Secure Access quand on souhaite s’y connecter en dehors d’un réseau d’entreprise.
Les différents clients de Global Secure Access sont disponibles sur cette page. Cliquez-ici pour télécharger la version Windows 10/11 :
Attendez que le téléchargement se termine :
Si vous le souhaitez, utilisez comme moi l’application Intunewin (Microsoft Win32 Content Prep Tool) afin de packager votre client Global Secure Access et de le déployer via Intune.
Attendez environ 30 minutes que l’application se déploie automatiquement sur les 2 machines virtuelles précédemment créées :
L’environnement est enfin prêt pour tester la connexion aux services 365 via Global Secure Access.
Etape V – Test de Global Secure Access :
Ouvrez 2 sessions RDP via Azure Bastion sur les 2 VMs en utilisant respectivement vos 2 utilisateurs Entra ID de test :
Constatez l’ouverture d’une page d’authentification de Global Secure Access, puis connectez-vous-y en utilisant l’identité Entra ID proposée par Windows :
Vérifiez la bonne connexion grâce à l’icône présent dans la barre de tâches :
Afin de comparer les 2 environnements, activez le mode Pause sur l’une des 2 VMs de test :
Cliquez sur le menu suivant du client Global Secure Access afin d’obtenir plus d’informations sur le statut de la connexion :
Comparez les deux checklist et leurs différences :
Vérifiez la présence de la règle concernant le profil Internet sur les 2 VMs :
Sur les 2 machines virtuelles de test :
Ouvrez une page web sur Edge afin de constater la connexion au service
Lancez une requête PING afin de constater les variations d’adresses IP
6.6.0.29 vs 13.107.246.42 😎
Retournez sur la page de log suivante du service Global Secure Access d’Entra ID afin de constater l’apparition de plusieurs lignes de log :
En quelques clics, nous avons mis en place un client Global Secure Access. Continuons un autre test en combinant le Global Secure Access avec un premier profil de sécurité général.
Etape VI – Global Secure Access + Profil de Sécurité 65000 :
Pour rappel, le profil de sécurité (unique) ayant la priorité 65000 sera pris en charge par l’ensemble des trafics internet transitant par la solution Global Secure Access.
Avant de créer le profil de sécurité 65000 du tenant, commencez par créer une première stratégie de filtrage via ce lien :
Nommez votre stratégie de filtrage de contenu internet, définissez sa nature, puis cliquez sur Suivant :
Block : bloque le trafic internet en direction des sites définis par la stratégie de filtrage
Allow : autorise le trafic internet en direction des sites définis par la stratégie de filtrage
Ajoutez une ou plusieurs règles de filtrage selon deux options possibles pour les cibles :
Catégorie de site : permet de choisir une catégorie de web prédéfinie
FQDN : domaine ou sous-domaine
Vérifiez et valider votre stratégie de filtrage :
Dans mon cas, mon blog jlou.eu sera bloqué par cette stratégie de filtrage.
Attendez quelques secondes l’apparition de cette notification :
Nous pouvons maintenant créer le profil de sécurité général.
Pour créer ce profil de sécurité à priorité 65000, cliquez-ici sur le menu suivant disponible sur cette page :
Nommez votre profil de sécurité, définissez sa priorité à 65000, puis cliquez sur Suivant :
Associez la stratégie de filtrage créée précédemment :
Vérifiez et valider votre profil de sécurité :
Attendez quelques secondes l’apparition de cette notification :
Vérifiez la bonne configuration et l’absence de police d’accès conditionnel sur le profil 65000 :
Attendez quelques minutes, puis effectuer un test avec le navigateur Edge sur les 2 VMs de test afin d’en mesurer les impacts :
L’utilisateur fonctionnant avec le Global Secure Access activé se retrouve alors bloqué.
Continuons avec un autre test de restriction internet pour Global Secure Access combiné à une police d’accès conditionnel.
Etape VII – Global Secure Access + Accès Conditionnel :
A l’inverse du profil de sécurité à priorité 65000, tous les autres auront besoin d’avoir un accès conditionnel pour s’appliquer.
Avant de créer ce second profil de sécurité, commencez par créer une autre stratégie de filtrage de contenu internet via ce lien :
Nommez votre stratégie de filtrage, définissez sa nature, puis cliquez sur Suivant :
Ajoutez une ou plusieurs règles de filtrage selon les deux options possibles :
Vérifiez et valider votre stratégie de filtrage :
Attendez quelques secondes l’apparition de cette notification :
2 stratégies de filtrage sont alors présentes sur votre environnement :
Cliquez-ici sur le menu suivant pour créer le second profil de sécurité :
Nommez votre profil de sécurité, définissez sa priorité à 150, puis cliquez sur Suivant :
Associez la stratégie de filtrage créée juste avant avec une priorité de 150 :
Vérifiez et valider votre profil de sécurité :
Attendez quelques secondes l’apparition de cette notification :
Vérifiez la bonne configuration et l’absence de police d’accès conditionnel sur le nouveau profil de sécurité :
Attendez quelques minutes, puis effectuer un test avec le navigateur Edge sur les 2 VMs de test afin d’en mesurer les impacts :
Aucun des deux ne se retrouve alors bloqué.
Comme on peut le constater, l’ajout d’une police d’accès conditionnel est nécessaire pour tous les profils de sécurité autre que celui à la priorité 65000.
Pour cela, rendez-vous sur la page suivante afin de créer la police d’accès conditionnel :
Spécifiez les utilisateurs concernés par cette police d’accès conditionnel :
Sélectionnez le trafic Internet dans les ressources cibles :
Indiquez le profil de sécurité créé au début de cette étape afin que s’appliquent les stratégie de filtrage associées :
Retournez sur la page des profils de sécurité afin de constater la bonne relation avec la police d’accès conditionnel :
Note : Pour des raisons de durée de vie de token, la mise en place d’un nouveau profil de sécurité sur des connexions Global Secure Access déjà actives peut prendre du temps avant de s’appliquer.
Attendez quelques minutes, puis effectuer un test avec le navigateur Edge sur les 2 VMs de test afin d’en mesurer les impacts :
L’utilisateur connecté via Global Secure Access se retrouve bloqué par la combinaison du profil de sécurité et de l’accès conditionnel.
Effectuez si besoin un second test sur un site faisant partie d’une des catégorie web bloquée dans votre stratégie de filtrage :
L’utilisateur connecté via Global Secure Access se retrouve bloqué par la combinaison du profil de sécurité et de l’accès conditionnel.
Continuons maintenant avec un test basé sur les priorités des stratégies de filtrage dans un même profil de sécurité Global Secure Access.
Etape VIII – Global Secure Access + Priorisation des stratégies de filtrage :
Afin de mesurer et comprendre la gestion des priorité des stratégie de filtrage de filtrage, nous allons réaliser la configuration suivante :
Stratégie de filtrage à priorité 140 autorisant un premier site azurewebsites
Stratégie de filtrage à priorité 150 interdisant tous les sites azurewebsites (déjà créée)
Stratégie de filtrage à priorité 160 autorisant un second site azurewebsites
Commencez par créer une première stratégie de filtrage de contenu internet via ce lien :
Nommez votre stratégie de filtrage, définissez sa nature, puis cliquez sur Suivant :
Ajoutez une ou plusieurs règles de filtrage :
Vérifiez et valider votre stratégie de filtrage :
Attendez quelques secondes l’apparition de cette notification :
Créez une seconde stratégie de filtrage :
Nommez votre seconde stratégie de filtrage, définissez sa nature, puis cliquez sur Suivant :
Ajoutez une ou plusieurs règles de filtrage :
Vérifiez et valider votre stratégie de filtrage :
Attendez quelques secondes l’apparition de cette notification :
Cliquez ici pour ajouter les stratégies de filtrage créées :
Ajoutez ces 2 stratégies de filtrage en respectant les priorités suivantes :
Retournez sur la page des profils de sécurité afin de constater l’ajout des 2 nouvelles stratégies de filtrage :
Attendez quelques minutes, puis effectuer un test avec le navigateur Edge sur les 2 VMs de test afin d’en mesurer les impacts :
L’utilisateur connecté via Global Secure Access n’est plus bloqué grâce à l’ajout de la stratégie de filtrage en priorité 140.
Effectuez un second test sur le site azurewebsites renseigné dans la stratégie de filtrage à priorité 160 :
L’utilisateur connecté via Global Secure Access se retrouve bloqué car l’ajout de la stratégie de filtrage en priorité 160 ne s’applique pas avant celle en priorité 150.
Continuons avec un autre test basé sur les priorités quand 2 profils de sécurité Global Secure Access sont assignés à un utilisateur.
Etape IX – Global Secure Access + Priorisation des profil de sécurité :
Afin de mesurer et comprendre la gestion des priorité des profil de sécurité, nous allons réaliser la configuration suivante :
Profil de de sécurité à priorité 130 interdisant le premier site azurewebsites et autorisant le second site azurewebsites
Profil de de sécurité à priorité 150 autorisant les 2 sites azurewebsites et interdisant tous les autres sites azurewebsites (déjà créé)
Créez un nouveau profil de sécurité ayant une priorité à 130 :
Associez à ce profil une première stratégie de filtrage avec une priorité à 131 bloquant le site azurewebsites précédemment accessible :
Associez à ce profil une seconde stratégie de filtrage avec une priorité à 132 autorisant le site azurewebsites précédemment bloqué :
Créez une nouvelle police d’accès conditionnel associée à ce nouveau profil de sécurité :
Vérifiez la bonne configuration de l’ensemble :
Afin d’accélérer le déploiement de ce nouveau profil de sécurité sur les machines de test, vous pouvez vous déconnecter / reconnecter au Global Secure Access :
Réauthentifiez-vous en utilisant le compte Entra ID utilisé pour ouvrir la session Windows :
Ouvrez Edge vers le premier site azurewebsites afin de constater les impacts :
L’utilisateur connecté via Global Secure Access est maintenant bloqué à cause de l’ajout de la profil de sécurité en priorité 130.
Ouvrez Edge vers le second site azurewebsites afin de constater les impacts :
L’utilisateur connecté via Global Secure Access n’est plus bloqué grâce à l’ajout de la profil de sécurité en priorité 130.
Continuons avec un autre test reprenant l’accès conditionnel précédent, et en y ajoutant un contrôle MFA obligatoire.
Etape X – Global Secure Access + Contrôle MFA
Retournez sur la page d’accès conditionnel pour cocher la case MFA sur la dernière police d’accès conditionnel créée :
Attendez quelques minutes, puis cliquez-ici pour réouvrir une connexion sur Global Secure Access :
Réauthentifiez-vous en utilisant le compte Entra ID utilisé pour ouvrir la session Windows :
Constatez l’apparition d’un prompt consacré à la MFA :
Confirmez la connexion en réussissant le challenge MFA selon la méthode voulue :
Vérifiez le changement de statut de connexion des profils de configuration actifs :
Ouvrez Edge vers le premier site azurewebsites afin de la bonne connexion :
Terminons par un dernier test en bloquant l’accès sur la police d’accès conditionnel modifiée durant ce test.
Etape XI – Global Secure Access + Blocage Internet :
Pour cela, retournez sur la police d’accès conditionnel en modifiant l’accès par un blocage systématique :
Cliquez-ici pour fermer et réouvrir une connexion sur Global Secure Access :
Réauthentifiez-vous en utilisant le compte Entra ID utilisé pour ouvrir la session Windows :
Constatez l’apparition d’un prompt expliquant un blocage complet d’internet :
Conclusion
Par la mise à disposition du Global Secure Access, Microsoft apporte une brique manquante et attendue depuis longtemps dans son approche Zéro Trust. D’autres fonctionnalités comme Remote network vont s’avérer très utile pour sécuriser les connexions depuis et vers le Cloud sans obligatoirement investir dans des solutions de type MPLS.
Un dernier article devrait bientôt suivre sur la gestion de trafic pour le profil Private access 😎
2024 est à peine là, mais certaines choses ne changent pas. La sécurité IT reste encore au cœur des préoccupations pour cette nouvelle année. Les façons de consommer la donnée au travers des outils informatiques ont été bouleversées depuis l’arrivée des Cloud publics. Mais ces usages doivent s’accompagner de mesures de sécurité toujours plus performantes.
Microsoft veut changer la partie avec son Global Secure Access. Parcourons ensemble quelques notions sur ce sujet.
Pourquoi Microsoft s’intéresse aux réseaux ?
L’émergence des outils 365, les nombreuses applications disponibles sous format SaaS, les ressources hébergées sur Azure, ou encore les effets du COVID ont fait voler en éclat les approches réseaux traditionnelles.
Partant de ce constat, la sécurité des réseaux, pensée de manière centralisée, a dû elle aussi s’adapter face à au nouveaux usages et fait face à de nouvelles menaces potentielles.
Microsoft est un acteur majeur du Cloud public, et la nouvelle approche sécuritaire des réseaux au-delà de leurs centre de données est donc une évidence pour eux.
Secure Access Service Edge (SASE) vs Security Service Edge (SSE) ?
Il s’agit avant tout de structurer les produits et les services de manière plus cohérentes selon les besoins :
Le SSE définit un cadre limité de la sécurité réseau convergente, qui allie des fonctions SWG, CASB/DLP et ZTNA dans un service cloud natif. Il permet un accès sécurisé aux applications Web, SaaS et métier internes, sans prise en charge directe des ressources WAN. Ce dernier aspect relève toujours d’une solution technologique distincte, englobant des fonctions comme le SD-WAN, les pare-feux nouvelle génération et les backbones réseau globaux.
Considérez simplement chaque demande d’accès comme suspecte :
Qu’est-ce que le Zéro Trust Network Access (ZTNA) ?
L’accès au réseau sans confiance (ZTNA), également connu sous le nom de périmètre défini par logiciel (SDP), est un ensemble de technologies et de fonctionnalités qui permettent un accès sécurisé aux applications internes pour les utilisateurs distants. Il fonctionne sur la base d’un modèle de confiance adaptatif, où la confiance n’est jamais implicite et où l’accès est accordé en fonction du besoin de savoir, sur la base du moindre privilège défini.
De manière plus simple, ZTNA reprend l’approche de ZT en y intégrant en tant que signal d’entrée la couche réseau, afin de rendre les décisions d’accès ou d’interdiction encore plus précises et donc plus sécurisantes :
Qu’est-ce que le Global Secure Access proposé par Microsoft ?
Voyant l’évolution des besoins de sécurité réseaux et la demande grandissante du Cloud, Microsoft a souhaité apporter sa propre solution SSE basée sur ZTNA :
Global Secure Access est l’emplacement unifié du centre d’administration Microsoft Entra et repose sur les principes fondamentaux de confiance zéro, d’utiliser le moindre privilège, de vérifier explicitement et de supposer une violation.
Voici d’ailleurs un excellent webinar animé par Seyfallah Tagrerout sur le Global Secure Access :
Afin de se faire une meilleure idée sur le Global Secure Access encore en préversion, je vous propose de réaliser un petit exercice. Mon premier but étant de mesurer son impact dans l’accès aux services 365 en simulant des postes utilisateurs ayant le client Windows Global Secure Access d’installé.
Les tâches que nous allons réaliser sont donc les suivantes :
Cliquez sur le service de votre choix pour en savoir un peu plus :
La documentation Microsoft correspondante s’ouvre alors dans un nouvel onglet :
De retour sur le portail d’Entra, continuer la configuration du Global Secure Access en cliquant sur Journalisation. Cette page nous informe que la Journalisation n’est pas encore activée sur Entra ID :
Activez la sauvegarde en passant par le menu suivant :
Configurez les Paramètres de diagnostic selon vos souhaits en cochant bien les logs nommées EnrichedOffice365AuditLogs :
Retournez sur la page de Journalisation de Global Secure Access afin de contrôler le bon changement :
La configuration de base de Global Secure Access est maintenant terminée.
Avant d’activer le service de Profil d’accès à Microsoft 365, nous allons créer 2 VMs dans Azure pour simuler des postes utilisateurs.
Etape II – Préparation de postes utilisateurs :
Depuis le portail Azure, créez 2 machines virtuelles sous Windows 11 sous un même réseau virtuel :
Sur ce réseau virtuel, déployer le service Azure Bastion afin de vous connecter à ces 2 VMs dépourvues d’IP publiques :
Joignez les deux machines virtuelles créées précédemment à Entra ID selon cet article, puis vérifiez leur présence sur cette page d’Entra ID :
Vérifiez également la présence de ces 2 VMs sur cette page de la console Intune :
Nos machines virtuelles de test sont prêtes.
Créez une premier groupe Entra ID contenant vos 2 utilisateurs de test :
Créez une second groupe Entra ID contenant vos 2 machines Azure de test :
L’environnement Azure est maintenant opérationnel. Retournons sur la configuration de Global Secure Access pour activer le profil dédié aux services Microsoft 365.
Etape III – Configuration du Profil d’accès à Microsoft 365 :
Retournez sur cette page d’Entra ID, puis cochez la case suivante pour activer ce profil sur votre tenant :
Confirmez votre action en cliquant sur OK :
Attendez quelques secondes l’apparition de cette notification :
Vérifiez le changement de statut pour le Profil d’accès à Microsoft 365 :
Pour gérer les détails de la politique de transfert de trafic Microsoft 365, sélectionnez le lien suivant :
Vous pouvez choisir d’ignorer certains trafics. Les utilisateurs peuvent toujours accéder au site, mais le service ne traite pas le trafic.
Continuons maintenant par l’installation du client Global Secure Access.
Etape IV – Déploiement du client Global Secure Access :
Ce client est nécessaire pour acheminer le trafic réseau vers le service Global Secure Access quand on souhaite s’y connecter en dehors d’un réseau d’entreprise.
Les différents clients de Global Secure Access sont disponibles sur cette page. Cliquez-ici pour télécharger la version Windows 10/11 :
Attendez que le téléchargement se termine :
Si vous le souhaitez, utilisez comme moi l’application Intunewin (Microsoft Win32 Content Prep Tool) afin de packager votre client Global Secure Access et de le déployer via Intune.
Attendez environ 30 minutes que l’application se déploie automatiquement sur les 2 machines virtuelles précédemment créées :
L’environnement est enfin prêt pour tester la connexion aux services 365 via Global Secure Access.
Etape V – Test de Global Secure Access :
Ouvrez 2 sessions RDP via Azure Bastion sur les 2 VMs en utilisant respectivement vos 2 utilisateurs Entra ID de test :
Constatez l’ouverture d’une page d’authentification de Global Secure Access, puis connectez-vous-y en utilisant l’identité Entra ID proposée par Windows :
Vérifiez la bonne connexion grâce à l’icône présent dans la barre de tâches :
Afin de comparer les 2 environnements, activez le mode Pause sur l’une des 2 VMs de test :
Cliquez sur le menu suivant du client Global Secure Access afin d’obtenir plus d’informations sur le statut de la connexion :
Comparez les deux checklist et leurs différences :
Vérifiez la présence de la règle concernant le profil Microsoft 365 sur les 2 VMs :
Sur les 2 machines virtuelles de test :
Ouvrez la page d’Outlook sur Edge afin de constater la connexion au service
Lancez une requête PING afin de constater les variations d’adresses IP
6.6.0.10 vs 52.98.163.18 😎
Retournez sur la page de log suivante du service Global Secure Access d’Entra ID afin de constater l’apparition de plusieurs lignes de log :
En quelques clics, nous avons mis en place un client Global Secure Access. Continuons un autre test en combinant le Global Secure Access avec l’Accès Conditionnel d’Entra ID.
Etape VI – Global Secure Access + Accès Conditionnel :
La signalisation de Global Secure Access fournit des informations sur l’emplacement du réseau à l’accès conditionnel, ce qui permet aux administrateurs de créer des politiques qui limitent l’accès des utilisateurs à des applications spécifiques en fonction de leur utilisation du client Global Secure Access ou d’un réseau distant.
La combinaison de Global Secure Access et de l’Accès Conditionnel va donc permettre de restreindre l’accès à certains services si la connexion via Global Secure Access n’est pas établie.
Pour cela, rendez-vous sur la page suivante d’Entra afin de constater la situation avant activation :
Activez l’option nommée Accès adaptatif sur cette page, puis sauvegardez :
Attendez quelques secondes l’apparition de cette notification :
Retournez sur page suivante d’Entra afin de constater la situation après activation :
Créez une nouvelle police d’accès conditionnel par le menu suivant :
Spécifiez le groupe d’utilisateurs de test concerné :
Définissez la ou les applications à protéger :
Excluez de cette police les connexions faites depuis Global Secure Access :
Bloquez l’accès pour les autres tentatives de connexion, activez la police puis sauvegardez-là :
Attendez quelques minutes, puis ouvrez Edge en navigation privée vers la page d’Outlook afin de constater les impacts :
L’utilisateur dépourvue de Global Secure Access se retrouve bloqué.
Continuons avec un dernier test de restriction de tenant pour Global Secure Access.
Etape VII – Global Secure Access + Restriction au tenant :
Les restrictions imposées aux locataires permettent aux administrateurs de contrôler si leurs utilisateurs peuvent accéder aux ressources d’une organisation externe avec des comptes émis par cette dernière, tout en utilisant le réseau ou l’appareil de votre organisation.
En d’autres termes, une fois connecté au Global Secure Access, plus moyen de s’authentifier sur un tenant tiers si cette option est activée et sans y ajouter le second tenant comme exception.
Pour cela, rendez-vous sur cette même page d’Entra ID, activez l’option suivante puis sauvegardez :
Attendez quelques minutes, puis réouvrez Edge en navigation privée vers la page d’Outlook afin de constater les impacts :
Cette fois-ci, l’utilisateur ayant Global Secure Access se retrouve bloqué.
Conclusion
Par la mise à disposition du Global Secure Access, Microsoft apporte une brique manquante et attendue depuis longtemps dans son approche Zéro Trust. D’autres fonctionnalités comme Remote network vont s’avérer très utile pour sécuriser les connexions depuis et vers le Cloud sans obligatoirement investir dans des solutions de type MPLS.
Enfin, d’autres articles vont bientôt suivre sur la gestion de trafic des autres profils (Private access profile, Internet access profile) 😎
Microsoft propose depuis quelques temps déjà plusieurs options pour gérer les organisations réparties sur plusieurs tenants Cloud. Par exemple, la synchronisation entre tenants a été introduite en janvier de cette année. Depuis, les choses continuent de progresser grâce à l’arrivée d’un nouveau niveau : l’organisation multi-tenants = regroupement de plusieurs tenants B2B dans un seul ensemble ayant des facultés de synchronisation.
Avant de tester la création d’une organisation multi-tenants sur mon environnement de démonstration, faisons d’abord un bref rappel de quelques notions importantes sur les tenants Microsoft.
Qu’est-ce qu’un tenant Microsoft ?
Nous pourrions traduire le mot anglais Tenant par locataire. Dans l’univers du Cloud Microsoft, le terme Tenant désigne le périmètre (le Cloud) dans laquelle vos données sont stockées. Ainsi chaque client possède sa propre sphère, son propre Tenant.
Voici d’ailleurs la définition selon Microsoft :
Un locataire est une instance d’Azure AD dans laquelle résident des informations sur une seule organisation, y compris des objets organisationnels tels que des utilisateurs, des groupes et des appareils, ainsi que des inscriptions d’applications, telles que Microsoft 365 et des applications tierces.
La synchronisation multi-tenants d’Entra ID est un mécanisme qui facilite la création, la modification et la suppression des utilisateurs à travers plusieurs tenants via un système automatisé et géré par Microsoft :
Son objectif principal est d’assurer une collaboration transparente entre les tenants d’une même organisation, tout en rationalisant la gestion des comptes utilisateurs B2B dans un environnement multi-tenants.
Une vidéo de John en parle d’ailleurs très bien :
Concernant la gestion d’identités externes au tenant, Microsoft propose également d’autres fonctionnalités comme par exemple :
Nous sommes ici à un niveau plus élevé que le tenant unique, nous parlons ici de fédérer plusieurs tenants Microsoft.
L’image ci-dessous montre 2 tenants Microsoft distincts, contenant chacun des utilisateurs présents dans chacun d’eux (Entra ID) :
Microsoft a développé ce niveau pour répondre à plusieurs demandes :
Une organisation multilocataire est une organisation qui a plusieurs instances d’Azure AD. Voici les principales raisons pour lesquelles une organisation peut avoir plusieurs locataires :
Conglomérats : les organisations avec plusieurs filiales ou unités commerciales qui fonctionnent indépendamment.
Fusions et acquisitions : organisations qui fusionnent ou acquièrent des sociétés.
Activité de cession : dans le cadre d’une cession, une organisation fractionne une partie de ses activités pour former une nouvelle organisation ou la vendre à une organisation existante.
Plusieurs clouds : les organisations dont la conformité ou la réglementation doivent exister dans plusieurs environnements cloud.
Plusieurs limites géographiques : organisations qui opèrent dans plusieurs emplacements géographiques avec différentes réglementations de résidence.
Locataires de test ou intermédiaires : organisations qui ont besoin de plusieurs locataires à des fins de test ou de préproduction avant de procéder à un déploiement plus large sur des locataires principaux.
Locataires créés par un service ou un employé : organisations où des services ou des employés ont créé des locataires pour le développement, le test ou le contrôle distinct.
Pour vous donner un exemple concret, ce scénario peut se présenter quand une entreprise en rachète d’autres. Bien souvent, celles-ci ont chacune un environnement 365 déjà en place, et l’idée d’une migration de tenant à tenant est considérée comme trop lourde.
Pour faire simple, l’organisation à multi-tenants continue elle aussi de s’appuyer sur la synchronisation entre tenants d’Entra ID : Les utilisateurs de votre tenant sont alors provisionnés dans les autres tenants de l’organisation en tant qu’utilisateurs de collaboration B2B.
Peut-on gérer une organisation multi-tenants dans Microsoft 365 ?
Au-delà les différents mécanismes possibles de collaboration sur Entra ID, Microsoft a rajouté ce niveau d’organisation multi-tenants dans la console d’administration de Microsoft 365 :
Note : L’activation antérieure de la synchronisation entre tenants d’Entra ID ne gêne en rien la mise en place d’une organisation multi-tenants. Celles-ci continueront toujours de fonctionner :
Afin de se faire une meilleure idée de l’ensemble de tenants, je vous propose de mettre en place une organisation multi-tenants à partir de 2 tenants B2B non connectés.
Voici les différentes étapes de l’exercice que je vous propose :
Avant la moindre configuration, j’ai testé le bon fonctionnement du chat EXTERNE de Teams entre 2 utilisateurs des 2 tenants :
Microsoft nous le rappelle bien : tenanta user1 fait partie d’une organisation. Il est possible qu’ils aient des politiques liées aux messages qui s’appliquent au chat.
Nous allons donc maintenant déployer une organisation multi-tenants depuis la console d’administration de Microsoft 365.
Etape I – Configuration de l’organisation multi-tenants :
La fonction d’organisation multi-tenants est encore en préversion à l’heure où ces lignes sont écrites. Il est donc nécessaire d’activer l’option de livraison ciblée sur les 2 tenants de test.
Attendez quelques minutes, puis rafraîchissez cette même page afin de voir apparaître le menu suivant :
Effectuez cette opération sur les 2 tenants.
Dans ce menu, commencez par démarrer le processus de mise en place de l’organisation multi-tenants en cliquant ici :
Sélectionnez le premier choix afin de créer l’organisation multi-tenants :
Avant d’aller plus loin, ouvrez un second navigateur internet afin de copier sur cette page l’identifiant tenant ID du second environnement :
Renseignez les champs et collez le tenant ID récupéré précédemment :
Cliquez sur Suivant :
Cochez les deux cases suivantes pour valider la synchronisation entrante, puis cliquez sur Suivant :
Cliquez sur le bouton ci-dessous pour valider et démarrer le processus de création de l’organisation multi-tenants :
Copiez le lien ci-dessous afin de terminer le processus de création dans le second tenant de test :
Dans votre second navigateur, rendez-vous sur le lien copié précédemment, puis cliquez-ici pour valider la synchronisation entrante :
Cliquez sur Terminer :
Le message suivant apparaît pour vous indiquer que le processus d’intégration du second tenant est en cours. Cliquez-ici plusieurs fois pour rafraichir le processus :
Quelques minutes plus tard, le lien de synchronisation est bien confirmé dans sur les deux tenants de notre organisation multi-tenants :
Sur les 2 tenants, cliquez ici pour partager un groupe d’utilisateurs vers l’autre tenant :
Après cela, cliquez sur les deux tenants de destinations afin de vérifier la bonne prise en compte des utilisateurs présentes dans vos 2 groupes Entra ID à synchroniser :
La configuration de l’organisation multi-tenants depuis le portail d’administration de Microsoft 365 est maintenant terminée. La synchronisation multi-tenants devrait se lancer sous peu.
Afin d’en savoir un peu plus, rendez-vous sur le portail d’Entra ID juste ici.
Etape II – Configuration de la synchronisation multi-tenants :
Grâce à la configuration de l’organisation multi-tenants, Entra ID a automatiquement préconfiguré la synchronisation multi-tenants.
Cliquez sur le menu suivant d’Entra ID pour découvrir les paramétrages effectués sur vos 2 tenants :
Cliquez sur les 2 configurations créées :
Visualisez les différentes informations disponibles, dont l’intervalle d’approvisionnement fixe :
Configurez-ici si besoin les notifications par email, puis sauvegardez :
Analysez les personnalisations possibles concernant les attributs d’Entra ID :
Quelques minutes plus tard, retournez sur les listes d’utilisateurs respectives de vos 2 tenants afin de constater l’apparition d’utilisateurs synchronisés :
Notez l’absence de synchronisation des groupes Entra ID, seuls des utilisateurs des groupes sélectionnés sont synchronisés :
Consultez et comparez sur les 2 tenants les propriétés synchronisées (ou non) d’un utilisateur concerné :
Il est également possible de lancer, sans attendre, une synchronisation manuelle.
Afin de tester cela, renseignez un titre de poste sur un autre utilisateur synchronisé :
Rendez-vous dans le menu suivant pour lancez la synchronisation à la demande :
Recherchez l’utilisateur à synchroniser, puis démarrez le traitement :
Attendez quelques secondes, puis constatez le changement de titre de poste sur le second tenant :
A noter qu’il n’est pas possible d’effectuer la synchronisation inverse depuis le tenant de destination :
Notre configuration est maintenant en place. Nous allons pouvoir effectuer différents tests entre nos deux utilisateurs de test :
tenanta-user1@jean0loup.onmicrosoft.com
tenantb-user1@tdsynnexchlab.onmicrosoft.com
Pour rappel, ces utilisateurs sont représentés de la façon suivante dans les 2 tenants de destination :
Depuis les 2 machines virtuelles, ouvrez le client Microsoft Teams. Pour une meilleure expérience utilisateur, activez le nouveau Teams :
Depuis l’écran des paramétrages de Teams, activez la prise en charge des 2 tenants :
Sur le 2 sessions Teams, recherchez les utilisateurs invités respectifs. Notez la présence d’utilisateurs externes précédemment utilisés pour communiquer :
Commencez la communication sur les utilisateurs NON EXTERNE :
Notez les points suivants :
La présence de 2 notifications Windows respectives
La présence de 2 notifications Teams respectives
L’incohérence dans le fil de discussion dans l’écran en tâche de fond
Un clic sur les 2 notifications Teams respectives permet de permuter sur le second tenant :
De retour sur les tenants de départ, commencez la création d’une équipe Teams :
Ajoutez dans celle-ci l’utilisateur invité du second tenant, puis cliquez sur Ajoutez :
Postez un nouveau message d’équipe en citant le second utilisateur comme ceci, afin de constater l’absence de notifications Teams :
Enfin, testez la fonctionnalité d’appel de Teams afin de constater la présence de notifications sur le second utilisateur :
Les quelques tests sur Microsoft Teams ont pu démontrer une bonne intégration des environnements multi-tenants, mais des efforts sur les notifications sont encore à faire.
Pour l’instant, je trouve que la communication via des comptes utilisateurs EXTERNES est encore plus simple.
Continuons les tests avec SharePoint Online.
Etape IV – Test de SharePoint Online :
Créez un nouveau site SharePoint online avec des droits au second utilisateur de test, puis ajoutez-y des fichiers.
Copiez / collez l’URL du site SharePoint Online dans la navigateur de la second VM, puis authentifiez-vous :
Vérifiez la bonne ouverture d’un des fichiers présents :
SharePoint Online fonctionne donc sans souci avec les utilisateurs synchronisés, continuons avec Exchange Online.
Etape V – Test d’Exchange Online :
Configurez une boite mail partagée sur un des 2 tenants, puis ajoutez-y des droits au second utilisateur de test :
Depuis Exchange Online, ouvrez sur les 2 sessions la boite mail partagée créée précédemment via la fonction Ouvrir une autre boîte aux lettres :
Saisissez le nom de la boite mail partagée, puis cliquez sur Ouvrir :
Constatez la présence d’un message d’erreur sur la seconde session :
Essayez si besoin avec le client Outlook local :
Là encore, l’expérience utilisateur ne sera pas encore fonctionnelle :
Je suppose que le point concernant Outlook repose encore sur le fait que les boîtes mails partagées n’acceptent toujours pas de comptes invités.
Conclusion :
Microsoft continue d’avancer avec sa solution d’organisation multi-tenants et cela facilite grandement la création d’utilisateurs ayant des droits SharePoint / OneDrive sur plusieurs entreprises. Mais il y a encore des difficultés dans la partie Teams, au niveau des notifications, et dans la partie Outlook dans la partie authentification.
Nul doute que d’autres améliorations encore à venir afin que les utilisateurs de tenants différents puissent encore accroitre leurs synergies.
Cette semaine, Microsoft vient juste d’annoncer la disponibilité générale (GA) de fonctionnalités récentes liées à l’Accès Conditionnel, et très présent au cœur d’Entra ID. L’ajout de tableaux de bord sur plusieurs ressources (utilisateurs, périphériques et applications) faciliteront grandement le contrôle de la bonne couverture des polices d’accès conditionnels sur les besoins.
Tous les environnements informatiques sont en quête d’une protection toujours plus efficace pour se prémunir des intrusions extérieures. L’ouverture des architectures IT au travers du Cloud apporte une plus grande disponibilité de l’information aux utilisateurs, mais occasionne un plus de grand nombre de connexions à distances, et donc de situations sécuritaires à gérer.
Le périmètre de sécurité moderne s’étend au-delà du périmètre réseau d’une organisation pour inclure l’identité de l’utilisateur et de l’appareil. Les organisations utilisent désormais des signaux basés sur l’identité dans le cadre de leurs décisions de contrôle d’accès.
L’accès conditionnel repose sur un certain nombre de signaux ou paramètres d’entrée. Ces derniers sont les éléments mêmes qui caractérise la connexion de l’utilisateur, tels que :
Emplacement (adresse IP)
Appareil (OS, version, conformité, …)
Utilisateur Entra ID
Application interrogée
IA (Détection des risques en temps réel géré par Entra ID Identity Protection)
Qu’est-ce qu’une Décision pour Entra ID ?
La décision est le résultat dicté par la police d’accès conditionnel en correspondance avec les signaux. Il est possiblement question de bloquer l’accès à l’utilisateur, ou de l’autoriser selon des conditions particulières. Ces conditions correspondent à des mesures de sécurité supplémentaires, telles que :
Exiger une authentification multifacteur (cas plus utilisé)
Exiger que l’appareil soit marqué comme conforme
Exiger un appareil joint en hybride à Entra ID
Exiger une stratégie de protection des applications
Qu’est-ce qu’une Option d’application pour Entra ID ?
Ces options apportent une supervision de session et des accès de l’utilisateur telles que :
Empêcher l’exfiltration des données
Protéger lors du téléchargement
Empêcher le chargement de fichiers sans label
Bloquer les programmes malveillants potentiels
Surveiller les sessions utilisateur pour la conformité
Bloquer l’accès
Doit-on disposer de licence pour utiliser l’accès conditionnel ?
Rappel important : Mi-juillet 2023, Microsoft a annoncé renommer son service Azure AD (Azure Active Directory). Ce changement est encore en cours et devrait être finalisé pour la fin de cette année. Cette simplification de dénomination est en cohérence avec le périmètre de la gestion identitaire élargie et gérée par le Cloud de Microsoft.
Cela a aussi pour conséquence un léger changement de nom de certaines licences :
L’utilisation de l’accès conditionnel d’Azure AD est une composante des licences Microsoft Entra ID Premium P1/P2. Vous retrouvez donc le service d’accès conditionnel dans un grand nombre de licences utilisateurs, dont les suivantes :
Microsoft Entra ID Premium P1
Microsoft Entra ID Premium P2
Enterprise Mobility + Security E3
Enterprise Mobility + Security E5
Microsoft 365 Business Premium
Microsoft 365 A3
Microsoft 365 A5
Microsoft 365 F1
Microsoft 365 F3
Microsoft 365 F5 Security
Microsoft 365 F5 Security + Compliance
Je vous remets également le lien vers le site très utile créé par Aaron Dinnage :
Qu’est-ce qu’alors la licence directement renseignée au niveau du tenant ?
Cette question me revient très souvent 😉. Il faut savoir que cette information provient des licences assignées aux utilisateurs du tenant. Ce n’est pas à proprement parler d’une licence ou un service du tenant :
Certains services clients ne sont actuellement pas en mesure de limiter les avantages à des utilisateurs spécifiques. Nous vous recommandons d’acquérir des licences pour tout utilisateur dont vous avez l’intention de bénéficier et/ou d’accéder au service.
Autrement dit, une seule licence ayant la fonctionnalité d’accès conditionnel active l’option pour l’ensemble des utilisateurs du même tenant. Seulement, les règles d’utilisation du service exigent que chaque utilisateur soit couvert par une licence disposant de cette fonctionnalité.
Maintenant que la partie licence est clarifiée, nous allons pouvoir nous intéresser aux principales fonctionnalités de l’accès conditionnel.
Pour vous rendre sur les règles d’accès conditionnel, allez sur la page suivante d’Entra ID dédiée :
Voici quelques fonctionnalités de l’accès conditionnel d’Entra ID que je vous propose d’étudier :
La page d’accueil de l’accès conditionnelle a été revue pour afficher plusieurs informations essentielles aux équipes IT :
C’est vraiment ce qui manquait à ce service : la visibilité. Il est maintenant beaucoup plus simple de comprendre d’un rapide coup d’œil les éléments suivants :
Polices actives ou non : les polices d’accès conditionnel ont 3 statuts possibles. Le mode « Rapport seulement » est utile pour contrôler l’impact durant une phase de test sans perturber les utilisateurs.
Utilisateurs : Affiche le nombre d’utilisateurs ayant pu s’authentifier sans passer par aucune police d’accès conditionnel.
Périphériques: Affiche le nombre de poste étant non managés ou non conformes.
Applications : lien vers une liste des applications couvertes et non couvertes par une police d’accès conditionnel
Par exemple, un clic sur la première rubrique affiche le journal d’événements d’ouverture de session avec les filtres adéquats :
Un clic sur les applications ou sur l’onglet Couverture montre 2 différents tops applications :
Top des applications non couvertes par un accès conditionnel
Top des applications couvertes par un accès conditionnel
Là encore, un clic est possible pour basculer à nouveau sur le journal des événements d’ouverture de sessions afin d’identifier plus facilement les utilisateurs concernés par l’application ciblée :
Microsoft a même pensé au graphique afin d’améliorer la prise de vue dans son ensemble de ce que représente les accès conditionnés à ceux en étant dépourvues :
Voici une nouvelle vidéo qui résume bien ce nouvel écran :
Fonctionnalité II – Création d’une police :
Le véritable moteur de l’accès conditionnel d’Entra ID est : la police.
Depuis longtemps, il est possible de créer une police d’accès conditionnel depuis une feuille blanche. Vous devrez alors choisir parmi toutes les options disponibles dans les sections suivantes :
Utilisateur(s) : cible la police sur un utilisateur, un groupe d’utilisateurs ou même des utilisateurs selon leurs rôles. Il est même possible d’exclure des utilisateurs selon ces mêmes règles.
Destination(s) cible(s) : cible une ou plusieurs applications Cloud créées sur votre tenant. Là encore, Il est même possible d’exclure des applications si nécessaire.
Condition(s) : ajoute des conditions (ou signaux) présents au moment de l’authentification. Comme le risque calculé par Entra ID Identity Protection ou encore la localisation du poste.
Condition(s) d’accès : détermine si l’accès est bloqué et cela même si le processus d’authentification est réussi, ou conditionne l’accès selon des critères supplémentaires : MFA, poste conforme…
Contrôle(s) de session : renforce si besoin les conditions de persistance de la session au sein de l’application.
Fonctionnalité III – Création d’une police à partir d’un modèle :
Microsoft a proposé il y a plusieurs mois déjà de simplifier la création de police d’accès conditionnel en proposant des modèles de départ :
Ces modèles de base sont classifiées dans les 5 sections suivantes :
Vous pouvez à tout moment changer le statut de votre police. Cela permet de désactiver celle-ci si les résultats sécuritaires obtenus ne sont pas ceux attendus :
Fonctionnalité IV – Test d’une police avec la fonction « Et si » :
Tester une police d’accès conditionnel est possible avec un utilisateur de test ou via la fonction Et si. Cette second option est très utile si l’utilisateur n’est pas disponible ou si le scénario de test demande des conditions très particulières.
Un grand nombre de paramètres (signaux) sont disponibles pour réaliser des tests dans tous les sens :
Et le résultat ne se fait pas attendre, notre nouvelle police d’accès conditionnel créée à partir d’un modèle joue bien son rôle :
Fonctionnalité V – Déclaration de lieux nommés :
Par exemple, quand des lieux sont considérés comme des sites de l’entreprise et que la sécurité réseau est géré par le service IT, il devient utile de les renseigner ici :
Cela permet alors de créer des règles d’accès conditionnel plus précises en incluant ou excluant ces lieux :
Fonctionnalité VI – Configuration d’une MFA renforcée :
L’authentification multi-facteurs est devenue la norme pour s’authentifier sur Internet. Mais toutes les méthodes multi-facteurs ne se valent pas. Microsoft propose de laisser le choix des méthodes MFA aux administrateurs :
Par exemple, ils peuvent faire en sorte que seules les méthodes d’authentification résistantes au hameçonnage soient disponibles pour accéder à une ressource sensible. Toutefois, pour accéder à une ressource non sensible, ils peuvent autoriser des combinaisons d’authentification multifacteur (MFA) moins sécurisées, telles que mot de passe + SMS.
Plusieurs méthodes de MFA renforcées sont déjà disponibles et il est aussi possible de créer les siennes :
Il suffit après d’appeler ces méthodes de MFA renforcées dans la configuration de la police d’accès conditionnel :
Conclusion :
L’accès conditionnel sous Entra ID a réussi s’imposer comme la référence de base dans l’autorisation d’accès aux ressources de l’entreprise. Les personnalisations possibles et la prise en compte d’exclusions apporte beaucoup de souplesse et évite la fatigue sécuritaire chez les utilisateurs. Nul doute que d’autres fonctionnalités sont encore à venir 😎.
Configurer la sécurité sur Azure en seulement 10 minutes ? Et pourquoi pas en 9 minutes ? Cette course au temps ne veut rien dire ! La sécurité est une tâche constante, et passe presque toujours par différentes phases, comme la découverte, l’analyse et la configuration. Néanmoins, une approche directe est malgré tout possible sur certains éléments élémentaires de sécurité.
Microsoft le rappelle très régulièrement, le premier risque identifié provient d’identités mal sécurisées :
Chaque jour, plus de 300 millions de tentatives de connexion frauduleuses à nos services Cloud sont enregistrées. Les cyberattaques ne ralentissent pas, et il convient de noter que de nombreuses attaques ont réussi sans l’utilisation de technologies avancées. Il suffit d’une seule d’identité compromise… pour provoquer une violation de données. Cela montre à quel point il est essentiel de garantir la sécurité des mots de passe et une authentification forte.
Déjà par lire mon article sur la sécurité, accessible juste ici ????. Plus sérieusement, commencer par assimiler quelques notions, comme la défense en profondeur ou le Zéro Trust.
Principe de sécurité en couche
Comme un oignon, chaque couche de sécurité apporte des mesures, passives ou actives, empêchant ou retardant l’accès à la donnée, élément critique de toute entreprise :
Qu’est-ce que TD SYNNEX peut faire pour ma sécurité ?
Travaillant chez TD SYNNEX depuis plusieurs années, j’accompagne des partenaires IT dans la conception d’architecture sur Azure. La collaboration entre Microsoft et TD SYNNEX est très forte, nous distribuons tous les produits Cloud de Microsoft via une marketplace.
Disposant de compétences techniques en interne, nous développons aussi nos propres solutions pour faciliter et automatiser toujours plus la mise en place de solutions innovantes sur Azure.
Concernant la sécurité, TD SYNNEX n’est pas en reste et propose une nouvelle solution appelée SMB Fraud Défense. Il s’agit d’une solution, dite Click-to-Run, donc prête à l’emploi : quelques clics suffisent pour mettre en place la solution sur un tenant Azure.
Que fait exactement la solution SMB Fraud Defense ?
Voyez un tenant Microsoft comme une maison : les identités et les périphériques sont les portes et les fenêtres. Il est donc évident que ces points des entrées à la donnée :
Des mesures de sécurité sont nécessaires protéger la donnée. Voici une liste non exhaustive des fonctionnalités facilement activables depuis SMB Fraud Defense :
Protection des identités Azure AD :
Création de scénarios d’accès conditionnel avec MFA
Restriction géographique par pays
Blocage d’anciens protocoles d’authentification
Gestion de l’expiration des mots de passe
Verrouillage des identités intelligent
Protection des ressources Azure :
Mise en place de budgets et notifications
Restrictions géographiques
Restrictions de familles de machines virtuelles
Combien coûte SMB Fraud Defense ?
Rien du tout ????, aucun frais à prévoir du côté de TD SYNNEX ou de Microsoft.
Comment procède-t-on pour déployer SMB Fraud Defense ?
Quelques étapes sont nécessaires et sont décrites dans les lignes de cet article, rien de plus.
Etape 0 – Rappel des prérequis :
Avant tout, le déploiement d’une solution Click-to-Run nécessite la mise en place d’un partenariat entre un vous et TD SYNNEX. En effet, ces solutions ne sont disponibles à l’achat qu’uniquement depuis notre Marketplace. Pour cela, cliquez ici.
Le second prérequis est de disposer d’un tenant Azure et d’une souscription Azure Plan acheté via la Marketplace de TD SYNNEX.
Etape I – Achat de la solution Click-to-Run SMB Fraud Defense :
Comme indiqué plus haut, SMB Fraud Defense est gratuit mais demande malgré tout par un provisionnement par depuis la Marketplace de TD SYNNEX.
Une fois votre Azure Plan en place, cliquez sur Modifier :
Parcourez la liste des solutions Click-to-Run disponibles à l’installation, et cliquez sur Acheter SMB Fraud Defense :
Note : La mise en place de la solution vous alerte sur l’incompatibilité avec des solutions MFA externe à Azure
Une fois que vous avez accepté ce message, la plate-forme vérifie la bonne configuration initiale du tenant :
Etape II – Déploiement de la solution Click-to-Run SMB Fraud Defense :
Juste avant de déployer SMB Fraud Defense, il est nécessaire de préparer 3 conditions sur le tenant cible, car la solution analyse les 3 points suivants :
Paramètre de sécurité par défaut d’Azure
Gestionnaire de coûts Azure
Souscription d’une licence Azure AD Premium (Plan 1 ou Plan 2)
Voici un détail point par point pour réussir la préparation et leur statut attendu :
Paramètre de sécurité par défaut d’Azure – désactivé :
La mise en place d’une sécurité personnalisée nécessite la désactivation de la sécurité par défaut d’Azure. Voici ce que cette dernière contient.
Sa désactivation est donc possible via ce menu :
Mais elle est aussi désactivable via le portail d’Azure AD :
Désactivez alors celle-ci en spécifiant un motif justifiant l’opération :
Gestionnaire de coûts Azure – Activé :
La mise en place de budget et d’alerte sur la consommation Azure nécessite l’activation du gestionnaire de coûts Azure.
En effet, la mise en place d’une souscription Azure Plan via un partenaire CSP ne l’active pas par défaut. Il est donc nécessaire de vous rapprocher de votre fournisseur CSP pour l’activation du Gestionnaire de coûts.
Souscription d’une licence Azure AD Premium Plan 1 ou Plan 2 – Souscrite :
La mise en place de l’accès conditionnel sur Azure AD nécessite de disposer d’une licence Azure AD Premium Plan 1 ou Plan 2 :
Pour un déploiement optimal, il est conseillé d’en disposer pour profiter de l’ensemble des avancées de SMB Fraud Defense, comme l’accès conditionnel avec prise en compte de l’évaluation du risque à la connexion.
Vous pouvez activer une licence Azure AD Premium Plan 2 en version d’essai directement depuis le portail Azure AD :
Une fois la version d’essai activée, pensez à affecter une licence Azure AD Premium Plan 2 à un utilisateur votre tenant.
Une fois ces 3 points corrects sur votre environnement, vous pouvez commencer la configuration sur chacun des onglets :
Etape III – Configuration de la solution Click-to-Run SMB Fraud Defense :
Cette configuration est divisée en 5 onglets :
Localisation
Budget
Accès conditionnel
Méthodes d’authentification
Polices
Note : cliquez sur Déployer à la fin, une fois seulement tous les onglets configurés.
A / Localisation
Des informations sont nécessaires pour le bon déploiement des polices Azure. Pour cela, choisissez une région Azure dans le menu déroulant et spécifiez le nom d’un groupe de ressources :
B/ Budget
La mise en place d’un budget est une bonne approche pour suivre la consommation Azure en fonction de l’estimation faite au début du projet :
La mise en place d’alertes l’est tout autant pour éviter les dépassements et donc les factures salées :
Vous pouvez indiquer plusieurs adresses emails pour les notifications.
C/ Accès conditionnel
La gestion identitaire d’Azure passe par Azure Active Directory (Azure AD). La sécurisation d’environnement Azure passe donc avant tout par celui-ci.
Vous pouvez contrôler l’accès à vos applications cloud basées sur l’emplacement réseau d’un utilisateur. La condition d’emplacement est couramment utilisée pour bloquer l’accès à partir des pays/régions d’où votre organisation sait que le trafic ne doit pas provenir :
La MFA propose donc d’aller plus loin que le couple classique identifiant / mot de passe. L’authentification multifacteur d’Azure AD impose de mettre en place les 3 méthodes d’authentification suivantes :
Un élément que vous connaissez (ex. mot de passe)
Un élément que vous possédez (ex. un appareil de confiance, comme un smartphone)
Un élément qui vous définit : (ex. identifiant biométrique, tel qu’une empreinte digitale)
Les périphériques et les applications accédant à vos données se doivent d’être protégés.
Il est toujours utile de joindre les périphériques à Azure AD. Comme pour un Active Directory, la connaissance de ces derniers apporte une meilleure maitrise de la sécurité lors de la création de règles de sécurité :
N’ayant pas de poste joint à Azure AD sur cet environnement de démo, je n’active donc pas ces 2 options dans la configuration.
D/ Méthodes d’authentification
Toujours sur la protection des identités, certaines options supplémentaires sont encore configurables :
Le verrouillage intelligent empêche les attaquants de pénétrer dans le système, tout en permettant à vos utilisateurs d’accéder à leur compte et de travailler :
Le déploiement local de Protection de mots de passe d’Azure AD utilise les mêmes listes globales et personnalisées de mots de passe interdits qui sont stockées dans Azure AD, et effectue les mêmes vérifications des modifications de mot de passe localement :
Comme annoncé avant, la validation en deux étapes permet de renforcer la sécurité de votre compte Microsoft en exigeant une deuxième étape de validation lorsque vous vous connectez.
En plus de votre mot de passe, vous pouvez générer un code par l’application Microsoft Authenticator sur votre téléphone :
Autrement, le standard de sécurité FIDO2 répond à ce problème en s’appuyant là aussi sur une authentification à deux facteurs basés sur l’utilisation de clés de sécurité (clés FIDO2) et de tokens (jetons d’authentification) :
E/ Polices
Les polices d’Azure sont un moyen de contrôler les déploiements des ressources. La solution SMB Fraud Defense vous propose de restreindre les SKUs de familles de machines virtuelles. Cela bloque alors les SKUs les plus coûteux :
Azure offre à ses clients la flexibilité de déployer des applications là où ils en ont besoin. Une région Azure a une tarification et une disponibilité de service distinctes.
Ici, Il est vous possible de restreindre le déploiement sur certaines régions Azure, mais aussi d’activer d’autres fonctionnalités de sécurité :
Tous les onglets ont maintenant été passés en revue, il ne vous reste qu’à déployer la configuration.
Etape IV – Déploiement de la solution Click-to-Run SMB Fraud Defense :
Pour cela, cliquez ici pour lancer le déploiement et attendez quelques minutes :
Une fois le déploiement terminé, un email de notification est également envoyé, et le status de la solution C2R change :
Etape V – Contrôle du déploiement sur le tenant :
Le déploiement est maintenant terminé, une vérification sur le tenant permet de s’assurer la présence de toutes les options choisies durant la phase de la configuration.
A / Localisation
Consultez votre portail Azure et vérifiez la présence du groupe de ressources sur votre souscription Azure Plan :
B/ Budget
Toujours sur la souscription Azure, contrôler l’ajout du budget reprenant le montant configuré :
Cliquez dessus et éditez le pour vérifier la présence des 2 alertes :
C/ Accès conditionnel
La configuration de la restriction géographique s’effectue depuis le portail Azure AD. Consultez la sécurité pour voir l’apparition du pays sélectionné dans les zones de confiance :
Toujours dans Azure AD, chaque option activée a généré la création d’une ou plusieurs polices d’accès conditionnel, toujours en mode audit au moment du déploiement :
D/ Méthodes d’authentification
Le contrôle de la désactivation de l’expiration du mot de passe se fait via le portail Microsoft 365 :
Quant à lui, le contrôle du seuil de verrouillage du compte se fait via le portail Azure AD :
La configuration des deux méthodes MFA d’authentification se retrouve juste ici :
E/ Polices
Du côté d’Azure, contrôlez les polices déployées :
Un clic sur une police affiche le détail de la configuration, comme la région autorisée ou les SKUs interdits :
Conclusion
Alors, finalement nous ne sommes pas si loin des 10 minutes ???? ?
Plus sérieusement, je trouve que ce type de solution est une bonne approche quand on voit l’éparpillement des principales mesures de sécurité, qui sont maintenant indispensables pour sécuriser au minimum un tenant Microsoft.
SMB Fraud Defense de TD SYNNEX doit être perçue comme un point de départ à une configuration sécuritaire, et facile son automatisation lors de la création de tenants.
Enfin, il faut garder en tête que ce type de solution Click-to-Run évolue sans cesse chez TD SYNNEX, grâce aux feedbacks et aux évolutions du Cloud Microsoft ????
Rassurez-vous, Azure Virtual Desktop propose depuis longtemps une intégration avec l’accès conditionnel disponible sur Azure AD. Ce billet, datant déjà de 2019, écrit par Freek Berson, nous montre bien l’intégration entre AVD et FIDO2.
Je souhaitais malgré tout vous écrire un article en français pour détailler le processus de mise en place FIDO2 et les possibilités intéressantes avec AVD.
Qu’est-ce que FIDO2 (Fast IDentity Online 2) ?
La réponse de l’industrie au problème des mots de passe.
Exit donc l’utilisation d’un simple du mot de passe pour valider un processus d’authentification. FIDO2 a été développé par la FIDO Alliance et est à ce jour leur dernière norme.
FIDO2 est bâti sur des spécifications Web Authentication, ou WebAuthn, du World Wide Web Consortium (W3C), donc universel mais disposant de capacités supplémentaires.
Cette vidéo en français explique plusieurs de ces avantages :
USB-A ou C ou encore NFC
Absence de donnée personnelle sur la clef
Code PIN de protection
Zone de contact pour valider une présence physique
Utilisation pour plusieurs comptes
Bon conseil : toujours avoir deux clefs ????.
Puis-je utiliser une clef FIDO2 pour m’authentifier sur Azure AD ?
Oui, Azure AD supporte un grand nombre de méthodes renforcées pour sécuriser l’authentification des utilisateurs. Vous pouvez retrouver cette liste ici, ou dans le portail Azure, via la page des Méthodes d’authentification :
D’une manière générale, Microsoft déconseille l’utilisation unique de mot de passe pour authentifier un compte (Voir tableau ci-dessous). Azure AD propose à ce jour différentes méthodes dans le cadre d’un processus d’authentification multifacteur :
Windows Hello Entreprise
Microsoft Authenticator
Clés de sécurité FIDO2
Ai-je besoin d’une licence particulière pour utiliser FIDO2 ?
FIDO2 n’exige pas de licence particulière, mais l’accès conditionnel en demandera une. En effet, pour intégrer FIDO2 dans une ou plusieurs polices d’accès conditionnel, il vous faudra une licence Azure Premium P1 ou P2 pour tous les utilisateurs concernés.
Fonctionnalité
Azure AD Free – Paramètres de sécurité par défaut
Azure AD Free – Administrateurs généraux uniquement
Office 365
Azure AD Premium P1
Azure AD Premium P2
Accès conditionnel
●
●
Accès conditionnel basé sur les risques
●
Il ne faut pas confondre l’accès conditionnel qui vient en remplacement, car plus abouti et personnalisable que la MFA de base ou les paramètres de sécurité par défaut :
Stratégie
Paramètres de sécurité par défaut
Accès conditionnel
Authentification multifacteur par utilisateur
Gestion
Ensemble standard de règles de sécurité pour garantir la sécurité de votre entreprise
●
Activé/désactivé en un clic
●
Inclus dans la gestion des licences Office 365
●
●
Modèles préconfigurés dans l’assistant Centre d’administration Microsoft 365
●
●
Flexibilité de la configuration
●
Fonctionnalité
Exempter les utilisateurs de la stratégie
●
●
Authentification par appel téléphonique ou SMS
●
●
S’authentifier par Microsoft Authenticator et jetons logiciels
●
●
●
Authentification par FIDO2, Windows Hello Entreprise et les jetons matériels
●
●
Bloque les protocoles d’authentification hérités
●
●
●
Les nouveaux employés sont automatiquement protégés
●
●
Déclencheurs MFA dynamiques en fonction des événements à risque
●
Stratégies d’authentification et d’autorisation
●
Configurable en fonction de l’emplacement et de l’état de l’appareil
●
Prise en charge du mode « Rapport seul »
●
Où peut-on se procurer des clefs FIDO2 ?
Microsoft met à disposition cette liste de fournisseur proposant justement des clefs FIDO2 :
Pour effectuer mes tests sur mon environnement Azure, j’ai décidé d’acheter deux clefs USB-A sous forme de pack auprès de Token2 Switzerland, au prix de 23€, frais de port compris :
Comment procède-t-on pour intégrer FIDO2 à Azure Virtual Desktop ?
Le processus d’installation est très simple, il vous faudra néanmoins quelques prérequis pour arriver à une intégration complète. Dans ce tutoriel, nous allons mettre en place une clef FIDO2 pour un utilisateur et créer deux polices d’accès conditionnel dédiées à AVD :
Etape 0 – Rappel des prérequis :
Les prérequis suivants sont nécessaires pour réaliser cette démonstration avec AVD :
Un poste sous Windows 10 (1903) ou supérieur
Un tenant Microsoft
Une souscription Azure valide
Un environnement AVD déployé (je vous conseille de suivre ce tutoriel)
Une licence Azure AD Premium Plan 1 ou Plan 2
Si votre tenant ne dispose d’aucune licence Azure AD Premium, vous pouvez activer une licence Azure AD Premium Plan 2 en version d’essai directement depuis le portail Azure AD :
Une fois la version d’essai activée, pensez à affecter une licence Azure AD Premium Plan 2 à un utilisateur votre tenant.
Etape I – Configuration du code PIN :
Azure AD exige que les clés de sécurité soient protégées par un code PIN. Insérer votre clef FIDO2 dans un port USB et allez dans les paramètres de votre poste pour le définir :
Cliquez ici pour configurer la clef :
Touchez la zone prévue à cet effet pour continuer :
Définissez un code PIN et confirmez-le :
Etape II – Activation de FIDO2 sur Azure AD :
Sur le portail d’Azure AD, consulter les paramètres de Sécurité via le menu suivant :
Cliquez sur Méthodes d’authentification :
Cliquez sur la ligne FIDO2 :
Activez la fonctionnalité FIDO2, puis cliquez sur Configurer :
Sauvegardez-là avec les options de base :
Quelques minutes sont parfois nécessaire pour continuer sur la configuration FIDO2 au niveau de l’utilisateur. Ne vous inquiétez pas si les écrans suivants ne sont pas encore identiques au tutoriel.
Etape III – Enrôlement d’une clef FIDO2 sur un compte Azure AD :
Comme dit précédemment, la clef FIDO2 n’embarque aucune information personnelle sur les comptes associés à celle-ci. Vous pouvez donc sans souci utiliser la même clef pour plusieurs comptes Azure AD.
Dans mon cas, j’ai créé un nouvel utilisateur pour retester un enrôlement complet.
Rendez-vous sur la page myaccount de Microsoft avec votre utilisateur de test, puis cliquez les Informations de sécurité :
Cliquez ici pour ajouter la première clef FIDO2 :
Dans mon cas, Azure m’avertit que mon utilisateur de test ne dispose d’aucune autre méthode MFA, j’en profite donc pour mettre en place le SMS comme seconde méthode :
Une fois terminé, recommencez le processus pour arriver sur cet écran :
Azure AD entame une communication avec la clef FIDO2 :
Plusieurs messages d’information de Windows 10 vont se succéder :
Renseignez le PIN de votre clef FIDO2, puis continuez :
Touchez la zone prévue à cet effet pour terminer :
Il ne vous reste plus qu’à donner un nom à cette première clef FIDO2 :
Comme il est fortement conseillé, recommencer la même opération avec une seconde clef FIDO2, utilisable en cas de secours :
Etape IV – Test de FIDO2 :
Avant d’aller plus loin dans l’intégration avec Azure Virtual Desktop, je vous conseille de tester l’authentification utilisateur avec sa clef FIDO2. Pour cela ouvrez le navigateur de votre choix en mode privé et allez sur la page web office.com.
Cliquez-ici pour vous authentifier :
Au lieu de saisir le mot de passe du compte de test, cliquez comme ceci :
Renseignez le code PIN de votre clef FIDO2 :
Touchez la zone prévue à cet effet pour confirmer l’authentification :
Cliquez enfin sur Non :
Et vous voilà correctement authentifié sur le portail Office365 ????
Etape V – Création d’une méthode d’authentification renforcée :
En faisant différents tests, je me suis rendu compte que l’on pouvait intégrer le mécanisme FIDO2 à plusieurs niveaux d’AVD.
Encore en préversion à ce jour, connectez-vous au portail d’Azure et rendez-vous dans le service Azure AD avec un compte administrateur adéquat :
Ouvrez le menu Sécurité :
Cliquez sur Méthodes d’authentification :
Cliquez sur Méthodes d’authentification renforcées pour en ajouter une nouvelle :
Terminez la création de celle-ci :
Etape VI – Test de l’accès conditionnel au premier niveau :
Toujours dans votre portail Azure AD, retournez dans la section Sécurité puis cliquez sur Accès conditionnel :
Créez votre nouvelle Police :
Saisissez un nom à votre police et sélectionnez votre utilisateur de test :
Ajoutez l’application Azure Virtual Desktop :
Terminez la configuration en autorisant l’accès sous réserve de satisfaire votre nouvelle méthode d’authentification renforcée :
Attendez quelques minutes et ouvrez votre client Windows d’Azure Virtual Desktop pour tester votre première police d’accès conditionnel :
Renseignez le compte Azure de votre utilisateur de test et constatez la présence de ce message :
Touchez la zone prévue à cet effet pour terminer l’authentification :
Félicitations ! Votre accès AVD est bien protégé par la clef FIDO2 ????.
Etape VII – Test de l’accès conditionnel au second niveau :
En parcourant les fonctionnalités de l’accès conditionnel d’Azure AD, j’ai remarqué une seconde application du Cloud Azure très intéressante :
J’ai donc créé une seconde règle d’accès conditionnel, avec les mêmes autres paramètres pour intégrer un mécanisme FIDO2 au moment de l’ouverture de session Windows d’AVD :
Sur votre application Azure Virtual Desktop, cliquez sur l’icône pour ouvrir une session AVD :
Attendez que le processus continue :
Choisissez le compte autorisé à AVD et disposant d’une clef FIDO2 :
Renseignez le code PIN de votre clef FIDO2 :
Touchez la zone prévue à cet effet pour confirmer l’authentification :
Attendez que la session AVD s’ouvre :
Conclusion
Cette combinaison AVD + AD + FIDO2 fut très intéressante à tester, et assez simple à mettre en place. Cette flexibilité nous montre aussi l’infinité de scénarios possibles pour augmenter la sécurité des utilisateurs sans pour autant rendre le quotidien lourd ou invivable.
Enfin, profitez-en pour sécuriser un peu plus vos comptes à vous ????
La jointure d’appareil à Azure AD est un sujet à lui tout seul. Celle-ci apporte pourtant un grand nombre de bénéfices pour la sécurité de son environnement 365 grâce à aux polices de compliance ou d’accès conditionnels. Très régulièrement, une confusion émane en provenance des messages parlant de jointure à Azure AD. Souvent ambigus, ils sont provoqués par l’authentification d’un utilisateur à un service 365 du Cloud Microsoft.
Dans cet article, nous allons apprendre les différents types de jointures possible à Azure AD notions et effectuer plusieurs tests sur un environnement de démo.
Qu’est-ce qu’Azure AD ?
Pourquoi joindre un appareil à Azure AD ?
Les appareils joints Azure AD ont pour objectif de simplifier :
Les déploiements Windows sur des appareils professionnels
L’accès aux applications .365 et aux ressources de l’organisation à partir de n’importe quel appareil Windows
Gestion cloud des appareils professionnels
Aux utilisateurs de se connecter à leurs appareils à partir de leurs comptes Azure AD ou Active Directory synchronisés professionnels ou scolaires.
Existe-t-il plusieurs types de jointure à Azure AD ?
Cette question a plusieurs réponses possibles et le choix va dépendre de l’identité du propriétaire des données, de la personne qui gère l’appareil et du type d’identification de l’utilisateur utilisé pour l’authentification :
Inscrire un appareil sur Azure :
L’objectif des appareils inscrits sur Azure AD (également appelés appareils joints à l’espace de travail) est de fournir à vos utilisateurs la prise en charge des scénarios d’appareil mobile et Bring Your Own Device (BYOD). Dans ces scénarios, un utilisateur peut accéder aux ressources de votre organisation à l’aide d’un appareil personnel.
Appareil appartenant à une entreprise et géré par elle
L’authentification au dispositif se fait à l’aide d’un identifiant local ou d’un identifiant personnel dans le Cloud.
Authentification aux ressources de l’entreprise à l’aide d’un identifiant d’utilisateur sur AAD.
Joindre un appareil sur Azure :
Les appareils joints Azure AD sont connectés au moyen d’un compte professionnel Azure AD. L’accès aux ressources peut être contrôlé en fonction du compte Azure AD et des stratégies d’accès conditionnel appliquées à l’appareil. Les administrateurs peuvent sécuriser et mieux contrôler les appareils joints Azure AD à l’aide d’outils de gestion des périphériques mobiles (GPM), tels que Microsoft Intune ou dans des scénarios de cogestion à l’aide de Microsoft Endpoint Configuration Manager.
Pour effectuer ces tests, nous allons partir d’un environnement Azure et y déployer plusieurs machines virtuelles Azure. Avant cela, voici la courte liste des composants déjà présents sur mon environnement :
Tenant Azure
Souscription Azure valide
Un compte Azure AD avec une licence Office365
Test I : Jointure Azure AD : Inscription + MDM Intune
Déployez une première machine virtuelle avec Windows 10 dans votre souscription Azure comme ceci :
Connectez-vous en bureau à distance à cette dernière avec le compte administrateur local :
Exécutez la commande ci-dessous et constatez l’absence d’informations relatives à Azure AD :
dsregcmd /status
Exécutez l’application Office directement disponible via le menu Démarrer :
Cliquez comme ceci pour lancer le processus d’authentification 365 :
Choisissez l’option suivante et saisissez les identifiants de votre compte 365 :
Laissez cochée la case suivante et cliquez sur OK :
Un message de traitement apparaît alors et vous invite à attendre :
Fermez la fenêtre une fois le traitement réussi :
Relancez la commande précédente pour constater les changements relatifs à Azure AD :
dsregcmd /status
Retournez sur la page listant vos appareils dans le portail Azure AD :
Consultez également sur la page de vos appareils Windows dans le portail Intune :
Ce test nous apprend que la jointure à Azure AD n’est faite que sous forme d’inscription, mais que l’appareil est malgré tout gérable dans Intune. Ce scénario pourrait correspondre à un appareil personnel utilisé dans le cadre professionnel.
Test II : Jointure Azure AD : Inscription
Déployez une seconde machine virtuelle depuis votre Azure, identique à la première :
Ouvrez là encore une session de bureau à distance avec un utilisateur local.
Effectuez les mêmes opérations pour arriver jusqu’à l’écran ci-dessous. Mais décochez cette fois la case et cliquez sur OK :
Le message de traitement vous invitant à patienter est toujours présent :
Attendez la fin du traitement et fermez la fenêtre :
Lancez la commande suivante pour constater d’éventuels changements par rapport au précédent test de jointure :
dsregcmd /status
Retournez sur la page de vos appareils dans votre portail Azure AD et constatez l’apparition de cette seconde machine virtuelle :
La colonne MDM n’est pas remplie, cela s’explique par la case décochée précédemment.
Retournez sur la page de vos appareils Windows dans le portail Intune :
Comme attendu, la seconde machine virtuelle n’apparaît pas.
Ce second test nous apprend que la jointure à Azure AD n’est faite que sous forme d’inscription, et que l’appareil n’est pas gérable dans Intune. Ce scénario pourrait lui aussi correspondre à un appareil personnel utilisé dans le cadre professionnel.
Test III : Absence de jointure Azure AD
Déployez une troisième machine virtuelle Azure pour continuer à tester une autre possibilité de jointure.
Effectuez les mêmes opérations pour arriver jusqu’à cet écran. Cliquez sur Non, authentifiez-vous uniquement sur l’application :
Pas de traitement ou de message de fin.
Relancez la commande suivante pour voir d’éventuels changements avec les précédents tests :
dsregcmd /status
Un tour dans la liste des devices d’Azure AD pour constater une éventuelle apparition :
Aucune nouvelle machine virtuelle.
Il en est de même dans le portail Intune : 0 changement.
Ce troisième test nous apprend qu’aucune jointure à Azure AD, et que l’appareil n’est pas non plus gérable dans Intune. Ce scénario pourrait lui aussi encore correspondre à un appareil personnel utilisé dans le cadre professionnel.
Test IV : Jointure Azure AD : Join + MDM Intune
A l’inverse des tests précédents, la jointure de ce test va s’effectuer dans la configuration Windows.
Déployez une quatrième machine virtuelle Azure, toujours identique aux précédentes :
Connectez-vous sur votre machine virtuelle avec l’utilisateur local et allez dans les Comptes de vos Paramètres Windows :
Connecter votre compte Azure AD comme ceci :
Cliquez sur l’option ci-dessous pour joindre la machine virtuelle à un tenant Azure AD :
Renseignez le compte 365 de votre utilisateur :
Approuvez la jointure en cliquant sur Joindre :
Attendez que la jointure s’applique :
Le message de succès vous indique que vous pouvez maintenant utiliser votre compte Azure AD pour ouvrir la session Windows :
La jointure est bien confirmée grâce à l’indication suivante :
Pour vous connecter sur la machine virtuelle avec votre compte Azure AD, décochez la case suivante dans les propriétés système de celle-ci :
Fermez la session RDP ouverte précédemment.
Sur votre poste, modifiez le fichier RDP avec un éditeur de texte pour y ajouter les paramètres suivants :
enablecredsspsupport:i:0
authentication level:i:2
Cela donne un fichier contenant les lignes suivantes :
Ouvrez ce programme RDP et renseignez comme ceci votre compte 365 :
Sur cette nouvelle session RDP ouverte, exécutez la commande ci-dessous :
dsregcmd /status
Retournez et constatez la présence de cette nouvelle machine virtuelle dans la liste des appareils d’Azure AD, avec un nouveau type de jointure :
Il en est de même dans le portail Intune :
La quatrième machine virtuelle apparaît bien comme appartenant à l’entreprise.
A l’inverse des tests précédents, celui-ci nous apprend que la jointure à Azure AD complète, et que l’appareil est aussi gérable dans Intune. Ce scénario pourrait correspondre à un appareil professionnel utilisé dans le cadre professionnel.
Test V : Jointure Azure AD : Hybride AD / Azure AD
Ce nouveau test demandera un peu plus d’efforts. Pour y arriver, il va nous falloir disposer d’un domaine Active Directory. Commencez donc par créer une première machine virtuelle basée sur une image Windows Server :
Une fois déployée, connectez-vous en RDP sur cette machine virtuelle Windows Server :
Ajoutez à votre serveur les rôles de Contrôleur de domaine et de Serveur DNS et laissez-vous guider jusqu’au lancement de l’installation :
Terminez la configuration de l’Active Directory en créer une nouvelle forêt de domaine :
Lancez la finalisation de l’installation avec des options de base et malgré l’affichage d’alertes non bloquantes :
Attendez que la session RDP se ferme automatiquement :
Retournez sur le portail Azure pour ajouter dans la résolution DNS du réseau virtuel par l’adresse IP de votre nouveau serveur DC / DNS :
Réouvrez une session RDP avec le nouveau compte administrateur de domaine :
N’attendez pas la fin du chargement de session et retournez sur votre portail Azure :
Créez une autre machine virtuelle sous Windows 10 sur le même réseau virtuel que la machine de domaine :
Ouvrez une session RDP avec un compte utilisateur local et joignez cette machine au domaine Active Directory :
Redémarrez cette machine virtuelle :
Retournez sur la session RDP ouverte sur le serveur Active Directory et utilisez le lien suivant pour y installer Azure AD Connect :
Lancez l’exécutable MSI téléchargé et choisissez l’option ci-dessous :
Cochez la case SSO dans la configuration de votre Azure AD Connect :
Renseignez le compte Administrateur Global de votre tenant 365 :
Renseignez le compte Administrateur d’entreprise de votre domaine Active Directory :
Cliquez sur Suivant :
Cochez la case et cliquez sur Suivant :
Synchronisez l’ensemble du domaine Active Directory :
Cliquez sur Suivant :
Cliquez encore sur Suivant :
Cliquez toujours sur Suivant :
Renseignez les identifiants d’Administrateur d’entreprise et cliquez sur Suivant :
Lancez l’installation de la configuration :
Une fois la configuration terminée, quittez le configurateur :
L’affichage des appareils d’Azure AD ne montre pour l’instant aucune nouvelle machine provenant de ce test :
Quelques minutes plus tard, relancez la configuration d’Azure AD Connect :
Cliquez comme ceci pour activer la jointure hybride AD / Azure AD :
Après avoir renseigné les identifiants d’Administrateur global du tenant 365, activez la fonctionnalité de jointure hybride :
Cochez la case pour les prendre en compte machines en Windows 10 ou ultérieures :
Renseignez les identifiants d’Administrateur d’entreprise du domaine Active Directory :
Démarrez la mise à jour de la nouvelle configuration :
Une fois la reconfiguration terminée, fermez la fenêtre d’installation d’Azure AD Connect :
Lancez en PowerShell la commande suivante pour forcer une nouvelle synchronisation entre l’AD et Azure AD :
Start-ADSyncSyncCycle -PolicyType Delta
Rafraîchissez la page des appareils d’Azure AD pour constater une nouvelle apparition :
Ouvrez une session RDP avec un compte de domaine sur la machine Windows 10 et retournez quelques minutes plus tard sur la page des appareils d’Azure AD pour constater le changement :
Conclusion
Les tests sur Azure AD sont toujours une précieuse méthode pour comprendre tous les mécanismes d’Azure. Enfin voici une vidéo explicative reprenant différentes étapes de nos tests ????????
