MFA pour tous les utilisateurs d’Azure à partir de juillet 2024

Microsoft vient d’annoncer, via un article posté sur le Techcommunity, une modification majeure à venir concernant l’authentification sur Azure : MFA pour tous ! Quand cela va arriver ? Qu’est-ce que cela implique ? Ces questions et bien d’autres encore sont légitimes. Tentons d’y voir plus clair ensemble.

Dans cet article sous forme de FAQ, je vous propose de commencer quelques notions important :

Et d’aborder ensuite les futurs changements prévus en juillet 2024 par Microsoft :

Qu’est-ce que la MFA ?

L’utilisation d’un mot de passe uniquement ne protège pas complètement des attaques. Si le mot de passe est faible ou s’il a été exposé ailleurs, un attaquant peut l’utiliser pour y accéder. Quand vous exigez une deuxième forme d’authentification, la sécurité est renforcée parce que ce facteur supplémentaire n’est pas un élément qu’un attaquant peut facilement obtenir ou dupliquer.

Microsoft Doc

La MFA propose donc d’aller plus loin que le couple classique identifiant / mot de passe. L’authentification multifacteur d’Entra ID 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)

Voici l’écran de configuration utilisateur d’une méthode MFA possible :

L’URL suivante (https://aka.ms/mfasetup) permet de gérer et configurer ses méthodes MFA :

Quelle licence est nécessaire pour la disposer d’une MFA ?

Les choses ont quelque peu évolué ces dernières années chez Microsoft. Les licences Entra ID présentes et assignées aux utilisateurs concernés sont le point de départ aux méthodes de MFA disponibles.

Cette information au niveau tenant est disponible sur la page principale d’Entra ID :

Voici un tableau de comparaison des features MFA en fonction des licences Microsoft :

FonctionEntra ID Gratuit : paramètres de sécurité par défaut activésEntra ID
Gratuit
Office 365Entra ID P1Entra ID P2
Protection des comptes avec authentification multifacteur● (comptes d’administrateur général uniquement)
Application mobile comme second facteur
Appel téléphonique comme second facteur
Le SMS comme deuxième facteur
Contrôle d’administration sur les méthodes de vérification
Alerte de fraude
Rapports MFA
Messages de bienvenue personnalisés pour les appels téléphoniques
ID d’appelant personnalisé pour les appels téléphoniques
Adresses IP approuvées
Mémoriser MFA pour les appareils fiables
MFA pour les applications locales
Accès conditionnel
Accès conditionnel en fonction du risque

Autrement dit, un tenant même gratuit (ou non) et ayant la sécurité par défaut activée dispose d’une MFA accessible à tous ses utilisateurs :

Tous les utilisateurs d’un locataire Microsoft Entra ID Gratuit peuvent utiliser l’authentification multifacteur Microsoft Entra à l’aide des paramètres de sécurité par défaut. L’application d’authentification mobile peut être utilisée pour l’authentification multifacteur Microsoft Entra lors de l’utilisation des paramètres de sécurité par défaut Microsoft Entra ID Gratuit.

Microsoft Learn

Les paramètres de sécurité par défaut peuvent être activés dans le niveau Microsoft Entra ID Free. Avec les paramètres de sécurité par défaut, tous les utilisateurs sont activés pour l’authentification multifacteur à l’aide de l’application Microsoft Authenticator. Il n’est pas possible d’utiliser la vérification par SMS ou appel téléphonique avec les paramètres de sécurité par défaut, mais uniquement l’application Microsoft Authenticator.

Microsoft Learn

Mais pourquoi alors payer pour un service MFA disponible gratuitement ?

L’activation de la sécurité par défaut sur un tenant est gratuite, mais reste non personnalisable. Microsoft recommande d’ailleurs une utilisation agile de la MFA grâce à l’utilisation de polices d’accès conditionnel, disponibles dans les licences Microsoft Entra ID P1 ou P2.

Un précédent article dédié aux accès conditionnels est disponible juste ici :

Existe-t-il des différentes configurations MFA possibles sur un tenant ?

Pour rappel, il est actuellement possible de configurer le challenge MFA via 3 méthodes distinctes :

  • Paramètres de sécurité par défaut
  • Accès conditionnel
  • Authentification multifacteur par utilisateur (per-user MFA)

Important : N’activez pas ou n’appliquez pas l’authentification MFA par utilisateur si vous utilisez également des polices d’accès conditionnel.

StratégieParamètres de sécurité par défautAccès conditionnelAuthentification 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 (voir les considérations relatives aux licences)
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 »
Possibilité de bloquer complètement les utilisateurs/services

Attention la méthode appelée Authentification multifacteur par utilisateur ou Per-user MFA est vouée à disparaitre :

En mars 2023, nous avons annoncé la dépréciation de la gestion des méthodes d’authentification dans les stratégies héritées de l’authentification multifacteur et de la réinitialisation de mot de passe en libre-service (SSPR). À compter du 30 septembre 2025, les méthodes d’authentification ne pourront pas être managées dans ces stratégies MFA et SSPR héritées.

Microsoft Learn

L’écran suivant est accessible via cette URL :

Peut-on migrer d’une configuration MFA à une autre ?

A cause de ce décommissionnement prévu pour 2025, Microsoft a déjà mis à disposition une documentation expliquant différentes étapes pour assurer une transition réussie :

Le SSPR (Réinitialisation du mot de passe en libre-service) et l’ancienne méthode MFA seront donc gérés par les Méthodes d’authentification unifiées :

Qu’est-ce qui se passe en juillet 2024 ?

La nouvelle est passée un peu inaperçue, mais juillet 2024 marque un pas important pour la sécurité Azure :

En juillet (2024), les équipes Azure commenceront à déployer des mesures de sécurité supplémentaires au niveau des locataires pour exiger l’authentification multifactorielle (MFA).

Microsoft Techcommunity

Autrement dit, le déploiement de cette règle MFA sera progressif et concernera à terme l’ensemble des tenants hébergés sur le Cloud public de Microsoft.

Quels sont les services impactés par ce changement ?

Azure et seulement Azure. Ce point est très important d’autres services 365, ou même l’utilisation de services pourtant hébergés Azure ne seront pas impactés par ce changement. Enfin, gardez à l’esprit qu’Azure est accessible via différentes méthodes, et seront donc toutes concernés :

  • Portail Azure
  • CLI
  • PowerShell
  • Terraform

À partir de juillet 2024, un déploiement progressif de cette application pour le portail uniquement commencera. Une fois le déploiement terminé pour le portail, un déploiement progressif similaire commencera pour CLI, PowerShell et Terraform.

Microsoft Techcommunity

Il s’agit donc d’assurer un contrôle MFA systématique afin de protéger les actions en relation avec la gestion des ressources Azure.

Quelles seront les méthodes de MFA possibles pour Azure ?

Les méthodes MFA classiques suivantes pourront être utilisées pour l’authentification Azure :

  • Microsoft Authenticator
  • Authenticator Lite (dans Outlook)
  • Windows Hello Entreprise
  • Clé de sécurité FIDO2
  • Token matériel OATH (préversion)
  • Token logiciel OATH
  • SMS
  • Appel vocal

Quelles sont les identités concernées / non concernées ?

Merci à John Savill pour ce schéma expliquant l’impact entre tous les types d’identités possibles sur Entra ID :

Sont donc concernées :

  • Toutes les identités humaines accédant à Azure dans le cadre de l’administration de ressources (membres et invités)

Sont donc non concernées :

  • Principaux de services
  • Identités managées (user ou système)
  • Comptes basés sur des tokens et utilisés pour l’automatisation

Un travail chez les utilisateurs est donc nécessaire. Mais un contrôle est aussi à prévoir sur les process automatisés utilisant des identités utilisateurs au lieu de des principaux de service ou d’identités managées.

Comment se rendre compte de l’impact avant le jour J ?

Après investigations, Il existe un template de police d’accès conditionnel qui semblerait très proche du résultat attendu par l’évolution de Microsoft prévue pour juillet 2024 :

Cette police semble bien cibler la gestion des ressources Azure :

La mise en place de cette police en mode Report seulement serait alors un premier pas vers la compréhension de ce qui va se passer sur votre environnement :

Conclusion

Dans tous les cas, gardez en tête les points suivants, et je ne peux que vous conseiller de prendre les devants dès que possible :

  • Microsoft recueille encore les feedbacks pour certains scénarios tels que les comptes « break-glass ».
  • Commencez à examiner les identifiants Entra utilisés pour les opérations de management, développement et les accès API à Azure Resource Manager.
  • Si nécessaire, remplacer les identités des utilisateurs par des principaux de service ou des identités managées.

Bon courage à tous 💪🙏😎

Créez votre premier tenant Microsoft Entra

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.

Microsoft Learn

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 :

Commençons par un bref rappel des prérequis.

Etape 0 – Rappel des prérequis :

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 :

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.

Microsoft Learn

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 😎.

Organisez-vous grâce au multi-tenants

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.

Microsoft Learn

Qu’est-ce que la synchronisation multi-tenants ?

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 :

Qu’est-ce qu’une organisation multi-tenants ?

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.
Microsoft Learn

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 :

Commençons d’abord par détailler les prérequis et l’environnement de départ pour nos tests.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la migration Active Directory vers Azure, il vous faudra disposer de :

  • 2 tenants Microsoft avec des licences 365
  • Une souscription Azure valide pour la création des machines virtuelles de test

Dans mon exemple, mes deux tenants de test sont issus du Microsoft 365 Developer Program. Voici la vue de mes deux tenants de test :

  • JLO Tenant A // jean0loup.onmicrosoft.com
  • JLO Tenant B // tdsynnexchlab.onmicrosoft.com

Chacun de mes 2 tenants dispose d’utilisateurs avec des licences Microsoft 365 E5 Dev :

Dans chacun des tenants de test, j’ai créé également 2 groupes de 3 d’utilisateurs chacun :

Enfin pour les tests, j’ai également créé 2 machines virtuelles de test pour la démonstration côté utilisateur :

Sur ces 2 machines virtuelles hébergées sur Azure, j’y ai installé la suite office 365 + Teams :

J’ai installé Microsoft Teams par ce lien :

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.

Pour cela, rendez-vous sur la page d’administration de Microsoft 365, puis dans le menu ci-dessous afin d’activer l’option suivante :

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 :

  • tenantb-user1_tdsynnexchlab.onmicrosoft.com#EXT#@jean0loup.onmicrosoft.com
  • tenanta-user1_jean0loup.onmicrosoft.com#EXT#@tdsynnexchlab.onmicrosoft.com

Etape III – Test de Microsoft Teams :

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.

Maîtrisez vos accès conditionnels

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.

Voici un lien vers un article pour un bref rappel de l’accès conditionnel, déjà expliqué dans un autre article dédié à Azure Virtual Desktop.

Qu’est-ce que l’Accès Conditionnel ?

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.

Microsoft Learn

Qu’est-ce qu’un Signal pour Entra ID ?

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 :

Microsoft a mis une FAQ à disposition juste ici.

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.

Microsoft Learn

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 :

Fonctionnalité I – Le nouveau tableau de bord :

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 :

  • Sécurisation de base
  • Zero Trust
  • Travail à distance
  • Protection des administrateurs
  • Menaces émergentes

Par exemple, le blocage de l’authentification traditionnelle peut se faire en seulement quelques clics :

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.

Microsoft Learn

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 😎.

Déployez des bases de sécurité Azure en 10 min

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.

Microsoft Blog

Par où commençons-nous ?

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 ????

Re-joignez la force d’Entra ID

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.

Microsoft Doc
  • 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. 

Doc Microsoft
  • Dispositifs appartenant à l’entreprise et gérés par elle
  • Authentification à l’aide d’un identifiant d’entreprise existant dans Azure AD.
  • L’authentification se fait uniquement par AAD.

Jointure hybride d’un appareil sur Azure :

Le meilleur des deux mondes !

  • Appareils appartenant à l’entreprise et géré par elle
  • Authentifié à l’aide d’un identifiant d’utilisateur d’entreprise qui existe dans l’AD local et dans Azure AD.
  • L’authentification peut être faite en utilisant les deux moyens : On-Prem AD et Azure AD.

Le tableau ci-dessous explique bien les 3 scénarios en détail :

Voici donc plusieurs des tests pour comprendre un peu mieux comment on génère ces méthodes de jointure :

Etape 0 : Rappel des prérequis

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 ????????

Optimisez votre Azure : 2/4 – La sécurité de vos périphériques

Les périphériques accédant à vos données se doivent d’être protégés. La mise en place d’outils de gestion, de contrôle et de conformité est déjà un premier pas vers plus de sécurité. Voici une liste non exhaustive d’outils Azure pour la sécurité de vos périphériques.

Périphérique joint / enregistré à Azure AD

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é.

Cette jointure ne rentre absolument pas en conflit pour les périphériques déjà présents dans un Active Directory. L’outil de synchronisation Azure AD Connect dispose d’une fonctionnalité permettant justement la jointure hybride pour ces périphériques.

Une fois le périphérique joint à Azure AD, il est possible de mettre en place des règles d’accès conditionnel qui tiennent compte de ce status :

Endpoint Management (Intune)

Qu’est-ce que Microsoft Intune ou Endpoint Management ?

Microsoft Intune est un service basé sur le cloud qui se concentre sur la gestion des périphériques mobiles (MDM) et la gestion des applications mobiles (MAM). Vous contrôlez la façon dont les appareils de votre organisation sont utilisés, y compris les téléphones mobiles, les tablettes et les ordinateurs portables. Vous pouvez également définir des stratégies spécifiques pour contrôler les applications. Par exemple, vous pouvez empêcher l’envoi d’e-mails à des personnes extérieures à votre organisation.

Microsoft Doc

Le schéma ci-dessous montre le large potentiel d’Intune sur le contrôle des périphériques, en situation de mobilité ou non.

L’étendue de ces contrôles est variable en fonction du périphérique lui-même :

  • Périphérique d’entreprise : contrôle total sur l’appareil, notamment les paramètres, les fonctionnalités et la sécurité. Par exemple, vous pouvez définir les critères de mot de passe et de code confidentiel, créer une connexion VPN, configurer la protection contre les menaces, …
  • Périphérique personnel : appelé aussi byOD (Bring-your-own Device), Le contrôle n’est pas total. Par exemple, les utilisateurs inscrivent leurs appareils uniquement s’ils veulent un accès aux ressources de votre organisation. Vous pouvez également utiliser les stratégies de protection des applications qui requièrent l’authentification multifacteur (MFA) pour utiliser ces derniers. Par exemple, si les utilisateurs souhaitent accéder à la messagerie ou Microsoft Teams.

Microsoft Intune est déjà inclus dans un grand nombre de licence Microsoft 365 (voir liste ci-dessous), mais est également disponible en licence seule pour un utilisateur ou un périphérique :

  • Microsoft 365 E5
  • Microsoft 365 E3
  • Enterprise Mobility + Security E5
  • Enterprise Mobility + Security E3
  • Microsoft 365 Business Premium
  • Microsoft 365 F1
  • Microsoft 365 F3
  • Microsoft 365 Gouvernement G5
  • Microsoft 365 Gouvernement G3
  • Intune for Education
  • Microsoft 365 Education A5
  • Microsoft 365 Education A3

Rien de mieux qu’une vidéo pour faire un tour d’horizon de l’outil :

Defender for Endpoint (Microsoft 365 Defender)

Qu’est-ce que Defender for Endpoint ?

Microsoft Defender for Endpoint est une plate-forme de sécurité conçue pour aider les réseaux d’entreprise à prévenir, détecter, examiner et répondre aux menaces avancées.

Microsoft Doc

Pour faire simple, l’intégration de périphériques dans le portail de sécurité Microsoft Security apporte à votre équipe une vision complète des alertes et des incidents de sécurité sur tout le parc IT. Cela est une bonne approche pour gagner du temps et comprendre et déjouer les attaques chaînées :

Côté licence, Defender for Endpoint est maintenant disponible sous deux plans :

Rappel des chapitres de l’article

Etape II : La sécurité de vos identités
Etape III : La sécurité de vos périphériques
Etape IV : La sécurité de votre Azure
Etape V : La sécurité de vos réseaux
Etape VI : La sécurité de vos applications
Etape VII : La sécurité de vos données
Etape VIII : Certifications de Sécurité Microsoft

Entra ID Connect à la sauce multi-tenants !

Déjà disponible en preview depuis quelques temps, Azure AD Connect apporte la synchronisation vers plusieurs tenants Azure AD en disponibilité générale (GA). Cette nouvelle fonctionnalité permet la réplication d’utilisateurs et de groupes présents dans un Active Directory vers plusieurs environnements Microsoft Cloud.

Pour arriver à cette situation, il faudra alors installer plusieurs agents Azure AD Connect sur différents serveurs (un par tenant à associer). Avant de rentrer ensemble dans la technique, voici un rappel de ce qu’Azure AD Connect apporte :

Quels sont les moyens actuels pour structurer un tenant Azure AD ?

Un tenant correspond le plus souvent une organisation souhaitant posséder et gérer environnement spécifique de services Microsoft Cloud (Azure / Office365).

Comme le recommande Microsoft, envisager l’utilisation de plusieurs tenants Azure AD ne doit pas être la norme. L’utilisation d’un seul tenant apporte les bénéfices suivants :

  • Identité Cloud unique (un seul UPN pour se connecter)
  • Simplification dans la gestion des services et des licences
  • Simplification du management IT et de la sécurité

Bien qu’Azure AD soit construit en structure plate, il existe aussi les unités administratives. Ces dernières peuvent couvrir plusieurs besoins, dans lesquels un seul tenant suffira :

La gestion des identités dans le cas B2C ne nécessite pas non plus la création d’un nouveau tenant B2B :

Que reste-t-il donc pour justifier la création d’autres tenants Azure AD ?

  • Création d’un environnement de test ou pour du développement applicatif
  • Séparation de branches d’une même entreprise
  • Exigences particulières de sécurité
  • Besoin de disposer de plusieurs variantes d’Azure (Azure Gov, Azure China, Azure Germany)
  • Limitations Azure AD
  • Limitations Azure

Quels seront les inconvénients à multiplier les tenants Azure AD ?

Il ne faut pas oublier que l’utilisation de plusieurs identités Cloud va compliquer le quotidien, comme par exemple :

  • Risque ou obligation de doublons de licence (erreur ou contrainte)
  • Complexification pour les utilisateurs finaux
  • Installation alourdie (une seule instance d’Azure AD Connect par serveur. Prévoir autant de serveur que de tenants à synchroniser. Prévoir également l’installations d’Azure AD Connect sur des serveurs de secours (redondance).
  • Synchronisation limitée : certains objets comme les périphériques ou les groupes des tenants ne seront pas remontés dans Active Directory
  • Gestion des mots de passe : synchronisation des hashs des mots de possible entre Active Directory et les tenants Azure AD sous certaines conditions

Test d’un changement de mot de passe pour un utilisateur synchronisé sur plusieurs tenants Azure AD

Microsoft signale justement une fonctionnalité intéressante concernant la gestion des mots de passe pour les utilisateurs synchronisés dans plusieurs tenants :

Il est possible de configurer la synchronisation du hachage de mot de passe depuis Active Directory avec plusieurs locataires Azure AD pour le même objet utilisateur. Si la synchronisation du hachage de mot de passe est activée pour un locataire, la réécriture du mot de passe peut également être activée, ce qui peut être fait sur plusieurs locataires : si le mot de passe est modifié sur un locataire, la réécriture du mot de passe est mise à jour dans Active Directory, et la synchronisation du hachage de mot de passe met à jour le mot de passe dans les autres locataires.

Microsoft Doc

Dans cet article, nous allons donc tester ensemble les différentes étapes pour mettre cette fonctionnalité en place.

Etape 0 : Rappel des prérequis

Comme toujours, des prérequis sont nécessaires pour réaliser cette démonstration d’Azure AD Connect :

  • Un premier tenant, Tenant A, synchronisé avec l’Active Directory
  • Un premier serveur, Serveur A, gérant un domaine Active Directory et avec l’agent Azure AD Connect d’installé
  • Un second tenant, Tenant B, non synchronisé à l’Active Directory
  • Un second serveur, Serveur B, joint au même domaine Active Directory

Serveur A : mon agent Azure AD Connect installé sur mon premier serveur synchronise déjà mes utilisateurs vers le tenant A

Tenant A : Filtrez vos utilisateurs pour ne voir que ceux provenant de la synchronisation de l’AD

Tenant B : Effectuez la même opération de filtrage pour constater l’absence d’utilisateurs synchronisés

Tenant B : un contrôle sur les propriétés Azure AD Connect du tenant B affiche un paramétrage encore vierge

Etape I : Installation d’Azure AD Connect sur le second serveur

Serveur B : connectez-vous en RDP sur ce second serveur pour y installer la dernière version d’Azure AD Connect, disponible sur cette page Microsoft

Rappel de sécurité :
On ne conseille jamais d‘installer Azure AD Connect sur un contrôleur de domaine.

Laissez-vous guider par l’installeur

Etape II : Configuration d’Azure AD Connect sur le second serveur

Serveur B : acceptez les termes, puis cliquez sur Continuer

Cliquez sur Installer

Choisissez la synchronisation des hash des mots de passe, puis cliquez sur Suivant

Inutile de cocher la case SSO car il ne sera pas possible de joindre un PC en hybride sur 2 tenant Azure AD.

Renseignez le compte Azure AD d’un administrateur global ou d’un administrateur de gestion des identités hybrides, puis cliquez sur Suivant

Ajoutez votre Active Directory grâce à l’utilisation d’un compte administrateur d’entreprise, puis cliquez sur Suivant

Cochez la case de confirmation de contrôle des UPN, puis cliquez sur Suivant

Définissez les OUs à synchroniser vers le tenant B, puis cliquez sur Suivant

Cliquez sur Suivant

Cliquez sur Suivant

Cochez la case concernant les mots de passe, puis cliquez sur Suivant

Cliquez sur Installer

Une fois la configuration terminée avec succès, fermez le configurateur Azure AD

Etape III : Vérifications de la synchronisation d’Azure AD Connect sur le second tenant

Serveur B : ouvrez Synchronisation Service Manager, disponible depuis le menu Démarrer

Vérifiez la bonne présence et le succès des 6 lignes de synchronisation

Cliquez sur la ligne d’exportation vers le tenant B pour y constater l’ajout d’utilisateurs

Tenant B : Retournez sur le portail Azure et rafraîchissez la liste des utilisateurs filtrés sur le tenant B

Etape IV : Test de l’authentification utilisateur sur le second tenant

Tenant B : testez l’authentification d’un utilisateur synchronisé depuis un navigateur privé avec son mot de passe AD

La connexion fonctionne bien et vous affiche la page d’accueil d’Office 365 :

Etape V : Premier test de changement de mot de passe sur le tenant B

Tenant B : essayez de changer mot de passe depuis le tenant B via le bouton de paramétrage en haut à droite

La réponse de Microsoft sur le tenant B est assez claire : il ne semble pas possible de modifier le mot de passe sur le tenant B, qui n’est pas le tenant « principal »

Fermez le navigateur privé

Etape VI : Second test de changement de mot de passe sur le tenant A

Tenant A : essayez à nouveau de changer mot de passe depuis le tenant A via la même procédure de navigateur privé

Aucun blocage pour ce second essai sur le tenant A, définissez-y alors un nouveau mot de passe sur cet utilisateur

Une fois modifié, fermez le navigateur privé

Optionnel : Si cela est possible, ouvrez une session RDP sur une machine du domaine AD avec le compte utilisateur modifié

Si la session Windows de l’utilisateur s’ouvre bien, le nouveau mot de passe a bien été pris en compte sur l’AD

Tenant B : ouvrez à nouveau un navigateur privé pour retenter l’opération d’authentification du même utilisateur avec le nouveau mot de passe sur le tenant B

Attendez quelques minutes et retentez l’opération avec le nouveau mot de passe sur le tenant B

Si la page d’accueil d’Office 365 s’ouvre bien, le mot de passe est été pris en compte sur l’Azure AD du tenant B

Conclusion

Comme nous le supposions, la gestion d’identités d’un Active Directory vers plusieurs tenants Azure AD est possible. Notre démonstration nous a aussi permis de tester la réplication des hashs des mots de passe sur plusieurs tenants sous certaines conditions.

Pour continuer sur la gestion de plusieurs tenants Azure, je trouvais intéressant de vous parler d’Azure AD Cross-Tenant Access

Associez FSLogix avec Azure AD

Microsoft vient tout juste de l’annoncer en préview : vous pouvez maintenant gérer les identités d’un partage de fichiers Azure PaaS directement avec Azure AD !

C’est une excellente nouvelle, attendue depuis plusieurs mois par de nombreux utilisateurs d’Azure Virtual Desktop, notamment pour mettre en place des solutions comme FSLogix, déjà utilisée pour la gestion des profils utilisateurs, sans serveur AD DS. Par contre, il y a encore une petite mauvaise nouvelle :

Cette fonctionnalité nécessite actuellement que les utilisateurs aient des identités hybrides, gérées dans Active Directory.

Documentation Microsoft

Quel est donc l’intérêt ?

Cette contrainte d’avoir un environnement hybride, qui sous-entend donc la présence d’un domaine AD, n’est pas forcément une mauvaise chose. Il s’agit ici d’une avancée technique intermédiaire. Nul doute que ce prérequis ne sera plus nécessaire à moyen terme.

Dans cet article, nous allons donc tester cette nouvelle fonctionnalité. Le but de tester cette préview de gestion des tickets Kerberos par Azure AD est de mesurer les avancées Microsoft. Vous pouvez suivre la documentation leur officielle ici.

Etape 0 : Rappel des prérequis

Comme vous allez travailler avec des tickets Kerberos spécifiques à Azure AD, il est obligatoire que les postes ayant accès au partage de fichiers PaaS disposent de l’un des OS suivants :

  • Windows 11 Enterprise mono ou multisession
  • Windows 10 Enterprise mono ou multisession, en version 2004 ou ultérieure avec la mise à jour KB5007253
  • Windows Server, version 2022 avec la dernière mise à jour KB5007254

Dans mon cas, j’ai utilisé l’environnement suivant :

  • une VM Windows Server 2022 pour jouer le contrôleur de domaine
  • Une environnement AVD composé de VMs en Windows 11 Enterprise multisession

Comme annoncé avant, les postes en accès au partage de fichier doivent donc être joints à Azure AD ou en mode hybride (Active Directory + Azure AD). Néanmoins, les utilisateurs doivent être « hybrides », il est donc nécessaire de passer par Azure AD Connect pour y arriver. Le choix du domaine managé Azure AD DS n’est donc pas possible ici :

  • Azure Active Directory Domain Services (Azure AD DS) : Azure AD DS fournit des services de domaine managé avec un sous-ensemble de fonctionnalités AD DS traditionnelles, comme la jonction de domaine, la stratégie de groupe, le protocole LDAP et l’authentification Kerberos/NTLM.
  • Active Directory Domain Services (AD DS) : serveur LDAP (Lightweight Directory Access Protocol) qui fournit des fonctionnalités clés telles que l’identité et l’authentification, la gestion des objets, la stratégie de groupe et les approbations.

Au final, les prérequis sont donc les suivants :

  • Un tenant Microsoft (Azure AD)
  • Des licences comprenant Windows 10 Entreprise pour vos utilisateurs AVD
  • Une souscription Azure active avec le rôle de propriétaire :
  • Un domaine Active Directory Domain Services (AD DS) :
  • Des utilisateurs AVD présents dans AD DS et synchronisés avec Azure AD :
  • Un environnement Azure Virtual Desktop déployé et lié à votre domaine AD DS :
  • Des machines virtuelles AVD jointes é la fois à votre AD DS et enrôlées dans votre Azure AD :

Une fois cela en place, déroulez les prochaines étapes d’installation depuis votre contrôleur de domaine.

Etape I : Création d’un nouveau compte de stockage

Sur votre portail Azure, commencez par créer votre nouveau compte de stockage :

Une fois créé, stockez l’ID de la souscription Azure, le nom du groupe de ressources et le nom du compte de stockage dans les variables suivantes :

$resourceGroupName = "<MyResourceGroup>"
$storageAccountName = "<MyStorageAccount>"
$Subscription = "<MySubscriptionID>"

Etape II : Configuration de l’authentification Azure AD

Vous allez utiliser plusieurs nouvelles fonctionnalités, il est donc préférable de réinstaller des modules PowerShell sur votre poste. Ouvrez PowerShell ISE en mode administrateur et lancez la commande suivante :

Install-Module -Name Az.Storage -AllowClobber
Install-Module -Name AzureAD -AllowClobber

Validez les messages d’avertissement si besoin :

L’activation de l’authentification via Azure AD passe elle aussi par une commande PowerShell :

Connect-AzAccount
$ApiVersion = '2021-04-01'

$Uri = ('https://management.azure.com/subscriptions/{0}/resourceGroups/{1}/providers/Microsoft.Storage/storageAccounts/{2}?api-version={3}' -f $Subscription, $ResourceGroupName, $StorageAccountName, $ApiVersion);

$json = 
   @{properties=@{azureFilesIdentityBasedAuthentication=@{directoryServiceOptions="AADKERB"}}};
$json = $json | ConvertTo-Json -Depth 99

$token = $(Get-AzAccessToken).Token
$headers = @{ Authorization="Bearer $token" }

try {
    Invoke-RestMethod -Uri $Uri -ContentType 'application/json' -Method PATCH -Headers $Headers -Body $json;
} catch {
    Write-Host $_.Exception.ToString()
    Write-Error -Message "Caught exception setting Storage Account directoryServiceOptions=AADKERB: $_" -ErrorAction Stop
}

Le lancement du script PowerShell vous demandera de vous authentifier en utilisant un compte propriétaire de la souscription Azure :

Le lancement réussi du script devrait vous donner le résultat suivant :

Constatez l’activation de la fonctionnalité en préview, directement sur le compte de stockage :

Il ne reste en plus qu’à générer une nouvelle clef pour le protocole Kerberos :

Set-azcontext -Subscription $Subscription
New-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName -KeyName kerb1 -ErrorAction Stop

Cette clef n’est pas contre pas visible sur le portail Azure.

Etape III : Création d’une identité principal de service

L’activation des droits d’Azure AD sur le compte de stockage n’est pas encore possible via le portail Azure. Commencez par générer un mot de passe, basé sur la nouvelle clef Kerberos de votre compte stockage, et stocker le dans une variable grâce à la commande PowerShell suivante :

$kerbKey1 = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName -ListKerbKey | Where-Object { $_.KeyName -like "kerb1" }
$aadPasswordBuffer = [System.Linq.Enumerable]::Take([System.Convert]::FromBase64String($kerbKey1.Value), 32);
$password = "kk:" + [System.Convert]::ToBase64String($aadPasswordBuffer);

Lors d’une étape précédente, vous vous êtes déjà connecté à Azure. Connectez-vous maintenant à Azure AD :

Connect-AzureAD
$azureAdTenantDetail = Get-AzureADTenantDetail;
$azureAdTenantId = $azureAdTenantDetail.ObjectId
$azureAdPrimaryDomain = ($azureAdTenantDetail.VerifiedDomains | Where-Object {$_._Default -eq $true}).Name

Utilisez ici un compte administrateur global du tenant :

Préparer la génération du principal de sécurité :

$servicePrincipalNames = New-Object string[] 3
$servicePrincipalNames[0] = 'HTTP/{0}.file.core.windows.net' -f $storageAccountName
$servicePrincipalNames[1] = 'CIFS/{0}.file.core.windows.net' -f $storageAccountName
$servicePrincipalNames[2] = 'HOST/{0}.file.core.windows.net' -f $storageAccountName

Créez et chargez dans une variable les éléments nécessaires à la future Enregistrement d’applications :

$application = New-AzureADApplication -DisplayName $storageAccountName -IdentifierUris $servicePrincipalNames -GroupMembershipClaims "All";

Générez alors le principal de sécurité :

$servicePrincipal = New-AzureADServicePrincipal -AccountEnabled $true -AppId $application.AppId -ServicePrincipalType "Application";

Configurez le mot de passe stocké précédement pour celui-ci :

$Token = ([Microsoft.Open.Azure.AD.CommonLibrary.AzureSession]::AccessTokens['AccessToken']).AccessToken
$apiVersion = '1.6'
$Uri = ('https://graph.windows.net/{0}/{1}/{2}?api-version={3}' -f $azureAdPrimaryDomain, 'servicePrincipals', $servicePrincipal.ObjectId, $apiVersion)
$json = @'
{
  "passwordCredentials": [
  {
    "customKeyIdentifier": null,
    "endDate": "<STORAGEACCOUNTENDDATE>",
    "value": "<STORAGEACCOUNTPASSWORD>",
    "startDate": "<STORAGEACCOUNTSTARTDATE>"
  }]
}
'@
$now = [DateTime]::UtcNow
$json = $json -replace "<STORAGEACCOUNTSTARTDATE>", $now.AddDays(-1).ToString("s")
  $json = $json -replace "<STORAGEACCOUNTENDDATE>", $now.AddMonths(12).ToString("s")
$json = $json -replace "<STORAGEACCOUNTPASSWORD>", $password
$Headers = @{'authorization' = "Bearer $($Token)"}
try {
  Invoke-RestMethod -Uri $Uri -ContentType 'application/json' -Method Patch -Headers $Headers -Body $json 
  Write-Host "Success: Password is set for $storageAccountName"
} catch {
  Write-Host $_.Exception.ToString()
  Write-Host "StatusCode: " $_.Exception.Response.StatusCode.value
  Write-Host "StatusDescription: " $_.Exception.Response.StatusDescription
}

Etape IV : Définir les autorisations API sur l’application nouvellement créée

Comme indiqué dans la documentation Microsoft, la suite du processus peut se faire dans le portail Azure. Ouvrez votre portail Azure Active Directory :


Dans vos Enregistrement d’applications, cliquez sur Toutes les applications, puis enfin sélectionnez l’application dont le nom correspond à votre compte de stockage :

Dans les autorisations API dans le volet de gauche, ajoutez une autorisation comme ceci :

Sélectionnez Microsoft Graph, puis choisissez délégation des permissions :

Dans la section OpenID, sélectionnez Profile :

Descendez plus bas dans la liste pour retrouver la section User. Cochez alors User.Read et cliquez sur Ajouter :

Une fois sur retourné sur l’écran des permissions, cliquez ci-dessous pour ajouter le consentement global à tout votre tenant :

Constatez la bonne application de celui-ci grâce au statut à droite :

Etape V : Création du partage de fichier

Retournez sur votre compte de stockage pour créer un nouveau partage de fichier comme ceci :

Etape VI : Jointure du partage de fichier Azure au domaine Active Directory

Pour l’instant, le partage de fichier Azure nécessite encore l’attribution de droits RBAC aux utilisateurs Azure Virtual desktop. Dans votre cas cette fonctionnalité nécessite d’activer l’authentification AD DS sur le compte de stockage.

Commencez par télécharger sur GitHub la version la plus récente du module PowerShell AzFilesHybrid.zip :

Décompressez les fichiers sur le disque C sur une VM, jointe à votre domaine :

Démarrez Windows PowerShell ISE en tant qu’administrateur et exécutez ce qui suit pour supprimer le flux de données alternatif Zone.Identifier, qui a une valeur de 3, indiquant qu’il a été téléchargé à partir d’Internet :

Get-ChildItem -Path C:\AzFilesHybrid -File -Recurse | Unblock-File

Toujours en PowerShell, connectez-vous à Azure :

Connect-AzAccount

Lancez alors le script suivant en modifiant les paramètres, selon votre configuration :

.\CopyToPSPath.ps1
Import-Module -Name AzFilesHybrid
Join-AzStorageAccountForAuth `
  -ResourceGroupName 'aadjoin-rg' `
  -StorageAccountName 'jloaadjoin2' `
  -DomainAccountType 'ComputerAccount' `
  -OrganizationalUnitDistinguishedName 'OU=AVDJOIN-Devices,DC=jloudev,DC=ml'

Constatez le retour de commande suivant :

Vous pouvez aussi contrôler la bonne activation sur le compte de stockage :

Restez sur votre compte de stockage pour assigner le rôle Storage File Data SMB Share Contributor à votre utilisateurs Azure Virtual Desktop :

Dans notre démonstration, nous allons seulement autoriser le groupe d’utilisateurs Azure Virtual Desktop.

Etape VII : Attribution des autorisations

Pour empêcher les utilisateurs d’accéder aux profils utilisateurs d’autres utilisateurs, vous devez également attribuer des autorisations au niveau du répertoire.

Le système que vous utilisez pour configurer les permissions doit répondre aux exigences suivantes :

  • La poste a une version de Windows répond aux exigences des systèmes d’exploitation des prérequis
  • Le poste doit être joint à Azure AD ou à Hybrid Azure AD à Azure AD
  • Le poste est relié au contrôleur de domaine

Installez ou importez si besoin sur le poste le module PowerShell ActiveDirectory. Dans mon cas, je n’ai pas eu à faire cette opération car j’ai tout exécuté depuis mon contrôleur de domaine :

Import-module ActiveDirectory

Azure AD ne prenant pas actuellement en charge la configuration des listes de contrôle d’accès dans Shell, il doit s’appuyer sur Active Directory. Pour configurer Shell sur votre compte de stockage, exécutez la commande suivante dans PowerShell ISE en tant qu’administrateur :

function Set-StorageAccountAadKerberosADProperties {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory=$true, Position=0)]
        [string]$ResourceGroupName,

        [Parameter(Mandatory=$true, Position=1)]
        [string]$StorageAccountName,

        [Parameter(Mandatory=$false, Position=2)]
        [string]$Domain
    )  

    $AzContext = Get-AzContext;
    if ($null -eq $AzContext) {
        Write-Error "No Azure context found.  Please run Connect-AzAccount and then retry." -ErrorAction Stop;
    }

    $AdModule = Get-Module ActiveDirectory;
     if ($null -eq $AdModule) {
        Write-Error "Please install and/or import the ActiveDirectory PowerShell module." -ErrorAction Stop;
    }	

    if ([System.String]::IsNullOrEmpty($Domain)) {
        $domainInformation = Get-ADDomain
        $Domain = $domainInformation.DnsRoot
    } else {
        $domainInformation = Get-ADDomain -Server $Domain
    }

    $domainGuid = $domainInformation.ObjectGUID.ToString()
    $domainName = $domainInformation.DnsRoot
    $domainSid = $domainInformation.DomainSID.Value
    $forestName = $domainInformation.Forest
    $netBiosDomainName = $domainInformation.DnsRoot
    $azureStorageSid = $domainSid + "-123454321";

    Write-Verbose "Setting AD properties on $StorageAccountName in $ResourceGroupName : `
        EnableActiveDirectoryDomainServicesForFile=$true, ActiveDirectoryDomainName=$domainName, `
        ActiveDirectoryNetBiosDomainName=$netBiosDomainName, ActiveDirectoryForestName=$($domainInformation.Forest) `
        ActiveDirectoryDomainGuid=$domainGuid, ActiveDirectoryDomainSid=$domainSid, `
        ActiveDirectoryAzureStorageSid=$azureStorageSid"

    $Subscription =  $AzContext.Subscription.Id;
    $ApiVersion = '2021-04-01'

    $Uri = ('https://management.azure.com/subscriptions/{0}/resourceGroups/{1}/providers/Microsoft.Storage/storageAccounts/{2}?api-version={3}' `
        -f $Subscription, $ResourceGroupName, $StorageAccountName, $ApiVersion);

    $json=
        @{
            properties=
                @{azureFilesIdentityBasedAuthentication=
                    @{directoryServiceOptions="AADKERB";
                        activeDirectoryProperties=@{domainName="$($domainName)";
                                                    netBiosDomainName="$($netBiosDomainName)";
                                                    forestName="$($forestName)";
                                                    domainGuid="$($domainGuid)";
                                                    domainSid="$($domainSid)";
                                                    azureStorageSid="$($azureStorageSid)"}
                                                    }
                    }
        };  

    $json = $json | ConvertTo-Json -Depth 99

    $token = $(Get-AzAccessToken).Token
    $headers = @{ Authorization="Bearer $token" }

    try {
        Invoke-RestMethod -Uri $Uri -ContentType 'application/json' -Method PATCH -Headers $Headers -Body $json
    } catch {
        Write-Host $_.Exception.ToString()
        Write-Host "Error setting Storage Account AD properties.  StatusCode:" $_.Exception.Response.StatusCode.value__ 
        Write-Host "Error setting Storage Account AD properties.  StatusDescription:" $_.Exception.Response.StatusDescription
        Write-Error -Message "Caught exception setting Storage Account AD properties: $_" -ErrorAction Stop
    }
}

