Все, что вы хотели знать о DPM 2010 Bare Metal Recovery, но боялись спросить (часть 1)

В жизненном цикле любого сервера, будь это многопроцессорный монстр – сердце основных бизнес-процессов компании, или маленький «самосбор», хранящий тщательно собранные сезоны любимого сериала, в результате неудачно сложившихся обстоятельств может настать момент отказа оборудования или полного краха операционной системы. Несмотря на возможное присутствие кластерных технологий и хранение копий файлов на дополнительных носителях, подобные аварии могут изрядно подпортить настроение и отнять несколько часов на ликвидацию последствий. Использование возможностей Data Protection Manager для защиты и восстановления исходного состояния системы – Bare Metal Recovery позволяет минимизировать негативные последствия таких событий. В этой статье мы рассмотрим подробно принцип работы BMR, а так же  – как и что именно данная технология защищает.
В Data Protection Manager (DPM) различаются два вида защиты системной информации –защита состояния системы (System State) и защита восстановления исходного состояния системы (Bare Metal Recovery, BMR, альтернативное название – Disaster Recovery, но, применительно к DPM, данное название закрепилось за другой технологией). Согласно определению Microsoft, Bare Metal Recovery – это процесс восстановления компьютера после катастрофического отказа. Для реализации данных видов защиты DPM 2010 использует компонент операционной системы – систему архивации данных Windows Server (Windows Server Backup, WSB). Точнее, для архивации состояния системы и BMR на серверах Windows 2008 и Windows 2008 R2 используется WSB, для архивации только состояния системы на серверах Windows 2003 используется утилита NTbackup. А как же остальные операционные системы? Ответ суров – BMR для них в DPM 2010 не поддерживается. С выходом DPM 2010 в перечень неподдерживаемых конфигураций для BMR попали:

• Windows Server 2003 (только состояние системы);
• весь спектр клиентских операционных систем – от Windows XP до Windows 7;
• сервер DPM 2010 не может обеспечить защиту BMR для самого себя (только состояние системы);
• невозможна архивация BMR сразу на ленту (возможен только вариант с краткосрочной архивацией на диск, долгосрочной на ленту).

Оставим в стороне разговоры о тонкой грани между маркетингом и техническими ограничениями в реализации BMR для Windows 7 и рассмотрим различия между двумя упомянутыми видами защиты. Защита состояния системы включает в себя создание резервных копий следующих компонентов:

• реестр (набор файлов реестра default, sam, security, software, system, shema.dat, components из %windir%\System32\Config);
• база данных регистрации классов COM+ (все файлы из папки %windir%\Registration);
• регистрационная и лицензионная информация операционной системы (файлы *.GUID из папки %windir%\System32 + все файлы из папок %SystemDrive%\ProgramData\Microsoft\Crypto\RSA\MachineKeys\ и %windir%\System32\Microsoft\Protect)
• объекты WMI (все файлы из папки %windir%\System32\wbem\repository);
• загрузочные файлы, в том числе системные файлы (Boot.ini, NDTLDR, NTDetect.com и т.д.);
• база данных служб сертификации (CA), при условии, что данный сервер является сервером CA (файлы CAName.p12 – сертификат и закрытый ключ CA, certbkxp.dat – информация о расположении базы данных CA и файлов журнала, CAName.edb – база данных CA, edb*.log – журналы транзакций CA);
• служба каталогов Active Directory, при условии, что данный сервер является контроллером домена (содержимое папки %SystemRoot%\NTDS: Ntds.dit – база данных AD, edb.chk – файл контрольных точек, edb*.log – журналы транзакций);
• содержимое директории SYSVOL, при условии, что данный сервер является контроллером домена;
• информация кластерных служб, если сервер является узлом кластера (файл %windir%\Cluster\CLUSDB);
• метакаталог IIS, если установлены службы IIS (файлы %windir%\System32\inetsrv\MetaBase.xml и MBSchema.xml);
• защищенные системные файлы Windows (все установленные статические файлы, идентифицируются атрибутом writeabletype = «static» или «» в манифесте компонента + содержимое папки %windir%\WinSxS + все файлы PnP для установленных драйверов PnP + все службы и не PnP драйверы пользовательского режима + все каталоги управляемые CryptSvc);
• служба DHCP, если установлена (файлы базы данных dhcp.mdb, dhcp.pat, журнала j*.log, контрольных точек j*.chk из папки %windir%\System32\dhcp + файл конфигурации DhcpCfg);
• служба WINS, если установлена (структура аналогична DHCP, только без файла конфигурации);
• задания планировщика Windows Scheduler (все файлы из папки %windir%\System32\Tasks и %windir%\Tasks);
• счетчики производительности Performance Counters (файлы Prf*.dat и Perf*.dat из папки %windir%\System32).

