Использование Authorization Manager для делегирования полномочий на виртуальные машины в среде Hyper-V

Если вы хоть раз разворачивали среду виртуализации на базе Windows 2008 R2 Hyper-V, вы знаете, что по умолчанию в среде Hyper-V любой администратор на сервере Hyper-V обладает полным доступом к виртуальным машинам и узлу Hyper-V.

Сегодня мы поговорим о том, как разделить полномочия пользователей в среде Hyper-V, делегировать права на управление виртуальными машинами пользователям, не обладающими правами администратора сервера. Поговорим о том, как формировать области, настраивать задачи и роли, рассмотрим детально, как задаются правила доступа к виртуальным машинам.

В этой статье мы рассмотрим следующие темы:

· Что такое Authorization Manager;

· Терминология Authorization Manager;

· Делегирование средствами Authorization Manager;

Authorization Manager, как компонента появился в версии Windows Server 2003, по сути, эта компонента была первым источником хранения информации доступа к различным объектам, позволяет реализовать ролевую систему доступа к виртуальным машинам. (Управление на основе ролей). Управление доступом на основе ролей, представляет собой модель авторизации при которой, вся модель строится вокруг учетной записи пользователя, такая модель обеспечивается на основе объекта — роль, назначаемую пользователю для выполнения конкретной функции. Роль, явно подразумевает набор разрешений для доступа к некоему набору ресурсов.

При управлении доступом на основе ролей разрешения выдаются по средствам высокоуровневых абстракций, соответствующих операциям и заданиям приложения. Операции являются неделимыми единицами, тогда как задания могут состоять из нескольких операций (и других заданий).

Что понимается под — делегированием управления виртуальными машинами

Делегирование управлением виртуальными машинами это процесс выделения диапазона административных задач для определенных пользователей или групп на управление определенной областью.

Например: можно выделить основные задачи администрирования виртуальных машин и передать администрирование членам определенных групп в Active Directory .

Терминология в контексте Authorization Manager

Как мы уже отметили ранее, Authorization Manager используется для предоставления функций управления доступом на основе ролей для Hyper-V.

Давайте в начале, рассмотрим терминологию, применяемую в Authorization Manager:

Authorization Manager включает в себя следующие компоненты:

• Оснастка Authorization Manager (файл AzMan.msc). Оснастка консоли управления (MMC) используется для выбора операций, группирования их в задачи, а затем для авторизации ролей с целью выполнения конкретных задач. Она также используется для управления задачами, операциями, ролями пользователей и разрешениями. Для использования оснастки нужно сначала создать или открыть существующие хранилище данных авторизации.
• Программный интерфейс (API) Authorization Manager . API предоставляет упрощенную модель разработки для управления гибкими группами, бизнес-правилами и политиками хранилищ данных авторизации.

Authorization Manager требуется хранилище данных для политики, в котором были бы объединены роли, учетные записи пользователей и права доступа. Такое хранилище называется хранилищем данных авторизации. В Hyper-V это хранилище данных может поддерживаться в базе данных Active Directory или в XML-файле на локальном сервере, где выполняется роль Hyper-V. Хранилище можно изменять через оснастку диспетчера авторизации или через API Authorization Manager, которые доступны в языках сценариев, таких как VBScript.

Если в качестве хранилища данных авторизации используется база данных Active Directory, доменные службы Active Directory должны находиться в режиме работы Windows Server 2003.

В контексте диспетчера авторизации используется следующая терминология.

Операция.

Разрешение нижнего уровня в приложении. Операции являются своеобразными строительными блоками политики для управления доступом на основе ролей. Например, в Hyper-V такие действия, как «Разрешить запуск виртуальной машины», «Разрешить остановку виртуальной машины», «Создать виртуальную машину», являются операциями.

Политика.

Данные, которые Authorization Manager использует для управления доступом на основе ролей. Эти данные, настраиваются администратором виртуальных машин, описывают отношения между ролями, задачами и операциями. Политика представляет собой XML-файл, который можно изменять с помощью оснастки Authorization Manager или инструментов для работы со сценариями.