Lancez alors la fonction précédente grâce à cette commande :

Connect-AzAccount
Set-StorageAccountAadKerberosADProperties -ResourceGroupName $resourceGroupName -StorageAccountName $storageAccountName

Cette commande fait alors rebasculer le statut Active Directory sur compte de stockage comme ceci :

Etape VIII : Création de la GPO

Toujours sur votre contrôleur de domaine, ouvrez le gestionnaire des polices :

Sous votre OU des postes AVD, créez une nouvelle police et éditez là :

Activer la police suivante :

Administrative Templates\System\Kerberos\Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon

Ajoutez également une règle de registre sur cette même police :

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1

Redémarrez les VMs Azure Virtual Desktop pour la bonne prise en compte de la GPO :

Connectez-vous à une session Azure Virtual Desktop grâce à Windows Remote Desktop :

Utilisez un compte utilisateur d’AVD.

Une fois la session AVD ouverte, ouvrez une ligne de commande et tapez le code suivant :

dsregcmd /RefreshPrt

Verrouillez votre session AVD, puis déverrouillez-là :

Saisissez les deux lignes de commande suivantes :

klist purge
klist get krbtgt

Constatez la présence de :

krbtgt/KERBEROS.MICROSOFTONLINE.COM @ KERBEROS.MICROSOFTONLINE.COM