В различных версиях операционной системы содержимое архива состояния системы может незначительно изменяться в сравнении с вышеизложенным, но основные моменты постоянны. И можно не забивать себе голову тонкостями его состава, т.к. актуализацией перечня входящих в него файлов занимаются специальные модули службы теневого копирования томов (Volume Shadow Copy Service, VSS) – VSS writers. Теперь взглянем на состав данных для защиты исходного состояния системы:

• все пункты, указанные в составе состояния системы;
• все содержание критических томов (том является критическим, если он содержит любой компонент данных состояния системы).

Всего из двух названных пунктов можно сделать множество выводов:

1. Если, например, папка SYSVOL будет расположена на томе с терабайтами пользовательской информации, вы получите многотерабайтный архив BMR. Старайтесь держать всю системную информацию на отдельных томах.
2. Невозможно защищать BMR без состояния системы.
3. Данные состояния системы можно восстановить из BMR отдельно.
4. При восстановлении из архива BMR приложения, расположенные на критических томах будут так же восстановлены и работоспособны.
5. Базы данных и аналогичные, жизненно необходимые для приложений компоненты, хранящиеся на отдельных от критических томов разделах, не войдут в состав BMR. Их необходимо защищать отдельно.
6. На сервере с защитой BMR нет никакой необходимости для защиты каких-либо файлов и папок на системном и загрузочном дисках (обычно это диск C). Вы всегда сможете восстановить эти файлы из архива BMR.
7. С помощью BMR можно восстановить сервер на отличную от оригинальной аппаратную платформу.

В случае каких-либо сомнений о составе BMR узнать точно – что именно в каждом конкретном случае войдет в архив можно выполнив из консоли с административными правами команду:

wbadmin.exe start backup -allcritical -quiet -backuptarget:%1

Путь для создания архива %1 приведет к ошибке, но на экран будет выведен перечень разделов для создания резервной копии. В данном случае в архив планируется  включить том Зарезервировано системой и C:. Правда, тут так же есть тонкость – по словам специалистов из команды поддержки DPM на TechNet EN том Зарезервировано системойисключен из состава данных BMR для DPM 2010.

Теперь, прояснив вопросы состава архива, взглянем на процедуру создания группы защиты включающей BMR. Запускаем мастер выбором действия Создать группу защиты… Пропустив страницу приветствия, мы видим окно выбора типов защиты.

Защита BMR для клиентов в DPM пока не существует, поэтому выбираем Серверы и следуем Далее. В окне выбора элементов группы необходимо отметить System Protection для всех серверов, архив BMR которых необходим для восстановления в случае сбоя. Напомню, что невозможно защищать BMR без Состояния системы, и в этом варианте у вас будут отмечены оба элемента – Bare Metal Recovery и System State. Для серверов, которым достаточно защиты только Состояния Системы, нужно отметить элемент System State.

Хотя в примере я выбираю один защищаемый компьютер, группа защиты может включать множество серверов с System Protection. В следующем окне мастера назначаем Имя группы защиты и выбираем Метод защиты Диск или Лента, либо оба варианта.

В моем тестовом стенде пока отсутствует ленточная библиотека, поэтому выбор тут один – диск . В следующем окне необходимо определиться с Диапазоном хранения и расписанием Быстрой полной архивации.

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

Забавная ошибка/опечатка как бы торопит нас своим побудительным наклонением –Измени, быстрее, то, что я тут насчитал, пока никто не увидел.

