Azure Virtual Desktop ❤️ FIDO2

Rassurez-vous, Azure Virtual Desktop propose depuis longtemps une intégration avec l’accès conditionnel disponible sur Azure AD. Ce billet, datant déjà de 2019, écrit par Freek Berson, nous montre bien l’intégration entre AVD et FIDO2.

Je souhaitais malgré tout vous écrire un article en français pour détailler le processus de mise en place FIDO2 et les possibilités intéressantes avec AVD.

Qu’est-ce que FIDO2 (Fast IDentity Online 2) ?

La réponse de l’industrie au problème des mots de passe.
FIDO Alliance

Exit donc l’utilisation d’un simple du mot de passe pour valider un processus d’authentification. FIDO2 a été développé par la FIDO Alliance et est à ce jour leur dernière norme.

FIDO2 est bâti sur des spécifications Web Authentication, ou WebAuthn, du World Wide Web Consortium (W3C), donc universel mais disposant de capacités supplémentaires.

Cette vidéo en français explique plusieurs de ces avantages :

USB-A ou C ou encore NFC
Absence de donnée personnelle sur la clef
Code PIN de protection
Zone de contact pour valider une présence physique
Utilisation pour plusieurs comptes

Bon conseil : toujours avoir deux clefs ????.

Puis-je utiliser une clef FIDO2 pour m’authentifier sur Azure AD ?

Oui, Azure AD supporte un grand nombre de méthodes renforcées pour sécuriser l’authentification des utilisateurs. Vous pouvez retrouver cette liste ici, ou dans le portail Azure, via la page des Méthodes d’authentification :

D’une manière générale, Microsoft déconseille l’utilisation unique de mot de passe pour authentifier un compte (Voir tableau ci-dessous). Azure AD propose à ce jour différentes méthodes dans le cadre d’un processus d’authentification multifacteur :

Windows Hello Entreprise
Microsoft Authenticator
Clés de sécurité FIDO2

Ai-je besoin d’une licence particulière pour utiliser FIDO2 ?

FIDO2 n’exige pas de licence particulière, mais l’accès conditionnel en demandera une. En effet, pour intégrer FIDO2 dans une ou plusieurs polices d’accès conditionnel, il vous faudra une licence Azure Premium P1 ou P2 pour tous les utilisateurs concernés.

Fonctionnalité	Azure AD Free – Paramètres de sécurité par défaut	Azure AD Free – Administrateurs généraux uniquement	Office 365	Azure AD Premium P1	Azure AD Premium P2
Accès conditionnel				●	●
Accès conditionnel basé sur les risques					●

Il ne faut pas confondre l’accès conditionnel qui vient en remplacement, car plus abouti et personnalisable que la MFA de base ou les paramètres de sécurité par défaut :

Stratégie	Paramètres de sécurité par défaut	Accès conditionnel	Authentification multifacteur par utilisateur
Gestion
Ensemble standard de règles de sécurité pour garantir la sécurité de votre entreprise	●
Activé/désactivé en un clic	●
Inclus dans la gestion des licences Office 365	●		●
Modèles préconfigurés dans l’assistant Centre d’administration Microsoft 365	●	●
Flexibilité de la configuration		●
Fonctionnalité
Exempter les utilisateurs de la stratégie		●	●
Authentification par appel téléphonique ou SMS		●	●
S’authentifier par Microsoft Authenticator et jetons logiciels	●	●	●
Authentification par FIDO2, Windows Hello Entreprise et les jetons matériels		●	●
Bloque les protocoles d’authentification hérités	●	●	●
Les nouveaux employés sont automatiquement protégés	●	●
Déclencheurs MFA dynamiques en fonction des événements à risque		●
Stratégies d’authentification et d’autorisation		●
Configurable en fonction de l’emplacement et de l’état de l’appareil		●
Prise en charge du mode « Rapport seul »		●

Où peut-on se procurer des clefs FIDO2 ?

Microsoft met à disposition cette liste de fournisseur proposant justement des clefs FIDO2 :

Pour effectuer mes tests sur mon environnement Azure, j’ai décidé d’acheter deux clefs USB-A sous forme de pack auprès de Token2 Switzerland, au prix de 23€, frais de port compris :

Comment procède-t-on pour intégrer FIDO2 à Azure Virtual Desktop ?

Le processus d’installation est très simple, il vous faudra néanmoins quelques prérequis pour arriver à une intégration complète. Dans ce tutoriel, nous allons mettre en place une clef FIDO2 pour un utilisateur et créer deux polices d’accès conditionnel dédiées à AVD :

Etape 0 – Rappel des prérequis :

Les prérequis suivants sont nécessaires pour réaliser cette démonstration avec AVD :

Un poste sous Windows 10 (1903) ou supérieur
Un tenant Microsoft
Une souscription Azure valide
Un environnement AVD déployé (je vous conseille de suivre ce tutoriel)
Une licence Azure AD Premium Plan 1 ou Plan 2

Si votre tenant ne dispose d’aucune licence Azure AD Premium, vous pouvez activer une licence Azure AD Premium Plan 2 en version d’essai directement depuis le portail Azure AD :

Une fois la version d’essai activée, pensez à affecter une licence Azure AD Premium Plan 2 à un utilisateur votre tenant.

Etape I – Configuration du code PIN :

Azure AD exige que les clés de sécurité soient protégées par un code PIN. Insérer votre clef FIDO2 dans un port USB et allez dans les paramètres de votre poste pour le définir :

Cliquez ici pour configurer la clef :

Touchez la zone prévue à cet effet pour continuer :

Définissez un code PIN et confirmez-le :

Etape II – Activation de FIDO2 sur Azure AD :

Sur le portail d’Azure AD, consulter les paramètres de Sécurité via le menu suivant :

Cliquez sur Méthodes d’authentification :

Cliquez sur la ligne FIDO2 :

Activez la fonctionnalité FIDO2, puis cliquez sur Configurer :

Sauvegardez-là avec les options de base :

Quelques minutes sont parfois nécessaire pour continuer sur la configuration FIDO2 au niveau de l’utilisateur. Ne vous inquiétez pas si les écrans suivants ne sont pas encore identiques au tutoriel.

Etape III – Enrôlement d’une clef FIDO2 sur un compte Azure AD :

Comme dit précédemment, la clef FIDO2 n’embarque aucune information personnelle sur les comptes associés à celle-ci. Vous pouvez donc sans souci utiliser la même clef pour plusieurs comptes Azure AD.

Dans mon cas, j’ai créé un nouvel utilisateur pour retester un enrôlement complet.

Rendez-vous sur la page myaccount de Microsoft avec votre utilisateur de test, puis cliquez les Informations de sécurité :

Cliquez ici pour ajouter la première clef FIDO2 :

Dans mon cas, Azure m’avertit que mon utilisateur de test ne dispose d’aucune autre méthode MFA, j’en profite donc pour mettre en place le SMS comme seconde méthode :

Une fois terminé, recommencez le processus pour arriver sur cet écran :

Azure AD entame une communication avec la clef FIDO2 :

Plusieurs messages d’information de Windows 10 vont se succéder :

Renseignez le PIN de votre clef FIDO2, puis continuez :

Touchez la zone prévue à cet effet pour terminer :

Il ne vous reste plus qu’à donner un nom à cette première clef FIDO2 :

Comme il est fortement conseillé, recommencer la même opération avec une seconde clef FIDO2, utilisable en cas de secours :

Etape IV – Test de FIDO2 :

Avant d’aller plus loin dans l’intégration avec Azure Virtual Desktop, je vous conseille de tester l’authentification utilisateur avec sa clef FIDO2. Pour cela ouvrez le navigateur de votre choix en mode privé et allez sur la page web office.com.

Cliquez-ici pour vous authentifier :

Au lieu de saisir le mot de passe du compte de test, cliquez comme ceci :

Renseignez le code PIN de votre clef FIDO2 :

Touchez la zone prévue à cet effet pour confirmer l’authentification :

Cliquez enfin sur Non :

Et vous voilà correctement authentifié sur le portail Office365 ????

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

En faisant différents tests, je me suis rendu compte que l’on pouvait intégrer le mécanisme FIDO2 à plusieurs niveaux d’AVD.

Pour rappel, je suis partie d’un environnement Azure Virtual Desktop existant et équivalent à ce qui est détaillé dans cet article : Simplifiez l’authentification des utilisateurs d’AVD joint Azure AD avec Single Sign-on – Jean-Loup & Azure (jlou.eu).

Encore en préversion à ce jour, connectez-vous au portail d’Azure et rendez-vous dans le service Azure AD avec un compte administrateur adéquat :

Ouvrez le menu Sécurité :

Cliquez sur Méthodes d’authentification :

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

Terminez la création de celle-ci :

Etape VI – Test de l’accès conditionnel au premier niveau :

Toujours dans votre portail Azure AD, retournez dans la section Sécurité puis cliquez sur Accès conditionnel :

Créez votre nouvelle Police :

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

Ajoutez l’application Azure Virtual Desktop :

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

Attendez quelques minutes et ouvrez votre client Windows d’Azure Virtual Desktop pour tester votre première police d’accès conditionnel :

Renseignez le compte Azure de votre utilisateur de test et constatez la présence de ce message :

Touchez la zone prévue à cet effet pour terminer l’authentification :

Félicitations ! Votre accès AVD est bien protégé par la clef FIDO2 ????.

Etape VII – Test de l’accès conditionnel au second niveau :

En parcourant les fonctionnalités de l’accès conditionnel d’Azure AD, j’ai remarqué une seconde application du Cloud Azure très intéressante :

J’ai donc créé une seconde règle d’accès conditionnel, avec les mêmes autres paramètres pour intégrer un mécanisme FIDO2 au moment de l’ouverture de session Windows d’AVD :

Sur votre application Azure Virtual Desktop, cliquez sur l’icône pour ouvrir une session AVD :

Attendez que le processus continue :

Choisissez le compte autorisé à AVD et disposant d’une clef FIDO2 :

Renseignez le code PIN de votre clef FIDO2 :

Touchez la zone prévue à cet effet pour confirmer l’authentification :

Attendez que la session AVD s’ouvre :

Conclusion

Cette combinaison AVD + AD + FIDO2 fut très intéressante à tester, et assez simple à mettre en place. Cette flexibilité nous montre aussi l’infinité de scénarios possibles pour augmenter la sécurité des utilisateurs sans pour autant rendre le quotidien lourd ou invivable.

Enfin, profitez-en pour sécuriser un peu plus vos comptes à vous ????

