четверг, 19 мая 2011 г.

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

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


На рис.1 показан процесс подключения EMC или EMS к серверу Exchange 2010. Данный процесс заключается в том, что запрос на аутентификацию принимается RBAC-ом, далее RBAC определяет тип ролей пользователя, а также командлеты и параметры, к которым есть у данного пользователя доступ. Потом, когда пользователь посылает запрос на запуск командлета, PowerShell и RBAC подтверждают разрешение на его запуск и только после этого командлет выполняется.


Рис.1: Windows PowerShell и RBAC
Примечание: На схеме вы видите Remote PowerShell, это не случайно, т.к. PowerShell в Exchange 2010 используется удаленное управление Windows (WinRM) 2.0. Командная консоль всегда подключатся к серверу Exchange 2010 через виртуальный каталог IIS (Internet Information Server) независимо от того, к какому серверу вы подключились: локальному или удаленному.
Очень важно понимать, что в зависимости от роли, пользователь может увидеть тот или иной набор командлетов. Например, роль OrganizationManagement — это роль, которая может управлять всеми аспектами организации Exchange 2010. В силу этого роль OrganizationManagement имеет доступ почти ко всем командлетам и параметрам, которые предоставляет Exchange 2010. Для сравнения, роль DiscoveryManagement имеет гораздо меньший набор командлетов и параметров, т.к. ей всего лишь необходимо осуществлять поиск по почтовым ящикам.
Примечание: Справка в командной консоли всегда показывает все параметры, доступные в командлете, независимо от ролей, назначенных пользователям.
Как уже говорилось в первой части, Exchange 2010 содержит множество встроенных ролей, удовлетворяющих большинству потребностей средней компании, но при необходимости можно создавать и свои роли, также каждому пользователю можно назначить несколько ролей, если их комбинация лучше подходит для его работы. При наличии нескольких пользователей с одинаковыми должностными обязанностями их можно добавить в универсальную группу безопасности, а затем назначить этой группе необходимые роли. При этом для управления разрешениями необходимо просто добавить или удалить участников из универсальной группы безопасности.
Примечание: Не забывайте, что в командной консоли Exchange 2010 есть встроенная справка вызывающаяся командлетом Get-Help. Для получения сведений о конкретном командлете введите Get-Help и имя необходимого командлета, например Get-Help Get-SystemMessage. Управлять отображением тех или иных сведений можно с помощью параметров Detailed для получения дополнительных сведений, Full для получения технических сведений и Example для вывода примеров. Они добавляются в конец команды. Например, Get-Help -Full возвращает все разделы справки по командлету. Для получения сведений о конкретных параметрах командлета, можно использовать параметр Parameters с командлетом Get-Help. Например, чтобы просмотреть все параметры и их описания в командлете Set-Mailbox, включающих слово «quota», введите команду Get-Help Set-Mailbox -Parameter *quota*.
Для демонстрации работы RBAC давайте решим небольшую задачу.

Задача:

Делегировать возможности импорта/экспорта почтовых ящиков группе пользователей.
Очень частый вопрос на форумах звучит примерно следующим образом: «Почему я, являясь членом группы администраторов Exchange не могу выполнить командлеты Import-Mailbox / Export-Mailbox?”.
Все дело в том, что по умолчанию, ни кто не может выполнять Import/Export почтовых ящиков, и сделано это умышленно, т.к. данная возможность может очень сильно повлиять на сохранность конфиденциальных данных. Администратор, при необходимости, может делегировать этот функционал доверенному лицу.

Решение:

Чтобы делегировать возможность выполнения конкретных командлетов, необходимо узнать какой из встроенных ролей они принадлежат. Для этого воспользуемся следующей командой:
Get-ManagementRoleEntry “*\Import-Mailbox”
В результате, мы выясним, что командлеты Import-Mailbox  и Export-Mailbox принадлежат встроенной роли Mailbox Import Export. Узнать, какие ещё командлеты принадлежат этой роли можно выполнив команду:
Get-ManagementRoleEntry “Mailbox Import Export\*”
Таким образом, мы ответили на вопрос «Что?» и знаем, какая роль нам нужна. Далее нужно ответить на вопрос «Кто?», и посмотреть, к какой группе привязана роль Mailbox Import Export. Для этой проверим назначения роли (Role Assignment) командой:
Get-ManagementRoleAssignment -role "Mailbox Import Export" | fl Identity
В результате мы видим, что данная роль связана с группой Organization Management, но у этой группы есть только право делегирования. Соответственно нужно воспользоваться этим правом и связать роль с другой группой. Следовательно, необходимо создать новую группу ролей (Role Group), связать с ролью и добавить в неё пользователей, например вот так:
New-RoleGroup -Name "Import/Export Group" -Roles "Mailbox Import Export" -Members User1
image
Рис.2: Создание новой группы ролей Import/Export Group.
Теперь, если ещё раз выполнить команду
Get-ManagementRoleAssignment -role "Mailbox Import Export" | fl Identity
То мы увидим, что в её выводе появилась группа Import/Export Group.
К командлету New-RoleGroup можно добавить такие параметры, как –DisplayName и –Description.
Теперь, если мы отправимся в Active Directory, то увидим, что у нас образовалась новая группа безопасности Import/Export Group, членом которой стал User1.