Роль.

Набор пользователей и/или групп, который определяет категорию пользователей, которые могут выполнять набор задач или операций. Например, пользователи, которым назначена роль администратора, по умолчанию имеют возможность выполнять любую задачу или операцию в на Hyper-V узле. Администратор может создать любое число других ролей.

Область.

Набор ресурсов с общей политикой управления доступом. В Authorization manager областью может быть папка, контейнер Active Directory. Объекту может быть назначена только одна область. Объект, которому не назначена область, использует политику управления доступом, определенную в области приложений Authorization Manager или в корневой области. Областью по умолчанию является область Службы Hyper-V.

Например, чтобы предоставить конкретному пользователю или группе права администратора для доступа к виртуальным машинам, создайте область для этих виртуальных машин и поместите виртуальные машины в область.

Задача.

Логическая группа операций для выполнения задачи. Задачи могут быть разбиты на категории по объектам и могут быть использованы для управления доступом к объекту.

Важное замечание:

При добавлении задач к определению роли, проверки для зависимых операций не выполняются. Например, для задачи «Подключение к виртуальной машине» требуются операции «Прочесть конфигурацию службы», «Разрешить вывод из виртуальной машины» и «Разрешить ввод в виртуальную машину».

Администратор Hyper-V. Администратор, имеющий права локального администратора в операционной системе управления сервером виртуализации и управляющий правами и разрешениями всех других делегированных администраторов.

Администратор виртуальных машин, имеет права только на выполнение задач, указанных в описании роли. На более высоком организационном уровне Администратор сервера Hyper-V создает и поддерживает определения ролей и области. Например, администратор Hyper-V может создать роль «Администратора виртуальных машин службы HR», который имеет доступ только к виртуальным машинам, принадлежащим отделу кадров, и другую роль (с теми же операциями и задачами), например «Финансовый администратор», для доступа только к виртуальным машинам, принадлежащим отделу финансов.

Определение роли. Список операций, которые пользователь может выполнять с помощью назначенной роли.

Назначение роли. Список пользователей, которые могут выполнять операции, перечисленные в определении роли. Например, определение по умолчанию для роли администратора включает все операции, а используемое по умолчание назначение роли распространяется на всех пользователей в группе BUILTIN\Administrators. Можно создать роль «Пользователь», которая может использовать только операции «Запустить виртуальную машину», «Остановить виртуальную машину». Можно также создать роли, основанные на организационных структурах. Например, можно создать роль «Администратор виртуальной сети» и назначить этой роли операции только для виртуальной сети.

Хранилище данных Authorization manager

Репозиторий для политики авторизации. Необходимо создать хранилище для управления доступом к ресурсам — это можно сделать либо программно, либо с помощью оснастки. По умолчанию хранилищем в Hyper-V является XML-файл, находящийся в расположении \ProgramData\Microsoft\Windows\Hyper-V\InitialStore.xml.

В среде Hyper-V, Authorization Manager поддерживают возможность хранения политики как XML-файлах так и в в Active Directory.

Режимы Authorization manager

В компоненте «Authorization Manager » можно использовать следующие режимы.

Рисунок 1 Режимы работы Authorization Manager

Режим разработчика. Используется для создания, разворачивания и поддержки приложений. При этом доступ ко всем возможностям компоненты «Authorization Manager» открыт.

Режим администратора. Этот режим включен по умолчанию. Используется для разворачивания и поддержки приложений. Открыт доступ ко всем возможностям компоненты «Authorization Manager», за исключением создания новых приложений или определения операций.

Приложения, поддерживающие роли в нашем случае Hyper-V, автоматически создают хранилище данных авторизации или используют существующее хранилище с уже определенными операциями и задачами. В этом случае нет необходимости в применении режима разработчика. При этом после установки Hyper-V и подключения к базе данных можно увидеть, что уже существует ряд предопределенных операций.