Privatisez l’accès de votre AVD

Azure Virtual Desktop continue encore d’évoluer et s’associe maintenant avec un autre service réseau du cloud Microsoft : Azure Private Link. En ce début du mois de novembre, Microsoft vient de l’ouvrir en préversion publique pour tester cette fonctionnalité. L’idée est donc de sécuriser d’avantage, par une restriction encore plus poussée, l’accès au service Azure Virtual Desktop.

Pourquoi restreindre un service Cloud ?

Pour répondre à une demande provenant de certaines entreprises. Beaucoup d’entre-elles ont même des exigences légales et ne souhaitent donc pas faire passer un flux réseau à travers internet, quand bien même il s’agirait de communications en HTTPS.

Il paraissait donc important que Microsoft propose ce type de fonctionnalité pour permettre à au service à Azure Virtual Desktop d’être 100% en dehors du web.

Pour parvenir à la mise en place de cette fonctionnalité, Microsoft met déjà à disposition plusieurs documentations, disponibles uniquement en anglais pour l’instant :

Qu’est-ce qu’Azure Private Link ?

En deux mot, Azure Private Link vous permet d’accéder aux services Azure PaaS (par exemple du stockage Azure, compte le compte de stockage ou encore une base de données SQL) depuis votre réseau virtuel :

Voici une vidéo qui aborde le sujet dans son entièreté :

Comment va fonctionner Azure Virtual Desktop avec Private Link ?

Comme pour les autres services proposant cette association, le trafic entre le réseau virtuel et Azure Virtual Desktop transitera par le réseau « dorsal » de Microsoft, ce qui signifie que vous n’aurez plus besoin d’exposer votre AVD à l’Internet.

En termes de sécurité, transiter son trafic dans le réseau « connu » et sécurisé de Microsoft renforcera toujours un peu plus la protection de vos données.

A quel moment intervient le Private Link dans le chemin de connexion entre l’utilisateur et AVD ?

Il peut intervenir à plusieurs niveaux. En effet, la connexion est décomposée en différentes étapes et avec plusieurs composants. Il est alors possible de choisir quelles connexions ont le droit ou non de transiter par internet.

C’est d’ailleurs pour cela que plusieurs options sont présentes dans la configuration réseau d’AVD :

La première option se charge d’autoriser ou non l’accès au service AVD des utilisateurs depuis internet. Autrement la partie frontale de la connexion AVD.
La seconde option se charge d’autoriser ou non l’accès au service AVD des machines virtuelles AVD depuis internet. Autrement la partie arrière-plan de la connexion AVD.

Peut-on utiliser à la fois les fonctionnalités Private Link et RDP Shortpath ?

Durant cette phase de préversion, cela n’est pas possible. Pour rappel RDP Shortpath est une méthode habile d’Azure Virtual Desktop qui établit un transport direct basé sur le protocole UDP entre le client Remote Desktop et l’hôte de session. Tout y est expliqué ici.

Etape 0 – Rappel des prérequis

Pour arriver à la démonstration de l’association entre Azure Virtual Desktop et Private Link, je dispose d’un environnement comprenant des composants déjà en place :

Poste Windows 10 avec Azure VPN
Environnement AVD avec jointure Azure AD

On retrouve ainsi mon premier réseau virtuel comprenant :

La machine virtuelle faisant office de poste utilisateur distant sous Windows 10
Le service Azure Bastion pour m’y connecter plus facilement

J’ai également déployé un second réseau virtuel. Celui-ci comprend

Mon environnement Azure Virtual Desktop
Une passerelle VPN pour assurer la connection entre le poste Windows 10 et AVD

La connexion VPN Point à Site est bien fonctionnelle :

*L’accès direct à une des machines virtuelles AVD répond bien*.

Comme vous pouvez le voir sur la configuration d’Azure Virtual Desktop, une nouvelle section dédiée au réseau a fait son apparition :

Avant d’aller plus loin, il est donc nécessaire d’activer la fonctionnalité, encore en préversion à l’heure où ces lignes sont écrites.

Etape I – Activation de la fonction de préversion d’Azure Private Link

Comme beaucoup de fonctionnalités encore en préversion, il est nécessaire de l’activer depuis le portail Azure. Pour cela, effectuer l’opération suivante via ce lien :

N’oubliez pas de sélectionner la bonne souscription Azure.

Une fois enregistrée, attendez environ 15 minutes.

Retournez sur la section réseau de votre Azure Virtual Desktop pour constater le déblocage des fonctionnalités réseaux :

Dans cette configuration par défaut, avec les 2 cases de cochées, la connexion réseau transite via internet dans sa totalité :

Entre le client et le service Azure Virtual Desktop
Entre le service Azure Virtual Desktop et les machines virtuelles AVD

Un test, avec le VPN désactivé, montre que la connexion se fait toujours via internet :

Etape II – Restreindre la communication entre le service AVD et le pool d’hôtes au réseau virtuel Azure

La première étape consiste donc à restreindre la communication entre le service Azure Virtual Desktop et les machines virtuelles AVD au réseau virtuel. Pour cela décochez la case suivante et sauvegardez :

Un nouvel essai de connexion utilisateur vous montre le blocage immédiat de cette méthode en passant par internet :

*Comme dit plus haut, l’utilisateur n’en est pas responsable : Le service Azure Virtual Desktop est incapable de communique avec la machine virtuelle AVD.*

Pour arriver rétablir l’accès au service AVD, nous avons besoin de créer un premier private endpoint en cliquant sur le second onglet de la section réseau :

*Pour réactiver les connexions, vous devrez créer un private endpoint* pour chaque *pool d’hôtes AVD que vous souhaitez autoriser.*

Donnez-lui un nom, puis passez à l’onglet suivant :

Laissez cet onglet comme ceci avec le type connexion et passez sur le suivant.

Pour information, il existe différents types de sous-resource cible, ils auront une importance et seront utilisés par la suite :

Type de resource	Type de sous-resource	Quantité
Microsoft.DesktopVirtualization/workspaces	global	Un pour tous les déploiements Azure Virtual Desktop
Microsoft.DesktopVirtualization/workspaces	feed	Un par workspace
Microsoft.DesktopVirtualization/hostpools	connection	Un par pool d’hôtes

Renseignez le réseau / sous réseau de votre environnement Azure Virtual Desktop :

Pour votre information, plusieurs adresses IP privées seront alors allouées pour les services suivants :

Sur l’onglet suivant, une zone DNS privée va être créé pour le private endpoint :

Lancez la création puis attendez :

Une fois créé, la carte réseau du private endpoint nouvellement créé vous montre que chaque service dispose bien d’une adresse IP dédiée :

Important : Pour les gros environnement AVD, prévoir un second sous-réseau pour éviter un souci d’adressage.

Un redémarrage de machines virtuelles AVD plus tard : la connexion AVD depuis le poste client refonctionne sans souci :

Veuillez noter que la copie d’écran ci-dessus montre bien que le VPN d’Azure est toujours déconnecté. Cela montre bien que nous n’avons pas encore influencé la partie frontale du service AVD.

Pour bien comprendre ce qui s’est passé, un test intéressant est de

Créer un groupe de sécurité réseau (NSG)
Y ajouter une restriction d’accès au service publique d’Azure Virtual Desktop
L’associer au sous-réseau contenant les machines virtuelles AVD

Ce test créé une contrainte qui n’empêche pas notre test de fonctionner, car la connexion entre le service Azure Virtual Desktop et les machines AVD transite par le private endpoint nouvellement créé.

J’ai également fait un autre test de retirer le private endpoint. Les machines virtuelles AVD apparaissent alors bien comme étant injoignables pour le service Azure Virtual Desktop :

Maintenant, la seconde étape est de restreindre également l’accès au service Azure Virtual pour les postes connectés uniquement à internet.

Etape IIIa – Restreindre la communication entre le service AVD et les utilisateurs au réseau virtuel

La première étape consiste donc à restreindre la communication entre le service AVD et les utilisateurs via internet. Pour cela, décochez la case suivante et sauvegardez :

Un nouvel essai de connexion à AVD nous montre le blocage immédiat de cette méthode en passant par internet :

Un rafraichissement de l’espace de travail AVD montre maintenant un refus d’affichage de celui-ci :

Pour terminer la configuration, nous avons besoin de créer deux autres private endpoints.

Pour cela, allez sur l’espace de travail AVD, allez dans la section réseau, décochez la case et sauvegardez :

Comme précédemment, commencez par créer un private endpoint comme ceci :

Nommez-le différemment du premier private endpoint créé durant l’étape précédente :

Choisissez cette fois-ci la sous-resource cible de type Feed :

Renseignez le réseau / sous réseau où votre environnement Azure Virtual Desktop :

Là encore, des adresses IP privées seront allouées pour les services suivants :

Sur l’onglet suivant, la première zone DNS privée va être réutilisée pour le second private endpoint, rattaché à votre espace de travail :

Lancez la création puis attendez :

Une fois créé, retournez sur la page d’Azure Virtual Desktop pour créer le troisième private endpoint de type Global.

Etape IIIb – Restreindre la communication entre le service AVD et les utilisateurs au réseau virtuel

Microsoft conseille d’isoler ce private endpoint sur un espace de travail dédié au réseau. En effet, ce private endpoint unique de type Global pourrait service servir à tous les réseaux virtuels appairés.

Pour cela, créez un nouvel espace de travail AVD :

Nommez-le et lancez sa création :

Une fois créé, retournez-y, décochez là encore l’option réseau, puis sauvegardez.

Créez ici le troisième private endpoint et remplissez le premier onglet comme les 2 précédentes fois :

Choisissez le type de sous-resource cible Global :

Choisissez un réseau en relation directe avec votre environnement AVD :

Pour information, une adresse IP privée sera là-encore allouée pour le service suivant :

Sur l’onglet suivant, la première zone DNS privée va être réutilisée pour le troisième private endpoint, rattaché à ce nouvel espace de travail :

Lancez la création puis attendez :

Etape IV : Configuration du réseau on-premise

Pour que la connexion restreinte à Azure Virtual Desktop fonctionne bien, il est nécessaire d’apporter les enregistrements DNS créés précédemment sur le réseau on-premise.

Comme mon réseau on-premise est virtuellement créé sur Azure, j’ai choisi de créer une seconde zone DNS privée avec le même nom et de la rattacher à mon réseau on-premise :

*Reprenez tous les enregistrements présents dans la zone DNS créée par les private endpoints*.

Si comme moi votre réseau on-premise est dans Azure, associez cette zone DNS privée à celui-ci.

