Установка/настройка Exchange 2010 в мульти-доменной / хостинг реализации

в 6:40, , рубрики: exchange 2010, microsoft, Microsoft Exchange, ит-инфраструктура, системное администрирование, системное администрирование windows, хостинг, метки: , , , ,

Я хочу описать сложности, с которыми администратор может столкнуться при настройке Exchange для нескольких доменов. Я не буду вдаваться в подробности решения данных проблем, однако опишу в общих словах как их следует решать и предоставлю ссылки на ресурсы (Microsoft или блоги специалистов по Exchange) где описано подробно решение тех или иных сложностей.
Я стараюсь обхватить как можно больше «тонкостей», однако что-то мог и забыть :)

Кому интересно – под кат. Внимание: очень много букв!

Прежде всего, стоит сказать о сложностях, которые мы встретим при внедрении Exchange в описанной в теме конфигурации:
Подготовка и создание объектов. Один из важнейших пунктов. Нужно быть уверенным, что объекты создаются правильно, в нужном месте и с правильными атрибутами, что в дальнейшем поможет Exchange-среде правильно функционировать.
Обеспечение безопасности для каждого домена/клиента. Сюда входит огромное множество функций и настроек, но если говорить просто – мы должны убедиться, что пользователи одной организации не будут видеть пользователей/данные из другой организации. Об этом надо думать сразу, при создании AD-инфраструктуры (к примеру, иерархия OU и права на них).
Системные параметры и политики. У Exchange есть много функций, доступных пользователям и администраторам, и эти функции могут управляться разными способами. Некоторые настройки влияют на отдельного пользователя, некоторые на БД, а некоторые на всю Exchange-организацию.
Транспорт. Очередным пунктом в настройке, который затронет всех пользователей – это транспорт. Речь идет о проблемах, когда Exchange пытается маршрутизировать почту между двумя доменами в режиме, будто они находятся в пределах одной организации, и пытается предоставить весь богатый функционал, который следует предоставлять пользователям одного AD-домена.
Дизайн и архитектура системы. Тут я пытаюсь сказать о именах для таких служб как OWA; URL, которые предоставляются клиентам с Outlook; конечных точках для таких сервисов как AutoDiscover и Outlook Anywhere. Эти адреса/hostname видны для всех клиентов и должны быть не привязаны ни к одному из них (non-branded) для избежания дальнейших проблем.
Масштабируемость. Еще одним ключевым атрибутом является масштабируемость. Речь идет не только о максимальном количестве доменов/пользователей, но и о расчете нагрузки, предсказании роста и определении слабых мест, чтобы понять как избегать проблем.

Теперь я постараюсь сказать о каждом пункте в частности:
Структура AD. Тут стоит придерживаться нескольких правил:
1) Каждый домен – отдельный OU.
2) Все пользователи каждого домена – в соотв. группе для этого домена.
3) Использование Active Directory List Object Mode. При включении List Object Mode в настройках Security (Advanced) для каждой OU можно будет выставлять права на List. Вот тут-то нам и потребуется группа из второго пункта – разрешить List OU определенного домена можно только пользователям этого домена. Это позволит разграничивать видимость объектов.

Обеспечение безопасности для каждого домена/клиента. Я уже начал обсуждать это в предыдущем пункте:
1) Использование AD List Object Mode.
2) Использование модифицированных Global Address List и Offline Address Book для каждого домена. Для этого потребуется создавать Address Book Policy (которые стали доступны только в Exchange 2010 SP2). В блоге Михаила Токарева подробно описан этот процесс.
3) Порталы администрирования для администраторов в каждом домене. Для того, чтобы определённый пользователь мог сам администрировать определенную группу пользователей Exchange (через ECP), в Microsoft был создан механизм Role Groups. О том, как создавать группы ролей (где Вы и создадите набор прав для администраторов) написано тут. Однако при создании эти ролей Вам нужно будет указывать Scope – зоны, на которые они распространяются. В качестве «зон» рекомендую использовать OU (для каждого клиента – свою). О создании таких Management Scopes с помощью PowerShell и командлета New-ManagementScope Вы можете прочитать тут.
4) Я не рекомендую давать права на просмотр Message Tracking Logs (подтверждения о доставке), т.к. они распространяются на всю организацию и Администраторам будет видна вся почта.
5) Изменение прав на календари. По-умолчанию ВСЕ пользователи Exchange будут видеть Free/Busy статус ВСЕХ остальных пользователей Exchange. С помощью командлета Set-MailboxFolderPermission или утилит, таких как ExFolders, отобрать у «Default» пользователя доступ, но предоставить необходимые разрешения пользователям данного домена.
6) Опционально: Биллинг для клиентов. К сожалению, в Exchange не встроено механизмов биллинга, однако Вы можете создавать свои даже на базе Excel. Для получения статистики по ящикам рекомендую ознакомиться с командлетами Get-MailboxStatistics и Get-ActivesyncDeviceStatistics, используя которые (Вы можете фильтровать статистику по клиентам/доменам с использованием PowerShell) можно получить статистику и выгрузить ее в CSV/XLS.
7) Я не рекомендую включать Outlook Protection Rules, т.к. при включенном Outlook Advanced Logging будет доступны данные об SMTP-доменах всех клиентов.
8) Базы Exchange. Многие из тех, кто имеет опыт работы с Exchange скажет, что «удобнее» для каждого клиента создать свою базу и хранить все ящики одного домена в отдельной базе. Но, если у Вас нет веского основания так делать, не разделяйте клиентов по базам. Ведь в случае проблем с 1 базой – вся почта домена будет недоступна, а это неприемлемо. Создайте несколько баз и используйте Automatic Mailbox Distribution и дайте Exchange самому выбирать в какую базу «класть» ящики. О том, как работает Automatic Mailbox Distribution вы можете прочитать здесь.