Lancez enfin la commande net use pour monter le lecteur réseau et vérifiez le bon fonctionnement :

net use Z: \\jloaadjoin2.file.core.windows.net\avdfileshare
Il arrive par moment que la commande échoue la première fois.

On retrouve bien le disque réseau dans l’explorateur Windows :

En retournant sur les tickets Kerberos, un nouveau CIFS a fait son apparition :

Etape IX : Configuration de FSLogix

Une fois l’architecture en place, on peut combiner cette dernière pour la gestion des profils utilisateurs via FSLogix. Pour cela, il nous faut rajouter la configuration FSLogix et une règle de registre en plus pour Azure AD.

#Variables
$storageAccountName = "jloaadjoin2"
$filesharename = "avdfileshare"

#Create Directories
$LabFilesDirectory = "C:\LabFiles"

if(!(Test-path -Path "$LabFilesDirectory")){
New-Item -Path $LabFilesDirectory -ItemType Directory |Out-Null
}
if(!(Test-path -Path "$LabFilesDirectory\FSLogix")){
New-Item -Path "$LabFilesDirectory\FSLogix" -ItemType Directory |Out-Null
}

 #Download FSLogix Installation bundle
  if(!(Test-path -Path "$LabFilesDirectory\FSLogix_Apps_Installation.zip")){
       Invoke-WebRequest -Uri "https://experienceazure.blob.core.windows.net/templates/wvd/FSLogix_Apps_Installation.zip" -OutFile     "$LabFilesDirectory\FSLogix_Apps_Installation.zip"

 #Extract the downloaded FSLogix bundle
 function Expand-ZIPFile($file, $destination){
     $shell = new-object -com shell.application
     $zip = $shell.NameSpace($file)
     foreach($item in $zip.items()){
     $shell.Namespace($destination).copyhere($item)
     }
 }

 Expand-ZIPFile -File "$LabFilesDirectory\FSLogix_Apps_Installation.zip" -Destination "$LabFilesDirectory\FSLogix"

}
   #Install FSLogix
   if(!(Get-WmiObject -Class Win32_Product | where vendor -eq "FSLogix, Inc." | select Name, Version)){
       $pathvargs = {C:\LabFiles\FSLogix\x64\Release\FSLogixAppsSetup.exe /quiet /install }
       Invoke-Command -ScriptBlock $pathvargs
   }
   #Create registry key 'Profiles' under 'HKLM:\SOFTWARE\FSLogix'
   $registryPath = "HKLM:\SOFTWARE\FSLogix\Profiles"
   if(!(Test-path $registryPath)){
       New-Item -Path $registryPath -Force | Out-Null
   }

   #Add registry values to enable FSLogix profiles, add VHD Locations, Delete local profile and FlipFlop Directory name
   New-ItemProperty -Path $registryPath -Name "VHDLocations" -Value "\\$storageAccountName.file.core.windows.net\$filesharename" -PropertyType String -Force | Out-Null
   New-ItemProperty -Path $registryPath -Name "Enabled" -Value 1 -PropertyType DWord -Force | Out-Null
   New-ItemProperty -Path $registryPath -Name "DeleteLocalProfileWhenVHDShouldApply" -Value 1 -PropertyType DWord -Force | Out-Null
   New-ItemProperty -Path $registryPath -Name "FlipFlopProfileDirectoryName" -Value 1 -PropertyType DWord -Force | Out-Null
    
    reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

   #Display script completion in console