Etape V : Test de la connexion via Azure VPN Point à Site

Sur le poste on-premise de test, effectuez un premier test de connexion à l’URL d’Azure Virtual Desktop tout en ayant la connexion VPN de stoppée :

aka.ms/wvdarmweb

Constatez avant tout que la page n’est dorénavant plus joignable :

Démarrez votre connexion VPN grâce au client Azure VPN :

Recharger la page web du service Azure Virtual Desktop et renseignez vos identifiants de l’utilisateur de test :

Cliquez sur l’icône de bureau à distance :

Renseignez une seconde fois son mot de passe :

Et vus voilà dans votre session AVD !

Un test de déconnexion de la connexion VPN affectera immédiatement la session utilisateur d’AVD :

Réactiver la connexion VPN pour retrouver la session AVD.

Etape VI : Résumé des ressources Azure créées

Afin d’apporter plus de clarté à toutes ces opérations de déploiement, voici un récapitulatif du travail effectué dans cet article sur mon environnement Azure :

3 private endpoints :

3 cartes réseaux :

2 zones DNS privées :

1 second espace de travail AVD :

Etape VI : Aide à la résolution

Si l’installation s’est déroulée sans accro, mais que vous n’arrivez toujours pas à vous reconnecter à votre environnement Azure Virtual Desktop, voici quelques pistes qui peuvent vous aider :

*Absence du premier private endpoint sur le pool d’hôtes AVD.*

*Authentification correcte, mais absence d’enregistrements DNS www,* rdweb et client sur le réseau on-premise.

*Authentification correcte, mais absence d’enregistrements DNS .*rdweb sur le réseau on-premise.

*Authentification correcte, mais absence d’enregistrements DNS gateway sur le réseau on-premise.*

Conclusion

Par cette nouvelle fonctionnalité, Microsoft apporte encore plus de liberté dans la manière d’utiliser son environnement AVD, avec toujours plus d’exigences de sécurité. La possibilité de restreindre le service AVD à différents types de connexions sécurisées, comme les VPNs ou encore Azure ExpressRoute était attendue depuis longtemps.

Comme toujours, Dean de l’Azure Academy a préparé une vidéo très explicative de la mise en route ????

Stockez vos données sur un service PaaS

Azure propose depuis longtemps plusieurs méthodes efficaces pour le stockage de donnée dans le Cloud. Disponibles sous différentes formes, le compte de stockage est une méthode PaaS (Platform As A Service) simple, rapide à déployer et pouvant correspondre à de nombreux scénarios d’architecture.

Il y a tant de choses à dire sur le compte de stockage d’Azure, qu’un seul article ne suffira pas. Dans cet article, nous allons donc parcourir les principales fonctionnalités du compte de stockage à travers différentes questions que l’on peut naturellement se poser.

Quels sont les principaux bénéfices du compte de stockage Azure ?

Il est facile de résumer les principaux avantages à utiliser un compte de stockage Azure :

Résilient : comme beaucoup de services Azure, celui-ci affiche une haute disponibilité grâce à différents types de redondance (LRS/ZRS/GRS). De plus, les outils de sauvegarde natifs d’Azure s’y applique également.
Sécurisé : toute donnée sur un compte de stockage Azure est systématiquement chiffrée. Ce chiffrage est aussi gérable avec une clef CMK.
Adaptatif : la flexibilité est une composante majeure du compte de stockage Azure grâce à une tarification ajustable selon la fréquence et les besoins en taille et en performances.
Accessible : les données stockées sont accessibles depuis n’importe où dans le monde via le protocole HTTPS. Microsoft fournit également des bibliothèques clientes dans de nombreux langages, notamment .NET, Java, Node.js, Python, PHP, Ruby, Go.

Quels services de stockage sont alors possibles sur un Azure Storage Account ?

Un compte de stockage Azure propose 4 différents services de stockage, selon la nature même des objets à stocker :

Objets blob : stockage objet hautement scalable pour les données texte ou binaires.
Partage de fichier : partage de fichiers classique géré via le protocole SMB.
Files d’attente : outil de messagerie entre différents composants d’application.
Tables : magasin NoSQL pour le stockage sans schéma de données structurées.

Quels types de compte de stockage Azure sont disponibles ?

Plusieurs types de comptes de stockage sont proposés par Azure. Il faut en retenir que l’utilisation de tel ou tel type de compte de stockage dépend de la performance désirée et du mode de réplication :

Type	Services disponibles	Options de redondance disponibles
Usage général v2 Standard	Blob, File d’attente, Table et Azure Files	LRS ZRS GRS RA-GRS GZRS RA-GZRS
Objets bloc blob Premium	Stockage Blob	LRS ZRS
Partage de fichiers Premium	Azure Files	LRS ZRS
Objets page blob Premium	Objets page blob de pages	LRS

Les comptes de stockage à hautes performances proposent une réplication limitée.

Comment la réplication fonctionne sous Azure ?

Les centres de données Azure sont maintenant présents en grand nombre à travers le monde. Il existe donc plus de 60 régions Azure, elles-mêmes regroupées en géographie :

Dans une région Azure, souvent composé de plusieurs centres, aussi appelés zone de disponibilité, sont interconnectés via un réseau haute performance et apporte une protection supplémentaire contre les défaillances matérielles, les pannes de réseau, d’électricité ou les catastrophes naturelles.

Comme vu précédemment, les options de réplication disponibles vont dépendre du type de compte de stockage sélectionné :

Donnée sur une région Azure :
- Stockage localement redondant (LRS) : 3 copies synchrones dans un seul centre de données d’une seule région.
- Stockage redondant interzone (ZRS) : 3 copies synchrones dans les 3 centres de données d’une seule région.

Donnée sur deux régions Azure (région paire de la première)
- Stockage géo-redondant (GRS) : 3 copies synchrones dans un seul centre de données d’une seule région + 3 copies asynchrones dans un seul centre de données de la région paire de la première.
- Stockage géo-redondant avec accès en lecture (RA-GRS) : 3 copies synchrones dans un seul centre de données d’une seule région + 3 copies asynchrones dans un seul centre de données de la région paire avec accès en lecture.
- Stockage géo-redondant interzone (GZRS) : 3 copies synchrones dans 3 centres de données d’une seule région + 3 copies asynchrones dans un seul centre de données de la région paire.
- Stockage géo-redondant interzone avec accès en lecture (RA-GZRS) : 3 copies synchrones dans les 3 centres de données d’une seule région + 3 copies asynchrones dans un seul centre de données de la région paire avec accès en lecture.

Ces options de réplication ont évidemment un impact conséquent sur les prix, comme le montre ce lien vers le calculateur Azure :

Comment accède-t-on à différents objets sur le compte de stockage ?

Un stockage de données a besoin au minium d’un point réseau pour remplir son rôle dans l’architecture. Par défaut, tout compte de stockage dispose d’URL uniques. Celles-ci reprennent le nom du compte de stockage suivi du service de stockage employé :

Service de conteneurs : https://mystorageaccount.blob.core.windows.net
Service de table : https://mystorageaccount.table.core.windows.net
Service de file d’attente : https://mystorageaccount.queue.core.windows.net
Partage de fichiers : https://mystorageaccount.file.core.windows.net

Par exemple, cet accès public met à disposition de la donnée sans authentification, comme par exemple pour un conteneur blob public :

Une URL ne signifie pas que l’accès est non contrôlé, comme le montre la création d’un second conteneur :

*L’accès est bien refusé car une authentification est nécessaire.*

L’accès au contenu devra donc passer par l’utilisation d’une des 2 clefs du compte de stockage, pour générer une signature d’accès partagé (SAS). L’avantage de cette gestion est de mieux gérer les droits précis et la durée d’accès :

Exemple d’URL avec signature SAS :

https://jlosto.blob.core.windows.net/pictures-secure/Geneva-at-night.jpg?sp=r&st=2022-11-09T12:33:20Z&se=2022-11-09T20:33:20Z&spr=https&sv=2021-06-08&sr=b&sig=AIWmVLKklAgOPoCYBvd%2BOl5fr5K0mZe3xAowIOXcq7

Les choses sont sensiblement proches pour un partage de fichiers. Dans ce service, l’authentification est possible de 2 manières :

Active Directory
Clef du compte de stockage

La première méthode demande au préalable de joindre le compte de stockage à un domaine Active Directory. Un précédent article parlant de FSLogix, au sein d’un environnement Azure Virtual Desktop, en fait référence ici.

La seconde méthode repose assez sur l’utilisation d’une des 2 clefs du compte de stockage. C’est un risque d’octroyer plus que de droits que nécessaires, car une clef donne un accès complet au compte de stockage.

Important : Microsoft le précise, vos clés d’accès de compte de stockage sont similaires au mot de passe racine pour votre compte de stockage. Veillez toujours à protéger vos clés d’accès :

Utilisez le service Azure Key Vault pour gérer et effectuer la rotation de vos clés en toute sécurité.
Évitez de distribuer des clés d’accès à d’autres utilisateurs, de les coder en dur ou de les enregistrer en texte brut dans un emplacement accessible à d’autres personnes.
Effectuez une rotation de vos clés si vous pensez qu’elles ont pu être compromises.

Exemple de montage du partage de fichier via le script proposé sur le portail et utilisant une des 2 clefs du compte de stockage :

Peut-on restreindre les IP publiques pouvant s’y connecter ?

Oui c’est tout à fait possible. L’onglet Réseau du compte de stockage apporte ce type de restriction, basée sur les ip publiques :

Même en possession de la clef du compte de stockage, un autre poste ayant une IP publique non référencée ne pourra s’y connecter :

Attention, la mise en place de cette restriction bloquera automatiquement l’accès aux ressources situées de la même région Azure :

Les services déployés dans la même région que le compte de stockage utilisent des adresses IP Azure privées. Vous ne pouvez donc pas restreindre l’accès à des services Azure spécifiques en fonction de leur plage d’adresses IP sortantes publiques.
Microsoft Doc

Pour les ressources Azure situées dans la même région que le compte de stockage, il est alors nécessaire de rajouter le réseau virtuel Azure pour retrouver un accès public fonctionnel :

Cette action ajoute un point de terminaison du service sur le sous-réseau rajouté sur la configuration :

Peut-on fermer l’accès public (URL) et ne transiter que via un adressage réseau privé ?

Il parfaitement possible de fermer l’accès public et d’intégrer le compte de stockage sur un réseau virtuel privé Azure.

