MVP

J’ai l’immense honneur de vous annoncer le renouvellement de mon titre Microsoft « Most Valuable Professional » pour l’année 2020/2021.

Je fais désormais partie des 22 MVP Français dans la catégorie « Microsoft Azure ».

WTF

Un « Big Thanks » à Microsoft, Martine THIPHAINE ainsi qu’à toute l’équipe MS pour le temps consacré à l’étude du renouvellement de mon titre.

Très honoré de faire partie de la « Biggest IT Community in the World » :).

What Next ?

Plusieurs contributions à venir, à commencer par :

Plusieurs séries d’articles autour de Microsoft Azure {Azure Security – Azure Design – Az CLI 2.0 – Az PowerShell – Azure Virtual Machine – Windows Virtual Desktop – Azure Batch – Azure Automation – Azure Monitor – Azure Networking – Azure Active Directory – ASR/Migration de Datacenter vers MS Azure – Azure KeyVault – Azure Backup, Azure Watcher – Azure AD – Azure SQL…)

Plusieurs séries d’articles autour de technologies Microsoft orientées « Infra & Virtu » : RDS {2016/2019 : Design, Deployment, Security, Tuning & Migration} – Windows Server 2019 {HowTo : OS Hardening, IIS, Bitlocker /AppLocker, Security, Group Policy Objects, DFS/R, BranchCach, ADFS …} – VBS /BATCH /PS Scripting (avec des advanced scenarios)

Plusieurs eBooks sur différentes technos Microsoft orientés Infrastructure & Cloud (Sentinel, Azure AD, Azure Windows Virtual Desktop, Azure Security Center, Azure FinOps)

Plusieurs scripts (.Bat /PS) de déploiement /automation sur différentes technos Microsoft orientées Infrastructure.

 

 

J’en profite de ce post pour remercier tous les followers (LinkedIn, Twitter, Blog …) ainsi que les personnes qui votent et partagent mes articles & actus.

A bientôt pour de nouvelles aventures.

Keep in touch :).

 

S’applique à : RDS Windows Server 2016 et RDS Windows Server 2019

Introduction

Pour réduire la surface d’attaque sur certains rôles/serveurs RDS, il est fortement recommandé de les déployer sur une infrastructure Windows Server en mode « Core » plutôt qu’en mode « GUI ». Cela vous permet aussi de réduire vos efforts en terme de maintien et exploitabilité de la plateforme (moins d’Updates, moins de config post-déploiement…).

 

Services de rôles RDS pris en charge par Windows Server Core 2016 et 2019

Le tableau ci-dessous, liste les différents services RDS pouvant être déployés/pris en charge sur un Windows Server 2016 et 2019 en mode Core:

Service de rôle RDS Supporté sur Server Core
RDCB  
RDLS  
RDSH  
RDVH  
RDWA  
RDG  
pris en charge

 

non pris en charge

 

En outre, Windows Server 2019 « Core » prend en charge tous les agents (graphiques) de Monitoring, Antivirus, Sauvegarde ou encore Sécurité (Encryption de Disk /Files). Vous pouvez donc continuer à inclure vos serveurs RDS en mode Core dans le périmètre de vos solutions d’infrastructures existantes, et ce sans aucun impact.

Pensez donc à privilégier l’utilisation du more « Core » pour vos serveurs Brokers (RDCB) et de Licences (RDLS).

Note importante : depuis Windows Server 2016, il n’est plus possible de Switcher entre les modes « GUI » et « Core ». Vous devez donc déployer vos serveurs RDS en mode Core « From Scratch ». Les serveurs RDS 2016 (existants) qui sont déjà en mode « Graphique » ne peuvent malheureusement être transformés en mode « Core » comme c’était le cas avec Windows Server 2012 et 2012 R2.

 

Gérer vos serveurs RDS Core à distance

Les serveurs RDS (RDCB et RDLS) exécutant Windows Server 2016 et 2019 en mode Core peuvent être gérés à distance depuis n’importe quelle machine d’administration ayant les outils RSAT installés. Cela pourrait être une machine cliente (Windows 7, 8/8.1 ou encore Windows 10) ou un serveur d’administration (Windows Server 2012 /2012 R2, 2016 ou encore 2019).

Depuis un Serveur d’Administration

Depuis une Session Windows Server (2012 ou ultérieur), lancez Windows PowerShell en tant qu’Administrateur et saisissez la commande suivante :

Get-WindowsFeature RSATRDS* | FT –AutoSize

Les outils RSAT dédiés pour la gestion des services de rôles RDS sont retournés

L’outil (Snap-in) RSAT-RDS-Licensing-Diagnosis-UI correspondant à « Outils de diagnostic des licences des services Bureau à distance » vous permet de gérer et diagnostiquer les services de licence RDS à distance.

Quant à l’outil « Gestionnaire de Licence des Services Bureau à distance« , celui-ci vous permettra d’activer votre serveur de Licence RDS, installer, gérer et migrer vos CAL RDS.

Depuis une machine cliente d’Administration

Il est également possible de gérer votre déploiement RDS depuis une machine cliente (Windows 7 ou ultérieur) ayant les outils RSAT installés.

En effet, ces derniers incluent l’outil « Server Manager » qui vous permet de regrouper vos serveurs RDS de déploiement dans le même pool de serveurs et gérer ainsi votre déploiement depuis le volet « Services Bureau à distance ».

Vous trouverez ci-après les liens de téléchargements des outils RSAT pour les clients Win7 > Win10:

Outils RSAT pour Windows 10

Outils RSAT pour Windows 8.1

Outils RSAT pour Windows 7

 

Enjoy :).

[Blog Post updaté le 15 Avril 2020]
Introduction à l’outil « AzAdvertizer » 

Aujourd’hui, je souhaite partager avec vous un Powerful Tool Azure nommé « AzAdvertizer« .

AzAdvertiser est un outil dédié à la Gouvernance Azure, il vous permet de Tracker/Suivre en temps réel tous les Updates/changements/évolutions introduites à plusieurs services Azure dédiés à la gouvernance de vos environnements Cloud, notamment :

  • Azure RBAC
  • Azure Policy
  • Policy Initiative
  • Policy Alias

 

Note importante : AzAdvertizer est un outil développé par un Senior PFE Microsoft (Julian Hayward), il ne s’agit pas d’un outil officiel Microsoft, par conséquent, aucun support n’est fourni, et aucun MCO (Maintien en Condition Opérationnelle) n’est garanti.

 