Режим разработчика рекомендуется использовать только для создания и настройки хранилищ данных авторизации, приложений и других необходимых объектов.

Контрольный список для подготовки к запуску компонента «Authorization Manager»

• Ознакомьтесь с основными понятиями безопасности Authorization Manager . http://technet.microsoft.com/ru-ru/library/cc785357 (WS.10).aspx
• Ознакомьтесь с похожими служебными программами, такими как мастер делегирования управления. http://technet.microsoft.com/ru-ru/library/cc782496 (WS.10).aspx
• Прочтите сведения общего характера о компоненте «Authorization Manager ».
• Прочтите о разнице между режимом администратора и режимом разработчика компонента «Authorization Manager».
• Прочтите сведения о хранилищах данных авторизации и приложениях, а также о разнице между хранилищами данных авторизации, размещенными в файлах XML и размещенными в Active Directory.http://technet.microsoft.com/ru-ru/library/cc758696 (WS.10).aspx
• Перед использованием компонента «Authorization manager» для хранилищ данных авторизации в Active Directory необходимо повысить функциональный уровень домена Active Directory до Windows Server 2003 .http://technet.microsoft.com/ru-ru/library/cc776703 (WS.10).aspx
• Запуск компоненты Authorization Manager http://technet.microsoft.com/ru-ru/library/cc787668 (WS.10).aspx

И так, с терминами подразобрались, давайте приступим к настройке нашей среды и делегированию прав. Допустим в нашей организации есть сервер c установленной ролью Hyper-V на котором мы развернули несколько виртуальных машин.

Srv-Vm01 – Файловый сервер компании;

Srv-VM02- Сервер приложений Бухгалтерии;

Srv-Vm03 – Сервер Баз данных HR;

Рисунок 2 Консоль Hyper-V Manager

Рисунок 3 Тестовая среда

Файловым сервером (Srv-Vm01) должен управлять администратор, который отвечает за общие ресурсы в компании. При этом он должен иметь разрешение на следующие операции с файловым сервером Запуск, Остановка, Перезагрузка, Конфигурация. Для администратора создана учетная запись User00 и группа безопасности, в Active Directory с именем VM-Resource Server Administrators Role членом которой, является учетная запись User00.

Сервером приложений (Srv-Vm02) должен управлять администратор от разработчиков. При этом он должен иметь разрешение на следующие операции с сервером приложений Запуск, Остановка, Перезагрузка. Для администратора создана учетная запись User01 и группа безопасности, в Active Directory с именем VM-Application Server Administrators Role членом которой, является учетная запись User01.

Сервером баз данных HR (Srv-Vm03) должен управлять администратор от сторонней организации с которой заключен договор на обслуживание . При этом он должен иметь разрешение на следующие операции с сервером приложений Запуск, Остановка, Перезагрузка, Конфигурация оборудования. Для администратора создана учетная запись User02 и группа безопасности, в Active Directory с именем VM-HR Servers Administrators Role членом которой, является учетная запись User02.

Если оглянуться и посмотреть на предыдущие продукты виртуализации Virtual Server 2005 то можно видеть, что единственным способом предоставления доступа к ограниченному набору виртуальных машин являлось использование NTFS ограничений на конфигурационные файлы, так чтобы пользователи могли работать, лишь с теми виртуальными машинами, на которые им прописаны права на NTFS. С появлением Hyper-V все изменилось в лучшую сторону — модель, используемая в Hyper-V, позволяет настраивать делегирование управлением виртуальными машинами более гибко.

Настройка сервера:

Начнем делегирование прав с того, что выполним ряд настроек на сервере Hyper-V.

Разрешаем  в Windows Firewall правило «Windows Management Instrumentation (WMI) » следующей командой:

netsh advfirewall firewall set rule group=“Windows Management Instrumentation (WMI) ” new enable=yes