Un point de terminaison privé est une interface réseau qui utilise une adresse IP privée de votre réseau virtuel. Cette interface réseau vous connecte de manière privée et sécurisée à un service fonctionnant avec Azure Private Link. En activant un point de terminaison privé, vous intégrez le service à votre réseau virtuel.

Ayant associé un service DNS privé à mon réseau virtuel, je retrouve bien un enregistrement dns pointant vers mon compte de stockage :

L’accès est bien à nouveau fonctionnel depuis le réseau virtual Azure :

La mise en place du point de terminaison privé permet alors la désactivation complète de l’accès public du compte de stockage :

La fermeture de l’accès public a aussi pour effet de restreindre l’accès aux données du compte de stockage depuis le portail Azure :

Existe-t-il un soft-delete pour les données ?

Oui et non ????. Les services de stockages principalement utilisés sont le blob et le partage de fichier. Le soft-delete consiste à ne pas vraiment supprimer définitivement la donnée lors de sa suppression par un utilisateur.

Le stockage blob propose deux soft-deletes : Un pour le container tout entier et un autre pour les blobs eux-mêmes :

Le partage de fichier ne propose l’option que pour la suppression du partage de fichiers, pas son contenu individuel :

Comment sauvegarder facilement les données ?

Deux services du compte de stockage se sauvegardent très facilement à travers des services Azure.

Le stockage blob nécessite la mise en place d’un coffre de sauvegarde, en veillant à le placer dans la même région Azure que le compte de stockage à sauvegarder :

Une fois le coffre de sauvegarde créé, mettez en place votre sauvegarde :

Définissez votre police de sauvegarde selon vos besoins de rétention :

Ajoutez le compte de sauvegarde blob et attendez quelques minutes pour confirmer sa validation :

Le coffre de sauvegarde a besoin du rôle pour pouvoir gérer la sauvegarde blob, cliquez comme ceci pour ajouter le rôle attendu :

Ce rôle est bien implémenté sur le compte de stockage :

Attendez quelques minutes pour constater la validation :

Déclenchez la configuration de sauvegarde, il est à noter que nous n’avons jamais pu choisir le ou les conteneurs du compte de stockage à sauvegarder :

Un contrôle dans le coffre de sauvegarde nous montre bien la bonne prise en compte de la configuration :

Pour le partage de fichier, il est nécessaire de passer par la création d’un coffre de récupération Azure :

Une fois le coffre de récupération créé, mettez en place votre sauvegarde :

Ajoutez le compte de stockage et le partage de fichier à sauvegarder, définissez la police et activez la sauvegarde :

Contrôler le paramétrage dans le coffre de récupération :

Comment fonctionne la synchronisation entre différents comptes de stockage ?

Lorsque la réplication d’objets blob est activée, les blobs sont copiés de manière asynchrone depuis un compte de stockage source vers un compte de stockage de destination.

Créez une règle de réplication sur le premier compte de stockage (source) :

Vérifiez le contre paramétrage sur le compte de stockage (destination) :

Comme la réplication est asynchrone, il faut attendre plusieurs minutes pour constater l’apparition des blobs sur le second compte de stockage :

Peut-on réduire les coûts blob ?

La gestion blob via un cycle de vie utilise des règles pour déplacer automatiquement les blobs vers des niveaux plus froids ou pour les supprimer. Cette stratégie est intéressante car les coûts varient selon la chaleur du stockage :

Cette variation impacte également le prix des transactions blob :

Par exemple, la création de règle en escalier est logique pour refroidir d’anciennes sauvegardes :

*Si vous créez plusieurs règles, les actions associées doivent être mises en œuvre dans l’ordre des niveaux (du stockage chaud au stockage froid, puis l’archivage, puis la suppression).*

Conclusion

On pourrait continuer encore longtemps sur toutes les autres fonctionnalités proposées par le compte de stockage Azure. Je vous conseille les vidéos suivantes pour en apprendre un peu plus ????????

Changez la résidence de vos données 365

Bonne nouvelle en ce début du mois de novembre, Microsoft a réouvert le processus gratuit de migration de données 365 pour les tenants existants. De quoi parle-t-on exactement ? En quelques mots, ces dernières années, Microsoft a ouvert de plus en plus de centres de données, et cela allonge donc automatiquement la liste des pays. Cet avantage permet aux entreprises de choisir dans quel pays les données 365 seront stockées.

Qu’est-ce que la résidence des données 365 ?

Avant toute chose, Microsoft liste leurs termes et définitions en relation avec la résidence de données 365 juste ici.

Important : les services 365 s’exécutent sur l’ensemble des centres de données Microsoft. A ce titre, les données peuvent donc être stockées dans plusieurs centres de données dans le cadre de transit :

La résidence des données fait ici donc référence à l’emplacement géographique où les données 365 sont stockées au repos.

Pourquoi s’intéresser à la résidence des données 365 ?

La résidence des données est cruciale pour les gouvernements, les entreprises du secteur public, les organismes d’éducation ou encore les entreprises travaillant dans des secteurs réglementés. Cette exigence est alors indispensable afin d’accroître la protection des informations personnelles et/ou sensibles.

Quelle est la résidence des données 365 par défaut ?

Lorsqu’on créé un nouveau tenant, il vous est systématiquement demandé de spécifier un pays durant le processus de création.

Important : Une fois le tenant créé, la zone géographique par défaut ne peut plus être modifiée.

Pourquoi changer la résidence des données ?

De plus, de nombreux pays exigent de leurs entreprises afin qu’elles se conforment aux lois, aux réglementations ou aux normes de secteur qui régissent explicitement l’emplacement du stockage des données.

Changer la résidence des données 365 est alors utile pour se conformer à ces règles, mais offre une également proximité entre le stockage des données et les utilisateurs finaux.

Qu’est-ce que le programme de déplacement hérité Data Residency ?

Coïncidant avec le lancement du module complémentaire Microsoft 365 Advanced Data Residency, le programme de déplacement n’est plus proposé lors du lancement de nouvelles régions de centre de données locales.
Microsoft Learn

Cette ouverture permettait donc de pouvoir migrer gratuitement les données de la région macro vers une région de centre de données locale qui correspond au pays d’inscription initial.

Autrement dit, de l’Europe vers la Suisse, la France, …

Comment activait-on cette demande de migration ?

Les clients éligibles voyaient cette option dans leur Centre d’administration Microsoft 365. Cocher cette case permettra de demander que leurs données applicables soient déplacées vers leur nouvelle région de centre de données :

Quand est-ce que la migration allait être opérée ?

Comme le monde la copie d’écran du tenant ci-dessus, la migration du tenant pouvait prendre jusqu’à 24 mois, à partir de la date d’échéance de la demande. La bonne nouvelle est que Microsoft a réouvert ce service gratuit, et ce pour une dernière fois !

Pendant combien de temps je peux activer cette option ?

Le tableau ci-dessous affiche la liste des pays éligibles et les dates associées. Il faut donc cocher la case précédente avant la fin de la période du pays qui vous concerne :

Important : Il s’agit de la dernière fenêtre de migration gratuite possible !!! Après ces dates, ce service existera toujours, mais sera payant ????

Et si j’ai d’autres questions concernant la migration ?

Microsoft met à disposition une FAQ concernant ce service et peut déjà répondre à certaines de vos interrogations ????

Bonne migration !

Plus que quelques heures pour finir votre défi Microsoft Learn Cloud Skills !

Comme chaque année, Microsoft organise par un evênement pour les développeurs et les professionnels de l’informatique.

Rappel des points importants

Voici une courte liste, mais pratique, des liens utiles pour ne rien louper de cet événement passé :

Comme à chaque fois, Microsoft propose à tous de passer des challenges techniques, dans le but d’obtenir des vouchers pour des certifications Microsoft gratuitement.

Voici la liste des examens accessibles via ce voucher Ignite :

Le défi prendra fin le 9 novembre 2022 à 16 h 00 UTC. Veillez à terminer tous les modules de votre défi avant cette date :

Years

Months

Quel que soit le nombre de défis Microsoft Learn Cloud Skills que vous relevez, vous ne pouvez remporter qu’un seul examen de certification Microsoft gratuit.

Votre offre d’examen de certification Microsoft gratuit sera envoyée d’ici le 18 novembre 2022 et expirera le 15 février 2023. Vous devez terminer votre examen avant cette date. Nous vous recommandons vivement de faire votre réservation au moins une semaine à l’avance. Pour consulter la liste complète des examens éligibles, reportez-vous aux règles officielles.

Architecte en cybersécurité Microsoft (SC-100)

Une nouvelle certification dédiée à la sécurité du Cloud Microsoft a fait son apparition il y a déjà quelques mois. Contrairement aux autres certifications dédiées au même sujet de niveau intermédiaire, celle-ci est de niveau expert. Elle ne se focalise par uniquement sur un pan sécuritaire spécifique du Cloud Microsoft, que ce soit Azure, Azure AD ou Microsoft 365.

Microsoft est d’ailleurs assez clair dans la description de ce que l’on peut attendre d’un Architecte en cybersécurité :

L’architecte de cybersécurité collabore continuellement avec les dirigeants et les professionnels en matière de sécurité informatique et de confidentialité, ainsi que d’autres rôles organisationnels, afin de planifier et d’implémenter une stratégie de cybersécurité répondant aux besoins d’une organisation.
Microsoft Learn

Comment comprendre le niveau Expert chez Microsoft ?

Je persiste à dire que les certifications de niveau Expert ont une utilité dans la connaissance macro du cloud Microsoft. Aucune volonté de réapprendre les fondamentaux de tel ou te service de sécurité, de leur fonctionnement précis, mais bien de comment les intégrer dans une stratégie sécuritaire globale de l’entreprise.

Il vous faut donc percevoir cette certification de la même manière que celles dédiées aux Architectes Azure ou aux Administrateurs Expert 365. N’en doutez-pas, les gammes de produits disponibles chez les acteurs majeurs du cloud publics sont tellement gigantesques que des rôles se sont nécessaire pour maîtriser cette vue d’ensemble et coordonner le tout.

Comment obtenir cette certification ?

Comme toutes les autres certifications de niveau expert, la certification ne s’obtient pas qu’avec un seul examen. Un examen de niveau associé est nécessaire pour obtenir le précieux badge.

En plus de l’examen SC-100, il vous faudra obtenir un des examens suivants :

*Aucune nécessité de programmer le passage d’examen dans un ordre précis.*

Quels sont les sujets abordés dans cette certification ?

Microsoft continue toujours de lister les compétences mesurées depuis la page d’examen :