AzAdvertizer : comment ça marche 

AzAdvertiser est un outil Web accessible directement depuis l’URL suivante :

https://www.azadvertizer.net

En plus de l’onglet « HOME » qui vous permet d’avoir un Overview sur les Last updates/changements apportés aux services Azure RBAC/Policy/PolicyAlias/PolicyInitiative avec un joli Graph (Azure Governance vitality) illustrant quand et combien de changements/évolutions ont eu lieu, AzAdvertizer regroupe les 4 onglets « clés » suivants :

 

L’onglet « HOME »

Au moment de la rédaction du présent Blog Post, AzAdvertizer indique depuis l’onglet « HOME« , la suppression d’un rôle RBAC au 28-03-2020, si vous cliquez sur le chiffre 2 sous Role, vous serez automatiquement redirigé sur l’onglet « RBAC Role », ce qui vous donnera plus de détails sur le rôle RBAC Azure supprimé :

Comme montré dans la capture d’écran ci-dessous, le rôle « VSOnline Virtual Network Service » a été retiré/supprimé le 28/03/2020 :

L’onglet HOME pourra être utile pour les plus pressés souhaitant simplement avoir les dernières news/updates/changes sans trop rentrer dans le détail, ou suivre les new releases (quand et quoi) avant d’aller sur chaque onglet et en savoir plus sur le changement ou évolution apportés au service.

 

Onglet « POLICY »

L’onglet « POLICY » répertorie les Stratégies Azure et les différents changements/évolutions ayant eu lieu récemment, AzAdvertizer vous offre deux options (cela s’applique à tous les autres onglets aussi) :

  • Changes on Policies : liste tous les changements/updates apportés aux Stratégies Azure. Vous pouvez filtrer chaque colonne pour affiner vos recherches. Dans l’exemple suivant, nous allons filtrer le résultat pour lister uniquement les Policies ayant été supprimées (deprecated) :

  • « All Policies » : liste toutes les stratégies Azure à date
    • Idem que l’ancien tableau, vous avez toujours la possibilité de filtrer vos recherches pour lister uniquement les informations dont vous avez besoin. N’hésitez donc pas à définir un ou deux filtres et noter le résultat (eg : ajouter le filtre « Add » pour savoir les Stratégies qui ont été ajoutées/introduites sur Azure récemment).

 

Onglet « INITIATIVE »

Comme mentionné précédemment, AzAdvertiser propose les mêmes (deux) options pour les 4 onglets, vous retrouverez donc le « Changes on Azure Policy Initiatives » ainsi que le « All Azure Policy initiatives »

Commencez par sélectionner « Changes on Azure Policy Initiatives » et noter le résultat retourné par l’outil : tous les changements apportés aux Policy initiatives Azure vous sont retournés :

Sélectionnez maintenant « All Azure Policy Initiatives » et notez le résultat retourné par AzAdvertizer : toutes les initiatives de stratégies Azure :

 

Onglet « ALIAS »

L’onglet « ALIAS » présente tous les Policy alias Azure, vous pouvez là aussi tracker tous les changements apportés aux alias de Stratégies Azure ou les lister tous, faites l’exercice 🙂

 

Onglet « RBAC ROLE »

Enfin, l’onglet « RBAC ROLE » répertorie tous les rôles RBAC et les leurs évolutions.

L’option « Changes on Azure RBAC Roles » vous retourne les dernières évolutions/new releases pour les rôles RBAC :

Si vous sélectionnez l’option « All Azure RBAC Roles« , AzAdvertizer vous retourne la liste complète de tous les rôles RBAC. Au moment de la rédaction du présent post, il existe 168 rôles RBAC (cf screenshot ci-dessous) :

Vous pouvez constater cela depuis le Portail Azure > Contrôle d’accès (IAM) de n’importe quel Abonnement, Resource Group (RG) ou Ressource Azure > Rôles > Filtrer Role Type sur « BuiltinRole » :

Comme montré dans l’image ci-dessus, le nombre de Rôles Built-in affichés sur le Portail Azure est le même que celui retourné par AzRoleAdvertizer.

 

Onglet « OTHER »

L’onglet « OTHER » liste/répertorie plusieurs outils Azure assez intéressants et Useful, notamment le fameux AzureChart , ou encore le Powerful Azure Speed/Latency Test tool.

Enjoy :).

 

Update du 15 Avril 2020

Une nouvelle fonctionnalité a été introduite sur l’outil AzAdvertizer ce mi Avril, il s’agit de ResProvOps.

Un nouvel onglet nommé « RESPROVOPS » a été effectivement ajouté à l’outil Web AzAdvertizer :

Ce nouvel onglet liste tous les fournisseurs de ressources Azure, avec les espaces de noms (NameSpace) et opérations associées.

Dans l’exemple suivant, nous allons sélectionner le Resource Provider Microsoft.Network, le tableau nous retourne les informations suivantes (notez la liste des opérations du RP) :

Cet onglet devient vite pratique et très utile si vous êtes dans une phase de design d’un nouveau modèle de gestion de droits RBAC, car vous permet de lister rapidement les Resources Opérations possibles pour un Resource Provider spécifique, et vous permettra donc d’établir rapidement les opérations nécessaires pour vos Custom Roles RBAC.

N’hésitez pas à faire le tour des autres fournisseurs de ressources, et analyser les résultats retournés.

 

Découvrez le nouveau service Azure Windows Virtual Desktop ...

 

Introduction

L’équipe Azure en charge de l’offre Desktop-as-a-Service (DaaS), connue sous le nom Windows Virtual Desktop (WVD) a récemment publié plusieurs sessions/vidéos assez intéressantes sur le sujet, vous permettant de préparer, déployer, sécuriser, optimiser et troubleshooter vos déploiements Azure WVD.

Je vous partage à travers ce Blog post les liens des différentes sessions recordées.

Enjoy the training :).

 

Liens utiles 

Ci-après les liens des sessions dont je vous ai parlé précédemment, pour une meilleure compréhension du sujet, je vous recommande de suivre/visionner les vidéos dans l’ordre suivant :

Préparez votre environnement Azure Windows Virtual Desktop

https://lnkd.in/dnSrYpX

Déployer votre environnement Azure Windows Virtual Desktop via le Portail Azure

https://lnkd.in/d2Addne