Рисунок 4 Настройка правил межсетевого экрана

Предоставление прав на удаленный запуск:

Далее нужно предоставить пользователю права на удаленный запуск (remote launch and activation) в DCOM. Это можно сделать как для конкретного пользователя, или группы, так и для всех AUTHENTICATED USERS, мы сделаем это для наших групп безопасности. Для этого заходим по RDP на сервер Hyper-V и в командной строке выполняем

net localgroup “Distributed COM Users” /add \

где  — домен, к которому относится учетная запись пользователя, а  — учетная запись, к которой нужно предоставить удаленный доступ.

В принципе эту процедуру можно выполнить и через графический интерфейс. Идем на любой сервер Windows 2008 в домене с графическим интерфейсом и выполняем, StartàRunàmmcàAddàComputer ManagementàAnother ComputeràУказываем имя сервера Hyper-V (в нашем случае это HV03.sep.local). Далее нажимаем Finish и Ок.

Выбираем Local Users and Groups—>Groups—> Distributed COM Users—>Add to group и добавляем в эту группу созданные ранее группы безопасности. Выбираем

• VM-Resource Server Administrators Role;
• VM-Application Server Administrators Role;
• VM-HR Servers Administrators Role;

Рисунок 5 Добавление в группу

Предоставление прав на удаленное управление в пространстве имен:

Далее нужно предоставить пользователю права на удаленное управление (remote enable) в пространстве имен (namespace) root\CIMv2 и root\virtualization. Это можно сделать как для конкретного пользователя или группы, или для AUTHENTICATED USERS. Мы сделаем это для наших групп. Идем на любой сервер Windows 2008 в домене с графическим интерфейсом и выполняем,

StartàRunàmmcàAddàComputer ManagementàAnother ComputeràУказываем имя сервера Hyper-V (в нашем случае это HV03.sep.local). Далее нажимаем Finish и Ок.

Рисунок 6 использование Computer Management для удаленного подключения

Разворачиваем меню, выбираем Computer Management (HV03.sep.local) —>Services and Remote Access—>WMI Control—>Properties.

Рисунок 7 Свойства WMI Control для удаленного сервера

Переходим на вкладку Security—>Разворачиваем корень Root—>Выбираем CIMV2—>Нажимаем кнопку Security.

Рисунок 8 Установка прав на CIMV2

Выбираем Add и добавляем группы безопасности, которые мы создали ранее в AD.

• VM-Resource Server Administrators Role;
• VM-Application Server Administrators Role;
• VM-HR Servers Administrators Role;

Рисунок 9 Установка разрешений

Нажимаем кнопку Advandcedàгруппы безопасности и для каждой присваиваем следующие разрешения. В разделе Apply to: выбираем This namecpace and subnamecpaces, отмечаем чекбоксы Aallow—Enable Account и Allow—Remote Enable.

Рисунок 10 Установка разрешений на пространство CIMV2

Такие же действия необходимо выполнить для раздела ROOT\virtualization. Для этого переходим на вкладку Security—>Разворачиваем корень Root—>Выбираем Virtualization —>Нажимаем кнопку Security.

Рисунок 11 Установка прав на Virtualization

Выбираем Add и добавляем группы безопасности, которые мы создали ранее в AD.

• VM-Resource Server Administrators Role;
• VM-Application Server Administrators Role;
• VM-HR Servers Administrators Role;

Рисунок 12 Установка разрешений на пространство Virtualization

Закрываем оснастку и перезагружаем сервер Hyper-V для применения настроек.

Делегирование прав:

После перезагрузки сервера Hyper-V идем на рабочую станцию администратора открываем оснастку Authorization Manager StartàRunàmmcàAdd

Рисунок 13 Добавление оснастки AzMan

Оснастка AzMan консоли управления (MMC) используется для выбора операций, группирования их в задачи, а затем для авторизации ролей с целью выполнения конкретных задач. Она также используется для управления задачами, операциями, ролями пользователей и разрешениями.