Concevoir une stratégie et une architecture zéro confiance (30-35 %)
Évaluer les stratégies techniques et les stratégies d’opérations de sécurité de gouvernance des risques (20-25 %)
Concevoir la sécurité pour l’infrastructure (20-25%)
Concevoir une stratégie de données et d’applications (20-25 %)

Le fichier PDF lui aussi disponible sur cette même page reprend toujours en détail ces pourcentages de chaque module.

Il a changé depuis peu et intègre maintenant tous les liens utiles à la préparation de l’examen. De plus il vous détaille aussi les prochains changements opérés par Microsoft sur cet examen, pour vous permettre d’appréhender au mieux sa future mise à jour.

Comment préparer cette certification ?

Depuis peu, Learn est maintenant au centre de l’offre d’apprentissage proposé par Microsoft, que ce soit pour la documentation en libre accès ou pour les cours officiels dispensés par un MCT (Microsoft Certified Trainer) :

Cette mise à disposition complète et gratuite de contenus d’apprentissage est donc aussi valable pour la préparation de certifications Microsoft, via la mise en place de collections accessibles à tous :

L’authentification sur Learn est conseillé car elle vous permet alors de suivre votre progression d’apprentissage, et même d’accumuler des badges de succès obtenus après la lecture complète de modules :

Des contrôles de connaissances sont régulièrement intégrés en fin de module pour vous aider à valider votre compréhension :

Quoi d’autres ?

Des contenus adaptés à cet examen sont aussi disponibles sur des sources externes, comme sur ce blog ???? :

Comme toujours, une autre source me sert et m’informe sur Azure toutes les semaines : YouTube. John Savill reste pour moi une valeur sûre sur le fond et sur la forme. Il suffit de voir le temps passé sur cet examen sur cette vidéo :

John en a même fait une playlist YouTube pour rentrer en détail dans chacun des sujets ????.

Microsoft Learn Cloud Skills Challenge3

Petit rappel : comme à chaque Ignite, Microsoft vous propose de passer de petits challenges techniques. Ces challenges sont un moyen facile d’obtenir des connaissances techniques mais également des vouchers pour des certifications Microsoft. Tout cela gratuitement !

Voici la liste des examens accessibles via ce voucher Ignite :

Ne tardez pas pour vous en occuper avant le 09 novembre !

Years

Months

Conclusion

Au final, et comme dit précédemment, le passage de cet examen m’a fait penser aux autres certifications de niveau expert. La majorité des questions ont concerné des connaissances précises sur la sécurité, sans en attendre un côté incollable. L’important est d’en avoir une vue d’ensemble sur les capacités générales pour faire face à différentes exigences de sécurité.

Comme vous le savez déjà, ce type de certification Microsoft doit être renouvelée tous les ans pour conserver sa validité. Ce cycle de re certification est pour moi une excellente approche pour se tenir informé des nouvelles menaces et mesures de sécurité disponibles sur le marché.

Bon examen ????

Augmentez la résilience de votre AVD

De manière générale, la grande majorité des services proposés par les principaux hébergeurs Cloud s’accompagnent d’un niveau de service (SLA). Ce Service-level agreement est un point d’accord concernant la disponibilité d’un service entre les utilisateurs et l’hébergeur Cloud. Une architecture entière dispose elle aussi de sa propre SLA. La SLA de ce produit final combine alors toutes les SLAs de ses sous-produits dont elle dépend.

Dans cet article, nous allons parcourir ensemble quelques mécanismes de résilience disponibles sur Azure. Nous testerons aussi ces méthodes dans le cadre de déploiement d’environnement AVD via le portail Azure.

Qu’est-ce que la SLA selon Microsoft ?

Les Contrats de Niveau de Service (« Service-level agreements », SLA) décrivent les engagements de Microsoft en termes de temps de disponibilité et de connectivité. Les SLA pour les différents services Azure sont énumérés ci-dessous.
SLA selon Microsoft

Azure élabore différentes SLAs pour chaque service qu’ils proposent. Certains services encore en préversion, destinés à du développement ou même gratuits peuvent être dépourvus de SLA. Tout naturellement, une SLA plus élevée apporte une meilleure disponibilité au service attendu.

Prenons en exemple la SLA des machines virtuelles créées sur Azure. Cette SLA dépend par exemple des performances des disques rattachés à la machine virtuelle :

Le choix de disques plus performant est une chose facile à comprendre et à mettre en place. Elle est donc la une première démarche à effectuer pour renforcer la résilience.

Quelle SLA dans le cadre d’un Azure Virtual Desktop ?

Azure Virtual Desktop s’appuie lui aussi sur des machines virtuelles Azure. Microsoft propose le un tableau comparant les cinq types de disques disponibles pour vous aider à choisir celui que vous allez utiliser selon votre scénario d’utilisation :

	Disque Ultra	SSD Premium v2	SSD Premium	SSD Standard	HDD Standard
Type de disque	SSD	SSD	SSD	SSD	HDD
Scénario	Charges de travail gourmandes en E/S, telles que le système SAP HANA, les bases de données de niveau supérieur (par exemple, SQL et Oracle), et autres charges de travail très lourdes en transactions.	Charges de travail de production et sensibles aux performances qui nécessitent systématiquement une latence faible, des IOPS et un débit élevé	Charges de travail de production et sensibles aux performances	Serveurs web, applications d’entreprise peu utilisées et Dev/Test	Sauvegarde, non critique, accès peu fréquent

Microsoft vous recommande donc de créer vos machines virtuelles AVD avec des disques Premium SSD, et cela pour trois raisons :

SLA de haut niveau, 99.9 %, indispensable pour environnement de production.
Performances élevées, bande passante et IOPS satisfaisantes.
Rapport qualité / prix en intégrant les coûts transactionnels dans son prix mensuel fixe.

Dans le cadre d’un pool de machines virtuelles AVD avec des disques Premium SSD, la SLA est alors à 99.9 % pour chacune d’elle.

Un autre paramètre rentre en ligne de compte pour renforcer la SLA de machines virtuelles : Nombre de machines virtuelles jouant un rôle identique :

Qu’est-ce qu’un Groupe à haute disponibilité ?

Un Groupe à haute disponibilité est un regroupement logique d’au moins deux machines virtuelles, de manière à fournir une application hautement disponible et à répondre aux exigences du niveau de 99,95 % inscrit dans les contrats de niveau de service Azure. Le groupe à haute disponibilité proprement dit ne vous coûte rien ; vous payez uniquement pour chaque instance de machine virtuelle que vous créez.
Microsoft Learn

Deux notions importantes sont alors configurables grâce à cette fonctionnalité d’Azure :

Domaine de mise à jour : regroupe des machines virtuelles pouvant être mises à jour et donc potentiellement redémarrées en même temps. Le redémarrage des domaines de mise à jour effectue un redémarrage que sur un seul un seul domaine à la fois. (Max 20 domaines de mise à jour par Groupe à haute disponibilité)
Domaine d’erreur : regroupe des machines virtuelles partageant une source d’alimentation et réseau en commune. Cela a pour effet de limiter l’effet des défaillances des équipements physiques, des pannes du serveur et des coupures d’électricité. (Max 3 domaines d’erreur par Groupe à haute disponibilité)

Autrement dit, Azure vous permet de positionner gratuitement vos machines virtuelles dans un Groupe à haute disponibilité, de telle sorte que si l’une d’entre-elles rencontre des difficultés ou une mise à jour Azure, une continuité de service de votre application est assurée via la disponibilité garantie des autres machines virtuelles.

Dans le cas d’un environnement Azure Virtual Desktop, certains services critiques peuvent alors être répartis sur plusieurs Groupes de disponibilité. Par exemple :

Groupe de disponibilité 1 : Les machines virtuelles dédiées au pool d’hôtes AVD
Groupe de disponibilité 2 : Les machines virtuelles dédiées au domaine AD

Qu’est-ce que les Zones de disponibilité ?

Un schéma est souvent plus clair que de longues explications. Voici un empilement hiérarchique du Cloud Microsoft. Chaque service Azure est défini par toutes ces strates ici présentes.

Les géographies d’Azure n’ont pas d’impact direct sur les architectures déployées dans le Cloud. Il faut juste garder en tête qu’une géographie Azure regroupe plusieurs régions Azure.

Le niveau le plus important à retenir est bien la Région Azure. Le Cloud de Microsoft est réparti sur environ une soixantaine de régions Azure. La plupart de ces régions Azure forment une paire de 2 régions. Cette liaison forte apporte des services spécifiques, comme le but d’accroitre les capacités de de reprise après sinistre.

Enfin, de plus en plus de régions Azure disposent de plusieurs Zones de disponibilité :

Les Zones de disponibilité Azure sont des emplacements physiquement séparés au sein de région Azure, qui sont tolérants aux défaillances de centre de données en raison de l’infrastructure redondante et de l’isolation logique des services Azure.
Microsoft Learn

L’intérêt de disposer de lieux géographiques séparés de plusieurs kilomètres, voir dizaines de kilomètres, est d’apporter une meilleure résilience que celle générée via les Groupes à haute disponibilité, toujours présent dans un seul site physique, pour faire face à des sinistres de grande envergure.

A titre d’information, les zones de disponibilité sont disponibles dans la région Azure Suisse Nord depuis mai 2022.

Afin de garantir un haut niveau de performance, Microsoft signale que l’impact sur la latence d’une architecture Azure répartie sur plusieurs Zones de disponibilité est minime voire nul, et cela grâce à une latence inférieure à deux millisecondes entre ces zones.

Il est possible de combiner les Zones de de disponibilité avec les **Groupes à haute** *disponibilit*é.

Microsoft met également à disposition un outil graphique intéressant sur les composantes de l’infrastructure Azure afin d’en savoir un peu plus :

Comme pour presque tous les articles dédiés Azure Virtual Desktop, voici différents tests pour en évaluer l’impact dans le déploiement de vos ressources.

Etape 0 : Rappel des prérequis

Des prérequis sont nécessaires pour réaliser ces démonstrations AVD :

Un tenant Microsoft
Une souscription Azure valide
Un réseau virtuel existant sur Azure

La mise en place d’une notion de disponibilité doit se faire lors de la création des machines virtuelles. Il n’est plus possible d’agir dessus une fois les machines virtuelles déployées. Cela est donc paramétrable uniquement :

Lors de la création du pool d’hôtes AVD
Lors de l’ajout de nouvelles machines virtuelles à un environnement AVD existant.

