Un peu long comme titre, mais j’ai eu du mal à faire mieux en restant clair. Et encore “clair” n’est pas forcément le terme le plus approprié.
En bref, il s’agit la de discuter de la possibilité de déléguer l’administration de machines virtuelles hébergées au sein d’un cluster Hyper-V.
Ainsi, dans le cadre d’un host classique, c’est à dire un serveur Hyper-V seul, hébergeant quelques VMs, la délégation de l’administration se fera via l’outil “Authorization Manager” (azman.msc).
Mise en place d’un Authorization Store classique
A ce sujet, je vous recommande de lire avec attention l’excellent billet (comme toujours) de Guillaume, de l’équipe de support Core ici qui détaille comment gérer l’accès aux VMs via des groupes AD.
Une fois les concepts d’opérations, tâches, rôles, groupes et autres assignations assimilés, il apparait que la gestion des droits est donc basé sur un fichier stocké localement.
Ainsi, imaginons un utilisateur admhv01 a qui je fournirais les droits pour accéder au serveur hyperv01, et gérer l’ensemble des VMs hébergés par ce serveur.
Dans le cas d’un cluster ?
Construisons ensuite un Failover Cluster en utilisant ce serveur comme premier nœud, et déclarons les machines virtuelles en tant qu’application afin de pouvoir les basculer.
Basculons ensuite les VMs vers le second noeud. L’utilisatateur admhv01 n’a donc plus accès aux VMs puisqu’il n’a pas les droits de se connecter au second nœud. (L’Authorization Store ayant été configuré sur le 1er nœud)
Pour adresser facilement cette problématique, il suffirait de copier le fichier d’autorisations (par défaut: c:programdataMicrosoftwindowsHyper-VInitialStore.xml) sur le second noeud du cluster. Mais cela implique une mise à jour manuelle (certes scriptable), du fichier à chaque modification.
Partant de ce constat, quelle est la recommandation ? N’ayant pas trouvé grand chose sur le sujet voici mon raisonnement:
Les 3 modes de stockage de l’Authorization Store:
L’Authorization Store peut être stocké dans un fichier XML local, dans l’AD, et dans une base SQL : http://technet.microsoft.com/en-us/library/dd283004.aspx
“Both Hyper-V and Authorization Manager support XML files and Active Directory Domain Services for storing a policy. However, Authorization Manager stores for other applications can be created in Active Directory Lightweight Directory Services and Microsoft SQL Server (new for Windows Vista and Windows Server 2008).”
Dans le cas d’Hyper-V, le stockage au sein d’une base SQL n’est pas supporté.
Il nous reste l’AD ou le fichier XML. Dans le cas du fichier, je n’ai pas su le mettre à disposition via un partage (le “msxml://\serversharefichier.xml” provoquait une erreur 3 au redémarrage du service.) Il reste l’hypothèse de le stocker sur un disque partagé au sein du cluster, dont les VMs dépendent, mais je rencontre la problématique du “Shared Nothing” propre au cluster: Une ressource ne peut être accéder à un instant T que par un seul nœud d’un cluster. Donc si mon cluster est en mode actif/actif, l’un des nœuds ne peut avoir accès à l’Authorization Store.
Tout ca pour en arriver à la dernière possibilité, l’AD ! Vous me direz, c’est logique, s’il faut centraliser les ressources et l’administration, l’AD est faite pour ca…
Ok, dans l’AD, mais comment ca marche ?
Il est absolument nécessaire d’avoir bien compris le billet de Guillaume cité plus haut !
Voici les points importants de la configuration de mon Lab:
J’utiliserais les Scopes selon le principe suivant: 1 scope par VM, et 1 groupe d’administrateur par VM.
Les machines:
- JPKSRVPHY01 : Nœud 1 du cluster Hyper-V
- JPKSRVPHY02 : Nœud 1 du cluster Hyper-V
- CLUSTERED VM 01 : Machine virtuelle administré par admhv01
- CLUSTERED VM 02 : Machine virtuelle administré par admhv02
Les groupes AD:
- HyperV Administrators : Administrateurs de tous les serveurs hyper-v et VMs
- HypevV Management : Autorisel’accès distant au serveur via la console.
- HyperV Mgmt VM01 : Administrateurs de la VM 01
- HyperV Mgmt VM02 : Administrateurs de la VM 02
Les utilisateurs AD:
- administrator : Le super admin
- admhv01 : Membre de “HyperV Mgmt VM01”
- admhv02 : Membre de “HyperV Mgmt VM02”
Création de l’Authorization Store dans l’AD
La création d’un scope se fait via AzMan.msc. Il est nécessaire de passer la console MMC en mode développeur pour accéder à l’option “New Authorization Store”. Voici la config sur mon Lab :
Une fois le Store créé, passons à l’application “Hyper-V Services” en cliquant droit sur le store puis “New Application” :
Nous avons donc alors un Authorization Store presque identique au fichier XML local :
Il nous reste à le configurer. Encore une fois, je n’aborderais pas la mise en place des permissions dans ce billet. Je créé ensuite 2 Scopes “ScopeVM01” et “ScopeVM02” au sein de nouvel Authorization Store :
Et j’affecte les VMs aux Scopes grâce aux scripts mis à disposition par Tony Soper ici : http://social.technet.microsoft.com/Forums/en-US/ITCG/thread/3d0888e2-7538-4578-b16c-97b73c8e0f96/
La configuration finale est la suivante:
Ainsi, tout serveur pointant vers cet Authorization Store appliquera les permissions suivantes:
- Autorise les administrateurs de domaine à gérer l’ensemble des VMs présentes sur ce serveur.
- Autorise l’accès aux VMs incluses dans le ScopeVM01 pour le groupe HyperV Mgmt VM01
- Autorise l’accès aux VMs incluses dans le ScopeVM02 pour le groupe HyperV Mgmt VM02
Point important, il faut permettre l’accès en lecture aux ordinateurs du domaine (ou spécifiquement aux nœuds du cluster), via les propriétés de l’Authorization Store:
Tout est prêt, nous avons positionné via GPO les autorisations suivantes sur les 2 noeuds: Ajout des administrateurs du serveurs au groupe “Distributed Com Users” et ajout des droits au sein des classes rootCIMV2 et rootVirtualization (encore une fois, si vous ne l’avez pas fait, c’est ici.
Il reste à faire pointer les serveurs vers notre nouvel Authorization Store via la clé de registre suivante…
Path=HKLMSoftwareMicrosoftWindows NTCurrentVersionVirtualization
Name=StoreLocation
Type=REG_SZ
Value=msldap://CN=VmAzStore,CN=Microsoft,CN=Program Data,DC=test,DC=com
… et à redémarrer les services VMMS et NVSPWMI.
La délégation est en place !
Quelques références sur le sujet:
AzMan et Hyper-V, ou comment déléguer l’accès aux machines virtuelles: http://blogs.technet.com/windowsinternals/archive/2009/01/02/azman-et-hyper-v-ou-comment-d-l-guer-l-acc-s-aux-machines-virtuelles.aspx
Script AzMan Scopes in Hyper-V : http://social.technet.microsoft.com/Forums/en-US/ITCG/thread/3d0888e2-7538-4578-b16c-97b73c8e0f96/
Delegate permissions to specific VM in Hyper-V hosts: http://alipka.wordpress.com/2009/02/10/delegate-permissions-to-specific-vm-in-hyper-v-hosts/
Votre console Hyper-V est dispo sur votre machine Windows 7 !
A noter également la ré-apparition de la console “Remote Desktops”, avec le support du NLA dans ces outils :
.gif)
![clip_image001[4]](http://jeanphilippeklein.files.wordpress.com/2009/01/clip-image0014.png "clip_image001[4]")
![clip_image001[7]](http://jeanphilippeklein.files.wordpress.com/2009/01/clip-image0017.png "clip_image001[7]")
![clip_image001[3]](http://jeanphilippeklein.files.wordpress.com/2009/01/clip-image0013.png "clip_image001[3]")