Write-Host "Script Executed successfully"

L’ouverture d’une nouvelle session utilisateurs d’AVD vous affiche bien la mention FSLogix :

Un tour dans le partage de fichier du compte de stockage montre bien la présence du dossier du profil utilisateur géré par FSLogix :

Conclusion

La gestion des tickets Kerberos par Azure AD est une belle avancée. Bien évidemment, le processus de prise en charge complète d’un compte de stockage de manière native n’est pas encore là, mais nous y sommes en bonne voie ???? Comme à chaque fois, n’hésitez pas à utiliser les commentaires pour exprimer de vos retours ????

AVD + Entra ID Join

Attendu depuis longtemps par la communauté Azure Virtual Desktop, Azure AD Join est enfin là ! Lancé il y a seulement quelques jours en public preview, la possibilité de se passer d’un Active Directory pour environnement AVD permet d’envisager certains projets avec une architecture 100% Cloud. Dans cet article, nous allons voir ensemble cette fonctionnalité et les bénéfices apportés par cette dernière.

Point important : cette amélioration pose un souci pour l’utilisation de la gestion des profiles via FSLogix, car l’utilisation d’un partage de fichier nécessite une authentification SMB, non possible pour l’instant via la gestion des identités Azure AD.

Introduction

Gestion des identités sur Azure Virtual Desktop : Rappel de l’existant