Рис.3: Новая группа ролей Import/Export Group в Active Directory.
В результате проделанных выше действия у User1 появилась возможность выполнять командлеты Import-Mailbox и Export-Mailbox.

Усложним задачу:

Ограничим количество командлетов, доступных группе Import/Export Group и число пользователей, с почтовыми ящиками которых она может работать.

Решение:

Для изменения набора командлетов у группы, нам надо создать дочернюю роль, у которой оставить только необходимые командлеты и уже эту дочернюю роли назначить группе Import/Export Group.
Создать дочернюю роль можно командлетом New-ManagementRole, указав при этом её родителя при помощи параметра Parent.
New-ManagementRole –Name “Mailbox Import Export Test” – Parent “Mailbox Import Export”
Примечание: Вы также можете указать область управления получателями (-CustomRecipientWriteScope) и областями управления конфигурациями (-CustomConfigWriteScope) непосредственно во время создания роли, это удобно, но для наглядности, сейчас мы так делать не будем.
После создания роли необходимо отредактировать её разрешения при помощи командлета Get-ManagementRoleEntry. Для начала, нужно удалить все разрешения, кроме одного:
Get-ManagementRoleEntry “Mailbox Import Export Test\*” | where {$_.name –ne “Import-Mailbox”} | Remove-ManagementRoleEntry
Далее нужно добавить необходимые разрешения, не забыв про то, которое мы оставили ранее. При помощи свойства Parameters можно включить только те параметры, которые вы считаете нужными:
Add-ManagementRoleEntry “Mailbox Import Export Test\Export-Mailboxes” –Parameters AllowMerge
image
Рис.4: Создание новой роли Mailbox Import Export Test
Теперь нужно заменить у группы Import/Export Group роль, делается это следующим образом:
Удалить роль из группы ролей можно простым удалением назначения, связывающего их. Для начала определимся с именем назначения, для этого выполним команду:
Get-ManagementRoleAssignment –RoleAssignee “Import/Export Groupe” | fl
В выводе команды найдем имя роли и используем его в следующей команде:
Remove-ManagementRoleAssignment “Mailbox Import Export-Import/Export Groupe”
image
Рис.5: Удаление роли из группы ролей.
Теперь добавим новую роль Mailbox Import Export Test группе Import/Export Group, для этого создадим новое назначение:
New-ManagementRoleAssignment -SecurityGroup "Import/Export Group" -Role "Mailbox Import Export Test"
image
Рис.6: Добавление новой роли группе ролей.
При этом имя назначения будет сгенерировано автоматически. Если вас это не устраивает, то вы можете воспользоваться параметром Name.
Если вы не назначили область действия роли при её создании, то она получила область от своего родителя, соответственно теперь нам нужно её изменить.
Для этого нужно ответить на вопрос «Где?» и создать соответствующую область действия (Scope). Делается это следующей командой:
New-ManagementScope –Name “Users Mailboxes” -RecipientRestrictionFilter {memberofgroup -eq "ou=Users,dc=test-mail,dc=local"}
Как вы помните из первой части, у каждой роли есть несколько типов областей. Чтобы изменить их все одновременно, нужно использовать следующую синтаксическую конструкцию:
Get-ManagementRoleAssignment -RoleAssignee | Set-ManagementRoleAssignment -CustomRecipientWriteScope -CustomConfigWriteScope -RecipientRelativeScopeWriteScope < MyDistributioGroups | Organization | Self> -ExclusiveRecipientWriteScope -ExclusiveConfigWriteScope -RecipientOrganizationalUnitScope
Изменить конкретный тип области действия группы, можно например вот так:
Get-ManagementRoleAssignment –RoleAssignee “Import/Export Group” | Set-ManagementRoleAssignment –CustomRecipientWriteScope “Users Mailboxes”
image
Рис.7: Изменения области действия группы ролей.

Итоги

В результате решения данной задачи мы:
  • Выяснили, какой встроенной роли принадлежат необходимые командлеты (Get-ManagementRoleEntry “*\Import-Mailbox”);
  • Проверили связи роли с группами (Get-ManagementRoleAssignment);
  • Создали новую группу ролей - Import/Export Group, связали её с ролью и добавили пользователей (New-RoleGroup);
  • Создали дочернюю роль Mailbox Import Export Test (New-ManagementRole);
  • Отредактировали набор командлетов дочерней роли (Get / Add -ManagementRoleEntry);
  • Удалили старые роли из группы Import/Export Group (Remove-ManagementRoleAssignment);
  • Связали роль Mailbox Import Export Test с группой Import/Export Group (New-ManagementRoleAssignment);
  • Создали новую область действия Users Mailboxes (New-ManagementScope);
  • Отредактировали область действия группы Import/Export Group (Set-ManagementRoleAssignment).