Рисунок 14 Добавление оснастки AzMan

Для использования оснастки нужно открыть существующее хранилище InitialStore.xml на сервере Hyper-V.

Рисунок 15 Оснастка Authorization Manager

Так, как наш сервер в домене, а мы работает под учетной записью администратора — мы можем получить доступ напрямую к диску С узла Hyper-V. Нажимаем правой кнопкой мыши Authorization Manager , выбираем Browse, далее указываем путь к файлу.

\\HV03.sep.local\c$\programdata\Microsoft\Windows\Hyper— V\InitialStore.xml

Рисунок 16 Открытие хранилища InitialStore.xml

После загрузки мы видим текущее состояние базы, на данном этапе все администраторы узла Hyper-V имеют доступ ко всем виртуальным машинам, а вновь создаваемые виртуальные машины помещаются в пул по умолчанию.

Рисунок 17 Обзор хранилища InitialStore.xml

Далее настраиваем возможность управления сервером Hyper-V для наших групп. Если этого не сделать, то при подключении пользователи не увидят список своих виртуальных машин. Для этого перейдем в консоль Authorization Manager, выбираем Hyper-V Services àDefinitionsà Role Definitionsà New Role DefinitionàAdd àУказываем имя VM-Manager Role, нажимаем кнопку Add.

Рисунок 18 Определение роли

Отмечаем следующие операции и нажимаем ОК.

• Read Service Configuration;
• View Virtual Machine Switch management Service;

Рисунок 19 Выбор операций для роли

Нажимаем Ок.

Рисунок 20 Выбранные операции для роли

Далее идем в Hyper-V services—>Role Assignments—>правой кнопкой мыши—>New Role Assignmentà Отмечаем чекбокс HV Manager Role и нажимаем Ок.

Рисунок 21 Добавление роли

Одним из основных терминов Authorization Management является Область (Scope), для задач делегирования прав на конкретные виртуальные машины на первом этапе потребуется создать три области, в которые поместить наши виртуальные машины в последствии доступ к которым мы и будем делегировать. Для этого перейдем в консоль Authorization Manageràжмем правой кнопкой мыши на Hyper-V Service и выбираем New Scope.

Рисунок 22 Создание новой области

Указываем имя Области Scope1 и заполняем поле Description For VM-Resource Administrators

Рисунок 23 Параметры области

Таким образом, мы создадим три области

Name: Scope1: Description: For VM-Resource Administrators;

Name: Scope2: Description: For VM-Application Administrators;

Name: Scope3: Description: For VM-HR Administrators;

Рисунок 24 Созданные области

На практике рекомендуется виртуальные машины группировать в области по ролям, например контроллеры домена, Exchange серверы, тестовые среды и т.д. Это облегчит понимание текущей структуры областей делегирование ролевым группам администрирования.

Рисунок 25 Пример группирования по ролям

Мы создали необходимые области и теперь нам необходимо поместить в них наши виртуальные машины согласно ролевой модели. Средств помещения виртуальной машины в заданную область в консоли AzMan нет. Перемещение виртуальных машин между областями можно сделать через WMI средствами PowerShell или VBS скриптом. В статье вы найдете два скрипта, которые автоматизируют эту задачу.

Первый скрипт — Getscope.vbs в качестве параметра требует имя виртуальной машины, а возвращает название области, которой она принадлежит. Если возвращенное значение пустое, значит, виртуальная машина принадлежит к области по умолчанию (default scope). Этот скрипт нужен для того чтобы определить в какой области находится виртуальная машина.

—————————————————————————————————————————-

Option Explicit

Dim WMIService

Dim VM

Dim VMManagementService

Dim VMSystemGlobalSettingData

Dim VMName

Dim NewVMName

Dim Result ‘Setup variables for the VM we are looking for, and the new name

VMName = Wscript.Arguments (0)

‘Get an instance of the WMI Service in the virtualization namespace.