Test A : AVD + Groupe à haute disponibilité

Commencez par déployer un pool d’hôtes AVD grâce à la barre de recherche du portail Azure :

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

Remplissez le premier onglet sans spécificité particulière :

Continuez sur les éléments de base de vos machines virtuelles AVD :

L’option ci-dessous nous invite à préciser la notion de disponibilité voulue. Choisissez ici Groupe à haute disponibilité :

Cliquez comme ceci pour en créer un nouveau Groupe à haute disponibilité :

Spécifiez le nom et les nombres de domaines de mise à jour et d’erreurs voulus :

Terminez de remplir les informations de cet onglet sans spécificité particulière :

Créez également un workspace AVD :

Lancez la création de votre environnement Azure Virtual Desktop :

Attendez que votre déploiement AVD se termine :

Contrôlez plusieurs machines virtuelles et constatez le Groupe à haute disponibilité dont elles dépendent :

Consultez l’ensemble des informations de votre Groupe à haute disponibilité en recherchant directement cette ressource Azure depuis votre groupe de ressources :

Ses paramétrages de base ne sont malheureusement plus modifiables :

L’ajout de nouvelle machines virtuelles à votre pool d’hôtes AVD avec ce même Groupe à haute disponibilité est toujours accessible.

La répartition des machines virtuelles est toujours faite en round-robin (équitable)

Finalement, le déploiement d’un environnement Azure Virtual Desktop via le portail Azure prend bien en charge la répartition des machines virtuelles du pool d’hôtes dans un Groupe à haute disponibilité.

Continuons maintenant avec un second test dédié aux Zones de disponibilité.

Test B : AVD + Zones de disponibilité

Là encore, nous allons commencer par déployer un second pool d’hôtes AVD. Repartez depuis la barre de recherche du portail Azure pour accéder au service AVD :

Remplissez là encore le premier onglet sans spécificité particulière :

Continuez sur les éléments de base de vos machines virtuelles AVD :

Choisissez dans le même menu déroulant Zones de disponibilité, puis sélectionnez les 3 Zones disponibles dans la région Suisse Nord :

Terminez de remplir les informations de cet onglet sans spécificité particulière :

Créez là encore un workspace AVD :

Lancez la création de votre environnement Azure Virtual Desktop :

Attendez que votre second déploiement AVD se termine :

Contrôlez plusieurs machines virtuelles et constatez la Zone de disponibilité dont elles dépendent :

A l’inverse du Groupe à haute disponibilité, il n’existe pas de ressource Azure symbolisant la Zones de disponibilité. Là encore, plus aucun paramétrage n’est modifiable après création.

Ici aussi, le déploiement d’un environnement Azure Virtual Desktop via le portail Azure prend lui aussi en charge la répartition des machines virtuelles du pool d’hôtes dans plusieurs Zones de disponibilité.

Remarque importante

Une différence subtile existe les Groupes à haute disponibilité et les Zones de disponibilité. Le premier est bien un groupe dont sont associées plusieurs machines virtuelles, tandis que le second est une affectation d’une machine virtuelle à un datacenter (zone) spécifique.

Au final, pour que ces deux services Azure fassent sens dans votre architecture :

Je n’ai besoin que d’un seul groupe à haute disponibilité pour plusieurs VMs
J’ai besoin de plusieurs zones de disponibilité pour plusieurs VMs

Pourquoi cette précision ?

Car il arrive souvent qu’un doute s’installe sur lesquelles et combien de ces ressources (Groupe à haute disponibilité / Zones de disponibilité) sont nécessaires.

Conclusion

Azure Virtual Desktop continue de progresser en automatisation et en simplicité de déploiement. Le fait que de plus en plus de régions Azure disposent de Zones de disponibilité est une très bonne nouvelle pour la résilience des services Cloud. Enfin Dean de l’Azure Academy nous en reparle en détail dans cette vidéo ????????

Re-joignez la force d’Entra ID

La jointure d’appareil à Azure AD est un sujet à lui tout seul. Celle-ci apporte pourtant un grand nombre de bénéfices pour la sécurité de son environnement 365 grâce à aux polices de compliance ou d’accès conditionnels. Très régulièrement, une confusion émane en provenance des messages parlant de jointure à Azure AD. Souvent ambigus, ils sont provoqués par l’authentification d’un utilisateur à un service 365 du Cloud Microsoft.

Dans cet article, nous allons apprendre les différents types de jointures possible à Azure AD notions et effectuer plusieurs tests sur un environnement de démo.

Qu’est-ce qu’Azure AD ?

Pourquoi joindre un appareil à Azure AD ?

Les appareils joints Azure AD ont pour objectif de simplifier :

Les déploiements Windows sur des appareils professionnels
L’accès aux applications .365 et aux ressources de l’organisation à partir de n’importe quel appareil Windows
Gestion cloud des appareils professionnels
Aux utilisateurs de se connecter à leurs appareils à partir de leurs comptes Azure AD ou Active Directory synchronisés professionnels ou scolaires.

Existe-t-il plusieurs types de jointure à Azure AD ?

Cette question a plusieurs réponses possibles et le choix va dépendre de l’identité du propriétaire des données, de la personne qui gère l’appareil et du type d’identification de l’utilisateur utilisé pour l’authentification :

Inscrire un appareil sur Azure :

L’objectif des appareils inscrits sur Azure AD (également appelés appareils joints à l’espace de travail) est de fournir à vos utilisateurs la prise en charge des scénarios d’appareil mobile et Bring Your Own Device (BYOD). Dans ces scénarios, un utilisateur peut accéder aux ressources de votre organisation à l’aide d’un appareil personnel.
Microsoft Doc

Appareil appartenant à une entreprise et géré par elle
L’authentification au dispositif se fait à l’aide d’un identifiant local ou d’un identifiant personnel dans le Cloud.
Authentification aux ressources de l’entreprise à l’aide d’un identifiant d’utilisateur sur AAD.

Joindre un appareil sur Azure :

Les appareils joints Azure AD sont connectés au moyen d’un compte professionnel Azure AD. L’accès aux ressources peut être contrôlé en fonction du compte Azure AD et des stratégies d’accès conditionnel appliquées à l’appareil. Les administrateurs peuvent sécuriser et mieux contrôler les appareils joints Azure AD à l’aide d’outils de gestion des périphériques mobiles (GPM), tels que Microsoft Intune ou dans des scénarios de cogestion à l’aide de Microsoft Endpoint Configuration Manager.
Doc Microsoft

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

Jointure hybride d’un appareil sur Azure :

Le meilleur des deux mondes !

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

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

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

Etape 0 : Rappel des prérequis

Pour effectuer ces tests, nous allons partir d’un environnement Azure et y déployer plusieurs machines virtuelles Azure. Avant cela, voici la courte liste des composants déjà présents sur mon environnement :

Tenant Azure
Souscription Azure valide
Un compte Azure AD avec une licence Office365

Test I : Jointure Azure AD : Inscription + MDM Intune

Déployez une première machine virtuelle avec Windows 10 dans votre souscription Azure comme ceci :

Connectez-vous en bureau à distance à cette dernière avec le compte administrateur local :

Exécutez la commande ci-dessous et constatez l’absence d’informations relatives à Azure AD :

dsregcmd /status

Exécutez l’application Office directement disponible via le menu Démarrer :

Cliquez comme ceci pour lancer le processus d’authentification 365 :

Choisissez l’option suivante et saisissez les identifiants de votre compte 365 :

Laissez cochée la case suivante et cliquez sur OK :

Un message de traitement apparaît alors et vous invite à attendre :

Fermez la fenêtre une fois le traitement réussi :

Relancez la commande précédente pour constater les changements relatifs à Azure AD :

dsregcmd /status

Retournez sur la page listant vos appareils dans le portail Azure AD :

Consultez également sur la page de vos appareils Windows dans le portail Intune :

Ce test nous apprend que la jointure à Azure AD n’est faite que sous forme d’inscription, mais que l’appareil est malgré tout gérable dans Intune. Ce scénario pourrait correspondre à un appareil personnel utilisé dans le cadre professionnel.

Test II : Jointure Azure AD : Inscription

Déployez une seconde machine virtuelle depuis votre Azure, identique à la première :

Ouvrez là encore une session de bureau à distance avec un utilisateur local.

Effectuez les mêmes opérations pour arriver jusqu’à l’écran ci-dessous. Mais décochez cette fois la case et cliquez sur OK :

Le message de traitement vous invitant à patienter est toujours présent :

Attendez la fin du traitement et fermez la fenêtre :

Lancez la commande suivante pour constater d’éventuels changements par rapport au précédent test de jointure :

dsregcmd /status

Retournez sur la page de vos appareils dans votre portail Azure AD et constatez l’apparition de cette seconde machine virtuelle :

*La colonne MDM n’est pas remplie, cela s’explique par la case décochée précédemment.*

Retournez sur la page de vos appareils Windows dans le portail Intune :

*Comme attendu, la seconde machine virtuelle n’apparaît pas.*

Ce second test nous apprend que la jointure à Azure AD n’est faite que sous forme d’inscription, et que l’appareil n’est pas gérable dans Intune. Ce scénario pourrait lui aussi correspondre à un appareil personnel utilisé dans le cadre professionnel.

Test III : Absence de jointure Azure AD

Déployez une troisième machine virtuelle Azure pour continuer à tester une autre possibilité de jointure.

Effectuez les mêmes opérations pour arriver jusqu’à cet écran. Cliquez sur Non, authentifiez-vous uniquement sur l’application :

*Pas de traitement ou de message de fin*.

Relancez la commande suivante pour voir d’éventuels changements avec les précédents tests :

dsregcmd /status

Un tour dans la liste des devices d’Azure AD pour constater une éventuelle apparition :

Il en est de même dans le portail Intune : 0 changement.

Ce troisième test nous apprend qu’aucune jointure à Azure AD, et que l’appareil n’est pas non plus gérable dans Intune. Ce scénario pourrait lui aussi encore correspondre à un appareil personnel utilisé dans le cadre professionnel.

Test IV : Jointure Azure AD : Join + MDM Intune

A l’inverse des tests précédents, la jointure de ce test va s’effectuer dans la configuration Windows.

Déployez une quatrième machine virtuelle Azure, toujours identique aux précédentes :

Connectez-vous sur votre machine virtuelle avec l’utilisateur local et allez dans les Comptes de vos Paramètres Windows :

Connecter votre compte Azure AD comme ceci :

Cliquez sur l’option ci-dessous pour joindre la machine virtuelle à un tenant Azure AD :