Bonnes pratiques relatives au Profile Management avec FSLogix

https://lnkd.in/dM4G2jr

Moderniser votre Stratégie de gestion d’image pour Azure Windows Virtual Desktop

https://lnkd.in/decx2R3

Optimiser votre déploiement Azure Windows Virtual Desktop

https://lnkd.in/deq99Xy

Sécuriser votre déploiement Azure Windows Virtual Desktop

https://lnkd.in/d3wJEPQ

Troubleshooter & Diagnostiquer votre environnement Azure Windows Virtual Desktop

https://lnkd.in/d3FYk9u

Deployment best practices for latency sensitive workloads

https://lnkd.in/dSGAssZ

 

A bientôt,

 

 

Azure Guys, Hello again,

Je voulais partager avec vous un (free) eBook Azure assez intéressant.

Il présente la suite Operations Management Suite (OMS) d’Azure et décrit pas mal de fonctionnalité intéressante, notamment le Backup & Recovery sur Azure (Azure Backup & ASR), Azure Automation, Desired State Configuration (DSC) ainsi que tous les services liés à l’analyse et configuration réseau Azure.

L’eBook est organisé en 12 Chapitres, à savoir :

  • Chapter 1: Introduction and Onboarding
  • Chapter 2: Searching and Presenting OMS Data
  • Chapter 3: Alert Management
  • Chapter 4: Configuration Assessment and Change Tracking
  • Chapter 5: Working with Performance Data
  • Chapter 6: Process Automation and Desired State Configuration
  • Chapter 7: Backup and Disaster Recovery
  • Chapter 8: Security Configuration and Event Analysis
  • Chapter 9: Analyzing Network Data
  • Chapter 10: Accessing OMS Data Programmatically
  • Chapter 11: Custom MP Authoring
  • Chapter 12: Cross Platform Management and Automation

 

Plusieurs scripts vous sont fournis avec l’eBook (cf Liens Github fournis dans l’eBook).

Vous pouvez télécharger l’eBook depuis le bouton Download ci-dessous :

 

 

Introduction

J’ai récemment découvert un outil assez intéressant pour Azure, il s’agit d’Azure VizGov.

Cet outil vous permet d’auditer vos environnements Azure (ou ceux de vos clients) pour :

  • Avoir de la visibilité sur la hiérarchie de vos Management Group Azure (Groupes d’Administration) jusqu’aux abonnements Azure
  • Capturer /récupérer toutes les informations relatives aux droits/attributions de rôle RBAC
  • Lister toutes les Stratégies (Azure Policies) appliquées à vos Management Group (MG) et abonnements

 

Télécharger AzGovViz

L’outil tourne sou forme de Script PowerShell, et est disponible en téléchargement depuis ce Repo Github

 

Prérequis

AzGovViz a été codé sous PowerShell, vous devez donc disposer d’un des modules PowerShell Azure suivant pour l’exécuter :

  • Module Az
  • Module AzureRM

De plus, pour pouvoir exécuter le script, vous devez disposez les autorisations/permissions RBAC suivantes :

  • [RBAC] : le rôle « Management Group Reader«  au niveau du Management Group
  • [RBAC] : le rôle « Reader«  au niveau du Management Group
  • [Permissions API] : si vous voulez exécuter le script via Azure Automation ou l’agent Azure DevOp, vous devrez configurer les permissions de l’API au niveau de l’annuaire Azure AD. Idem pour le compte Automation qui sera utilisé, l’inscription de l’App du compte doit être autorisé avec l’autorisation suivante : Azure Active Directory API | Application | Directory | Read.All

 

HowTo : exécuter AzGovViz

Suivez les instructions suivantes pour exécuter l’outil de visualisation de gouvernance Azure depuis votre environnement :

.\AzGovViz.ps1 -managementGroupId <ID_de_votre_Management_Group>

 

 

Outputs

AzGovViz audit/collecte et retourne des informations sur vos Management Group, Abonnements, droits RBAC, Initiatives Policy et Policies Azure.

AzGovViz vous retourne le résultat sous format « HTML » et CSV (Comma-Separated Values).

 

Petit Bonus !

Le résultat /données collectées post-exécution d’AzGovViz sont directement disponibles dans le Wiki Azure DevOps (voir screenshot ci-dessous) :

 

Informations utiles

AzGovViz a été testé (par mes soins) sur le CloudShell et PowerShell Core pour Windows et Linux (Ubuntu 18.04 LTS). Il est compatible et ne présente aucun problème d’exécution/stabilité.

 

 

 

 

Introduction 

La notion de rôles dans Azure est souvent oubliée par les clients qui veulent aller « trop vite » et commencer à migrer/déployer des Workloads dans le Cloud.

Après plusieurs dizaines de missions autour d’Azure, j’ai constaté que la plupart des clients (pour ne pas dire tous ^_^), confondent toujours les rôles « RBAC » Azure de type « Owner, Contributor ou encore User Access Administrator« , avec les rôles Azure AD de type « Global Administrator /User Administrator ou encore Application Administrator/Developper« .

Sans parler des rôles Azure historiques « Classiques » de type « Administrateur de Comptes, Administrateur de Service ou encore Co-Administrateur« , introduits avec la toute première version d’Azure (Azure ASM : Azure Service Manager) dont peu de personnes connaissent l’existence.

Pour bien démarrer avec Azure, il est très important de comprendre chaque type de rôle, son utilité (quand et comment l’utiliser) et à quel niveau (Scope).

L’objectif du présent post est de vous présenter les différents rôles Azure, la différence entre eux, limitations relatives à chaque type de rôle et comment les implémenter dans vos environnements Cloud Azure.

Bonne lecture à tous !

 

Les rôles fournis avec Microsoft Azure

Trois types de rôles sont fournis aujourd’hui avec Microsoft Azure, à savoir :

  • Les rôles Azure « Classiques » (rôles historiques)
  • Les rôles Azure « RBAC »
  • Les rôles Azure « Active Directory »

Reportez-vous aux sections suivantes pour en savoir plus !

Les rôles « Azure Classic » : Un peu d’historique

Quand Azure était proposé pour la première fois (sous le modèle de déploiement ASM : Azure Service Manager), la gestion des accès aux ressources se faisait via l’utilisation de trois rôles (Administrateurs) uniquement, à savoir :

  • Administrateur de compte (Account Administrator)
  • Administrateur de Service (Service Administrator)
  • Co-Administrateur (Co-Administrator)

 