Системные параметры и политики. Этот пункт очень сильно «пересекается» с предыдущим, поэтому тут я скажу не много.
1) Не надо предоставлять клиентам прямой доступ (LDAP + MAPI). Это плохая идея. Многие хостеры так и делают (к примеру, Masterhost), но я не могу согласиться с правильностью такого решения. ТОЛЬКО RPC over HTTPs (тем более в следующей версии Exchange есть только такой доступ). Такой тип доступа чуть сложнее в начальной настройке но гарантированно избавит Вас от проблем в будущем.
2) Следите за Вашим файрволом. За DDoS-атаками, за возможными bruteforce атаками. Не оставляйте сетевую безопасность «на потом».
3) Я рекомендую отключать политику «авто-блокирования» аккаунтов в случае неверного ввода паролей (иначе злоумышленнику будет очень просто заблокировать аккаунт), но обязательно используйте политики, требующие от пользователей сложные пароли.

Транспорт.
1) Требуется запретить отправку на Distribution-группы из других доменов. Для этого нужно ограничивать отправителей, которые имеют право отправлять на DG и требовать аутентификацию для отправки на DG. Это можно настроить через EMC или командлет Set-DistributionGroup.
2) Ограничение размера писем. К примеру, ограничение размера входящих писем на Edge-сервере должно быть меньше или равно ограничению, установленному для внутренней почты. Обратное будет просто тратой ресурсов Edge-сервера. Помните, что с помощью пользовательских лимитов Вы можете дать пользователю или группе пользователей превышать лимиты, установленные для всей организации Exchange.
3) Настройка маршрутизации почты для «соседних» доменов через внешний relay. Это требуется если Вы хотите полностью «замаскировать» почту от доменов на данном Exchange, если они отправляются домену-«соседу». Конечно, в header’ах останется некоторая информация, однако Вы обеспечите симуляцию того, что почта получена из Интернета, что, в свою очередь, предотвратит resolve этого отправителя во внутреннего.
4) Помните, что если Вы захотите использовать Mutual TLS (о том, что это такое, можно прочитать тут), настройки TLSRecieveDomainSecureList и TLSSendDomainSecureList настраиваются для всей организации Exchange. И если Вы собираетесь предложить данную функцию клиентам, нужно будет убедиться, что они понимают, почему флаг «Безопасно» будет отображаться на некоторых письмах, которые они будут получать.
5) Рекомендуется включить Анти-спам агентов на Hub-серверах, чтобы проверялась почта между доменами. Как это сделать – написано тут.
6) Требуется отключить внутренние сообщения Out Of Office между доменами. Ведь если пользователь выберет «отправлять OOF только внутри моей организации» письмо OOF может уйти пользователю данного Exchange, но из другого домена. Чтобы предотвратить это требуется создать несколько правил транспорта, которые будут разрешать сообщения класса IPM.Note.Rules.Oof.Template.Microsoft (именно этот класс имеют OOF письма) только между одинаковыми доменами (по правилу на домен).
7) Отключить некоторые «подсказки» при отправке писем. При мульти-доменной структуре придется пожертвовать некоторым функционалом, таким как отображение членов групп и предупреждений о том, что у получателя включен OOF-автоответ и т.д. Вы можете менять данные настройки через командлет Set-OrganizationConfig.

Дизайн и архитектура.
1) Используйте общие URL. К примеру, зарегистрируйте домен exchsuperhost.ru. Создайте узлы m.exchsuperhost.ru и m2.exchsuperhost.ru (для отказоустойчивых EDGE – это будут MX с разным приоритетом), mail.exchsuperhost.ru (для клиентского доступа и OutlookAnywhere) и autodiscover.exchsuperhost.ru для Autodiscover. Пускай Ваши клиенты используют CNAME для веб-интерфейсов и Ваши MX-адреса для MX и SPF записей. Это очень сильно упростит администрирование и отслеживание почты.
2) Рекомендую не предоставлять пользователям доступ по POP и IMAP, т.к. это может создать проблемы при миграциях, а также при работе пользователей.
3) Задумайтесь о виртуализации. Microsoft не имеет ничего против виртуализации некоторых ролей Exchange. Это поможет сократить расходы на оборудование и лицензии.
Масштабируемость. Тут все зависит от Ваших клиентов, оборудования и т.д. Все, что я могу посоветовать: не используйте «устаревшие» технологии (такие как Public Folders), рассчитывайте «железные» мощности и место на хранилищах и дисковых полках, старайтесь использовать динамические группы рассылки и максимально автоматизируйте свою работу – PowerShell скрипты, правила транспорта, GAL, политики именования и хранения.

Буду рад ответить на Ваши вопросы и выслушать Ваши советы :) Спасибо!

Автор: pportnoy

Поделиться

* - обязательные к заполнению поля