Jusqu’à présent, un environnement Azure Virtual Desktop (anciennement Windows Virtual Desktop) nécessitait de joindre les machines virtuelles Azure à un domaine Active Directory. Ce domaine pouvait provenir d’un Windows Server, ayant le rôle d’Active Directory sur un machine virtuelle Azure, ou via le service de domaine managé Azure AD DS.

Merci à Dean pour cette explication claire sur la gestion des identités sous AVD.

Qu’est-ce qu’un périphérique joint à Azure AD ?

La jonction Azure AD est destinée aux organisations axées en priorité ou uniquement sur le cloud. Toute organisation peut déployer des appareils joints Azure AD, quels que soient leur taille et leur secteur d’activité. La jonction Azure AD fonctionne même dans un environnement hybride et permet l’accès aux applications et ressources locales et cloud

Documentation Microsoft

Attention, il est possible de joindre des machines en Windows 10 à Azure AD, à l’exception de Windows 10 Famille.

Cette jointure à Azure AD est prévu à l’origine pour des entreprises ne disposant pas d’une infrastructure Windows Server Active Directory locale.

Dans le cas contraire, il est malgré tout possible de fonctionner de manière hybride. L’avantage sera de protéger les appareils Windows 10, tout en conservant l’accès aux ressources locales qui nécessitent une authentification locale. Dans ce cas précis, nous parlerons alors des machines jointes à Azure AD hybride. Ces appareils sont joints à votre annuaire Active Directory local et à votre Azure AD.