Lors de l’inscription à Microsoft Azure (création d’un nouveau compte/environnement Azure), le compte (Adresse Email) utilisé est automatiquement défini/déclaré en tant que « Administrateur de compte » et « Administrateur de Service ». Des Co-Administrateurs pourront ensuite être déclarés pour déléguer l’accès et la gestion des ressources Azure hébergées au niveau des abonnements.

Tip : Connectez-vous sur le Portail Azure, sélectionnez un de vos abonnements, et cliquez ensuite sur « Propriétés« , notez le nom du compte (Adresse Email) portant le rôle « Administrateur de compte » et « Administrateur de Service »

Les administrateurs « Classiques » ont un accès/contrôle total à la Souscription Azure. Ils peuvent gérer les ressources en utilisant le portail Azure ou via les API Azure ARM et ASM.

Note : Les Administrateurs de Services et les Co-administrateurs sont équivalents au rôle « Owner /Propriétaire » du nouveau modèle RBAC (Azure ARM) et offrent un accès total au niveau de l’abonnement. Le rôle « Administrateur de compte » quant à eux, ne permet pas la gestion des ressources. Cf tableau ci-dessous

Le tableau suivant décrit en détails les différences entre ces trois rôles Azure historiques :

Ce tableau peut être downloadé depuis ce lien Direct.

Vous aurez compris, avec Azure ASM, nous étions plus dans un modèle de Tout ou Rien (All-or-Nothing), car seuls les trois Administrateurs cités précédemment étaient disponibles, si votre politique de sécurité impose le principe du moindre privilège (PoLP : Principle of Least Privilege) et que vous deviez par exemple, limiter l’accès et la gestion de vos VMs Azure à un groupe d’utilisateurs spécifique, eh bien techniquement cela n’était pas possible, car tous les membres du groupe Azure AD auquel vous allez attribuer un des rôles Azure Classique se verront attribuer un rôle d’Administrateur (Co-Administrateur généralement), leur permettant automatiquement un accès total sur toutes les ressources Azure de votre abonnement.

Gérer l’attribution et la suppression des rôles Azure Classiques

Pour gérer l’attribution et la suppression des rôles Azure « Classiques », sélectionnez un abonnement,  groupe de ressources ou encore une Ressource Azure, et rendez-vous ensuite sous la Blade « Contrôle d’accès (IAM) » > onglet « Administrateurs Classiques » :

  • La liste des Administrateurs Classiques (Administrateurs de Service et Co-Administrateurs) est affichée :

Note : le compte ayant servi à l’inscription sur Azure, est automatiquement déclaré en tant que « Administrateur de services fédérés ».

  • Pour ajouter ou supprimer un Co-Administrateur, cliquez sur « Ajouter« , et sélectionnez ensuite « Ajoute un coadministrateur » :

N’hésitez pas à ajouter et supprimer un compte co-administrateur sur vos environnements de Test/Sandbox Azure et tester les droits qui lui seront attribuer.

 

En savoir plus sur les rôles Azure « Classiques »

Pour en savoir plus sur les rôles « Classiques » Azure, je vous invite à consulter cette documentation.

 

Ce qu’il faut retenir  

Azure étant proposé aujourd’hui qu’en mode ARM (Azure Resource Manager), la notion de rôles « Classiques » ne doit pas être prise en considération lors du design de votre modèle de délégation de droits Azure.

Le focus doit être porté sur les nouveaux rôles « RBAC » et « Azure AD ».

La section précédente avait simplement pour but de vous expliquer l’historique des premiers rôles apparus avec la première version d’Azure ASM.

 

Les rôles « Azure RBAC »

Avec l’introduction du modèle de déploiement Azure ARM (Azure Resource Manager), un nouveau modèle/système de gestion des droits d’accès a été introduit, il s’agit du modèle RBAC (Role-Based Access Control).

RBAC a permis à plusieurs entreprises ayant un niveau de sécurité « sérieux » de décoller et d’aller vers le Cloud.

Ce nouveau système de gestion de droits a résolu la problématique liée à l’ancien model de droit d’accès ASM offrant un niveau d’accès limité de type All-or-Nothing.

Azure RBAC permet en effet une gestion de droits d’accès plus fine et inclut (par défaut) plusieurs dizaines de rôles prédéfinis (Built-in) vous permettant de restreindre au maximum l’accès et la gestion à vos ressources et services Azure.

Microsoft a pensé son modèle RBAC de la manière suivante :

  • Un type de rôle par Service/Offre Cloud (eg : Azure VM Contributor | Azure Sentinel Contributor…)
  • Plusieurs profils au niveau du même rôle RBAC (eg : Azure Security Admin | Azure Security Reader …)

Note importante : les rôles Azure RBAC sont dédiés à l’accès et gestion des ressources Azure uniquement telles que les VMs Azure, Bases de données SQL Clusters HDI, Services Réseaux (VNET, Subnet, Gateway VPN, NSG, LB…) ou encore les WebApp, Mobile App…etc. La gestion de l’annuaire Azure AD et ses objets associés nécessitent d’autres droits /rôles (Rôles Azure AD), voir section suivante pour en savoir plus !

 

Il existe plus précisément (au moment de la rédaction du présent post) 166 rôles Azure intégrés (Built-in). Vous pouvez les visualiser depuis la Blade « Contrôle d’accès (IAM) » > « Rôles » :

RBAC vous permet de créer un modèle de délégation par profil (Build Team), par modèle de service Cloud (IaaS Builder, PaaS Contributor…) ou par offre Cloud(VM Builder, VNET Admin, Azure SQL Admin)…

 

Liste des « Built-in » Rôles RBAC Azure 

La liste complète des Built-in rôles RBAC Azure est disponible depuis l’URL suivante :

https://docs.microsoft.com/fr-fr/azure/role-based-access-control/built-in-roles

L’équipe Azure en charge de la partie RBAC mets régulièrement à jour cette liste, généralement après introduction d’un nouveau service /offre Cloud (eg : Azure Sentinel > introduction de nouveaux Built-in Roles : Azure Sentinel Contributor | Azure Sentinel Reader…).

Note : La suppression d’un service Cloud implique également la suppression des Built-in rôles RBAC associés. Avant de commencer vos travaux de conception du modèle RBAC, je vous recommande vivement de consulter cette page.

 