В документации DPM 2010 честно сказано, что при защите BMR он не затрудняет себя точным подсчетом необходимого места. Если быть  объективным, DPM вообще, без прямого указания администратора, подсчетами необходимого для архивов места себя не утруждает. Поэтому не пугайтесь, когда он потребует от вас докинуть сверху терабайт дискового пула к выделенным для защиты 100 ГБ данных. Методику и лучшие практики выделения дискового пространства для архивов DPM мы рассмотрим в отдельной статье, а для BMR получаем следующую раскладку:

объем необходимого места для реплики = объем загрузочного диска + объем системного диска + объемы всех критических томов

DPM автоматически выделит 30 Гб для реплики, и администратор должен отрегулировать размер самостоятельно, опираясь на указанную выше формулу.

При защите BMR, все входящие в архив данные копируются напрямую в раздел реплики на сервере DPM. И только при явной защите одного Состояния Системы, без BMR, данные архивируются на защищаемом сервере локально и затем копируются в папку реплики на сервере DPM. Это накладывает требование на тома защищаемого сервера – хотя бы на одном из них должно быть 15 Гб свободного места для хранения Состояния системы. 15 Гб является официальной рекомендацией, на практике же я не встречал архива более 10 Гб.

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

C:\Program Files\Microsoft Data Protection Manager\DPM\Datasources\PSDataSourceConfig.xml

и изменив букву раздела в строке <FilesToProtect>. Изменяйте только букву диска. АрхивСостояния системы должен находиться в папке WindowsImageBackup в корневом каталоге.

Таким образом, при использовании DPM, защита BMR, в отличие от защиты System State, не накладывает каких-либо особых требований к дисковому пространству защищаемого сервера.

Возвращаемся к мастеру создания группы защиты. После подсчетов необходимого дискового пространства, вы можете активировать опцию Автоматически увеличивать размер томов. Это позволит процессу защиты данных не прерываться, если вы ошиблись в расчетах размеров томов, и выделенное место закончилось.

В следующем окне производим Выбор метода создания реплики.

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

Далее мы видим окно Параметры проверки согласованности.

Суть этого процесса в поблочном сравнении источника данных с репликой на стороне DPM сервера с целью убедиться в идентичности данных. Мастер предупреждает, что выполнение проверки согласованности требует дополнительных ресурсов как на стороне защищаемого сервера, так и на стороне DPM. Если следовать общим рекомендациям, при защите BMR можно оставить настройку по умолчанию Выполнять проверку согласованности, если реплика оказывается несогласованной.

В принципе, группа защиты готова. Остается только проверить данные в окне Сводка, где отображены элементы и параметры группы защиты. Жмем Создать группу, и дальше сервер DPM выполнит работу сам.

Вернемся к составу архива. Если уж я взялся собрать всю информацию по BMR, то здесь должен быть отражен способ включить в архив BMR не критические тома. Впервые метод описан в блоге Robert & DPM. Итак, для включения произвольного тома в архив BMR необходимо найти файл

C:\Program Files\Microsoft Data Protection Manager\DPM\bin\Bmrbackup.cmd

Данный файл сценария содержит вызов программы wbadmin.exe с ключом -allcritical

start /WAIT %SystemRoot%\system32\wbadmin.exe start backup -allcritical -quiet -backuptarget:%1

Именно так, простым вызовом программы архивации Windows, DPM решает задачу создания архива BMR. Для добавления произвольного тома в архив BMR нужно дописать в строку вызова параметр -include:буква тома: что для диска D будет выглядеть следующим образом:

start /WAIT %SystemRoot%\system32\wbadmin.exe start backup -allcritical -include:D: -quiet -backuptarget:%1

При добавлении томов к архиву не забывайте учитывать их размер при выделении дискового пространства в пуле DPM сервера. И еще один момент – DPM позволяет свободно защищать Состояние Системы или BMR в одной группе защиты, а системный диск C – в другой. Это дает администратору дополнительное пространство для планирования схем резервного копирования.

На этом я заканчиваю первую часть этой порядком разросшейся статьи. В следующей части я подробно опишу процесс восстановления сервера из архива BMR.

Role Based Access Control (RBAC) – новая модель управления доступом к Exchange 2010