В данной статье я постарался показать основные приемы работы с новой моделью управления доступом к Exchange 2010. RBAC – это очень мощная и гибкая технология, которая позволит вам решать самые сложные вопросы делегирования полномочий. Более подробную информацию вы всегда сможете найти в библиотеке TechNet - http://technet.microsoft.com/en-us/library/dd297943.aspx.

14 комментариев:

Илья комментирует...
Этот комментарий был удален автором.
Илья комментирует...
Этот комментарий был удален автором.
Илья комментирует...
Этот комментарий был удален автором.
Илья комментирует...

Вот что я делаю:
Узнаю какие командлеты есть у роли:
Get-ManagementRoleEntry "Mail Recipient Creation\*"

Узнаю к чему она пренадлежит:
Get-ManagementRoleAssignment -role "Mail Recipient Creation" | fl Identity

Создаю группу и она будет отображаться в Active Directory:
New-RoleGroup -Name "Create Mailbox Group" -Roles "Mail Recipient Creation" -Members TestUser

Создаю подгруппу для более тонкого управления правами:
New-ManagementRole –Name “Create Mailbox” –Parent “Mail Recipient Creation”

Оставляю у подгруппы только создание ящиков:
Get-ManagementRoleEntry “Create Mailbox\*” | where {$_.name –ne “New-Mailbox”} | Remove-ManagementRoleEntry

Узаню как полностью называется роль:
Get-ManagementRoleAssignment –RoleAssignee “Create Mailbox Group” | fl

Удаляю старую связь с ролью Recipient Creation:
Remove-ManagementRoleAssignment “Mail Recipient Creation-Create Mailbox Group”

Связываю группу с подгруппой:
New-ManagementRoleAssignment -SecurityGroup "Create Mailbox Group" -Role "Create Mailbox"

Я правильно всё понял?

И если мне необходимо расширить права для поддгруппы, то я выполняю:
Add-ManagementRoleEntry “Create Mailbox\Get-RemoteMailbox” –Parameters AllowMerge

???

Илья комментирует...

Понял что не много перепутал понятия Роль и Группа. Группа это Create Mailbox Group и к ней уже привязывается создаваймая Роль. Роль в данном случии Create Mailbox.

Алексей Богомолов (Alexx) комментирует...

Илья, давайте резюмируем - вы разобрались с проблемой, или же вопросы остались?

Илья комментирует...

Мне самому это интересно. Я правильно написал последовательность и синтаксис командлетов? И также не подскажите Вы как мне создать область применения для Роли "Create Mailbox"? Спасибо!

Илья комментирует...

Алексей, при попытке добавить командлетов к "Create Mailbox":
Add-ManagementRoleEntry "Create Mailbox\Remove-Mailbox" -Parameters AllowMerge
выдаёт ошибку:
Запись роли управления "(Microsoft.Exchange.Management.Power hell.E2010) Remove-Mailbox -AllowMerge" не удается добавит
ь в роль управления "Create Mailbox", так как ее родительская роль не содержит следующие параметры для этой же записи р
оли: "AllowMerge".
+ CategoryInfo : InvalidOperation: (Create Mailbox:ADObjectId) [Add-ManagementRoleEntry], InvalidOperatio
nException
+ FullyQualifiedErrorId : 72C0D1AB,Microsoft.Exchange.Management.RbacTasks.AddManagementRoleEntry

Илья комментирует...

разобрался. Надо писать без -Parameters AllowMerge

Илья комментирует...

В конце выдаёт что нет прав на командлет "Enable-Mailbox" который пренадлежит к Роле "Mail Recipients". Тогда получается я выбрал не правильную родительскую Роль для своей роли? Или я могу добавить командлет "Enable-Mailbox" для своей Роли "Create Mailbox" у которой родительская Роль "Mail Recipient Creation"?

Илья комментирует...

Получилось! Изменил у Роли "Create Mailbox" родительскую роль с "Mail Recipient Creation" на "Mail Recipients". И также добавил два командлета без которых работать не будет "Enable-Mailbox" и "Get-MailboxDatabase".

Теперь буду думать как дать права на отключение почтовых ящиков...

Denis комментирует...

У меня вопрос, у меня стоит Exchange в режиме hosting, управление только из консоли. У меня пользователи через веб могут и отправлять и принимать почту, а при попытке подключится клиентом не авторизируются на SMTP серевере, но если добавить пользователей в группу Organization Management то авторизация проходит успешно в чем проблема и как мне дать доступ всем пользователям домена к смтп серверу?

Алексей Богомолов (Alexx) комментирует...

По SMTP пользователи авторизуются на Receive Connector`e, соответственно смотреть надо его настройки, либо создайте новый, чисто для клиентских подключений.

Denis комментирует...

А по практичней ответа нет? Что я там должен увидеть?

Отправить комментарий