Ce titre pourrait annoncer un nouveau film avec une vague de super héros, mais il n’en est rien !
L’intention de ce bulletin est d’expliquer brièvement ce qu’est AzMan et comment l’utiliser pour mettre en oeuvre de la délégation d’administration sur un serveur hébergeant le rôle Hyper-V.
AzMan
Hyper-V est désormais bien connu mais AzMan reste un peu dans l’ombre. De son vrai nom Windows Authorization Manager, AzMan est un framework de gestion des accès basé sur la notion de rôles (ou role-based access control, soit RBAC) qui permet de mettre à disposition des applications des stratégies auxquelles elles peuvent se référer pour contrôler ce que chaque utilisateur a la permission de faire.
Ce framework doit donc être pris en compte lors du développement de ces applications.
Je ne m’étendrais pas sur AzMan car cela ne fait pas parti de mes compétences au sein de l’équipe Windows Core mais il est nécessaire de détailler les quelques notions de base utilisées dans la suite de ce bulletin :
Comment attribuer des permissions sur Hyper-V
L’objectif ici est donc de détailler toutes les étapes nécessaires pour donner à certains utilisateurs la possibilité de travailler avec certaines machines virtuelles s’exécutant sur un hôte Hyper-V.
Avant de manipuler l’authorization store de Hyper-V, quelques pré-requis doivent être mis en oeuvre pour autoriser l’accès à distance de l’hôte Hyper-V :
Pour référence, voici la liste des opérations qui peuvent être déléguées à des utilisateurs dans Hyper-V :
Pour la partie réseau, ces deux schémas seront peut-être plus explicites pour décrire a quoi correspondent les différents composants :
Démarche
Je vais prendre l’exemple suivant : un administrateur Hyper-V souhaite déléguer la création et l’administration des machines virtuelles à un groupe d’utilisateurs (groupe Hyper-V Admins) et autoriser un autre groupe de personnes à utiliser ces machines virtuelles (groupe Hyper-V Users).
La démarche consiste donc à créer dans cette ordre depuis AzMan :
Pour simplifier la compréhension, j’utilise une terminologie spécifique pour chaque type d’élément créé en préfixant chacun de ces éléments :
Création des définitions de tâches
L’adresse suivante donne un grand nombre d’exemples de tâches correspondants à des scénarios de délégation : Example Authorization Manager Tasks and Operations
Il s’agit tout d’abord d’ouvrir l’authorization store de Hyper-V :
Note : si SCVMM est utilisé pour gérer l’hôte Hyper-V, les modifications apportées au fichier InitialStore.xml ne seront pas prises en compte. SCVMM permet de déléguer l’accès à un hôte Hyper-V via son propre fichier (HyperVAuthStore.xml). La modification de ce fichier n’est pas supportée.
La première définition de tâche que je vais créer permettra de donner l’accès à la console Hyper-V (visualisation des machines virtuelles) :
La seconde définition de tâche que je vais créer permettra de donner les permissions suffisantes pour gérer les machines virtuelles :
La dernière définition de tâche que je vais créer permettra de donner les permissions suffisantes pour utiliser les machines virtuelles sans pouvoir modifier leur configuration :
Au final, j’ai donc la liste suivante de définitions de tâches :
Création des définitions de rôle
Depuis AzMan :
Au final, j’ai donc la liste suivante de définitions de rôles :
Il faut maintenant attribuer à chaque définition de rôle les permissions adéquates :
Assignation des rôles
Si nous suivons les best practices Microsoft, l’attribution définitive des permissions sur l’hôte Hyper-V se fera par des groupes Active Directory (à la rigueur à travers les groupes locaux de l’hôte Hyper-V).
Je reprends donc la nomenclature AD-Hyper-V Admins et AD-Hyper-V Users pour créer mes deux groupes dans Active Directory.
Ensuite, depuis AzMan, je vais créer des groupes “application” dans l’authorization store incluant ces groupes Active Directory :
Je vais ensuite lier les groupes Active Directory avec les groupes applicatifs :
Au final, j’ai donc les groupes applicatifs suivants :
Cette étape n’est pas nécessaire mais elle permet de définir une seule fois dans l’authorization store le relation entre les groupes Active Directory et des groupes propres à ce store.
Il s’agit enfin d’attribuer à ces groupes applicatifs la délégation créée au travers des définitions de rôles et de tâches.
Depuis AzMan, je vais créer des assignations de rôles dans l’authorization store :
Jusque là, ces assignations de rôles ne sont définies que par les opérations qui leur sont autorisées et ne définissent pas encore quels utilisateurs peuvent en bénéficier. Il faut donc lier ces assignations de rôles aux groupes applicatifs.
Ce qui me donne en définitive ceci :
Scopes
La seule notion que je n’ai pas encore abordé sont les scopes.
Un scope définit un périmètre au sein d’un authorization store sur lequel s’appliquent des définitions de rôles et de tâches ainsi que des assignations de rôles.
Il est ainsi possible de définir plusieurs scopes (Maquettage, Pré-Production, Production, …) disposant de leur propre délégation. Ceci permet d’affiner encore plus la délégation en attribuant des permissions à un groupe de machines virtuelles et non à toutes.
Des exemples de scripts permettant de mainpuler les scopes sont disponibles ici : Script AzMan Scopes in Hyper-V
Ressources
Windows Authorization Manager (en Anglais)
Developing Applications Using Windows Authorization Manager (en Anglais)
Authorization Manager Terminology (en Anglais)
Configure Hyper-V for Role-based Access Control (en Anglais)
Virtualization Security Best Practices – How to Lockdown a Hyper-V Host (blog de Tony Soper en Anglais)
Hyper-V Security Getting Started Guide (blog de Tony Soper en Anglais)
Guillaume
Windows Core Support Escalation Engineer
PingBack from http://jeanphilippeklein.wordpress.com/2009/04/02/la-gestion-de-la-dlgation-dadministration-de-machine-virtuelle-au-sein-dun-cluster-hyper-v/
Suite au bulletin traitant du sujet , Jean-Philippe a élevé un peu le débat en abordant les aspects d’un