Les périphériques accédant à vos données se doivent d’être protégés. La mise en place d’outils de gestion, de contrôle et de conformité est déjà un premier pas vers plus de sécurité. Voici une liste non exhaustive d’outils Azure pour la sécurité de vos périphériques.
Périphérique joint / enregistré à Azure AD
Il est toujours utile de joindre les périphériques à Azure AD. Comme pour un Active Directory, la connaissance de ces derniers apporte une meilleure maitrise de la sécurité lors de la création de règles de sécurité.
Cette jointure ne rentre absolument pas en conflit pour les périphériques déjà présents dans un Active Directory. L’outil de synchronisation Azure AD Connect dispose d’une fonctionnalité permettant justement la jointure hybride pour ces périphériques.
Une fois le périphérique joint à Azure AD, il est possible de mettre en place des règles d’accès conditionnel qui tiennent compte de ce status :
Endpoint Management (Intune)
Qu’est-ce que Microsoft Intune ou Endpoint Management ?
Microsoft Intune est un service basé sur le cloud qui se concentre sur la gestion des périphériques mobiles (MDM) et la gestion des applications mobiles (MAM). Vous contrôlez la façon dont les appareils de votre organisation sont utilisés, y compris les téléphones mobiles, les tablettes et les ordinateurs portables. Vous pouvez également définir des stratégies spécifiques pour contrôler les applications. Par exemple, vous pouvez empêcher l’envoi d’e-mails à des personnes extérieures à votre organisation.
Le schéma ci-dessous montre le large potentiel d’Intune sur le contrôle des périphériques, en situation de mobilité ou non.
L’étendue de ces contrôles est variable en fonction du périphérique lui-même :
Périphérique d’entreprise : contrôle total sur l’appareil, notamment les paramètres, les fonctionnalités et la sécurité. Par exemple, vous pouvez définir les critères de mot de passe et de code confidentiel, créer une connexion VPN, configurer la protection contre les menaces, …
Périphérique personnel : appelé aussi byOD (Bring-your-own Device), Le contrôle n’est pas total. Par exemple, les utilisateurs inscrivent leurs appareils uniquement s’ils veulent un accès aux ressources de votre organisation. Vous pouvez également utiliser les stratégies de protection des applications qui requièrent l’authentification multifacteur (MFA) pour utiliser ces derniers. Par exemple, si les utilisateurs souhaitent accéder à la messagerie ou Microsoft Teams.
Microsoft Intune est déjà inclus dans un grand nombre de licence Microsoft 365 (voir liste ci-dessous), mais est également disponible en licence seule pour un utilisateur ou un périphérique :
Microsoft 365 E5
Microsoft 365 E3
Enterprise Mobility + Security E5
Enterprise Mobility + Security E3
Microsoft 365 Business Premium
Microsoft 365 F1
Microsoft 365 F3
Microsoft 365 Gouvernement G5
Microsoft 365 Gouvernement G3
Intune for Education
Microsoft 365 Education A5
Microsoft 365 Education A3
Rien de mieux qu’une vidéo pour faire un tour d’horizon de l’outil :
Defender for Endpoint (Microsoft 365 Defender)
Qu’est-ce que Defender for Endpoint ?
Microsoft Defender for Endpoint est une plate-forme de sécurité conçue pour aider les réseaux d’entreprise à prévenir, détecter, examiner et répondre aux menaces avancées.
Pour faire simple, l’intégration de périphériques dans le portail de sécurité Microsoft Security apporte à votre équipe une vision complète des alertes et des incidents de sécurité sur tout le parc IT. Cela est une bonne approche pour gagner du temps et comprendre et déjouer les attaques chaînées :
Côté licence, Defender for Endpoint est maintenant disponible sous deux plans :
Microsoft organise assez régulièrement un évènement appelé Microsoft Build. Comme l’indique sa page Wikipédia, c’est une conférence annuelle destinée aux ingénieurs logiciels et aux développeurs Web utilisant Windows, Azure et d’autres technologies Microsoft.
Sa première organisation date de 2011, en remplacement d’autres évènements eux aussi dédiés aux développeurs, comme la Conférence des développeurs professionnels et le MIX. Cette année encore, il fut organisé en virtuel.
Qu’est-ce que le Microsoft Build Cloud Skills Challenge ?
Comme pour le Microsoft Ignite, organisé pour la dernière fois en novembre dernier, Microsoft propose de rendre ses évènements plus interactifs avec la participation de l’audience.
Pour cela, Microsoft vous propose de participer à un exercice technique, appelé challenge. La réalisation d’un seul challenge vous apporte une meilleure compréhension du message de Microsoft et vous donne la possibilité de repartir avec un gain immédiat : un bon d’examen pour une certification Microsoft.
Attention :
Ce challenge est limité dans le temps, vous devez le terminer au plus tard le 21 juin prochain
La réalisation de plusieurs challenges ne vous apportera pas plusieurs bons d’examen Microsoft
Quelques informations supplémentaires sont disponibles dans la FAQ officielle
La réalisation d’un des 3 challenges techniques, vous offre un bon d’examen pour tester et valider vos connaissances Microsoft. Cette année, 3 challenges vous sont accessibles :
Pour quelles certifications pourrons-nous utiliser notre bon d’examen ?
Vous retrouvez ci-dessous les certifications Microsoft accessibles gratuitement grâce à l’utilisation de votre bon d’examen Microsoft Build :
Il arrive qu’une machine virtuelle ne corresponde plus aux besoins initialement définis avec sa taille. Pas de panique ! Un changement est toujours possible après coup. L’un des grands avantages d’Azure est la possibilité de modifier la taille des machines virtuelles, à la volée, des besoins en termes de performances du processeur, du réseau ou de disques.
Dans cet article, nous allons démontrer ensemble la simplicité de changer la taille d’une machine virtuelle, mais également les étapes additionnelles pour un changement particulier.
Dans quel cas redimensionner ?
Lorsque l’on examine le redimensionnement de machines virtuelles sous Azure, trois axes définissent ce processus de changement de taille :
Localisation : votre région Azure ne contient pas le matériel nécessaire pour prendre en charge la taille de machine virtuelle souhaitée.
Interruption : vous devrez dans certains cas désallouer la machine virtuelle. Cela peut se produire si la nouvelle taille n’est pas disponible sur le cluster matériel qui l’héberge actuellement.
Restriction : Si votre machine virtuelle utilise le stockage Premium, assurez-vous que vous choisissez une version s de la taille pour obtenir le support du stockage Premium.
Tailles des machines virtuelles dans Azure
Avant de basculer sur le portail Azure pour effectuer les étapes de modification de taille, voici un rappel de l’offre des machines virtuelles Azure. Afin d’y voir plus clair, Microsoft a segmenté son offre de machines virtuelles par famille, correspondant à des scénarios de besoin utilisateur :
En exemple, voici la définition donnée par Microsoft pour des besoins GPU :
Les tailles de machine virtuelle au GPU optimisé sont des machines virtuelles spécialisées disponibles avec des GPU uniques, multiples ou fractionnaires. Ces tailles sont conçues pour des charges de travail de visualisation, mais également de calcul et d’affichage graphique intensifs.
Les familles sont généralement couvertes par plusieurs séries. Une série est une combinaison CPU + RAM + Autre critères. Les séries sont régulièrement mis à jour par Microsoft via des versions. Voici en exemple le détail de la composition pour la série NCv3 :
Les machines virtuelles de série NCv3 sont optimisées par les GPU NVIDIA Tesla V100. Ces GPU peuvent fournir des performances de calcul une fois et demie supérieure à celles de la série NCv2… les machines virtuelles de la série NCv3 sont également pilotées par des processeurs Intel Xeon E5-2690 v4 (Broadwell).
Enfin, chaque série dispose plusieurs SKUs pour proposer différentes puissances. Toujours en exemple, la série graphique NCv3 :
La taille de la machine virtuelle influe également sur le prix de celle-ci. Toujours en exemple, la série graphique NCv3 :
Codification Azure
Cette large découpe propose aux utilisateurs un très grand nombre de machines virtuelles possibles. Dans cette jungle de SKUs, Microsoft a mis en place une codification précise dans la dénomination.
Une ou plusieurs lettres minuscules indiquent des fonctionnalités supplémentaires, telles que : a = processeur basé sur AMD b = bloquer les performances de stockage d = diskfull (c.-à-d., un disque temporaire local présent) ; ceci concerne les nouvelles machines virtuelles Azure, consultez Séries Ddv4 et Ddsv4 i = taille isolée l = mémoire insuffisante ; une quantité de mémoire inférieure à la taille d’utilisation intensive de la mémoire m = utilisation intensive de la mémoire ; la plus grande quantité de mémoire dans une taille particulière t = très petite mémoire ; la plus petite quantité de mémoire dans une taille particulière s = capacité de stockage Premium, y compris l’utilisation possible de SSD Ultra (Remarque : certaines tailles plus récentes sans l’attribut de s peuvent toujours prendre en charge le stockage Premium, par exemple M128, M64, etc.)
*Type d’accélérateur
Indique le type d’accélérateur matériel dans les références (SKU) spécialisées/GPU. Seules les nouvelles références (SKU) spécialisées/GPU lancées à partir du troisième trimestre 2020 auront l’accélérateur matériel dans leur nom.
Version
Indique la version de la série de machines virtuelles
Voici un exemple de dénomination pour la machine virtuelle graphique NC4as_T4_v3 :
Valeur
Explication
Famille
N
Sous-famille
C
Nombre de processeurs virtuels
4
Fonctionnalités supplémentaires
a = processeur basé sur AMD s = capacité de stockage Premium
Type d’accélérateur
T4
Version
v3
Avec toutes ces informations, nous allons pouvoir nous intéresser au changement de SKU sur une machine virtuelle existante.
Etape 0 : Rappel des prérequis
Pour cela, nous allons créer différentes ressources sur Azure pour y parvenir. Comme toujours, des prérequis sont nécessaires pour réaliser cette démonstration :
Un tenant Microsoft
Une souscription Azure valide
Une machine virtuelle déployée et démarrée
Comme le montre la copie d’écran ci-dessous, ma machine virtuelle dispose actuellement de la taille D4ds v4
Afin de mesurer les impacts d’un changement de taille sur une machine virtuelle démarrée, j’ai également ouvert une connexion RDP à celle-ci
Test I : Changement d’une taille dans la même série
Le changement de taille de la machine virtuelle s’effectue depuis le portail Azure via la section Taille.
Azure y regroupe différentes tailles, accessibles ou non :
Jouez avec les filtres suivants pour trouver la taille adaptée
Sélectionnez la taille et cliquez sur redimensionner
Une fois déclenché, une notification de traitement apparait dans votre portail Azure
La session RDP est-elle aussi coupée
Après traitement (30 secondes environ), la machine virtuelle retrouve son status démarré. La nouvelle taille se retrouve alors sur la page principale de la machine virtuelle Azure
La réouverture manuelle de la session RDP montre bien la nouvelle puissance
Test II : Changement d’une taille dans une série disponible
Continuez vos tests en effectuant un changement de taille vers une autre famille de machine virtuelle
Là encore, la session RDP se ferme et la notification de changement apparaît sur le portail Azure. Moins d’une minute plus tard, la machine virtuelle repart avec sa dernière taille
Test III : Changement d’une taille dans une série disponible
Dans certains cas, il est nécessaire de partir sur une taille de machine virtuelle ayant des propriétés différentes. Ma machine virtuelle, actuellement en Standard F8s v2, dispose d’un stockage temporaire.
Le disque temporaire est très utile pour les données qui, vous l’aurez deviné, sont de nature temporaire. Un excellent exemple de ce type de données pour Windows est le pagefile. Lorsqu’une nouvelle machine virtuelle Windows est provisionnée à partir d’une image dans Azure, le pagefile est configuré si cela est possible pour qu’il soit situé sur ce disque temporaire.
Ce stockage temporaire se retrouve alors sur le disque D
Les clients ne doivent pas utiliser le disque temporaire pour des données qui doivent être persistantes.
Un retour dans la liste des tailles disponibles pour ma machine virtuelle vm001 ne permet pas de choisir une machine virtuelle dépourvue de disque temporaire.
Dans ce cas, pas le choix, la recréation d’une nouvelle machine virtuelle est un passage obligatoire.
Etape I : Créer une sauvegarde du ou des disques présents
Allez sur la page des disques de la machine virtuelle et cliquez sur chacun d’eux
Créez une sauvegarde de chaque disque (OS et Data)
Vérifiez les champs et lancez la création
Une fois terminé, cliquez ici pour accéder au snapshot
Etape II : Créez un ou des disques depuis la ou les sauvegardes
Lancez la création du ou des nouveaux disques depuis le ou les snapshots créés
Une fois terminé, cliquez ici pour accéder au disque créé
Etape III : Création de la nouvelle machine virtuelle
Il ne reste plus qu’à rattacher ce ou ces disques à une nouvelle machine virtuelle
Renseignez tous les champs nécessaires et la nouvelle taille de machine désirée
Lancez la création de la machine virtuelle
Cliquez ici pour retrouver les propriétés de votre nouvelle machine virtuelle
Constatez la bonne taille de votre machine virtuelle Standard D4s v4
Rouvrez une session RDP sur cette nouvelle machine virtuelle pour finaliser les réglages de pagefile. Un message d’avertissement apparaît à l’ouverture de la session
Sélectionnez les paramétrages automatiques Windows
Redémarrez la machine virtuelle pour appliquer les modifications pagefile
Et vous voilà avec la nouvelle taille ????
Conclusion
Azure apporte beaucoup de flexibilité avec le changement de taille pour les machines virtuelles. Il est même possible de scripter le changement de taille selon les besoins ou les pics de charges.
Comme toujours John nous propose une vidéo pour aller plus loin sur ce sujet ????
Sauvegarder ou ne pas sauvegarder ? Telle est la question ! Évidemment, la sauvegarde n’est pas un choix mais bien une nécessité ! Dans cet article, nous allons prendre le temps de nous intéresser aux sauvegardes de machines virtuelles dans un cas très particulier.
Cet article n’a pas pour but de vous parler de la sauvegarde native des machines virtuelles sous Azure, via le service Azure Recovery Service Vault. Cette fonctionnalité est à la portée de tous et fonctionne sans souci.
Mais il arrive dans certains cas que ce service ne fonctionne pas pour certaines machines virtuelles… Voici par exemple le déploiement d’un firewall Fortigate, disponible sur la marketplace d’Azure
Une fois cette machine virtuelle déployée, j’ai rajouté des disques de données supplémentaires à cette dernière
J’ai ensuite créé un Recovery Service Vault pour mettre en place une sauvegarde habituelle
J’ai continué avec la configuration de la police de sauvegarde avec ma machine virtuelle
Seulement l’activation de la sauvegarde Azure me pose quelques soucis
Voici le détail du message d’erreur
{
"status": "Failed",
"error": {
"code": "UserErrorUnSupportedDistribution",
"message": "Unsupported OS version for virtual machine backup."
}
}
Ce problème est visiblement connu sur la toile depuis plusieurs années, mais pour l’instant aucune alternative n’a été proposée par Microsoft. Inutile de penser aux agents MARS ou MABS…
Que faire dans ce cas ?
Il est bien possible de faire des snapshots réguliers … à la main !
En quête d’automatisation, je suis tombé sur plusieurs articles intéressants, assez proche sur la solution apportée :
Azure Automation est un service d’automatisation et de configuration basé sur le cloud qui prend en charge la gestion cohérente de vos environnements Azure et non-Azure. Il comprend l’automatisation des processus, la gestion des configurations, la gestion des mises à jour, les capacités partagées et les fonctionnalités hétérogènes. L’automatisation vous donne un contrôle total pendant le déploiement, l’exploitation et la mise hors service des charges de travail et des ressources.
Dans notre déploiement, nous allons utiliser un compte Azure Automation pour stocker et lancer notre script PowerShell. Ce script prend en compte les disques rattachés à la machine virtuelle afin d’en faire des snapshots pour chacun d’eux.
Etape 0 : Rappel des prérequis
Passé cette rapide explication, nous allons créer différentes ressources sur Azure pour y parvenir. Comme toujours, des prérequis sont nécessaires pour réaliser cette démonstration :
Un tenant Microsoft
Une souscription Azure valide
Une machine virtuelle déployée
Etape I : Affectation d’un tag sur la machine virtuelle
Le script va effectuer une recherche sur les machines virtuelles à sauvegarder. Il est nécessaire de marquer celles qui nous intéresse. Rendez-vous sur la machine virtuelle concernée et ajoutez-y le tag suivant :
Nom : Snapshot
Valeur : True
Etape II : Création du compte Azure Automation
Tout commence par la création d’un compte Azure Automation pour héberger notre script PowerShell. Utilisez la barre de recherche du portail Azure pour commencer éa création
Renseignez les éléments de base sur le premier onglet du compte puis lancez directement la création de celui-ci :
Cherchez la section Paramétrages du compte,puis cliquez sur Identité et enfin assignez les rôles Azure
Ajoutez le rôle de Contributeur sur le groupe de ressources contenant la machine virtuelle, puis sauvegardez
Quelques minutes plus tard, constatez la présence de ce dernier dans le tableau précédent
Etape III : Création du Runbook
Continuez avec la création de votre runbook
Renseignez les champs pour valider sa création
La création vous ouvre ensuite l’éditeur de code
Collez le script suivant dans l’éditeur, ou également disponible sur mon GitHub
Cliquez sur le bouton ci-dessous pour démarrer le test
Attendez un peu
Constatez le succès ou l’échec de votre runbook
Retournez sur le groupe de ressources pour y voir apparaître les snapshots des disques
Cliquez sur l’un d’eux et constatez les tags
Etape V : Mise en place de l’automatisation
Une fois constaté le succès de votre script, il ne vous reste qu’à le publier et à le programmer périodiquement. Retournez sur votre runbook et cliquez sur Publier
Ajoutez une programmation périodique sur votre runbook
Cliquez sur le premier lien
Cliquez sur ajouter une programmation
Renseignez les champs selon votre besoin
Confirmez la bonne création de votre programmation
Contrôlez au prochain lancement de la programmation dans le groupe de ressources
Contrôlez également l’historique des lancements du runbook
Conclusion
Et voilà ! Une tâche manuelle de moins… Cette petite opération nous a permis de bien comprendre l’utilité et la puissance des automatismes possibles sur Azure. Celui-ci est bien évidemment très simple, d’autres sont sans doute très intéressants à mettre en oeuvre ????.
Déjà disponible en preview depuis quelques temps, Azure AD Connect apporte la synchronisation vers plusieurs tenants Azure AD en disponibilité générale (GA). Cette nouvelle fonctionnalité permet la réplication d’utilisateurs et de groupes présents dans un Active Directory vers plusieurs environnements Microsoft Cloud.
Pour arriver à cette situation, il faudra alors installer plusieurs agents Azure AD Connect sur différents serveurs (un par tenant à associer). Avant de rentrer ensemble dans la technique, voici un rappel de ce qu’Azure AD Connect apporte :
Quels sont les moyens actuels pour structurer un tenant Azure AD ?
Un tenant correspond le plus souvent une organisation souhaitant posséder et gérer environnement spécifique de services Microsoft Cloud (Azure / Office365).
Comme le recommande Microsoft, envisager l’utilisation de plusieurs tenants Azure AD ne doit pas être la norme. L’utilisation d’un seul tenant apporte les bénéfices suivants :
Identité Cloud unique (un seul UPN pour se connecter)
Simplification dans la gestion des services et des licences
Simplification du management IT et de la sécurité
Bien qu’Azure AD soit construit en structure plate, il existe aussi les unités administratives. Ces dernières peuvent couvrir plusieurs besoins, dans lesquels un seul tenant suffira :
La gestion des identités dans le cas B2C ne nécessite pas non plus la création d’un nouveau tenant B2B :
Que reste-t-il donc pour justifier la création d’autres tenants Azure AD ?
Création d’un environnement de test ou pour du développement applicatif
Séparation de branches d’une même entreprise
Exigences particulières de sécurité
Besoin de disposer de plusieurs variantes d’Azure (Azure Gov, Azure China, Azure Germany)
Quels seront les inconvénients à multiplier les tenants Azure AD ?
Il ne faut pas oublier que l’utilisation de plusieurs identités Cloud va compliquer le quotidien, comme par exemple :
Risque ou obligation de doublons de licence (erreur ou contrainte)
Complexification pour les utilisateurs finaux
Installation alourdie (une seule instance d’Azure AD Connect par serveur. Prévoir autant de serveur que de tenants à synchroniser. Prévoir également l’installations d’Azure AD Connect sur des serveurs de secours (redondance).
Synchronisation limitée : certains objets comme les périphériques ou les groupes des tenants ne seront pas remontés dans Active Directory
Gestion des mots de passe : synchronisation des hashs des mots de possible entre Active Directory et les tenants Azure AD sous certaines conditions
Test d’un changement de mot de passe pour un utilisateur synchronisé sur plusieurs tenants Azure AD
Microsoft signale justement une fonctionnalité intéressante concernant la gestion des mots de passe pour les utilisateurs synchronisés dans plusieurs tenants :
Il est possible de configurer la synchronisation du hachage de mot de passe depuis Active Directory avec plusieurs locataires Azure AD pour le même objet utilisateur. Si la synchronisation du hachage de mot de passe est activée pour un locataire, la réécriture du mot de passe peut également être activée, ce qui peut être fait sur plusieurs locataires : si le mot de passe est modifié sur un locataire, la réécriture du mot de passe est mise à jour dans Active Directory, et la synchronisation du hachage de mot de passe met à jour le mot de passe dans les autres locataires.
Dans cet article, nous allons donc tester ensemble les différentes étapes pour mettre cette fonctionnalité en place.
Etape 0 : Rappel des prérequis
Comme toujours, des prérequis sont nécessaires pour réaliser cette démonstration d’Azure AD Connect :
Un premier tenant, Tenant A, synchronisé avec l’Active Directory
Un premier serveur, Serveur A, gérant un domaine Active Directory et avec l’agent Azure AD Connect d’installé
Un second tenant, Tenant B, non synchronisé à l’Active Directory
Un second serveur, Serveur B, joint au même domaine Active Directory
Serveur A : mon agent Azure AD Connect installé sur mon premier serveur synchronise déjà mes utilisateurs vers le tenant A
Tenant A : Filtrez vos utilisateurs pour ne voir que ceux provenant de la synchronisation de l’AD
Tenant B : Effectuez la même opération de filtrage pour constater l’absence d’utilisateurs synchronisés
Tenant B : un contrôle sur les propriétés Azure AD Connect du tenant B affiche un paramétrage encore vierge
Etape I : Installation d’Azure AD Connect sur le second serveur
Serveur B : connectez-vous en RDP sur ce second serveur pour y installer la dernière version d’Azure AD Connect, disponible sur cette page Microsoft
Laissez-vous guider par l’installeur
Etape II : Configuration d’Azure AD Connect sur le second serveur
Serveur B : acceptez les termes, puis cliquez sur Continuer
Cliquez sur Installer
Choisissez la synchronisation des hash des mots de passe, puis cliquez sur Suivant
Renseignez le compte Azure AD d’un administrateur global ou d’un administrateur de gestion des identités hybrides, puis cliquez sur Suivant
Ajoutez votre Active Directory grâce à l’utilisation d’un compte administrateur d’entreprise, puis cliquez sur Suivant
Cochez la case de confirmation de contrôle des UPN, puis cliquez sur Suivant
Définissez les OUs à synchroniser vers le tenant B, puis cliquez sur Suivant
Cliquez sur Suivant
Cliquez sur Suivant
Cochez la case concernant les mots de passe, puis cliquez sur Suivant
Cliquez sur Installer
Une fois la configuration terminée avec succès, fermez le configurateur Azure AD
Etape III : Vérifications de la synchronisation d’Azure AD Connect sur le second tenant
Serveur B : ouvrez Synchronisation Service Manager, disponible depuis le menu Démarrer
Vérifiez la bonne présence et le succès des 6 lignes de synchronisation
Cliquez sur la ligne d’exportation vers le tenant B pour y constater l’ajout d’utilisateurs
Tenant B : Retournez sur le portail Azure et rafraîchissez la liste des utilisateurs filtrés sur le tenant B
Etape IV : Test de l’authentification utilisateur sur le second tenant
Tenant B : testez l’authentification d’un utilisateur synchronisé depuis un navigateur privé avec son mot de passe AD
La connexion fonctionne bien et vous affiche la page d’accueil d’Office 365 :
Etape V : Premier test de changement de mot de passe sur le tenant B
Tenant B : essayez de changer mot de passe depuis le tenant B via le bouton de paramétrage en haut à droite
La réponse de Microsoft sur le tenant B est assez claire : il ne semble pas possible de modifier le mot de passe sur le tenant B, qui n’est pas le tenant « principal »
Fermez le navigateur privé
Etape VI : Second test de changement de mot de passe sur le tenant A
Tenant A : essayez à nouveau de changer mot de passe depuis le tenant A via la même procédure de navigateur privé
Aucun blocage pour ce second essai sur le tenant A, définissez-y alors un nouveau mot de passe sur cet utilisateur
Une fois modifié, fermez le navigateur privé
Optionnel : Si cela est possible, ouvrez une session RDP sur une machine du domaine AD avec le compte utilisateur modifié
Si la session Windows de l’utilisateur s’ouvre bien, le nouveau mot de passe a bien été pris en compte sur l’AD
Tenant B : ouvrez à nouveau un navigateur privé pour retenter l’opération d’authentification du même utilisateur avec le nouveau mot de passe sur le tenant B
Attendez quelques minutes et retentez l’opération avec le nouveau mot de passe sur le tenant B
Si la page d’accueil d’Office 365 s’ouvre bien, le mot de passe est été pris en compte sur l’Azure AD du tenant B
Conclusion
Comme nous le supposions, la gestion d’identités d’un Active Directory vers plusieurs tenants Azure AD est possible. Notre démonstration nous a aussi permis de tester la réplication des hashs des mots de passe sur plusieurs tenants sous certaines conditions.
Pour continuer sur la gestion de plusieurs tenants Azure, je trouvais intéressant de vous parler d’Azure AD Cross-Tenant Access
Beaucoup d’entre-nous sommes régulièrement confrontés à l’univers des licences du Cloud Microsoft dans le cadre de projets IT. Bien souvent, l’adjectif de jungle revient quand on aborde ce point.
Microsoft ne nous facilite pas la tâche non plus par les évolutions constantes de leurs programmes (ex. CSP / NCE), de leurs familles de produits, de leur nom, de leurs services mais aussi de leur prix !
Cela paraît surestimé mais il s’agit ici d’un vrai travail de recherche et de maintien à jour des connaissances, en permanence. Cet effort n’est pas uniquement valable pour Microsoft, mais il touche bien l’ensemble des éditeurs de solutions professionnelles.
Pour m’en sortir, j’utilise toutes les semaines un site, et pourtant je n’y avais pas encore fait le moindre article dessus …
Un grand merci à Aaron Dinnage pour son précieux travail sur le monde des licences du Cloud Microsoft. L’adresse de son site est donc https://m365maps.com/
De prime abord assez austère, on remarque très vite que son site est organisé par familles de licence et cela rend la recherche rapide et ciblée. La grande idée de son site repose sur sa facilité de comparaison entre les plans de licence d’un même produit.
Fonction I : Affichage des services disponibles sur une licence Microsoft
Prenons en premier exemple la licence Microsoft 365 Business Basic. Voici la page officielle de Microsoft concernant cette licence :
A ce stade, je ne pense pas qu’un commentaire soit nécessaire quant à la différence d’informations apprises. Pour aller plus loin, chaque icône représentant un service dispose d’un lien web vers la documentation Microsoft.
Notre second exemple est la licence Microsoft 365 Business Premium. Cette dernière est très intéressante pour beaucoup de projets. Microsoft y combine un grand nombre de services pour Office 365, la sécurité ou encore des fonctionnalités additionnelles pour le poste Windows.
Un second besoin lui aussi régulier porte sur la comparaison des plans de licence entre eux. Prenons l’exemple des plans de licence disponibles pour Azure Active Directory.
Notre second exemple porte sur les différents plans de licence disponibles pour Microsoft 365 Business : Basic / Standard / Premium.
Dans ce second exemple, Microsoft propose aussi des tableaux intéressants, mais pouvant manquer de synthèse entre les plans et pouvant influer sur la décision d’achat :
Il devient alors beaucoup plus évident de comprendre rapidement les différences entre les plans.
Fonction III : Mise à disposition d’une matrice
Dans d’autres cas, l’utilisation d’une matrice est pratique pour comparer plusieurs familles de produits. Voici en exemple de ce qui est disponible pour la famille Microsoft 365 :
Le but ici n’est pas de comparer celui qui en affichera le plus, mais bien de disposer d’une information fiable, mise régulièrement à jour et disponible facilement.
Conclusion
En quelques mots, un très bel outil qui me simplifie la vie ???? Quoi de mieux dans la vie que cela pour rester zen au travail ?
Azure Virtual Desktop utilise le protocole RDP (Remote Desktop Protocol) pour établir la connexion avec l’utilisateur. Pour rappel, ce protocole permet de se connecter à des ordinateurs de manière distante. Dans la plupart des cas, cette connexion utilise le protocole TCP pour y parvenir. Le serveur écoute par défaut sur le port TCP 3389.
Il est néanmoins possible de varier cette approche de connexion pour des questions de perfomences et de fiabilité. Depuis déjà l’année dernière, Microsoft proposait la fonctionnalité RDP Shortpath pour améliorer cette connexion, débit et latence, entre l’utilisateur et la machine virtuelle AVD :
RDP Shortpath est une fonctionnalité d’Azure Virtual Desktop qui établit un transport direct basé sur UDP entre le client Remote Desktop et l’hôte de session. RDP utilise ce transport pour fournir le Bureau à distance et le RemoteApp tout en offrant une meilleure fiabilité et une latence constante.
Microsoft Doc
Dans cet article, nous allons regarder en détail cette évolution et effectuer un test sur un environnement AVD. Avant de commencer à manipuler Azure, cette vidéo vous explique très bien l’idée :
Voici également un schéma montrant la « simplicité évidente » à utiliser cette fonctionnalité réseau :
L’article de Microsoft expliquait déjà alors la configuration à effectuer sur les machines virtuelles dans le cadre d’un réseau non public.
L’excellent billet de Denis Gundarev nous explique avec simplicité l’inadéquation entre le protocole TCP pour un besoin RDP :
TCP est un excellent protocole pour la livraison garantie de petites quantités de données. Les applications telles que les navigateurs ou les clients de messagerie se contentent d’envoyer les données et de les oublier. Le protocole assure la cohérence et l’ordre des paquets et relance la transmission si la livraison échoue. Cependant, RDP utilise des connexions de longue durée et les connexions TCP de longue durée sont problématiques.
Le protocole TCP est idéal pour les réseaux locaux, mais pas pour l’Internet. Oui, si le paquet est perdu, il sera retransmis. La disponibilité de la bande passante est un facteur essentiel. Malheureusement, les algorithmes de contrôle de congestion TCP limitent la possibilité de saturer le réseau.
RDH Shortpath s’applique donc sur les réseau publics
Comme son grand frère, cette fonctionnalité établit un flux UDP direct pour RDP. Toutefois, elle ne nécessite pas l’ouverture de ports entrants sur le pare-feu. Au lieu de cela, elle sélectionne automatiquement les conditions du réseau. Elle utilise une combinaison de protocoles de traversée NAT tels que STUN et UPnP et le processus d’établissement de la connectivité interactive (ICE). RDP établit alors le flux UDP direct dans la plupart des configurations de réseau.
Par conséquent, vos utilisateurs bénéficieront d’une latence plus faible, d’une meilleure utilisation du réseau et d’une grande tolérance à la perte de paquets ou aux changements de configuration du réseau.
Et la sécurité ?
RDP Shortpath pour les réseaux publics étend les capacités de multi-transport de RDP. Il ne remplace pas le transport de connexion inverse mais le complète. Le courtage de la session initiale est toujours géré par l’infrastructure Azure Virtual Desktop.
Comment constater le bénéfice ?
Denis nous a même préparé une vidéo pour montrer le bénéfice possible dans la gestion des paquets perdus entre les différents protocoles possibles :
Mise en oeuvre de la solution
Dans un environnement Azure Virtual Desktop, chaque connexion RDP commence par l’établissement du transport de connexion inverse sur la passerelle Azure Virtual Desktop. Après l’authentification de l’utilisateur, le client et l’hôte de session établissent le transport RDP initial, et le client et l’hôte de session commencent à échanger leurs capacités.
Important : comme le rappel la documentation Microsoft, RDP Shortpath configurés sur des réseaux managés est actuellement incompatible avec la prévision de RDP Shortpath pour les réseaux publics.
Comme à chaque article d’Azure Virtual Desktop, vous pouvez suivre les différentes étapes pour mettre en route cette fonctionnalité, toujours en preview à l’heure où ces lignes sont écrites.
Etape 0 : Rappel des prérequis
Des prérequis sont nécessaires pour réaliser cette démonstration AVD :
Un tenant Microsoft
Une souscription Azure valide
Un réseau virtuel existant sur Azure
Un domaine Active Directory synchronisé avec Azure AD via l’agent Azure AD Connect
Une ou des machines virtuelles AVD déployées sur ce même réseau virtuel
Mon environnement Azure Virtual Desktop est donc déjà en place :
Etape I : Test avant modification du RDP Shortpath
Avant d’effectuer les modifications, connectez-vous à votre environnement AVD avec un utilisateur pour constater la connexion RDP via le protocole TCP :
Saisissez vos identifiants pour ouvrir votre session RDP :
Contrôlez la méthode de connexion TCP, mise en place par défaut :
Afin de mettre en place la configuration nécessaire sur les machines virtuelles AVD, il est possible d’y parvenir de plusieurs manières. En voici deux :
Etape IIa : Modifiez la configuration de registre d’une machine virtuelle AVDmanuellement
Fermez la session utilisateur et retournez sur une machine virtuelle via votre portail Azure. Exécutez la commande suivante comme ceci
Attendez quelques minutes et constatez le succès de celle-ci sur le portail Azure
Etape IIb : Modifiez la configuration de registre d’une machine virtuelle AVD via GPO
Au lieu de faire cette modification manuelle sur toutes vos machines virtuelles, vous pouvez également créer une GPO dans votre domaine AD et l’appliquer aux machines AVD.
Connectez à une machine de votre domaine AD pour y créer votre nouvelle GPO
Commencez la création de cette nouvelle GPO sur l’OU correspondante à vos machines AVD
Nommez votre GPO à votre convenance
Editez-là avec un clic droit
Créez y un nouvel objet de registre comme ceci
Descendez dans l’arborescence suivante et sélectionnez là :
Ajoutez-lui les propriétés suivantes et cliquez sur OK
Redémarrez les machines virtuelles AVD pour une bonne prise en compte de cette nouvelle GPO
Etape III : Test après modification du RDP Shortpath
Comme au premier essai, reconnectez-vous à votre environnement AVD avec un utilisateur de test, puis constatez le changement de protocole UDP :
Evidemment, Microsoft prévoit aussi des ajouts de règles firewall pour les machines virtuelles AVD et pour les machines clients. Ces opérations sont nécessaires si le protocole UDP est à l’origine bloqué.
Conclusion
Cette nouvelle fonctionnalité est donc une façon facile d’améliorer l’expérience de vos utilisateurs sans mettre en défaut la sécurité à travers des réseaux publics.
Pour finir et vous aider dans cette démarche, Dean nous a même préparé un seconde vidéo sur la chaine YouTube et dédiée à cette évolution du RDP Shortpath, encore en préversion !
De temps à autre, je suis sollicité pour valider différentes combinaisons possibles entre des composants du Cloud Microsoft. Je trouvais donc intéressant de partager avec vous l’une d’entre elles.
Dans cet article, nous allons donc déployer une connexion VPN Point à Site sur un réseau Azure, et sécurisée par une authentification multifacteur (MFA).
Etape 0 : Rappel des prérequis
Comme pour beaucoup de mes articles Azure, des prérequis sont nécessaires pour réaliser cette démontration :
Un tenant Microsoft
Une souscription Azure valide
Un réseau virtuel existant sur Azure
Une ou des machines virtuelles déployées sur ce réseau (pour les tests)
Comme le montre la copie d’écran ci-dessous, quelques ressources sont déjà en place sur ma souscription Azure. Il s’agit essentiellement de ressources dédiées aux tests finaux.
Etape 1 : Déploiement de la passerelle VPN
Pour tester notre ensemble, nous devons mettre en place une passerelle VPN sur notre réseau virtuel Azure. Pour cela, Azure propose une ressource tout à fait adaptée à ce type de connexion.
Vous la retrouverez en utilisant la barre de recherche du portail
Cliquez sur Créer pour commencer le processus de création
Prenez votre temps pour renseigner tous les champs, en fonction devotre situation
Info : La copie d’écran ci-dessous montre l’absence d’authentification Azure AD possible lors de l’utilisation d’une passerelle VPN en SKU Basic
Comme pour toute liaison VPN, il est nécessaire de créer une adresse IP publique
Une fois terminé, cliquez sur Valider et créer
Une dernière vérification, puis lancez la création de la passerelle VPN.
Ce processus est assez long puisqu’Azure déploie des machines virtuelles managées pour produire la connexion VPN. Comptez environ 30 minutes pour que le déploiement se termine.
Nous allons profiter de ce temps pour créer une second machine virtuelle, représentant une ressource locale utilisant cette passerelle VPN.
Etape 2 : Déploiement d’une seconde machine virtuelle pour jouer le rôle du client de la connexion VPN Point à Site
Comme annoncé juste avant, cette seconde machine ne sera évidemment pas sur le même réseau virtuel que la première.
Créez un second réseau virtuel dans une autre région Azure pour bien les identifier
Continuez avec l’adresse réseau et le sous-réseau
Lancez la création une fois tous les champs vérifiés
La création d’un réseau virtuel Azure est généralement très rapide
Continuiez avec le déploiement d’une nouvelle machine virtuelle sur ce réseau virtuel local
N’oubliez pas de renseigner le compte d’administrateur local et cochez la case concernant les droits d’utilisation de licence Windows 10
Vérifiez aussi que l’onglet réseau reprend le nouveau réseau virtuel local nouvelle créé, ainsi qu’une nouvelle adresse IP publique, utilisée pour s’y connecter en RDP
Décochez l’arrêt automatique de la machine virtuelle dans l’onglet suivant
Vérifiez une dernière fois les champs et lancez la création de la machine virtuelle
Quelques minutes plus tard, la machine virtuelle est bien créée. Cliquez ici pour rentrer sur la ressource
Démarrer une première connexion RDP sur celle-ci
Renseignez les identifiants indiqués lors de la création de la machine virtuelle
Vérifiez la configuration IP de cette machine locale avec la ligne de commande suivante
Testez le refus de connexion depuis cette machine à sur votre première machine Azure
Retournez sur votre portail Azure et attendez la création de votre passerelle VPN
Un contrôle dans le réseau virtuel Azure affiche bien un nouveau sous-réseau, dédié à notre passerelle VPN
Etape 3 : Préparation du tenant à la connexion VPN
L’opération qui va suivre nécessite un compte administrateur global. Il va falloir en effet donner des permissions spéciales à notre passerelle VPN pour utiliser l’authentification via Azure AD.
Cliquez sur le lien ci-dessous pour lui donner votre consentement :
Authentifiez-vous avec un compte administrateur global de votre tenant
Autorisez l’application Azure VPN
Une fois cette opération terminée, retournez sur le portail Azure AD pour y récolter plusieurs informations. Depuis la page principale, commencez par noter votre tenant ID
Dans la section des applications d’entreprise, localisez la nouvelle application nommée Azure VPN puis cliquez dessus
Notez l’application ID de cette dernière
Etape 4 : Configuration de la connexion Point à Site de la passerelle VPN
Retournez sur la liste des passerelles VPN d’Azure, puis cliquez dessus
Cliquez sur la configuration Point à Site, puis sur Configurer maintenant
Renseignez tous les champs suivants puis cliquez sur Sauvegarder
Adressage réseau : pour attribution d’IP aux périphériques, par exemple 172.16.0.0/24
Type de d’authentification désirée : Azure Active Directory
Une notification Azure vous confirme le succès ou l’échec de votre configuration Point à Site
Raffraîchissez la page web d’Azure pour être en mesure de télécharger la configuration du client VPN sur votre machine virtuelle de test
Copiez et extrayez l’archive ZIP téléchargée sur la machine virtuelle sur laquelle nous allons installer la connexion VPN
Sur cette même machine, ouvrez Microsoft Store pour y télécharger Azure VPN Client
Lancez le téléchargement d’Azure VPN Client
Inutile de vous authentifier pour continuer le téléchargement
Une fois le téléchargement terminé, lancez l’application Azure VPN Client
Importez la configuration de notre VPN créé sur Azure
Cherchez le fichier azurevpnconfig.xml dans l’archive extraite sur le bureau de notre machine de test
Sauvegarder la configuration issue de ce fichier xml
Etape 5 : Test de la connexion Point à Site de la passerelle VPN
Avant de lancer la connexion VPN, retournez sur la fenêtre de commande et lancez la commande PING suivante.
ping 10.0.0.4 -t
Cette commande lance une demande d’écho de manière ininterrompue vers notre première machine Azure
Retournez sur l’application Azure VPN Client et démarrez la connexion
Renseignez les identifiants d’un utilisateur présent dans Azure AD
Décochez la case et cliquez comme ceci
Le status de la connexion VPN devrait alors passer à Connecté
Contrôler le changement de résultat concernant la commande PING
Si cela n’est pas le cas, il vous faudra vous connecter sur la première machine Azure pour autoriser dans Windows Firewall les requêtes d’écho PING
Une fois la connexion réussie, stoppez la connexion VPN
Constatez l’arrêt de succès de la commande PING
Etape 6 : Implémentation de l’accès conditionnel sur la connexion VPN
Comme indiqué au début de cet article, nous voulons une connexion VPN Point à Site couplée à une authentification multifacteur. Le but étant de renforcer par l’exmple l’accès un réseau d’entreprise au moyen d’une authentification supplémentaire.
Voici une vidéo explicative sur l’authentification multifacteur
Voici une seconde vidéo combinant les effets de la MFA et de l’accès conditionnel
La configuration de l’accès conditionnel se fait depuis Azure AD, cliquez sur le menu Sécurité puis Accès Conditionnel
Créez une nouvelle police d’accès conditionnel
Donnez-lui un nom puis cherchez le ou les utilisateurs de test
Exigez l’authentification multifacteur et activez votre police en cliquant sur ON puis sauvegardez
Azure demande quelques minutes avant d’appliquer les modifications faites sur les polices d’accès conditionnel.
Quelques minutes plus tard, retourner sur votre seconde machine et relancez la connexion VPN déjà présente dans l’application Azure VPN Client
La MFA devrait rentrer en ligne en compte. Mon compte de test Azure AD étant insuffisamment paramétré, le message suivant apparaît
Terminez au besoin la procédure d’enrôlement de sécurité pour votre utilisateur de test
Retrouvez bien par la suite la demande MFA pour finaliser la connexion VPN
Une fois celle-ci réussie, la connexion VPN s’établit bien
La commande PING retrouve bien l’accès à ma première machine Azure
Conclusion
Par cet article, nous voyons qu’Azure nous apporte toujours plus de sécurité grâce à la combinaison rapide et facile de différentes mesures de protection. Il est toujours important d’aborder la sécurité sous forme de couches hérmétiques entre elles afin de rendre toujours plus difficile les intrusions informatiques.
Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences ????
Me revoilà après plusieurs semaines d’absence. Pour vous expliquer simplement, la New Commerce Expérience (NCE) de Microsoft, aussi détaillée dans mon blog sur cet article, nous a beaucoup sollicité chez Tech Data. De plus, j’ai eu la bonne idée de me casser des doigts, ce qui ne m’a pas empêché de travailler, mais m’a demandé quelques efforts pour le clavier. Tout ça pour vous dire que ceux ne sont que des petits soucis ????.
Je suis donc très content de commencer l’écriture d’une nouvelle série d’articles, dédiée l’optimisation de votre environnement Cloud. A travers ces derniers, je souhaite vous parler d’optimisations d’architectures Azure déjà en production sur 4 axes :
Coûts : Analyse pure et simple des coûts Azure pour comprendre la répartition des sommes dépensées.
Sécurité : Sans rentrer dans les détails maintenant, la sécurité reste toujours un axe d’amélioration constant.
SLAs : Mis de côté par moment, cet indice doit être pris en compte lors de l’établissement de services auprès des clients finaux ou lors d’appels d’offre.
Performances : Travailler avec les outils de monitoring Azure pour traquer les ressources Azure sous-utilisées, et donc inutilement coûteuses. Mais aussi de manière inverse, mettre en lumière le manque de performances pouvant justifier un changement d’approche.
Je me doute qu’il existe encore d’autres axes, manières ou approches pour retravailler une architecture Cloud. Gardez toujours en tête que toutes les solutions Cloud sont des produits en évolutions constantes ????.
Axe 1 : Les coûts
J’ai choisi cet axe dans mon premier article car c’est pour moi une demande récurrente dans beaucoup de projets Cloud sur lesquels je travaille :
Comment faire la même chose pour moins cher ?
Cette question n’a rien d’idiote ou de contre-productive. Gardez toujours l’esprit ouvert sur l’arrivée de nouveaux services Azure, ou sur la création par Microsoft de nouvelles offres aux grilles tarifaires encore plus attrayantes.
Pour rester dans le concret, mon approche repose simplement sur plusieurs questions :
Le projet Azure dispose-t-il d’une estimation de tarif pouvant servir de référence ?
Le projet Azure a-t-il fait l’objet d’une phase de preuve de concept (POC) ?
Ai-je créé les bonnes ressources pour les bons besoins ?
L’analyse des coûts est-elle faite de manière périodique ?
Ai-je consulté récemment Azure Advisor ?
Les ressources Azure en place ont-elles été optimisées contractuellement ?
Le projet Azure dispose-t-il d’une estimation de tarif pouvant servir de référence ?
Pas de mystère, une maison se construit avec un plan et un budget des matériaux nécessaires à sa construction. Microsoft propose l’outil de calcul, Azure Pricing Calculator, pour établir au plus près les coûts d’une infrastructure Azure. Gardons en tête qu’il ne s’agit que d’une estimation de tarif, basée sur les données entrées par l’utilisateur.
Pour rappel, cet outil vous permet de calculer le coûts via la mise à disposition d’un catalogue proposant un grand nombre de ressources Azure, elles-mêmes paramétrables.
Tous les projets sur Azure devraient passer par cette étape. L’idée n’est pas de viser la perfection tarifaire ou encore d’afficher le tarif le plus attractif possible, mais bien d’en faire sortir un ou plusieurs scénarios pour ensuite les comparer à d’autres méthodes d’architecture.
Dans le cas d’une analyse de coûts sur une architecture Azure déjà en place, je trouve pertinent de comparer l’offre initiale faite sur Azure Pricing Calculator avec la réalité de consommation de la souscription Azure.
Le projet Azure a-t-il fait l’objet d’une phase de preuve de concept (POC) ?
Après l’estimation des coûts et avant la mise en production, une phase de preuve de concept vous permet aussi d’aborder l’aspect financier. Le POC est principalement vu comme une étape de validation de faisabilité technique. Mais elle apporte aussi des indices de viabilité économique de l’architecture.
A ce titre, Microsoft recommande vivement cette étape pour l’estimation de certains coûts variables (bande passante sortante, transactions de stockage, volume de stockage ( sauvegardes ou journaux et métriques, …)). Cette étape est donc une composante dans le processus de calibrage financier.
Doit-on forcément dépenser de l’argent pour un POC Azure ?
Pas nécessairement. Microsoft propose plusieurs offres : des crédits Azure ou encore des conseils d’ingénieurs Microsoft Cloud. De nombreux programmes Azure propose une intégration de nouveaux projets Cloud sous différentes formes. Voici quelques exemples :
Microsoft for Startups : conçu pour vous aider à vous développer à votre propre rythme, vous pouvez débloquer jusqu’à 150 000 $ de crédits et du temps supplémentaire pour construire au fur et à mesure de la croissance de votre entreprise.
FastTrack for Azure: programme d’assistance technique qui aide à concevoir et à déployer rapidement et efficacement des solutions cloud. Il comprend des conseils personnalisés d’ingénieurs Azure pour fournir des pratiques éprouvées et des conseils en matière d’architecture.
Je pense aussi au statut partenaire, gold ou silver chez Microsoft. Ce dernier propose lui aussi de disposer de conseils d’ingénieurs avant-ventes pour choisir les bonnes ressources.
A-t-on créé les bonnes ressources pour les bons besoins ?
Cette question est déjà présente durant la phase de POC, mais elle doit être périodiquement reposée pendant toutes les phases de vie de l’architecture :
Une ressource créée temporairement est-elle bien systématiquement détruite ?
Les opérations de tests sont bien cataloguées comme telles et retirées des services Azure après coup ?
La région Azure utilisée est-elle en adéquation avec le projet et aux plus proches des utilisateurs finaux ?
Beaucoup de questions du même genre existent. La solution simple à ces questions est et reste la pratique de l’inventaire périodique des ressources Azure. Au risque d’en décevoir certains, je recommande simplement de dérouler la liste depuis le portail Azure afin de toutes les passer en revue.
Afin rendre cet exercice le plus rapide et efficace possible, le maintien à jour d’une cartographie facilite grandement l’analyse :
L’analyse des coûts est-elle faite de manière périodique ?
Comme l’inventaire des ressources Azure, son intérêt repose également sur sa récurrence. Mettre des alertes de coûts Azure est une bonne chose, mais elles ne sont déclenchées qu’après coup et ont toujours un risque d’être ignorées. Microsoft propose là encore un outil gratuit, intégré et très facile d’utilisation : Azure Cost Management.
Gardez en tête que les consommations réalisées sont affichées avec 24 heures de décalage. Malgré cela, l’outil propose des affichages réalisant des synthèses et des vues granulaires pour comprendre tous les coûts.
Envie d’en savoir plus sur ses fonctionnalités ?
Ai-je consulté récemment Azure Advisor ?
Voici une définition précise du service :
Azure Advisor est un conseiller personnalisé basé dans le cloud qui décrit les meilleures pratiques à suivre pour optimiser vos déploiements Azure. Il analyse votre télémétrie de configuration et d’utilisation des ressources, puis recommande des solutions qui peuvent vous aider à améliorer la rentabilité, les performances, la fiabilité (anciennement appelée haute disponibilité) et la sécurité de vos ressources Azure.
Azure Advisor est le principal outil disponible sur Azure qui regroupe les axes cités au début de cet article. Pas besoin de connaissances précises pour commencer l’optimisation via cet outil car il analyse l’architecture pour vous !
Un clic dans la partie Coût vous affiche des recommandations actualisées régulièrement :
La seconde ligne de ce tableau nous montre une analyse télémétrique de l’utilisation CPU de la machine virtuelle. Autrement dit, Microsoft lui-même vous conseiller de prendre une taille de machine virtuelle plus petite et donc moins chère vous.
Pourquoi demander à un client de prendre un produit financièrement moins intéressant ?
Pour garantir des revenus stables et sur une plus longue période. Cet outil est disponible dans le menu de gauche des raccourcis Azure et doit être, comme le Cost Management, visité régulièrement.
Les ressources Azure en place ont-elles été optimisées contractuellement ?
Quel est le fond de ma pensée derrière cette phrase ?
Je veux bien sûr parler d’engagement. Saviez-vous qu’il vous est possible de vous engager pour des ressources Azure sur plusieurs années ? Le cloud est souvent perçu comme une dépense IT à la demande (Capex vs Opex) :
Mais Azure propose aussi des formules beaucoup plus avantageuses si l’on envisage la durée de son besoin sur une période plus longue.
Le tableau ci-dessus affiche des instances réservées pour des machines virtuelles. Comment fonctionne une instance réservée ? Il faut simplement voir celle-ci comme une place de parking, louée pour un ou trois ans chez Microsoft :
Cet engagement n’est pas uniquement disponible que pour les machines virtuelles. Microsoft propose cette formule pour beaucoup d’autres services Azure. Le rabais de réservation s’applique automatiquement à l’utilisation des ressources qui correspondent aux instances réservées.
L’engagement n’est pas uniquement présent pour les ressources Azure. Par exemple, les licences Microsoft sont aussi optimisables sur Azure. Je pense avant tout à Windows Server ou encore à SQL Server.
Qu’est-ce qu’Azure Hybrid Benefit ?
Azure Hybrid Benefit est un avantage en matière de licences qui vous permet de réduire considérablement les coûts d’exécution de vos charges de travail dans le cloud. Son fonctionnement consiste à vous autoriser à utiliser vos licences Windows Server et SQL Server compatibles sur Azure.
Il est donc possible d’acheter des licences en souscriptions annuelles ou pluriannuelles. Les économies représentent des sommes non négligeables.
Conclusion
Je suis content de vous parler de l’aspect financier des architectures Azure. Cela représente une partie non négligeable de mon travail au quotidien.
Comme je l’ai expliqué dans cet article, l’aspect Coût est systématiquement abordé durant toutes les phases d’un projet IT. Et il n’est pas rare de changer de stratégie en fonction de l’évolution de ce dernier.
Dans mon prochain article de la série Optimisez votre Azure, nous nous intéressons plus aux basiques de la sécurité ????.
Aujourd’hui, je m’écarte un peu d’Azure pour vous parler d’un changement global chez Microsoft, appelé New Commerce Expérience et impactant la vente de leurs services Cloud. Le but de cet article est de vous rappeler quelques notions clefs et les principaux impacts de NCE.
Microsoft a introduit une nouvelle expérience de commerce pour les clients achetant et gérant leurs licences Cloud dans le cadre de son programme CSP (Cloud Solution Provider). Il s’agit d’une démarche que Microsoft déjà a commencée en 2019, et est toujours en cours en ce début d’année 2022.
Qu’est-ce que le programme CSP ?
Pour faire simple, Microsoft travaille de différentes manières pour vendre leurs produits aux clients finaux. Dans le schéma ci-dessous, on retrouve une liste de programmes existants pour acquérir des droits de licence sur des produits Microsoft :
Le programme CSP est conçu pour permettre aux partenaires de revendre les services Cloud de Microsoft. L’objectif du programme de CSP est donc de créer un modèle de revendeurs pour fournir des services aux petites et moyennes entreprises (PME). Deux modèles sont possibles via le programme CSP : indirect ou indirect.
Qu’est-ce que la New Commerce Experience ?
L’image affichée plus haut met en évidence la complexité et la multitude de scénarios possibles pour acheter des licences de produits Microsoft. Il était donc temps de simplifier cette approche, comme le veut la New Commerce Experience :
Cette simplification d’achat met aussi en avant l’utilisation d’une seule plateforme centrale pour les partenaires Microsoft, le Partner Center :
Microsoft s’attaque donc maintenant aux licences associées aux utilisateurs :
Microsoft 365
Dynamics 365
Power Platform
Windows 365
Tandis que le bouleversement de la NCE fut mineur pour les utilisateurs d’Azure, cela est moins vrai pour Modern Work Place. En effet les règles du jeu des licences utilisateurs changent grandement avec NCE. Nous en reparlerons un peu plus loin dans cette article.
Quel est le planning NCE pour Modern Work Place ?
Le programme CSP repose donc sur le planning NCE suivant pour 2022. Comme on peut le voir Microsoft concentre ses évolutions sur 3 axes :
Mise en place de promotions incitatives NCE jusqu’à juin 2022
Renforcement des règles liées à un achat NCE en mars et juillet 2022
Réduction des marges arrières pour les souscriptions non transférées sur NCE en 2023
Pourquoi Microsoft augmente ses prix ?
Depuis le lancement de 365, Microsoft a rajouté plus de 24 applications (Microsoft Teams, Power Apps, Power BI, Power Automate, Stream, Planner, Visio, OneDrive, Yammer et Whiteboard …), mais aussi un nombre incalculable de nouvelles fonctionnalités.
Le 1er mars 2022, Microsoft appliquera donc une hausse de prix sur les licences suivantes :
Microsoft 365 Business Basic (de 5 à 6 $)
Microsoft 365 Business Premium (de 20 à 22 $)
Office 365 E1 (de 8 à 10 $)
Office 365 E3 (de 20 à 23 $)
Office 365 E5 (de 35 à 38 $)
Microsoft 365 E3 (de 32 à 36 $)
Nous n’avons pas encore les chiffres précis en Euros ou en CHF, je ne manquerai pas de les rajouter dès que cela sera disponible.
Quelle est la meilleure période pour migrer les licences vers NCE ?
Maintenant ! Aucunement l’idée de vous faire faire un achat précipité, mais plusieurs arguments me permettent d’en arriver à cette conclusion :
La promotion NCE sur les différents engagements (mensuel / annuel) s’arrête au 1er juillet 2022
Le blocage du prix sur la période d’engagement permet de reporter la hausse de certains produits 365 prévue pour mars 2022
Les différents verrous prévus par Microsoft sur les achats en 2022 risque de compliquer la gestion et le renouvellement des licences en fonction de l’évolution des besoins.
Tout est donc rose avec NCE ?
Historiquement :
Dans le cadre du programme CSP, Microsoft offrait aux partenaires une très grande souplesse dans la gestion des licences durant la période d’engagement. Cette flexibilité était très appréciée car le provisionnement des licences utilisateurs suivait alors de près l’évolution des besoins du client.
Avec NCE :
Microsoft laisse une fenêtre de 72 heures après l’achat pour annuler un abonnement NCE. Si l’abonnement n’est pas annulé dans cette fenêtre de 72 heures, le client devra payer le reste de la durée de l’abonnement. Autrement dit : un mois, un an, ou même 3 ans !
Si un client souhaite réduire le nombre de licences, l’abonnement doit être modifié dans les 72 heures de la date d’anniversaire. Si cette fenêtre est dépassée, la modification à la baisse ne sera prise en compte qu’au prochain anniversaire. Autrement dit : le mois prochain, l’année prochaine, ou même dans 3 ans !
En revanche, les clients peuvent toujours augmenter le nombre de sièges et changer la licence pour une autre de niveau supérieur, même après cette période de 72 heures.
On serait alors tenté de prendre toutes les licences sur un abonnement mensuel pour plus de liberté. Ce choix logique est possible, mais le prix pour cet engagement de courte durée est 20% plus cher que pour le même avec un engagement annuel.
Dernière précision, un engagement annuel ou pluriannuel est payable en une seule fois au début de l’engagement, ou tous les mois de ladite période d’engagement.
Peut-on prendre des licences avec engagement mensuel ET annuel ?
C’est aussi possible ! Et cela est même fortement conseillé dans certains secteurs, avec une saisonnalité des besoins informatiques.
Que faut-il retenir sur NCE ?
Voici les principaux points à garder en tête pour bien comprendre les enjeux de NCE :
Ce nouveau mode d’achat licence est déjà en place depuis le 10 janvier de cette année
La bascule des licences vers NCE est transparente pour les utilisateurs car ce changement n’impacte pas l’assignation
La durée d’engagement est un maintenant point majeur dans la décision d’achat. Tant pour le client, que pour le partenaire qui fournit le service
Toute baisse du nombre ou changement de licences NCE n’est possible qu’aux dates anniversaires
Les partenaires restent redevables des licences NCE prises auprès de Microsoft, même si leurs clients ne sont plus en capacité d’honorer les paiements
Les licences mensuelles sont fortement conseillées pour les besoins ponctuels
La fenêtre de 72 heures est la SEULE porte de sortie d’un engagement NCE avant le terme d’engagement
Conclusion
Pas de panique ! Bien que ce changement bouleverse nos habitudes d’achat chez Microsoft, il ne pas oublier que cela est déjà la norme dans le monde des licences par abonnement.
Mon dernier conseil : en tant que partenaire, assurez-vous de communiquer le plus en amont possible avec vos clients, pour que ces derniers considèrent les meilleures options possibles.