До выхода Exchange 2010 наделение пользователей дополнительными возможностями осуществлялось при помощи функционала делегирования управления и списков управления доступом (ACL). В Exchange 2010 сердцем модели авторизации стала новая система разрешений Role Based Access Control(RBAC).

Role Based Access Control (RBAC) — это новая модель разрешений в Microsoft Exchange Server 2010. При использовании RBAC отпадает необходимость в изменении и поддержании списков управления доступом (ACL), использовавшихся в Exchange Server 2007.

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

К сожалению, Exchange Management Console (EMC) не позволяет полноценно работать с RBAC, по этому, мы будем использовать командлеты Exchange Management Shell (EMS). Правда для просмотра набора ролей и редактирования их участников подойдет и веб-сайт с Exchange Control Panel (ECP).

Принцип работы RBAC:

Справка TechNet предлагает визуализировать схему работы RBAC следующим образом:

Рис.1: Визуальная схема работы RBAC.

Мне же больше нравится несколько модернизированный её вид:

Рис.2: Треугольник RBAC.

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

На практике, более правильным будет порядок вопросов Кто? –> Что? –> Где?, но для лучшего понимания теории давайте рассмотрим эти вопросы немного в другой последовательности.

1. Что?

Ответ на вопрос «Что?» должен подразумевать под собой те действия, которыми вы хотите наделить пользователя, т.е. Что он должен иметь право делать. Для ответа на этот вопрос существуют роли (Roles).

Роли управления (Management Roles) являются частью модели RBAC. Роли работают как логическая группировкакомандлетов, которые объединены для предоставления доступа к просмотру и изменению конфигурации компонентов Exchange 2010, например почтовых ящиков, правил транспорта и получателей. 

По умолчанию, сервер Exchange 2010 предоставляет множество встроенных ролей управления, которые можно использовать для администрирования организации. В таблице приведен их список:

Active Directory Permissions Role	Роль разрешений Active Directory
Address Lists Role	Роль списков адресов
ApplicationImpersonation Role	Роль ApplicationImpersonation
Audit Logs Role	Роль журналов аудита
Cmdlet Extension Agents Role	Роль агентов расширения командлетов
Database Availability Groups Role	Роль групп доступности базы данных
Database Copies Role	Роль копий баз данных
Databases Role	Роль баз данных
Disaster Recovery Role	Роль аварийного восстановления
Distribution Groups Role	Роль групп рассылки
Edge Subscriptions Role	Роль пограничных подписок
E-Mail Address Policies Role	Роль политик адресов электронной почты
Exchange Connectors Role	Роль соединителей Exchange
Exchange Server Certificates Role	Роль сертификатов сервера Exchange Server
Exchange Servers Role	Роль серверов Exchange
Exchange Virtual Directories Role	Роль виртуальных каталогов Exchange
Federated Sharing Role	Роль федеративного общего доступа
Information Rights Management Role	Роль управления правами на доступ к данным
Journaling Role	Роль ведения журнала
Legal Hold Role	Роль юридического удержания
Mail Enabled Public Folders Role	Роль общих папок с включенной поддержкой почты
Mail Recipient Creation Role	Роль создания получателя электронной почты
Mail Recipients Role	Роль получателей почты
Mail Tips Role	Роль советов по использованию электронной почты
Mailbox Import Export Role	Роль экспорта и импорта почтового ящика
Mailbox Search Role	Роль поиска в почтовом ящике
Message Tracking Role	Роль отслеживания сообщений
Migration Role	Роль миграции
Monitoring Role	Отслеживание роли
Move Mailboxes Role	Перемещение роли почтовых ящиков
MyBaseOptions Role	Роль Мои_базовые_параметры
MyContactInformation Role	Роль Моя_контактная_информация
MyDiagnostics Role	Роль MyDiagnostics
MyDistributionGroupMembership Role	Роль Членство_в_моей_группе_рассылки
MyDistributionGroups Role	Роль Мои_группы_рассылки
MyProfileInformation Role	Роль Информация_о_моем_профиле
MyRetentionPolicies Role	Роль Мои_политики_хранения
MyVoiceMail Role	Роль Моя_голосовая_почта
Organization Client Access Role	Роль клиентского доступа организации
Organization Configuration Role	Роль конфигурации организации
Organization Transport Settings Role	Роль параметров транспорта организации
POP3 and IMAP4 Protocols Role	Роль протоколов POP3 и IMAP4
Public Folder Replication Role	Роль репликации общих папок
Public Folders Role	Роль общих папок
Receive Connectors Role	Роль соединителей получения
Recipient Policies Role	Роль политик получателя
Remote and Accepted Domains Role	Роль удаленных и обслуживаемых доменов
Retention Management Rolet	Роль управления хранением
Role Management Role	Роль управления ролями
Security Group Creation and Membership Role	Роль создания и членства в группе безопасности
Send Connectors Role	Роль соединителей отправки
Support Diagnostics Role	Поддержка роли диагностики
Transport Agents Role	Роль агентов транспорта
Transport Hygiene Role	Роль санации транспорта
Transport Queues Role	Роль очередей транспорта
Transport Rules Role	Роль правил транспорта
UM Mailboxes Role	Роль почтовых ящиков единой системы обмена сообщениями
UM Prompts Role	Роль запросов единой системы обмена сообщениями
Unified Messaging Role	Роль единой системы обмена сообщениями
Unscoped Role Management Role	Роль управления с незаданной областью
User Options Role	Роль параметров пользователя
View-Only Configuration Role	Роль конфигурации с правами только на просмотр
View-Only Recipients Role	Роль получателей с правами только на просмотр