Set WMIService = GetObject («winmgmts:\\.\root\virtualization»)

‘Get a VMManagementService object

Set VMManagementService = WMIService.ExecQuery («SELECT * FROM Msvm_VirtualSystemManagementService»).ItemIndex (0)

‘Get the VM object that we want to modify

Set VM = (WMIService.ExecQuery («SELECT * FROM Msvm_ComputerSystem WHERE ElementName=’» & VMName & «’»)).ItemIndex (0)

‘Get the VirtualSystemGlobalSettingData of the VM we want to modify

Set VMSystemGlobalSettingData = (VM.Associators_ («MSVM_ElementSettingData», «MSVM_VirtualSystemGlobalSettingData»)).ItemIndex (0)

‘Print the scope property

Wscript.Echo VMSystemGlobalSettingData.ScopeOfResidence

——————————————————————————————————————————

Создаем файл с названием Getscope.vbs помещаем в него скрипт и выполняем на хосте Hyper-V Для получения принадлежности к области виртуальной машины:

C:\Getscope.vbs «Srv-Vm01»

где — «Srv-Vm01» название виртуальной машины.

Рисунок 26 Результат выполнения скрипта, виртуальная машина находится в области по умолчанию

В итоге мы получаем значение Null это означает, что виртуальная машина размещена в области по умолчанию. Далее выполняем второй скрипт.

Второй скрипт Setscope.vbs в качестве параметров требует имя виртуальной машины и название созданной области, в которую вы хотите поместить виртуальную машину. В результате работы скрипта виртуальная машина переместится в указанную область.

—————————————————————————————————————————-

Option Explicit

Dim WMIService

Dim VM

Dim VMManagementService

Dim VMSystemGlobalSettingData

Dim VMName

Dim NewVMName

Dim Result ‘Setup variables for the VM we are looking for, and the new name

VMName = Wscript.Arguments (0)

‘Get an instance of the WMI Service in the virtualization namespace.

Set WMIService = GetObject («winmgmts:\\.\root\virtualization»)

‘Get a VMManagementService object

Set VMManagementService = WMIService.ExecQuery («SELECT * FROM Msvm_VirtualSystemManagementService»).ItemIndex (0)

‘Get the VM object that we want to modify

Set VM = (WMIService.ExecQuery («SELECT * FROM Msvm_ComputerSystem WHERE ElementName=’» & VMName & «’»)).ItemIndex (0)

‘Get the VirtualSystemGlobalSettingData of the VM we want to modify

Set VMSystemGlobalSettingData = (VM.Associators_ («MSVM_ElementSettingData», «MSVM_VirtualSystemGlobalSettingData»)).ItemIndex (0)

VMSystemGlobalSettingData.ScopeOfResidence=Wscript.Arguments (1)

Wscript.Echo (VM.Path_.Path)

WScript.Echo (VMSystemGlobalSettingData.GetText_ (1))

‘Update the VM with ModifyVirtualSystem

Result = VMManagementService.ModifyVirtualSystem (VM.Path_.Path, VMSystemGlobalSettingData.GetText_ (1))

‘WScript.Echo (Result)

—————————————————————————————————————————-

Для помещения виртуальной машины в область скопируйте скрипт на хост Hyper-V и выполните:

C:\Setscope.vbs «Srv-Vm01» «Scope1»

где — «Srv-Vm01» название виртуально машины.

где — «Scope1» название области в которую помещается виртуальная машина.

Информация взята с блога Russian Windows Virtualization Discussion

Теперь опишем задачи, роли для наших областей и свяжем с группами безопасности в домене.

Рисунок 27 Результат выполнения скрипта добавления виртуальной машины в область

Нажмите Ок.

Не пугайтесь, у вас появится еще одно сообщение, просто нажмите Ok.

Рисунок 28 Сообщение скрипта

Теперь проверим, что наша виртуальная машина перемещена в новую область, для этого повторно выполним скрипт Getscope.vbs.