Appareils joints Azure AD

Pourquoi se passer d’un contrôleur de domaine pour AVD ?

Le premier argument est le coût ! Beaucoup de projets Azure Virtual Desktop sont petits et concernent un petit nombre d’utilisateurs en Remote Desktop. L’ajout d’un domaine sur des VMs ou via un domaine managé augmente la facture environ plus une centaine d’euros par mois .

Enfin, la gestion des machines AVD peut également se faire via Intune (Endpoint Manager). Que vous utilisiez des machines virtuelles partagées ou individuelles pour AVD, Intune peut gérer les deux ????Un précédent article en parle et explique le processus d’intégration sur Intune pour les machines AVD partagées ici.

Vue générale des fonctionnalités d’Intune (MEM + MAM).

Déploiement d’un AVD utilisant Azure AD

On y est ! On va détailler ici, étapes par étapes, la création d’un environnement Azure Virtual Desktop en ne disposant d’aucun domaine Active Directory en place. Pour rappel, à l’heure où ces lignes sont écrites, la fonctionnalité de jointure avec Azure AD est toujours en public preview.

Etape I : Création du réseau virtuel

Habituellement, le réseau virtuel hébergeant AVD est déjà présent par le domaine existant. Dans un environnement vide, il faut donc commencer la création de celui-ci en premier :