Renseignez le compte 365 de votre utilisateur :

Approuvez la jointure en cliquant sur Joindre :

Attendez que la jointure s’applique :

Le message de succès vous indique que vous pouvez maintenant utiliser votre compte Azure AD pour ouvrir la session Windows :

La jointure est bien confirmée grâce à l’indication suivante :

Pour vous connecter sur la machine virtuelle avec votre compte Azure AD, décochez la case suivante dans les propriétés système de celle-ci :

Fermez la session RDP ouverte précédemment.

Sur votre poste, modifiez le fichier RDP avec un éditeur de texte pour y ajouter les paramètres suivants :

enablecredsspsupport:i:0
authentication level:i:2

Cela donne un fichier contenant les lignes suivantes :

Ouvrez ce programme RDP et renseignez comme ceci votre compte 365 :

Sur cette nouvelle session RDP ouverte, exécutez la commande ci-dessous :

dsregcmd /status

Retournez et constatez la présence de cette nouvelle machine virtuelle dans la liste des appareils d’Azure AD, avec un nouveau type de jointure :

Il en est de même dans le portail Intune :

La quatrième machine virtuelle apparaît bien comme appartenant à l’entreprise.

A l’inverse des tests précédents, celui-ci nous apprend que la jointure à Azure AD complète, et que l’appareil est aussi gérable dans Intune. Ce scénario pourrait correspondre à un appareil professionnel utilisé dans le cadre professionnel.

Test V : Jointure Azure AD : Hybride AD / Azure AD

Ce nouveau test demandera un peu plus d’efforts. Pour y arriver, il va nous falloir disposer d’un domaine Active Directory. Commencez donc par créer une première machine virtuelle basée sur une image Windows Server :

Une fois déployée, connectez-vous en RDP sur cette machine virtuelle Windows Server :

Ajoutez à votre serveur les rôles de Contrôleur de domaine et de Serveur DNS et laissez-vous guider jusqu’au lancement de l’installation :

Terminez la configuration de l’Active Directory en créer une nouvelle forêt de domaine :

Lancez la finalisation de l’installation avec des options de base et malgré l’affichage d’alertes non bloquantes :

Attendez que la session RDP se ferme automatiquement :

Retournez sur le portail Azure pour ajouter dans la résolution DNS du réseau virtuel par l’adresse IP de votre nouveau serveur DC / DNS :

Réouvrez une session RDP avec le nouveau compte administrateur de domaine :

N’attendez pas la fin du chargement de session et retournez sur votre portail Azure :

Créez une autre machine virtuelle sous Windows 10 sur le même réseau virtuel que la machine de domaine :

Ouvrez une session RDP avec un compte utilisateur local et joignez cette machine au domaine Active Directory :

Redémarrez cette machine virtuelle :

Retournez sur la session RDP ouverte sur le serveur Active Directory et utilisez le lien suivant pour y installer Azure AD Connect :

Lancez l’exécutable MSI téléchargé et choisissez l’option ci-dessous :

Cochez la case SSO dans la configuration de votre Azure AD Connect :

Renseignez le compte Administrateur Global de votre tenant 365 :

Renseignez le compte Administrateur d’entreprise de votre domaine Active Directory :

Cliquez sur Suivant :

Cochez la case et cliquez sur Suivant :

Synchronisez l’ensemble du domaine Active Directory :

Cliquez sur Suivant :

Cliquez encore sur Suivant :

Cliquez toujours sur Suivant :

Renseignez les identifiants d’Administrateur d’entreprise et cliquez sur Suivant :

Lancez l’installation de la configuration :

Une fois la configuration terminée, quittez le configurateur :

L’affichage des appareils d’Azure AD ne montre pour l’instant aucune nouvelle machine provenant de ce test :

Quelques minutes plus tard, relancez la configuration d’Azure AD Connect :

Cliquez comme ceci pour activer la jointure hybride AD / Azure AD :

Après avoir renseigné les identifiants d’Administrateur global du tenant 365, activez la fonctionnalité de jointure hybride :

Cochez la case pour les prendre en compte machines en Windows 10 ou ultérieures :

Renseignez les identifiants d’Administrateur d’entreprise du domaine Active Directory :

Démarrez la mise à jour de la nouvelle configuration :

Une fois la reconfiguration terminée, fermez la fenêtre d’installation d’Azure AD Connect :

Lancez en PowerShell la commande suivante pour forcer une nouvelle synchronisation entre l’AD et Azure AD :

Start-ADSyncSyncCycle -PolicyType Delta

Rafraîchissez la page des appareils d’Azure AD pour constater une nouvelle apparition :

Ouvrez une session RDP avec un compte de domaine sur la machine Windows 10 et retournez quelques minutes plus tard sur la page des appareils d’Azure AD pour constater le changement :

Conclusion

Les tests sur Azure AD sont toujours une précieuse méthode pour comprendre tous les mécanismes d’Azure. Enfin voici une vidéo explicative reprenant différentes étapes de nos tests ????????

Conditionnez l’accès de votre AVD

Je souhaitais faire cet article depuis quelques temps déjà. Comme pour les autres services disponibles sur le Cloud Microsoft, Azure Virtual Desktop nécessite une sécurité renforcée. Hors de question de laisser un accès ouvert aux applications de l’entreprise avec un simple identifiant / mot de passe.

Dans cet article, nous allons commencer par reprendre quelques bases sur l’accès conditionnel disponible sur Azure AD. Puis nous allons le mettre en oeuvre dans un environnement Azure Virtual Desktop.

Qu’est-ce que l’Accès Conditionnel proposé par Azure AD ?

Tous les environnements informatiques sont quête d’une protection toujours plus efficace pour se prémunir des intrusions extérieures. L’ouverture des architectures IT au travers d’un hébergeur 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 à gérer pour la sécurité IT.

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

Pour cela, Microsoft propose d’intégrer dans le processus d’authentification à Azure AD de nouvelles étapes, sous forme de police :

*Le schéma ci-dessus est une vue simplifiée des 3 étapes du processus d’accès conditionnel.*

Signal : pour Azure AD, l’accès conditionnel repose sur un certain nombre de signaux ou paramètres. 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 Azure AD
Application interrogée
IA (Détection des risques en temps réel par Azure AD Identity Protection)

Décision : la décision sera alors le résultat dicté par la police d’accès conditionnel en correspondance avec les signaux. Il est question ici de bloquer l’accès à l’utilisateur, ou de l’autoriser selon les 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 à Azure AD
Exiger une stratégie de protection des applications

Application : apporte une supervision des sessions et des accès utilisateur aux applications en fonction des stratégies d’accès et de session, 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

Quelles sont les licences nécessaires pour l’accès conditionnel d’Azure AD ?

L’utilisation de l’accès conditionnel d’Azure AD est une composante des licences Azure AD Premium P1. Cela est donc bien différent des offres disponibles pour disposer de l’authentification multifacteur (Challenge MFA).

Vous retrouvez donc le service d’accès conditionnel dans un grand nombre de licences utilisateurs, dont les suivantes :

Azure AD Premium P1
Azure AD 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

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

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 capables de limiter les avantages à des utilisateurs spécifiques. Des efforts doivent être déployés pour limiter les avantages du service aux utilisateurs sous licence.
Doc Microsoft

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

*Voici un autre tenant Azure ne disposant d’aucune licence.*

Comment l’accès conditionnel est vécu par un utilisateur ?

Une fois l’accès conditionnel mis en place via une police, la sécurité est immédiatement renforcée par l’application de celle-ci. L’image ci-dessous montre en exemple une authentification multifacteur déployée par ce mécanisme pour protéger le portail Azure :

*L’accès au portail Azure est conditionné à une authentification multifacteur pour cet utilisateur* : challenge MFA.

L’absence de réponse entraîne alors un blocage dans le processus d’authentification et donc de l’accès au portail Azure pour l’utilisateur :

En alternative, si l’utilisateur ne peut pas utiliser cette méthode, Il lui est malgré tout possible de continuer le processus d’authentification par une autre mesure disponible dans la double authentification :

Les réussites ou les échecs des connexions d’utilisateurs sont directement visibles dans le journal des connexions de l’utilisateur sur Azure AD :

Un clic sur une authentification affiche alors les détails et l’application de la police utilisée :

Essai I : Absence de règle d’accès conditionnel

Le premier essai que nous allons faire repose sur aucune configuration particulière.

L’accès au service Azure Virtual Desktop se fait en HTML 5 via l’URL officielle. L’accès conditionnel marcherait également avec les applications installées sur le poste en local, comme le client Remote Desktop, disponible ici au téléchargement.

Aucun blocage ni contrainte pour l’utilisateur n’est constaté :

La sécurité y est donc minimale et l’obtention du login et du mot de passe par un tier permet de se connecter à son environnement et d’accéder aux données.

Essai II : Mise en place d’une règle de blocage total

Le second essai nécessite la création d’une police d’accès conditionnel. Connectez-vous au portail d’Azure et rendez-vous dans le service Azure AD avec un compte administrateur adéquat :

Ouvrez le menu de la Sécurité :

Rentrez dans la section d’Accès conditionnel :

Créez votre nouvelle Police :

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

Cherchez l’application Azure Virtual Desktop dans la section suivante :

Définissez la décision sur Bloquer l’accès :

Activez votre police et validez sa création :

Attendez quelques minutes et retester l’accès à Azure Virtual Desktop sur votre utilisateur. Pour information, l’accès conditionnel d’Azure AD dispose d’une fonction Et Si pour tester vos règles avant de les appliquer :

Quelques minutes plus tard, le test de connexion nous montre que blocage est bien effectif pour cet utilisateur :

*Les conditions d’authentification sont bien réunies, mais ici l’utilisateur n’a tout simplement par le droit de se connecter à AVD.*

Essai III : Mise en place d’une règle pour exiger la MFA

Retournez sur votre accès conditionnel et cliquez sur votre police pour la modifier :

Modifiez la décision pour autoriser l’accès à Azure Virtual Desktop, sous réserve d’un succès au challenge MFA par votre utilisateur de test :

Retentez la connexion à Azure Virtual Desktop avec votre utilisateur de test. La modification MFA de la police est bien prise en compte ici :

Dans mon cas, l’utilisateur est alors invité à enregistrer une ou des méthodes pour le challenge MFA pour poursuivre cette nouvelle opération d’authentification. L’application Microsoft Authenticator est proposée en tant que première méthode du challenge à configurer :

*Il est possible de choisir une autre méthode*.