Рисунок 29 Результат выполнения скрипта Getscope.vbs виртуальная машина помещена в область Scope1

Все отлично наша машина помещена в область Scope1. Повторите шаги по помещению виртуальных машин в области Scope2 и Scope3. Дополнительно для эксперимента я попытался поместить несуществующую виртуальную машину в область Scope3 (просто посмотреть, что будет)

Рисунок 30 Ошибка скрипта

Скрипт работает, как нужно J.

Честно говоря, я не пойму для чего компания Microsoft устроила такой вот геморрой с перемещением машин по областям, неужели трудно было создать пару тройку графических меню для выполнения такой процедуры.

Конфигурация ролей для областей.

Теперь сконфигурируем роли для области Scope1, для этого откроем Role Definitionsà New Role DefinitionàAdd àУказываем VM-Resource Server Administrators Role

Рисунок 31 Определение роли и задач

Далее нам нужно определить задачи , которые будут доступны для нашей роли. В области The task and lower-level roles that define this role: Нажимаем Add.

Переходим на вкладку Operations и отмечаем следующие операции:

• Allow Input to Virtual Machine;
• Allow Output from Virtual Machine;
• Start Virtual Machine;
• Stop Virtual Machine;
• Pause and restart Virtual Machine;
• Reconfigure Virtual Machine;

Нажимаем OK.

Рисунок 32 Выбор операций

После конфигурации операций мы видим окно, где показаны сформированные операции для нашей роли.

Рисунок 33 Сформированные операции для нашей роли.

Далее идем в Role Assignments области Scope1 выбираем, New Role Assignment выбираем, Add Role, отмечаем чекбокс VM-Resource Server Administrators Role и нажимаем Ок.

Рисунок 34 Создание роли

После создания роли нам необходимо включить в нее нашу группу из Active Directory для этого идем Role Assignments, жмем правой кнопкой мыши, выбираем Assign Users and ComputersàFrom Windows and Active Directory.

Рисунок 35 Добавление группы из Active Directory

Указываем имя группы VM-Resource Server Administrators Role, которую мы предварительно создали в Active Directory для этой роли. Нажимаем Ок.

Рисунок 36 Добавление группы из Active Directory

Теперь группа безопасности из Active Directory VM-Resource Server Administrators Role сопоставлена роли для области Scope1- можно смело включать в нее пользователей.

Рисунок 37 Добавление группы из Active Directory

Далее конфигурируем роли для области Scope2 для этого откроем Role Definitionsà New Role DefinitionàAdd àУказываем VM-Application Server Administrators Role.

Рисунок 38 Определение роли и задач

Далее нам нужно определить задачи, которые будут доступны для нашей роли. В области The task and lower-level roles that define this role: Нажимаем Add, переходим на вкладку Operations и отмечаем следующие операции:

• Allow Input to Virtual Machine;
• Allow Output from Virtual Machine;
• Start Virtual Machine;
• Stop Virtual Machine;
• Pause and restart Virtual Machine;

Нажимаем OK.

Рисунок 39 Выбор операций

После конфигурации операций мы видим окно, где показаны сформированные операции для нашей роли. Нажимаем ОK.

Рисунок 40 Сформированные операции для нашей роли.

Далее идем в Role Assignments области Scope2, выбираем New Role Assignment, выбираем Add Role, отмечаем чекбокс VM-Application Server Administrators Role, нажимаем ОK.

Рисунок 41 Создание роли

После создания роли для области Scope2, нам необходимо включить в нее нашу группу из Active Directory, для этого идем Role Assignments, жмем правой кнопкой мыши, выбираем Assign Users and ComputersàFrom Windows and Active Directory.

Рисунок 42 Добавление группы из Active Directory

Указываем имя группы VM-Application Server Administrators Role, которую мы предварительно создали в Active Directory для этой роли.

Рисунок 43 Добавление группы из Active Directory