Je prends soin de choisir la région adaptée à mon architecture AVD.

La configuration de la plage réseau et des sous-réseaux ne change pas d’un projet classique AVD. Dans mon exemple rapide, on ira au plus simple :

Une fois la création du réseau virtuel terminée, je peux passer à la création de mon environnement Azure Virtual Desktop.

Etape II : Déploiement d’Azure Virtual Desktop

Comme pour un déploiement classique d’Azure Virtual Desktop, notre travail commence par déployer un pool d’hôtes. Vous trouverez ce dernier dans la barre de recherche d’Azure :

Taper « virtual desktop » dans la barre de recherche pour voir le service AVD apparaître.

La procédure de départ reste identique au processus habituel pour AVD. Cependant, il est important de cocher la Validation environnement à OUI pour réussir la jointure avec Azure AD :

Dans mon exemple, j’ai choisi un host pool composé de VMs personnelles, il est possible de le faire avec des VMs partagées.

Note : l’assignement de type automatique dans le cadre de machines virtuelles individuelles va directement affecter ces dernières aux personnes se connectant à AVD dans la mesure où ces utilisateurs y sont autorisés.

Dans l’onglet des machines virtuelles, je défini les options relatives à ces dernières. Aucune particularité concernant la jointure avec Azure AD dans la première partie :