Совет: Если вы хотите применять настраиваемые сценарии или командлеты, не относящихся к Exchange, то вам необходимо использовать Роль управления с незаданной областью (Unscoped Role Management Role).

Список всех ролей можно получить командлетом:

Get-ManagementRole

Рис.3: Вывод списка ролей.

Каждая роль включает в себя командлеты и параметры, необходимые пользователям для управления определенными компонентами Exchange.

Вы можете проконтролировать какие именно командлеты может выполнять роль, выполнив команду:

Get-ManagementRoleEntry "Mail Recipients\*"

Рис.4: Вывод списка командлетов роли Mail Recipients.

Данная команда показывает нам все командлеты, которые применимы внутри роли Mail Recipients.

Аналогично можно использовать следующие конструкции для получения списка командлетов, доступных ролям:

Пример	Описание
*\*	Возвращает список всех записей роли для всех ролей.
*\Set-Mailbox	Возвращает список всех записей роли, которые содержат командлет Set-Mailbox.
Mail Recipients\*	Возвращает список всех записей роли в роли получателей почты.
Mail Recipients\*Mailbox	Возвращает список всех записей роли в роли получателей почты, оканчивающихся на Mailbox.
My*\*Group*	Возвращает список всех записей роли, которые содержат строку Group в имени командлета, для всех ролей, начинающихся с My.

Встроенные роли, выполняя определенный список задач, не покрывают все сценарии использования Exchange 2010. Для более гибкой настройки политики распределения полномочий, у нас есть возможность создавать дочерние роли (Child Roles).

Рис.5: Иерархия ролей.

Создать дочернюю роль можно командлетом New-ManagementRole, указав при этом её родителя при помощи параметра –Parent.
New-ManagementRole –Name “New Databases” – Parent “Databases”

Есть несколько вещей, которые должен знать администратор при создании дочерних ролей:

1. Вы можете создавать дочерние роли для уже дочерних ролей.
2. Дочерняя роль НЕ может обладать большими полномочиями, чем родительская, даже если родительская роль сама является дочерней.
3. У каждой роли должно быть минимум одно разрешение.
4. Перед удалением роли необходимо вручную удалить все её разрешения.
5. У вас должно быть право выполнять Get-командлеты для этой роли.

После создания роли необходимо отредактировать её разрешения при помощи командлета Get-ManagementRoleEntry. Для начала, нужно удалить все разрешения, кроме одного:

Get-ManagementRoleEntry “New Databases\*” | where {$_.name –ne “Get-Recipient”} | Remove-ManagementRoleEntry

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

Add-ManagementRoleEntry “New Databases\Mount-Database” –Parameters Confirm,Debug

Рис.6: Добавление дочерней роли.

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

Типы ролей управления делятся на следующие категории.