Теперь группа безопасности из Active Directory VM-Application Server Administrators Role сопоставлена роли для области Scope2 и можно смело включать в нее пользователей.

Рисунок 44 Добавление группы из Active Directory

Далее сконфигурируем роли для последней области Scope3, для этого идем в область Scope3, открываем Role Definitionsà New Role DefinitionàAdd àУказываем VM-HR Servers Administrators Role

Рисунок 45 Определение роли и задач

Далее нам нужно определить задачи, которые будут доступны для нашей роли. В области The task and lower-level roles that define this role: Нажимаем Add, переходим на вкладку Operations и отмечаем следующие операции:

• Allow Input to Virtual Machine;
• Allow Output from Virtual Machine;
• Start Virtual Machine;
• Stop Virtual Machine;
• Pause and restart Virtual Machine;
• Reconfigure Virtual Machine;

Нажимаем OK.

Рисунок 46 Выбор операций

Видим сформированные операции для нашей роли.

Рисунок 47 Сформированные операции для нашей роли

Далее идем в Role Assignments области Scope3, выбираем New Role Assignment, выбираем Add Role, отмечаем чекбокс VM-HR Servers Administrators Role и нажимаем ОK.

Рисунок 48 Создание роли

После создания роли для области Scope3 нам необходимо включить в нее нашу группу из Active Directory, для этого идем Role Assignments жмем правой кнопкой мыши, выбираем Assign Users and ComputersàFrom Windows and Active Directory.

Рисунок 49 Добавление группы из Active Directory

Указываем имя группы VM-HR Servers Administrators Role, которую мы предварительно создали в Active Directory для этой роли.

Рисунок 50 Добавление группы из Active Directory

Теперь группа безопасности из Active Directory VM-HR Servers Administrators Role сопоставлена роли для области Scope3 и можно смело включать в нее пользователей.

Рисунок 51 Добавление группы из Active Directory

Итак, мы имеем 3 виртуальные машины, размещенные по трем разным областям, для каждой области мы создали соответствующую роль и указали операции, которые может выполнять эта роль.

Рисунок 52 Области и роли

Вот собственно и все, делегирование окончено. Далее на рабочей станции необходимо выполнить следующие шаги:

1. Разрешить на Windows Firewall правило «Windows Management Instrumentation (WMI) » командой:

netsh advfirewall firewall set rule group=»windows management instrumentation (wmi)» new enable=yes

1. Добавить в Windows Firewall исключение для исполняемого фалйла mmc.exe:

netsh firewall add allowedprogram program=%windir%\system32\mmc.exe name=»Microsoft Management Console»

1. Добавить разрешение Remote Access для COM Security.

Запустите оснастку «Component Services» правами администратора. Start—>Run—>dcomcnfg.exe.

Рисунок 53 Запуск оснастки

В дереве консоли последовательно разверните узлы «Component Services» и «Computers».

В контекстном меню объекта «My Computer» выберите «Properties».

Рисунок 54 Свойства My Computer (Com Security)

В окне «My Computer Properties» выберите вкладку «COM Security».

В разделе «Access Permissions» нажмите кнопку «Edit Limits».

В диалоговом окне «Access Permissions» выберите строку ANONYMOUS LOGON из списка «Group or user names». В графе «Allow» раздела «Permissions for User» выберите «Remote Access».

Рисунок 55 Установка разрешений

Закройте все диалоговые окна нажатием ОК.

После всех настроек заходим на рабочую станцию под именем User01, запускаем Hyper-V Manager и в консоли видим только те виртуальные машины, которые сопоставлены для роли VM-Application Server Administrators Role, то есть, разрешены для учетной записи User01.

Рисунок 56 Виртуальные машины, сопоставленные роли VM-Application Server Administrators Role

После выполнения всех описанных действий, каждый администратор может управлять только своей виртуальной машиной размещенной в отдельной области.
Денис Абраменко

Источник http://itband.ru/2009/10/authorization-manager/