Les rôles RBAC fondamentaux 

Comme expliqué précédemment, il existe aujourd’hui plus de 150 Rôles RBAC Built-in.

Les 4 principaux rôles RBAC Built-in à retenir sont listés dans le tableau :

Rôle RBAC Autorisations Notes
Propriétaire (Owner)
  • Accès total à toutes les ressources
  • Délégation de l’accès à d’autres personnes
L’administrateur de services et les coadministrateurs se voient attribuer le rôle Propriétaire/Owner au niveau de chaque abonnement.

Ce rôle s’applique à tous les types de ressources.

Contributeur (Contributeur)
  • Création et gestion de tous les types de ressources Azure
  • Ne peut pas attribuer/déléguer l’accès à d’autres personnes
Ce rôle s’applique à tous les types de ressources.
Lecteur (Reader)
  • Consultation/Lecture des ressources Azure uniquement
Ce rôle s’applique à tous les types de ressources.
Administrateur de l’accès utilisateur (User Access Administrator)
  • Gestion de l’accès utilisateur aux ressources Azure

 

Gérer l’attribution et la suppression des rôles Azure RBAC

Pour gérer l’attribution et la suppression des rôles Azure « RBAC », sélectionnez un abonnement, groupe de ressources ou une ressource et rendez-vous ensuite sous la Blade « Contrôle d’accès (IAM) » > onglet « Attributions de rôles » :

  • Les attributions de rôles RBAC déclarées peuvent être consultées depuis cet onglet :

  • Pour ajouter une nouvelle attribution de rôle, cliquez sur « Ajouter » et sélectionnez ensuite « Ajouter une attribution de rôle » :

  • Dans l’exemple suivant, nous allons attribuer le rôle Virtual Machine Contributor (Contributeur de machines virtuelles) au groupe Azure AD « HK Run Team« .
    • Note : il faut cliquer ensuite sur « Enregistrer » pour que cette nouvelle attribution de rôle soit prise en compte.

  • La nouvelle attribution de rôle RBAC (VM Contributor) apparaît désormais sous « Attribution de rôles« :

  • Pour supprimer une attribution de rôle existante, il suffit de la sélectionner, et cliquez sur « Supprimer » :

  • Vous serez invités à confirmer cette suppression en cliquant sur « Oui » :

 

Les Custom Rôles RBAC

Azure RBAC vous offre également la possibilité de créer vos propres rôles RBAC, appelés « Custom Roles » ou « Rôles personnalisés« .

Si les rôles RBAC « Built-In » fournis par défaut avec Azure ne répondent pas à vos besoins, vous pouvez créer vos rôles Custom et définir des droits/autorisations personnalisées.

Si votre politique de sécurité définit un modèle RBAC basé sur le concept du Least privilège, avec une utilisation de groupes (Azure AD) distincts permettant uniquement :

  • La lecture et exportation de Logs Azure AD & des ressources
  • Le démarrage, redémarrage et l’arrêt des services IaaS (VM) et PaaS (Serveurs SQL Azure)
  • Création et lecture des règles NSG

vous avez la possibilité de créer des Custom Roles avec les autorisations nécessaires correspondant aux droits définis dans votre modèle de droit d’accès.

Un Custom Role est créé sur la base d’un fichier JSON, avec une structure (setting <> data value) spécifique.

L’exemple suivant, montre un Custom Role permettant uniquement le démarrage, arrêt et redémarrage des VMs Azure :

Je vous invite à consulter cet article pour en savoir plus sur les Azure Custom Roles.

 

Azure RBAC : Limitations

Il existe certaines limitations relatives à l’utilisation des rôles RBAC Azure, voir tableau ci-dessous :

ID Limitation

Description de la limitation

#1

Vous pouvez avoir jusqu’à 2 000 attributions de rôle dans chaque Souscription Azure

#2

Vous pouvez avoir jusqu’à 500 attributions de rôle dans chaque Management Group

#3

Vous pouvez avoir jusqu’à 5000 Custom roles par Tenant Azure

Note importante : la limitation #1 comprend l’attribution de rôles Built-in et Customs.

 

En savoir plus sur les rôles Azure « RBAC »

Pour en savoir plus sur les rôles RBAC Azure, je vous invite à consulter cette documentation.

 

Les rôles « Azure Active Directory »

Les rôles Administrateurs Azure AD (aka AAD) sont utilisés pour gérer les ressources de l’annuaire Azure AD, par exemple pour créer ou modifier des comptes utilisateurs Azure, attribuer des rôles d’administration à d’autres personnes ou gérer l’appartenance aux groupes Azure AD, réinitialiser les mots de passe des utilisateurs, gérer les licences utilisateur et encore gérer les propriétés du domaine Azure AD.

 

Liste des « Built-in » Rôles Azure AD 

La liste complète des Built-in rôles Azure AD est disponible depuis l’URL suivante :

https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#available-roles

Il existe (au moment de la rédaction du présent post) 56 rôles Built-in Azure AD.

L’équipe Azure en charge de la partie « IDentity/IAM | Azure AD » mets régulièrement à jour cette liste, je vous invite à consulter cette page avant de démarrer vos travaux de conception des droits Azure AD.

 

Les rôles Azure AD fondamentaux 

Les 3 principaux rôles Built-in Azure AD à retenir sont listés dans le tableau :

Rôle AzureAD Autorisations Notes
Administrateur général (Global Administrator) ·       Gestion de l’accès à toutes les fonctionnalités d’administration dans Azure Active Directory, ainsi que les services qui sont fédérés à Azure Active Directory

·       Attribution des rôles d’administrateur à d’autres personnes

·       Réinitialisation des mots de passe des utilisateurs et de tous les autres administrateurs

La personne/utilisateur qui déploie l’annuaire Azure Active Directory est automatiquement déclarée en tant qu’Administrateur général.
Administrateur d’utilisateurs (Users Administrator) ·       Création et gestion de tous les aspects liés aux utilisateurs et aux groupes

·       Gestion des tickets de support

·       Suivi de l’intégrité des services

·       Changement des mots de passe des utilisateurs, des administrateurs du support technique et autres administrateurs d’utilisateurs

Administrateur de facturation (Billing Administrator) ·       Achats

·       Gestion des abonnements Azure

·       Gestion des tickets de support

·       Suivi de l’intégrité des services

 

Gérer l’attribution et la suppression des rôles Azure AD