• Администратор или специалист (Administrative or specialist)   Роли, связанные с типом ролей администратора или специалиста, имеют более широкую область влияния в организации Exchange. Роли этого типа позволяют выполнять такие задачи, как управление сервером или получателями, настройка организации, администрирование в соответствии с требованиями, аудит и другие.
• Ориентированные на пользователя (User-focused)   Роли, связанные с типом ролей, ориентированных на пользователя, имеют область влияния, привязанную к одному пользователю. Роли этого типа позволяют выполнять такие задачи, как настройка профиля пользователя и самоуправление, управление пользовательскими группами рассылки и другие.
  Имена ролей, связанных с типами ролей, ориентированных на пользователя, и имена типов ролей, ориентированных на пользователя, начинаются с My.
• Специальность (Specialty)   Роли, связанные с типом ролей специальности, позволяют выполнять задачи, не относящиеся к типам административных или ориентированных на пользователя ролей. Роли этого типа позволяют выполнять такие задачи, как олицетворение приложения (application impersonation) и использование сценариев и командлетов, не относящихся к Exchange.

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

2. КТО?

Данный угол треугольника RBAC подразумевает под собой ответ на вопрос Кто?. Т.е. кто именно может выполнять обозначенные в вопросе «Что?» действия.

В качестве ответа на вопрос «Кто?» мы можем использовать конкретного пользователя (в RBAC пользователи представлены в виде почтовых ящиков), или группу. Чтобы выдать полномочия пользователю, необходимо добавить его в группу ролей управления (Role Groups), а затем группу связать с определенной ролью (Role).

Группа ролей управления(Management Role Group) — это универсальная группа безопасности, используемая в модели RBAC в Microsoft Exchange Server 2010. В Active Directory, группы ролей (Role Groups) располагаются в отдельной OU – Microsoft Exchange Security Groups. Там же можно посмотреть, кто входит в группу. Для всех участников группы ролей назначается идентичный набор ролей.

Рис.7: Расположение групп ролей в AD.

Существует несколько встроенных групп ролей, эти роли, входят в комплект поставки Exchange 2010. Во встроенных группах ролей можно добавлять и удалять пользователей. В большинстве групп ролей можно также добавлять и удалять назначения ролей.

В следующей таблице перечислены встроенные группы ролей в составе Exchange 2010.

Группа ролей		Описание
Organization Management	Управление организацией	Администраторы, являющиеся участниками группы ролей Управление организацией, имеют административный доступ ко всей организации Exchange 2010 и могут выполнять практически все задачи с любым объектом Exchange 2010.
View-Only Organization Management	Управление организацией с правами только на просмотр	Администраторы, являющиеся участниками группы ролей Управление организацией с правами только на просмотр, могут просматривать свойства любого объекта в организации Exchange.
Recipient Management	Управление получателями	Администраторы, являющиеся участниками группы ролей Управление получателями, имеют административный доступ для создания или изменения получателей Exchange 2010 в организации Exchange 2010.
UM Management	Управление единой системой обмена сообщениями	Администраторы, являющиеся участниками группы ролей управления единой системы обмена сообщениями, могут управлять компонентами единой системы обмена сообщениями в организации Exchange, например конфигурацией сервера единой системы обмена сообщениями, свойствами этой системы для почтовых ящиков, запросами системы и конфигурацией автосекретаря единой системы обмена сообщениями.
Discovery Management	Управление обнаружением	Администраторы или пользователи, которые являются участниками группы ролей Управление обнаружением, могут выполнять поиск данных, которые соответствуют определенным критериям, в почтовых ящиках организации Exchange.
Records Management	Управление записями	Пользователи, которые являются участниками группы ролей Управление записями, могут настраивать такие соответствия требованиям, как теги политики хранения, классификации сообщений, правила транспорта и другие.
Server Management	Управление сервером	Администраторы, являющиеся участниками группы ролей управления сервером, имеют административный доступ к конфигурации сервера Exchange 2010. Они не имеют административного доступа к конфигурации получателя Exchange 2010.
Help Desk	Служба поддержки	Пользователи, являющиеся участниками группы ролей службы поддержки, могут выполнять ограниченное число задач управления получателями Exchange 2010.
Hygiene Management	Управление санацией	Администраторы, которые являются участниками группы ролей «Управление санацией», могут настраивать эти функции защиты от нежелательной почты и вирусов в Exchange 2010. Сторонние программы, интегрированные с Exchange 2010, могут добавлять в эту группу ролей учетные записи служб, чтобы предоставить этим программам доступ к командлетам, необходимым для извлечения и настройки конфигурации Exchange.
Public Folder Management	Управление общими папками	Администраторы, являющиеся участниками группы ролей управления общими папками, могут управлять общими папками и базами данных на серверах Exchange 2010.
Delegated Setup	Делегированная установка	Администраторы, являющиеся участниками группы ролей делегированной установки, могут развертывать предварительно подготовленные серверы Exchange 2010.

