Очевидно, что любая заранее сконфигурированная компьютерная система, в последствие требует не только постоянного контроля, но и возможности легкого доступа к функциям управления. Если процесс внедрения может происходить непосредственно с консоли сервера, то вопросы администрирования крайне неудобно решать таким образом.
Я думаю, что читатель со мной согласится, если я скажу, что в подавляющем большинстве организаций сервера находятся совсем не там, где сидят их администраторы, т.е. нельзя просто развернуть стул и получить прямой доступ к консоли сервера. А раз так, то абсолютно обосновано требование технического персонала, иметь инструменты, позволяющие выполнять свои задачи «не вставая с рабочего места». Здесь кто-то может сказать, что для этого уже существует удаленный рабочий стол Windows и нечего тут «изобретать велосипед». В какой степени это верно, но использование RDP не всегда удобно и в некоторых случаях не приемлемо. Неудобно потому, что если, у вас достаточно много серверов, то подключаться к каждому из них несколько утомительно, гораздо проще открыть локальную консоль PowerShell и уже иметь подключение ко всем из них, либо запустить локально установленную Exchange Management Console и работать со всеми серверами одновременно, но уже через графический интерфейс. А не приемлемо, потому, что часто бывают ситуации, когда сотруднику необходимо делегировать одно-два строго определенных действия, следовательно, пускать его в терминальный сеанс сервера не совсем правильно с точки зрения безопасности, гораздо лучше, если у него будет только доверенный набор кнопок в EMC и только разрешенные командлеты в EMS.
Что касается стандартных служб Windows Server, то Microsoft дает нам набор утилит удаленного администрирования RSAT (Remote Server Administration Tools), которые мы всегда можем скачать, установить на рабочую станцию и использовать оснастки служб Windows так, как будто мы находимся непосредственно на сервере. RSAT – это хорошо, но в этом случае мы получаем доступ только к службам самого сервера, а как быть с ПО, установленном на нем, например с сервером Exchange 2010? Здесь разработчики Microsoft тоже не оставили системных администраторов без поддержки и дали им возможность полноценного удаленного управления, как через стандартную графическую оболочку Exchange Management Console (EMC), так и через командную консоль Exchange Management Shell (EMS).
Удаленное подключение
Для того чтобы управлять сервером удаленно, логично, что к нему необходимо как-то подключиться. Так вот, в случае с Exchange Server 2010, любые удаленные подключения происходят через виртуальный каталог IIS (Internet Information Services), который носит название PowerShell (рис.1).
Рис.1: Виртуальный каталог PowerShell в диспетчере IIS.
При этом подключение осуществляется по протоколу HTTP, а при аутентификации по умолчанию используется Kerberos, само же взаимодействие происходит при помощи WinRM и новой функции Remote PowerShell. Раз речь зашла о Remote PowerShell, то на клиенте должен быть установлен Windows Management Framework, в который входят Windows PowerShell 2.0 и WinRM. Подробнее о Windows Management Framework можно почитать в библиотеке TechNet (http://technet.microsoft.com/ru-ru/library/dd335147.aspx).
Так как клиенты подключаются к виртуальному каталогу по протоколу HTTP на 80-й порт, то это дает нам возможность с легкостью опубликовать данный веб-сервер в сеть Интернет и работать удаленно уже в прямом смысле этого слова, из любой точки, где есть выход в сеть Интернет. Публикацию каталога PowerShell можно осуществить любыми доступными средствами, например, при помощи корпоративного шлюза на базе TMG или ISA сервера, при этом можно настроить HTTPS-переадресацию для HTTP-соединения и в результате получить защищенный шифрованный канал между клиентом и шлюзом, что усилит безопасность работы.
Нужно заметить, что подключаться удаленно к Exchange 2010 по протоколу HTTP могут клиенты только с доменных компьютеров, если вы хотите работать с компьютера, который не входит в домен организации Exchange, то вам для подключения в любом случае придется использовать HTTPS-соединение.
Подготовка пользователя
Прежде чем давать пользователю возможность удаленного доступа к организации Exchange, нужно определиться со списком прав, которые вы хотите ему делегировать.
Для управления правами пользователей, в Exchange 2010 введена новая модель управления доступом - Role Based Access Control (RBAC), которая пришла на смену спискам контроля доступа (ACL). Основное отличие в данном случае состоит в том, что разрешения ассоциируются не с объектами AD, такими как серверы и почтовые ящики, а с задачами, при этом в RBAC пользователю присваивается объединение всех ролей и прав, которые для него назначены.
В процессе аутентификации сервер Exchange 2010 выполняет проверку RBAC и получает список ролей, назначенных пользователю. В каждой роли управления есть список командлетов и их параметров, которые могут быть использованы. Таким образом, при создании среды пользователя, в нее добавляются только те командлеты и параметры, к которым есть доступ.
RBAC – это отдельная тема, уже описанная ранее в одном из циклов статей (http://www.alexxhost.ru/2010/04/role-based-access-control-rbac-exchange.html), здесь я лишь приведу пример делегирования пользователю права выполнять операции импорта/экспорта почтовых ящиков.
Импорт/экспорт почтовых ящиков выполняется при помощи командлетов Import-Mailbox и Export-Mailbox (в Exchange 2010 SP1 для этой цели введен ряд новых командлетов, например New-MailboxImportRequest и New-MailboxExportRequest, они позволяют более гибко использовать операцию импорта/экспорта), данные командлеты включены в роль Mailbox Import Export, о чем свидетельствует команда
Get-ManagementRoleEntry “*\Import-Mailbox”
При этом данная роль связана только с группой Organization Management, у которой есть право лишь делегирования. Выяснили мы это при помощи команды:
Get-ManagementRoleAssignment -Role "Mailbox Import Export" | fl Identity
В результате, подключившись к серверу Exchange из под учетной записи, входящей в группу ролей Organization Management, мы можем делегировать выполнение необходимых командлетов по крайней мере двумя способами:
- Связать пользователя непосредственно с ролью Mailbox Import Export, тем самым дав ему право выполнять командлеты, находящиеся в этой роли:
New-RoleAssignement -Role "Mailbox Import Export" -User User1
Как вы понимаете, это не совсем правильный подход к делегированию полномочий, т.к. со временем накопится столько связей, что вы в них попросту не разберетесь. Гораздо правильнее использовать другой подход:
- Создать группу ролей, например Remote Admins, включить в неё все роли, которые планируется делегировать сотрудникам и добавить сотрудников уже непосредственно в группу ролей. Делается это командой:
New-RoleGroup -Name "Remote Admins" -Roles "Mailbox Import Export" -Members User1
К командлету New-RoleGroup
можно добавить такие параметры, как –DisplayName
и
–Description.
Теперь, если мы отправимся в Active Directory, то увидим, что у нас образовалась новая группа безопасности Remote Admins в OU Microsoft Exchange Security, членом которой стал User1.
Также членством в группах ролей RBAC легко управлять через Exchange Control Panel, как показано на рисунке 2.
Рис.2: Управление членством в группах RBAC при помощи ECP.
После того, как вы определились с тем, какие командлеты будет выполнять удаленный пользователь, можно для него включать само удаленное управление. Делается это присвоением параметру RemotePowerShellEnabled, учетной записи пользователя, значения True при помощи команды:
Set-User YourUser -RemotePowerShellEnabled $True
Активировав разрешение на удаленное подключение к PowerShell можно двигаться далее.
Управление через оснастку Exchange Management Console (EMC)
Начнем с простого, а именно с подключения к серверу Exchange через EMC. Наверняка каждый, кто хоть раз устанавливал сервер Exchange 2010, замечал, что в процессе выбора ролей можно выбрать для установки отдельно компонент Management Tools (Средства управления) (рис.3), собственно эта возможность и служит для того, чтобы инсталлировать оснастку управления Exchange на отдельный сервер или рабочую станцию.
Рис.3: Установка Exchange Management Tools.
Нужно иметь ввиду, что установить средства управления Exchange можно только на современные операционные системы, такие как:
- Windows 7
- Windows Vista с пакетом обновления 2 (SP2)
- Windows Server 2008 с пакетом обновления 2 (SP2)
- Windows Server 2008 R2
При этом ОС обязательно должна быть 64-х битной, т.к. сам Exchange 2010 существует только в 64-х битной редакции.
Средства управления можно установить и в автоматическом режиме при помощи команды
Setup.com /R:MT
Инсталлировав графическую консоль управления нужно её открыть и подключиться к удаленному серверу Exchange при помощи действия Добавить лес Exchange…, (см. рис. 4).
Рис.4: Подключение к серверу Exchange черeз EMC.
В поле адреса указываем либо имя сервера, либо URL расположения виртуального каталога PowerShell, на котором запущен Remote PowerShell и нажимаем кнопку ОК. В результате будет предпринята попытка подключиться по протоколу HTTP на 80-й порт указанного сервера, с использованием проверки подлинности на основе Kerberos.
После успешного подключения мы увидим классическую консоль управления сервером Exchange, точно такую же, какую можно запустить на самом сервере. При этом нужно понимать, что интерфейс будет меняться в зависимости от того, какой учетной записью вы пользуетесь для подключения, и соответственно в какие группы ролей RBAC входит эта учетная запись.
Одним из преимуществ удаленного использования Management Tools является то, что вы можете, подключив в одну консоль сразу несколько серверов, находящихся в разных лесах Active Directory, осуществлять перемещение почтовых ящиков между лесами, создав простой запрос на перемещение командой New Move Request.
На этом тему графической консоли управления закончим и далее поговорим про командную консоль (EMS) во второй части.
5 комментариев:
Если ПК, на котором установлена EMC, существует вне домена и локальной сети, а isa или FF TMG не используются, гораздо удобнее опубликовать EMC через RemoteApp.
Согласен, достаточно интересный вариант!
Добрый день.
Отличная статья. Спасибо.
Хотел бы поинтересоваться можно ли эту консольку на windows 8 установить?
Да, должно работать - http://www.petri.co.il/install-exchange-2010-management-tools-windows-8.htm#
Привет, может знаете по каким причинам консоль может не устанавливаться, вываливается ошибка: "не выбрана ни одна роль" Пробовал разные дистрибутивы с разными сервис паками, результат один и тот же. Операционка 2008r2
Отправить комментарий