Pour gérer l’attribution et la suppression des rôles « Azure AD », cherchez et sélectionnez le service « Azure Active Directory », et rendez-vous ensuite sous la Blade « Rôles et Administrateurs »:

  • La liste des rôles Azure AD vous est retournée (à droite)
  • Vous pouvez également voir le rôle Azure AD qui vous est attribué actuellement sur Azure AD:

  • Pour ajouter une attribution de rôle Azure AD, commencez par sélectionner (cliquer) sur le rôle en question (Users Administrator/Administrateurs d’utilisateurs dans l’exemple suivant), et cliquez ensuite sur « Ajouter des affectations« . Dans l’exemple ci-dessous, nous avons ajouté/déclaré l’utilisateur (Hicham KADIRI) en tant que « Users Administrator »:

  • Les affectations de rôles Azure AD peuvent être consultés depuis le rôle Azure AD, ou en sélectionnant un compte utilisateurs et cliquant sur « Rôles affectés » :

  • Pour supprimer une attribution/affectation de rôle Azure AD, il suffit de sélectionner le compte utilisateur, et cliquez sur « Supprimer les attributions« .

 

Les Custom Rôles Azure AD

Comme pour les rôles Azure RBAC, vous avez la possibilité de créer vos propres rôles Azure AD Custom et définir vos droits/autorisations personnalisées.

Les Custom Roles Azure AD sont créés à partir de fichiers JSON aussi, et disposent la même syntaxe/structure que les Custom Roles RBAC.

Si vous voulez en savoir plus sur les Custom Roles Azure AD, je vous recommande la consultation de cette page.

 

En savoir sur sur les rôles Azure Active Directory

Pour en savoir plus sur les rôles Azure AD, je vous invite à consulter cette documentation.

 

Quelle est la différence entre les rôles « Azure RBAC » vs « Azure AD » ? Se chevauchent-ils entre eux ? 

Comme expliqué précédemment, les rôles Azure RBAC sont dédiés à la gestion des droits d’accès au niveau des services /ressources Azure (Compute, Storage, Network…), alors que les rôles Azure AD, sont plutôt dédiés à la gestion des objets Azure AD et des ressources Office 365 associées.

L’image ci-dessous illustre la séparation (Scope) de ces deux types de rôles :

Rôles RBAC Azure versus administrateur Azure AD

 

Note importante [ce qu’il faut retenir !] : les rôles RBAC vous permettent de définir un modèle de déléguation /droit d’accès aux ressources Azure (VM, Compte de Stockage, VNet, Base PaaS SQL, WebApp, Cluster HDI…), les rôles Azure AD quant à eux, vous permettent de définir un modèle de droit d’accès aux objets associés à l’annuaire Azure AD (objets Utilisateurs, Groupes, Apps…). De plus, Azure RBAC contrôle l’accès aux ressources Azure à l’aide d’Azure Resource Management (ARM) alors que les Custom Roles Azure AD contrôlent l’accès aux ressources Azure AD à l’aide de l’API Graph.

 

Ayant des étendues (Scopes) différents, les rôles Azure RBAC et Azure AD ne se chevauchent jamais entre eux.

Les droits attribués via les deux catégories de rôles (RBAC & Azure AD) sont uniques et définis à des scopes distincts (Ressources Azure <> annuaire Azure AD), par conséquent, aucun impact /chevauchement n’a lieu.

 

Licensing Azure RBAC vs Azure AD

Azure RBAC est un service gratuit :), aucune licence n’est requise pour implémenter vos rôles RBAC Built-in et Custom.
En revanche, la création de rôles Custom pour Azure AD, nécessite un niveau de Licensing Azure AD Premium 1 ou 2.

 

Élévation de privilège : From « Azure AD Global Administrator » to « User Access Admin » 

En tant qu’administrateur général (Global Administrator) dans Azure Active Directory (Azure AD), il est possible que vous n’ayez pas accès à tous les abonnements et groupes d’administration de votre annuaire. Cet article décrit les méthodes pour élever votre accès à tous les abonnements et groupes d’administration.

 

Pourquoi devez-vous élever votre accès ?

Si vous êtes Azure AD Global Admin, il peut vous arriver de vouloir effectuer les opérations suivantes :

  • Récupérer l’accès à un abonnement ou groupe d’administration Azure quand un utilisateur a perdu cet accès
  • Accorder à un autre utilisateur ou à vous-même l’accès à un abonnement ou groupe d’administration Azure
  • Voir tous les abonnements ou groupes d’administration Azure au sein d’une organisation
  • Autoriser une application d’automation (telle qu’une application de facturation ou d’audit) à accéder à tous les abonnements ou groupes d’administration Azure

 

Comment fonctionne l’accès avec élévation de privilèges ?

Les ressources Azure AD et Azure sont sécurisées de façon indépendante les unes des autres. Ainsi, les attributions de rôles Azure AD n’accordent pas d’accès aux ressources Azure et inversement, les attributions de rôles Azure n’accordent pas d’accès à Azure AD. En revanche, si vous êtes administrateur général dans Azure AD, vous pouvez vous attribuer à vous-même un accès à tous les abonnements et groupes d’administration Azure de votre annuaire. Utilisez cette fonctionnalité si vous n’avez pas accès aux ressources de l’abonnement Azure, comme les machines virtuelles ou les comptes de stockage, et que vous voulez utiliser vos privilèges d’administrateur général pour accéder à ces ressources.

Quand vous élevez votre accès, le rôle Administrateur de l’accès utilisateur vous est attribué dans Azure au niveau de l’étendue racine (/). Ceci vous permet de voir toutes les ressources et d’attribuer des accès dans n’importe quel abonnement ou groupe d’administration de l’annuaire. Les attributions de rôles Administrateur de l’accès utilisateur peuvent être supprimées à l’aide d’Azure PowerShell, d’Azure CLI ou de l’API REST.

Vous devez supprimer cet accès avec élévation de privilèges après avoir effectué les modifications nécessaires au niveau de l’étendue racine.

 

Comment élever l’accès d’un Global Administrator Azure AD

Suivez les instructions suivantes pour élever les privilèges d’un Compte Global Administrator Azure AD :

#1. Connectez-vous au Portail Azure ou au Centre d’administration Azure Active Directory en tant qu’administrateur général.

#2. Recherchez et sélectionnez Azure Active Directory