Вы можете назначить группе несколько ролей, если желаете, чтобы её члены имели больше возможностей. Также, при создании группы можно указать область (Scope), если вы не хотите, чтобы была присвоена область по умолчанию (но об этом чуть позже).
Чтобы создать новую группу ролей нужно воспользоваться командлетом New-RoleGroup:

New-RoleGroup “Group new databases” –Roles “New Databases”

Добавить пользователя или группу пользователей в группу ролей можно при помощи команды:

Add-RoleGroupMember “Group new databases” -Member user1

Рис.8: Добавление группы ролей и связывание её с пользователем.

Добавить пользователя в группу и просмотреть её параметры вы можете и при помощи Exchange Control Panel - ECP -> Users & Groups -> Administrator Roles.

Рис.9: Просмотр информации о группе через веб-страницу Exchange Control Panel.

Увидеть список всех групп мы можем, выполнив команду:

Get-RoleGroup

3. ГДЕ?

Следующим вопросов, на который вы должны ответить – это вопрос «Где?». Т.е. на какие объекты вы планируете давать разрешения? Ответ на данный вопрос вы должны задать в параметре Role Scope (область действия роли).

Область действия роли (Role Scope) – это объект, на который направлено действие конкретной роли, это может быть целая организация, отдельная OU в AD, либо группа пользователей.

У всех ролей RBAC есть свои области действия (Management role scope).

Когда вы создаете новую роль RBAC, по умолчанию, она будет наследовать область действия своего родителя. Но вы можете указать область действия роли также непосредственно во время её создания. Хорошей практикой является предварительное создание области действия (Role Scope) и последующее назначение её определенной роли с той целью, чтобы эту область потом можно было использовать ещё раз.

Создание новой области действия происходит при помощи командлета New-ManagementScope, к которому должны быть применены параметры фильрации:

• RecipientRestrictionFilter
• ServerRestrictionFilter
• ServerList

Например так:

New-ManagementScope -name "Managers" -RecipientRestrictionFilter {memberofgroup -eq "cn=Managers,ou=Managers,dc=domain,dc=local"}

Эта команда создает новую область действия с названием Managers из всех пользователей, группы Managers, находящейся в OU Managers.

Таким образом, мы видим, что области могут быть двух видов:

• Неявные области (implicit scopes) - наследуемые;
• Явные области (explicit scopes) - предварительно определенные и настраиваемые:
• Предварительно определенные относительные области (Predefined Relative Scopes)
• Настраиваемые области (Custom Scopes)

Посмотреть область действия конкретной роли можно командой:

Get-ManagementRole “Databases” | fl *scope*

Рис.10: Область действия конкретной роли

В выводе команды мы может увидеть, что каждая роль иметь следующие типы областей:

• Область чтения получателей (Recipient read scope)  Неявная область чтения получателей определяет объекты получателей, которые пользователь с назначенной ролью управления может читать из Active Directory.
• Область записи получателей (Recipient write scope)   Неявная область записи получателей определяет объекты получателей, которые пользователь с назначенной ролью управления может изменять в Active Directory.
• Область чтения конфигурации (Configuration read scope)   Неявная область чтения конфигурации определяет объекты конфигурации, которые пользователь с назначенной ролью управления может читать из Active Directory.
• Область записи конфигурации (Configuration write scope)   Область записи конфигурации определяет объекты сервера и организации, которые пользователь с назначенной ролью управления может изменять в Active Directory.