La copie d’écran ci-dessous concernant Azure AD et connaît une évolution sur deux points :

  • Type de domaine à joindre : il est maintenant possible de choisir Azure Active Directory
  • Intune : il est également possible d’automatiser l’enrôlement des machines virtuelles AVD dans Intune. Cela permet de configurer ces dernières, que ce soient des machines virtuelles dédiées ou partagées entre utilisateurs.
En sélectionnant Azure Active Directory, un certain nombre de champs disparaissent de la configuration de base.
Plus besoin ici de renseigner un login du domaine.

La création de l’espace de travail ne change pas par rapport aux environnements AVD classiques :

Une fois tous les champs correctement renseignés, il ne reste plus qu’à lancer la création des ressources :

Une fois la création terminée, nous pouvons constater les ressources suivantes dans notre groupe de ressources :

Etape III : Affectation des utilisateurs

Comme pour tout environnement Azure Virtual Desktop, il est nécessaire d’affecter des utilisateurs ou des groupes d’utilisateurs pour que ces derniers soient autorisés à se connecter aux machines virtuelles. Cela se passe par ici :

Etape IV : Ajout d’un argument RDP

Pour que la connexion RDP avec l’identité utilisateur Azure AD se fasse bien, il est nécessaire d’ajouter un argument spécifique. La gestion des propriétés RDP se font directement sur le pool d’hôtes d’AVD :

targetisaadjoined:i:1

Vous retrouverez ici la liste de toutes les options RDP possibles, dont seulement certaines sont compatibles avec Azure Virtual Desktop. Voici les arguments utilisés sur la copie d’écran ci-dessus :

drivestoredirect:s:;audiomode:i:0;videoplaybackmode:i:1;redirectclipboard:i:1;redirectprinters:i:1;devicestoredirect:s:;redirectcomports:i:1;redirectsmartcards:i:1;usbdevicestoredirect:s:*;enablecredsspsupport:i:1;use multimon:i:1;targetisaadjoined:i:1

Etape V : Ajout des rôles RBAC

Afin d’autoriser les utilisateurs à se connecter aux machines virtuelles, l’attribution des rôles RBAC est nécessaire. Pour rappel, ces rôles sont différents de ceux dans Azure AD, puisqu’ils sont affectés au ressources d’Azure. Dans notre AVD, l’affectation de deux rôles RBAC est nécessaires et se font assigner directement le groupe de ressources AVD :

  • Virtual Machine Administrator Login : Groupe d’utilisateurs ayant les droits d’administrateur local sur les machines virtuelles AVD
  • Virtual Machine User Login : Affecter le rôle Virtual Machine User Login au même groupe d’utilisateurs que celui utilisé pour le groupe d’application AVD

Etape VI : Test de la solution côté utilisateur via Remote Desktop

Une fois les étapes précédentes terminées, il ne reste plus qu’à tester le bon fonctionnent de la solution. Cela se fait en téléchargeant le client Remote Desktop PC dédié à Azure Virtual Desktop (téléchargeable ici), ou via l’accès web multi-plateformes (accessible )

Application Remote Desktop

Renseigner ici un compte Azure AD présent dans le groupe d’utilisateurs AVD.
L’écran de gestion du poste arrive dans la foulée, inutile de lier votre poste local à l’identité Azure AD.

L’écran ci-dessous nous emmène sur l’environnement Azure Virtual Desktop. Ici se trouvent tous les espaces de travail affectés à l’utilisateur, dans lesquels se trouvent toutes les applications (Remote Desktop ou Remote Apps) affectées à l’utilisateurs :

Ecran du Remote Desktop PC.

Une seconde demande d’authentification est affichée pour accéder à la machine virtuelle via le protocole RDP :

Le mot de passe peut être mémorisé pour éviter la ressaisie ultérieure.

Une fois le mot de passe saisi, l’ouverture d’une fenêtre RDP donne l’accès au bureau Windows 10 d’AVD. A noter que la jointure AVD apporte également le Seamless Sign on, rendant l’expérience utilisateur encore plus agréable :

Etape VII : Test de la solution côté utilisateur via HTML 5

Il est également possible de se connecter à Azure Virtual Desktop via un navigateur internet. Pour rappel, la page d’accès est la suivante : aka.ms/wvdarmweb :

Comme pour l’application Remote Desktop, l’authentification utilise le compte Azure AD.

On se retrouve alors, de la même manière que précédemment, sur une page donnant accès aux espaces de travail et aux applications :

Une seconde demande d’authentification est demandée pour accéder à la machine virtuelle.

Etape VIII : Vérifications Azure Virtual Desktop

Vérification de la jointure sur la machine virtuelle

Afin de regarder plus en détail cette jointure, la commande dsregcmd /status sur la machine virtuelle AVD nous en dit plus :

La jointure avec Azure AD est bien là mais aucune jointure à un domaine n’est faite.
Les informations relatives au tenant d’Azure AD.
Les informations relatives à l’activation de la fonctionnalité SSO.

Vérification de l’ajout des machines virtuelles dans Azure AD

Les machines virtuelles créées par Azure Virtual Desktop sont bien retranscrites dans la section Devices d’Azure AD. Cet ajout est réalisé lors de la jointure des machines virtuelles à Azure AD :

Vérification de l’ajout des machines virtuelles dans Intune

Comme j’ai coché la gestion des machines virtuelles AVD via la solution Intune, je retrouve bien mes machines virtuelles dans la console de cette dernière (lien ici)

Vérification du pool d’hôtes d’Azure Virtual Desktop

Comme cet exemple reposait sur un environnement AVD avec des machines virtuelles individuelles, je retrouve bien sur chacune un utilisateur assigné :

Etape IX : Gestion des erreurs liées à la jointure avec Azure AD

Il est possible de rencontrer des erreurs lors du déploiement de cet environnement AVD, en jointure avec Azure AD. Pour vous aider, Microsoft met à votre disposition cette page d’aide. Voici quelques exemples d’erreurs possibles :

Les machines virtuelles sont bien déployées, mais elles sont encore marquées comme indisponibles, plusieurs minutes après le déploiement d’AVD :

>> Avez-vous bien marqué à OUI la case de validation de l’environnement ?

Erreur de mot de passe de l’ouverture de la session RDP : « The logon attempt failed »

J’ai passé du temps sur cette erreur ????.

>> Si vous rencontrez une erreur indiquant que la tentative de connexion a échoué à l’invite des informations d’identification de sécurité Windows, vérifiez les éléments suivants :

  • Vous êtes sur un appareil qui est joint à Azure AD ou à Azure AD hybride au même locataire Azure AD que l’hôte de session OU
  • Vous êtes sur un appareil exécutant Windows 10 2004 ou version ultérieure qui est Azure AD enregistré auprès du même locataire Azure AD que l’hôte de session
  • Le protocole PKU2U est activé à la fois sur le PC local et sur l’hôte de session

La dernière hypothèse est fortement probable dans ce cas. Il faut donc penser à vérifier cette option sur la machine locale ET sur la machine virtuelle AVD, grâce à la commande secpol.msc :

Cette option est également configurable via GPO. la commande rsop.msc vous permet de voir cela.

Conclusion

Comme à chaque fois, Dean de l’Azure Academy nous met à disposition une vidéo très explicative sur tout le processus de cette nouvelle fonctionnalité d’Azure Virtual Desktop :

On attend bien évidemment avec impatience la prise en charge de la solution FSLogix dans ce scénario de jointure avec Azure AD. Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Virtual Desktop ????