#3. Sous Gérer, sélectionnez Propriétés.

#4. Sous Gestion de l’accès pour les ressources Azure (Access management for Azure Resources), sélectionnez « Oui /Yes« :

Quand vous sélectionnez « Oui », le rôle Administrateur de l’accès utilisateur (User Access Administrator) vous est attribué dans Azure RBAC au niveau de la racine (/). Ceci vous accorde l’autorisation d’attribuer des rôles dans tous les abonnements et groupes d’administration Azure associés à cet annuaire Azure AD. Cette option est disponible seulement pour les utilisateurs auxquels le rôle Administrateur général a été attribué dans Azure AD.

Quand cette option est définie sur Non, le rôle Administrateur de l’accès utilisateur dans Azure RBAC est supprimé de votre compte d’utilisateur. Vous n’aurez plus la possibilité de vous attribuer des droits/rôles aux niveaux des abonnements et groupes d’administration Azure associés à votre Azure AD.

 

#5. Cliquez sur Enregistrer pour que la modification soit prise en compte.

Note importante : cette option n’est pas une propriété globale et s’applique uniquement à l’utilisateur connecté. Vous ne pouvez pas élever l’accès des autres utilisateurs Azure AD Global Admin.

 

#6. Déconnectez-vous et reconnectez-vous pour actualiser votre accès.

Vous devez maintenant avoir accès à tous les abonnements (Subscriptions) et à tous les groupes d’administration (Management Groups) de votre annuaire Azure AD.

 

Guide pas à pas sur « Azure RBAC » 

Je suis en train de finaliser un guide assez détaillé (step-by-step) sur le sujet « Azure RBAC ».

Ce guide sera bientôt disponible en téléchargement gratuit sur Slideshare, n’hésitez pas à vous abonner pour rester informé dès sa publication :).

 

Conclusion

La notion de rôles dans Azure est un item important à prendre en considération dans la phase « Design » de tout projet de migration vers Azure ou le déploiement d’infra Cloud Native.

Le modèle RBAC est un composant critique du modèle de gouvernance Global Azure, prenez donc le temps d’étudier le sujet avant de commencer à déployer vos Workloads dans le Cloud.

 

 

J’avais publié dans le passé un post décrivant la matrice d’interopérabilité des Licences TSE/RDS Windows Server 2000 à 2016.

Note : le post est disponible directement depuis ce lien.

 

J’expliquais à travers cet article quand et comment pouvez-vous ré-utiliser vos Licences (CAL) TSE/RDS 2000 à 2016 sur les différentes plateformes Windows Server 2000 à 2016.

Aujourd’hui, je vais partager avec vous la nouvelle Matrice d’interopérabilité des Licences/CAL RDS à partir de 2012 à 2019.
Windows Server 2003 & 2008/2008 R2 étant Obsolètes, nous allons principalement nous focaliser sur les versions d’OS Server pouvant être utilisées en Production.

 

Comme vous le savez, Windows Server 2008 et 2008 R2 ne sont plus supportés depuis le 14 Janvier 2020. Consultez ce post pour en savoir plus.

 

Je vais plus précisément répondre aux questions suivantes :

  • Puis-je réutiliser mes anciennes CAL RDS et les réinstaller sur un nouveau serveur exécutant une version d’OS Windows Server différente à celle du serveur « Source/existant »?
  • Puis-je utiliser mes CAL TSE/RDS existantes pour autoriser mes utilisateurs RDS à se connecter à des serveurs Hôtes de Session (RDSH) exécutant des versions Windows Server différentes ?

 

Ma réponse sera « Splitée » en deux parties :

  • Compatibilité des CAL TSE/RDS pour les serveurs de Licence RDS (RDLS)
  • Comptabilité des CAL TSE/RDS pour les serveurs Hôte de Session (RDSH)

 

Note importante : les informations détaillées ci-dessous s’applique à vos serveurs de Licence RDS et RDSH hébergés OnPrem mais aussi ceux qui tournent sous forme de VM IaaS Azure (ou AWS, GCP, AliBabaCloud…Etc)

 

#R1 : Compatibilité des CAL RDS avec les serveurs de Licences RDS (RD Licensing Server)

Le tableau ci-dessous vous montre les CAL RDS pouvant être installées/utilisées sur chaque version d’OS Windows Server hébergeant le service de Licensing RDS (RDLS : Remote Desktop Licensing Server) :

 

#R2 : Compatibilité des CAL RDS avec les serveurs Hôtes de Session RDS (RD Session Host Server)

Le tableau ci-dessous vous montre les CAL RDS pouvant être installées/utilisées pour autoriser vos utilisateurs distants à se connecter aux serveurs RDSH en fonction de la version d’OS Windows Server qui exécutent :

Ce qu’il faut retenir

Vous ne pouvez pas utiliser vos anciennes CAL RDS pour accéder aux nouvelles versions de Windows Server (RD Session Server), mais vous pouvez utiliser des nouvelles CAL RDS pour accéder aux anciennes versions de Windows Server (RD Session Host). Les serveurs de licences RDS peuvent héberger toutes les CAL RDS ayant la même version de l’OS qu’il exécute ou ultérieur (eg : un RD Licensing Server 2016 peut héberger des CAL RDS 2016 et 2019).

Pour vous aider à mieux comprendre le tableau, je vous détaillerai un vrai « Use Case »:

Supposons qu’un Client (Société) X dispose déjà d’un Pack de Licences RDS 2012 R2 et est sur le point de dé-commissionner son infrastructure RDS 2012 R2 pour en déployer une nouvelle sous 2016 ou 2019. Comme indiqué dans le tableau ci-dessus, les CAL « RDS 2012 R2 » peuvent être installées sur les OS Windows Server suivants : 2012, 2012 R2, 2016 et 2019. Cette société pourra donc continuer à utiliser (en réinstallant) les Licences RDS 2012 R2 sur tout futur serveur de Licence RDS exécutant Windows Server 2012 R2 à 2019.

Cette même société souhaite savoir s’elle peut réutiliser ses licences RDS 2012 R2 pour permettre l’accès à des hôtes de session RDSH 2016 ou 2019, comme indiqué dans le tableau ci-haut, les CAL RDS 2012 R2 ne permettent l’accès qu’à des RDSH Servers exécutant la même versions que les CAL ou antérieur, donc des hôtes de sessions sous Windows Server 2012 R2, 2012, 2008 R2 ou 2008.

 