Области должны добавляться в один из этих типов областей.

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

Назначение области для определенной роли делается при помощи политики назначений (Role Assignment), командлетами New-ManagementRoleAssignment или Set-ManagementRoleAssignment.

4. Назначение ролей (Role Assignment)

Наконец мы добрались до центра треугольника.
Как вы уже заметили «Где», «Что» и «Кто» - это все элементы Active Directory. Таким образом, связующим, для этих трех элементов будет другой объект AD – назначение ролей (Role Assignment).

Политика назначения ролей управления (Role Assignment) — это набор из одной или нескольких ролей управления. Политики назначения ролей являются частью модели RBAC и позволяют определять, какие именно параметры может изменять конечный пользователь.

Командлет New-RoleGroup создает именно политику назначения (Role Assignment) между группой ролей (Role Groups) и ролью (Management Role), с дополнительными атрибутами.

Рис.11: Модель политики назначения ролей управления

Запустив команду

Get-ManagementRoleAssignment

вы увидите список из порядка 160 значений. Все потому, что Role Assignment связывает конкретную роль, область и группу ролей 1 к 1-ому. Таким образом, каждый раз, назначая роль группе ролей создается уникальное назначение (Role Assignment), которое и связывает их вместе.

Примечание: Как уже говорилось в самом начале, очень важно не путать RBAC с назначением разрешений безопасности (например NTFS), где приоритетно ограничивающее разрешение. В RBAC пользователю присваиваетсяобъединение всех ролей, которые для него назначены. Таким образом, нужно назначать пользователю только те роли, которые необходимы.

Назначения создаются при помощи командлета New-ManagementRoleAssignment с добавлением в виде параметров всех связываемых элементов: имени назначение (–Name), группы ролей (–SecurityGroup), роли (–Role) и области действия (-RecipientRelativeWriteScope), например так:

New-ManagementRoleAssignment -Name -SecurityGroup < USG> -Role -RecipientRelativeWriteScope < MyDistributionGroups | Organization | Self >

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

Заключение

В конце давайте подведем итог и закрепим основные понятия:

Роль (Role) – определяет набор командлетов и параметров, которые могут быть запущенны внутри неё. Это угол треугольника, который определяет Что именно пользователь можете сделать. В PowerShell – ManagementRole.

Запись роли (Role Entry) – индивидуальная запись для роли, которая определяет командлет и параметр этой роли. Это именно та часть, которую нужно редактировать, когда вы хотите тонко настроить права роли. В PowerShell – ManagementRoleEntry.

Группа ролей (Role Group) – это группа безопасности, которая определяет Кто принадлежи конкретной роли или области. Это угол треугольника, который обозначает кто именно может выполнять указанные выше действия. В PowerShell – RoleGroup.

Область (Scope) – область определяет объекты Где находятся объекты, на которые накладывает свое действие определенная роль. Область определяет Где роль может работать. В PowerShell – ManagementScope.

Назначение ролей (Role Assignment) – это объект AD, который связывает вместе все 3 угла треугольника, т.е. объекты Кто, Что и Где. В PowerShell – ManagementRoleAssignment.

RBAC это очень обширная и не простая тема. В этой статье я лишь хотел изложить её основы, чтобы вы начали смотреть на эту технологию с правильной точки зрения. Главное, когда планируете политику RBAC, не забывайте о том, что это треугольник, в центре которого Role Assignment.

В итоге, RBAC дает большим компаниям комплексную модель делегирования полномочий и позволяет более тонко настраивать разрешения пользователей и специалистов. Для небольших и средних организаций, уже заложенный в Exchange 2010 набор ролей, групп, областей и назначений предоставляет необходимый и достаточный функционал делегирования, при этом позволяя гибко изменять его под свои нужды.

На этом теоретическая часть закончена, более подробную информацию про RBAC вы можете получить в библиотеке TechNet по адресу - http://technet.microsoft.com/en-us/library/dd297943.aspx, также есть и русская справка вот тут -http://technet.microsoft.com/ru-ru/library/dd297943.aspx, но лично я рекомендую использовать английскую, т.к. в русской очень легко запутаться и не правильно понять суть написанного.