La méthode MFA choisie est immédiatement vérifiée pour éviter un blocage ultérieur :

Essai IV : Mise en place d’une règle pour bloquer la connexion autre qu’au bureau

La restriction ou le blocage d’un service comme Azure Virtual Desktop est possible selon la localisation de l’utilisateur par son adresse IP. Retournez sur votre police pour la modifier comme ceci :

Pensez à créer votre location de confiance, en reprenant votre propre IP publique :

Retentez la connexion de votre utilisateur à AVD et constatez l’absence de blocage ou de challenge MFA :

Un contrôle dans le journal des connexions nous montre bien le processus d’exclusion de la police d’accès conditionnel grâce à mon adresse IP publique, exclue :

Essai V : Mise en place d’une règle pour exiger le challenge MFA toutes les heures

La mémorisation constante du challenge MFA sur une poste peut être considérée comme un risque sécuritaire, spécialement si le poste est en accès libre pour différents utilisateurs.

Retournez sur votre police pour la modifier comme ceci :

Effectuez l’authentification de votre utilisateur et réussissez le challenge MFA :

Validez la présence des icônes et attendez une heure. Une heure plus tard, rafraîchissez votre AVD :

Une MFA est bien redemandée après le délai défini dans la police d’accès conditionnel.

Conclusion :

Grâce à l’accès conditionnel d’Azure AD, il est assez facile de renforcer la sécurité d’Azure Virtual Desktop. Comme toujours, Microsoft rappelle les risques encourus à seulement utiliser un login et mot de passe pour seule sécurité. L’excellente vidéo de Dean nous montre cela en détail :

En espérant que cela a pu vous aider à mieux sécuriser votre environnement Cloud ????

Simplifiez l’authentification des utilisateurs d’AVD joint Azure AD avec Single Sign-on

Après ces quelques chaudes semaines d’été, il est pour nous l’occasion de nous replonger dans Azure Virtual Desktop et ses dernières nouveautés. Comme vous le savez peut-être, AVD repose sur une authentification d’Azure AD, potentiellement combinée avec un Active Directory classique. Cette méthode apporte une couche de sécurité dans l’accès au service grâce aux mesures de protections disponibles sur Azure AD.

Dans cet article, nous allons nous intéresser au Single Sign-on, ou Authentification Unique, dans Azure Virtual Desktop à travers une première méthode de gestion des identités Cloud : Azure AD. Enfin, nous finirons ce billet par un rapide troubleshooting concernant cette évolution, encore en préversion à l’heure où les lignes de cet article sont écrites.

Avant de commencer, voici un rappel de la définition du Single S ign-on par Wikipédia :

L’authentification unique, souvent désignée par le sigle anglais SSO est une méthode permettant à un utilisateur d’accéder à plusieurs applications informatiques (ou sites web sécurisés) en ne procédant qu’à une seule authentification.
Wikipédia

Rappel de l’existant

Afin de bien comprendre l’évolution du SSO dans Azure Virtual Desktop, l’authentification utilisateur s’effectue en deux étapes. Voici un rappel du processus depuis le client Windows Remote Desktop utilisé pour AVD, disponible ici :

Première authentification Azure AD (ou serveur AD FS si besoin) :

Seconde authentification pour l’ouverture de la session Windows :

La mémorisation du mot de passe de session Windows est bien disponible via la case à cocher ci-dessous, mais elle pose un souci de sécurité. Il ne s’agit pas ici de SSO mais d’un classique stockage de mot de passe en local. En effet, le mot de passe sera alors sauvegardé sur le Credential Manager de Windows :

*Sur un ordinateur partagé, cela rendrait simplement l’accès à Azure Virtual Desktop ouvert à tous !*

Microsoft travaille depuis déjà pas mal de temps sur du SSO pour Azure Virtual Desktop. L’excellente vidéo ci-dessous faite il y a quelques mois par Dean Cefola de l’Azure Academy nous montre son processus de mise en place, mais uniquement si l’infrastructure dispose d’un Active Directory avec un serveur AD FS :

Comment faire du SSO sans serveur AD FS ?

C’est dans ce cas précis que la nouveauté de Microsoft intervient ! Une nouvelle option RDP vient de se faire son apparition sur Azure Virtual Desktop. Cette option apporte le SSO de manière 100% native. Petit rappel toujours utile, voici la liste des propriétés RDP acceptées par AVD.

Comme pour presque tous les articles de ce blog, nous allons détailler le processus de mise en place de cette nouvelle fonctionnalité d’AVD :

Etape 0 : Rappel des prérequis

Cette fonctionnalité d’AVD est encore en préversion. Nous allons donc partir d’un environnement Azure vierge et y installer un environnement AVD joint à Azure AD. Voici la courte liste des composants déjà présents sur mon environnement de test :

Tenant Azure
Souscription Azure valide

Etape I : Création du réseau virtuel

Dans un environnement vide, il faut donc commencer par la création d’un réseau virtuel :

Dans mon exemple de test, je ne modifie pas l’adressage réseau :

Attendez que la création se termine pour continuer :

Etape II : Déploiement d’Azure Virtual Desktop

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

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

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

*Il n’est toujours pas possible de stocker les métadatas d’AVD sur un centre de données en Suisse.*

Le choix de l’image Windows utilisée pour Azure Virtual Desktop a son importance ! Actuellement, la fonctionnalité de préversion du SSO repose sur une modification de l’OS Windows, et n’est pour l’instant déployée que sur la version 22H2 de Windows 11 :

La suite des options concernant les machines virtuelles AVD ne changent pas :

Type de domaine à joindre : Choisissez Azure Active Directory
Intune : il est également possible d’automatiser l’enrôlement des machines virtuelles AVD dans Intune. Cela permet de configurer ces dernières, que ce soient des machines virtuelles dédiées ou partagées entre utilisateurs.

La création de l’espace de travail ne change pas :

Lancez la création et attendez plusieurs minutes :

Une fois le déploiement terminé, constatez la présence des ressources suivantes dans le groupe de ressources :

Etape III : Affectation des utilisateurs AVD

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

Il est aussi possible de passer par l’attribution d’un rôle RBAC pour cette même opération :

Etape IV : Ajout des rôles RBAC

Afin d’autoriser les utilisateurs à se connecter aux machines virtuelles AVD jointes à Azure AD, l’attribution d’un rôle RBAC spécifique est nécessaire. Affectez les deux rôles RBAC suivants sur le groupe de ressources :

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

Etape V : Implémentation de la fonctionnalité SSO

Retournez sur votre pool d’hôtes afin de profiter très facilement de cette nouvelle fonctionnalité :

La sauvegarde de cette option impacte les arguments RDP affichés dans l’onglet Avancé :

Un clic sur la session RDP vous affiche toujours la demande d’authentification de la session Windows :

Lancez un rafraîchissement pour mettre à jour les options RDP :

Retentez l’opération de connexion RDP pour voir cette nouvelle fenêtre apparaître :

Confirmez votre identité :

Acceptez la demande d’autorisation pour autoriser les connexion RDP :

*Il semble que cette demande soit valable pour une machine du pool uniquement.*

La session Windows 11 devrait alors s’ouvrir :

Retentez l’opération une seconde fois pour vérifier le bon fonctionnement du SSO ????

Conclusion

On peut dire que Microsoft a fait le maximum pour simplifier les choses concernant le déploiement de cette nouvelle fonctionnalité AVD ! D’autres articles suivront pour tester les autres cas de gestions des identités via Active Directory.

Encore merci à Dean pour cette annonce et sa vidéo sur le sujet.

Troubleshoot

Depuis l’apparition de cette nouvelle fonctionnalité, je me suis retrouvé embêté dans le déploiement d’environnements AVD joint à Azure AD et sous Windows 10/11 sans utiliser cette nouvelle option.

En effet, mes utilisateurs de test n’étaient plus en mesure de passer l’authentification de la session Windows :

La faute revient à l’impossibilité de remettre l’ancien argument RDP suivant dans ma configuration RDP, comme indiqué dans mon premier article sur le sujet.

targetisaadjoined:i:1

Voici le message d’erreur en question sur mon AVD depuis le portail Azure :

La solution

Pour contourner ce blocage, il est nécessaire de passer cet argument RDP targetisaadjoined:i:1 via une commande PowerShell :

$properties = "drivestoredirect:s:*;audiomode:i:0;videoplaybackmode:i:1;redirectclipboard:i:1;redirectprinters:i:1;devicestoredirect:s:*;redirectcomports:i:1;redirectsmartcards:i:1;usbdevicestoredirect:s:*;use multimon:i:1;targetisaadjoined:i:1"

Update-AzWvdHostPool -ResourceGroupName toto-rg -Name toto-hp -CustomRdpProperty $properties

Retournez sur votre client Remote Destop et lancez un rafraîchissement :

Et sa refonctionne !

En espérant que cela a pu vous aider ????

Fournisseur	Biométrie	USB	NFC	BLE	Certifié FIPS	Contact
AuthenTrend						https://authentrend.com/about-us/#pg-35-3
Ciright						https://www.cyberonecard.com/
Ensurity						https://www.ensurity.com/contact
Excelsecu						https://www.excelsecu.com/productdetail/esecufido2secu.html
Feitian						https://shop.ftsafe.us/pages/microsoft
Fortinet						https://www.fortinet.com/
Giesecke + Devrient (G+D)						https://www.gi-de.com/en/identities/enterprise-security/hardware-based-authentication
GoTrustID Inc.						https://www.gotrustid.com/idem-key
HID						https://www.hidglobal.com/contact-us
Hypersecu						https://www.hypersecu.com/hyperfido
IDmelon Technologies Inc.						https://www.idmelon.com/#idmelon
Kensington						https://www.kensington.com/solutions/product-category/why-biometrics/
KONA I						https://konai.com/business/security/fido
NeoWave						https://neowave.fr/en/products/fido-range/
Nymi						https://www.nymi.com/nymi-band
Octatco						https://octatco.com/
OneSpan Inc.						https://www.onespan.com/products/fido
Swissbit						https://www.swissbit.com/en/products/ishield-fido2/
Thales Group						https://cpl.thalesgroup.com/access-management/authenticators/fido-devices
Thetis						https://thetis.io/collections/fido2
Token2 Switzerland						https://www.token2.swiss/shop/product/token2-t2f2-alu-fido2-u2f-and-totp-security-key
Solutions TrustKey						https://www.trustkeysolutions.com/security-keys/
VinCSS						https://passwordless.vincss.net
Yubico						https://www.yubico.com/solutions/passwordless/