Référence documentation

Pour en savoir plus sur le Licensing RDS et la compatibilité des CAL RDS entre les différentes versions d’OS Windows Server, je vous invite à consulter la documentation officielle Microsoft disponible directement depuis ce lien.

A bientôt, et soyez forts pendant cette crise sanitaire (covid-19), tout va rapidement rentrer dans l’ordre :).

#ProtegezVous #RestezVous #SoyezForts

 

Introduction 

Microsoft vient de lancer un programme d’expérimentation pour son nouveau service d’impression Cloud appelé ‘Azure Universal Print’

Universal Print est un nouveau service cloud qui centralise sur Azure la gestion des systèmes d’impression.

 

Note importante : Pour participer à cette expérimentation, vous devez vous inscrire sur la Private Preview « Universal Print » (via ce Formulaire), notez que vous devez impliquer au moins 20 users/collaborateurs.

 

Universal Print est accessible dans le cadre des licences Microsoft 365 Entreprise et Éducation. Il s’appuie sur Azure Active Directory pour la gestion d’identité et d’accès.

Microsoft travaille en étroite collaboration avec des fournisseurs d’imprimantes (tel que Canon) pour garantir une compatibilité native avec son nouveau service Cloud.

En attendant, l’utilisation de Universal Print nécessite l’installation un connecteur (agent), qu’est disponible au moment de la rédaction du présent post que pour Windows 10 et Windows Server 2016 et 2019.

 

Universal Print : Console d’Administration

La console Universal Print ressemble à ceci :

up1.png

Vous pouvez reporter vos feedbacks /remarques /incidents directement depuis les liens disponibles depuis l’onglet « Getting started« .

Sous « Manage« , vous avez la possibilité de déployer et suivre l’install de vos connecteurs (agents) mais aussi déployer (inscrire) ou supprimer (désinscrire) vos imprimantes (Printers), depuis le volet « Printers », vous pouvez également checker le statut de vos imprimantes déployées prête(ready), arrêtée (stopped)…

 

Ce qu’il faut retenir 

Azure Universal Print vous offre la possibilité de déployer des imprimantes et les inscrire (Register) au niveau de ce service d’impression Cloud sans avoir besoin de déployer des infrastructures/services d’impression complexe et difficile à gérer/exploiter.

Les imprimantes inscrites dans Universal Print peuvent être facilement préconfigureés et détectées par vos Devices (Machines) Windows joints au domaine Azure Active Directory.

Vos utilisateurs (Azure) pourront ainsi imprimer depuis leurs devices Windows ou Apps Office de manière transparente.

Universal Print pourra désormais remplacer vos serveurs d’impression OnPrem, en effet, Universal Print déplace les principales fonctionnalités d’impression de Windows Server vers le Cloud « Azure /O365 », vous n’avez plus besoin de déployer et gérer des serveurs d’impression Windows OnPrem, il n’y a plus besoin non plus d’installer et maintenir à jour des pilotes d’imprimante sur vos devices Windows. De plus, Universal Print ajoute des nouvelles fonctionnalités clés telles que des groupes de sécurité pour l’accès à l’imprimante, la découverte d’imprimante basée sur l’emplacement et une riche expérience d’administrateur.

 

Participer au programme d’expérimentation & Joindre la Tech Community Universal Print

Pour participer au programme d’expérimentation d’Universal Print lancée par Microsoft, remplissez ce formulaire

Pour joindre la Communauté technique Universal Print, rendez-vous sur ce lien.

Quelques liens utiles

Je vous ai regroupé ici quelques liens utiles pour bien démarrer avec Azure Universal Print

Documentation officielle sur Universal Print

Prise en main d’Universal Print

Installation des connecteurs Universal Print

 

My feedbacks

Je suis en train d’expérimenter Universal Print avec mes équipes (K&K Group), je partagerai avec vous mon feedback d’ici quelques semaines.

Stay connected 🙂 !

 

Microsoft a abandonné cette semaine son free tool RDCMan (Remote Desktop Connection Manager suite à la découverte d’une faille de sécurité.

Le lien de téléchargement de RDCMan affiche désormais le message suivant :

Ce téléchargement n’est plus disponible !

Pour rappel, RDCMan vous permet d’établir plusieurs connexions Bureau à distance (Remote Desktop) depuis une console centrale.

Il permet également d’organiser les Connexions Remote Desktop via des groupes (catégories) et surveiller le statut de chaque connexion : Connectée, Déconnectée, Fermée…

L’outil s’appuie sur le protocole RDP (Remote Desktop Protocol), fourni nativement avec les plateformes/OS Windows Client & Server.

RDCMan a été développé par l’équipe Windows Live Experience de Microsoft pour un usage interne seulement. Il a ensuite été proposé publiquement à la fin des années 2000.

L’outil a connu un grand succès auprès des IT Admin dans les années 2000 et 2010.

MS l’a toujours maintenu à jour jusqu’à 2014, la dernière version stable proposée par l’éditeur est la 2.7

 

Suppression de RDCMan avec le Security Patch de Mars 2020 !

Avec la publication du patch de Mars 2020, la suppression officielle de RDCMan a été prononcée. Microsoft a déclaré avoir reçu un rapport sur un nouveau Bug dans RDCMan qui pourrait permettre à un Hacker de récupérer des données sur la machine qui héberge et exécute RDCMan.

 

RDCMan : quelle faille de sécurité ?!

Microsoft a déclaré dans un avis de sécurité (CVE-2020-0765)

< Pour exploiter la vulnérabilité, un attaquant pourrait créer un fichier RDG contenant un contenu XML spécialement conçu et convaincre un utilisateur authentifié d’ouvrir le fichier >

 

Au lieu de corriger la faille, Microsoft a décidé de mettre RDCMan à la retraite, ne voyant aucune raison de faire revivre une application qui a reçu sa dernière mise à jour il y a près de six ans. Les utilisateurs qui continuent à utiliser l’application doivent savoir qu’ils ne doivent pas ouvrir les fichiers RDCMan connection configuration (RDG) qu’ils reçoivent de manière non sollicitée ou de sources inconnues.

 

Note importante : il est recommandé de remplacer RDCMan par un autre Remote Desktop Manager, la faille est critique, et pourrait être une porte d’entrée à un Hacker à votre S.I

Pensez « Security First » 🙂

A bientôt :).