Подключение к exchange вне домена

Автоматическое подключение почтового ящика в Outlook (Mailbox auto mapping)

Добрый день! Уважаемые читатели и гости лучшего IT блога pyatilistnik.org. Я очень мало пишу про Microsoft Exchange и не заслуженно обхожу данный программный продукт, поэтому сегодня я хочу открыть небольшой цикл статей на эту тему, и передать некоторый практический опыт в данной области.

Я думаю эти записи будут полезны начинающим системным администраторам, кто только знакомится с этим почтовым комплексом. Уж так завелось, что в Москве, почти каждая компания имеет у себя почтовый сервер Exchange, в регионах все сложнее, там выбирают чаще всего, свободное ПО, по типу Zimbra или MDaemon.

В этой заметке я бы хотел поговорить на тему автоматического подключения почтового ящика в Outlook, через функцию Mailbox auto mapping (автоматическое сопоставление почтовых ящиков).

Что такое Mailbox auto mapping

Наверняка в подавляющем количестве организаций, внутренняя инфраструктура имеет домен Active Directory, для централизованного управления, и это понятно, это очень удобно для системного администратора. Админам доступны групповые политики и такие программные продукты по централизованному распространению программ, как SCCM.

Ни один бизнес процесс, сейчас невозможно представить без корпоративной почты, она может быть в облаке «Бизнес mail» или же на своих серверах, и вот для домена Active Directory, самым удобным вариантом считается Microsoft Exchange Server. Так как он полностью интегрируется в данную среду и все другие продукты Microsoft, а так же упрощает администратору настройку почтового клиента, Outlook на всех платформах.

Уже не нужно объяснять пользователям, что такое IMAP или POP3, они просто открывают Outlook и у них все работает.

Mailbox auto mapping или как ее еще называют в русскоязычной локализации «Автоматическое сопоставление почтовых ящиков» — это функция позволяющая при наличии определенных прав подключить пользователю почтовый ящик на автомате, без его участия. Он просто открывает почтовый клиент Microsoft Outlook и у него появляется дополнительный почтовый ящик, с которым он может взаимодействовать.

Какие права должны быть для Mailbox auto mapping

Функция автоматическое сопоставления почтовых ящиков появилась давно, еще в Exchange 2010 SP1, до первого Service Pack, все делалось в ручном режиме. По умолчанию она работает, когда вы даете пользователю полные права (Full Access), но никто вам не мешает дать права «Только на чтение» и самому добавить пользователя для автомапинга почты, все будет прекрасно работать.

Хочу отметить, что функция автоматического подключение почтового ящика в Outlook, не будет работать если вы дадите разрешения на группу безопасности Active Directory, права появятся, но ящик сам не подцепиться, это нужно будет делать вручную. Официально я нигде не нашел ветки обсуждения или официального подтверждения со стороны Microsoft, так показала практика.

Недостатки функции Auto Mapping

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

• Увеличении загрузка почтового клиента
• Нагрузке на компьютер, не у всех в компаниях есть рабочие станции с SSD дисками и процессорами Core i5
• Неработоспособность самого почтового клиента Outlook. Приведу простой пример, если рассматривать версию Outlook 2007, то там допустимый размер профиля, составляет 20 ГБ, после чего клиент просто перестает работать, у вас будет постоянно переиндексация профиля и куча всевозможных проблем, и вот представьте ситуацию, что у сотрудника его основной профиль 5 ГБ, а вот дополнительный 25, он просто не сможет работать с таким размером ящика, и не у всех есть возможность обновиться до Outlook 2013-16, да и архивацию не всегда можно выполнить.
• Еще распространенный случай, что когда у сотрудника забирают права от дополнительного ящика, то в Outlook он продолжает видится, что так же будет отрицательно влиять.

Но не спешите расстраиваться, компания Microsoft это предусмотрела в Exchange 2010 SP2, добавив функционал возможности отключения автоматического сопоставления ящиков для пользователей

Как работает механизм автоматического подключения почтового ящика

Когда вы назначаете пользователю полные права, у него обновляется атрибут в Active Directory, отвечающий за автомапинг почтового ящика, называется он msExchDelegateListLink. Distinguished Nameузнать уникальное имя. В данном атрибуте прописываются  учетной записи, оно уникально.Если вы дали права на чтение, то вы должны пользовательской учетки (Distinguished Name) и прописать его вручную в атрибуте msExchDelegateListLink.

У меня есть тестовая учетная запись, через редактор атрибутов, я нашел у нее атрибут msExchDelegateListLink, в котором вижу, что у Семина Ивана Львовича, ест ьправа на данный почтовый ящик, и будет произведен автоматическое подключение в Outlook.

И так мы выяснили, что у почтового ящика заполняется атрибут msExchDelegateListLink, в то же время у учетной записи, которой вы предоставили права, будет изменен атрибут msExchDelegateListBL. Он будет доступен только на чтение, он просто перечисляет почтовые ящики, которые будут автоматически подключены при открытии Outlook,

Включение и отключение Mailbox auto mapping

Как я писал выше, функция автоматического подключения почтового ящика будет работать сразу, если вы дадите полные права, и будет работать в ручном добавлении при правах на чтение. Но бывают ситуации, что пользователю нужны полные права, а автомапинг необходимо выключить, все те же примеры с производительностью Outlook. Тут есть два врианта:

1. Вы удаляете нужное DN из атрибута msExchDelegateListLink, через редактор атрибутов или ADSI Edit
2. Через power shell, я рассмотрю его, так как первый метод интуитивно понятен.

Для примера дадим пользователю pyatilistnik права с полным доступом, но не включим автомапинг:

Add-MailboxPermission -Identity SharedMBX -User 'pyatilistnik'  -AccessRight FullAccess -InheritanceType All -Automapping $false

Если права уже назначены, придется сначала их забрать, а потом переназначить заново:

Remove-MailboxPermission -Identity SharedMBX -User 'pyatilistnik' -AccessRight FullAccess -InheritanceType All

Add-MailboxPermission -Identity SharedMBX -User1 'pyatilistnik' -AccessRight FullAccess -InheritanceType All -Automapping $false

Источник: http://pyatilistnik.org/mailbox-auto-mapping/

Базовая настройка Exchange Server 2019. Часть 1

Базовая настройка Exchange Server является обязательной задачей после установки продукта. О том как выполнить установку, какие необходимо учесть нюансы можно ознакомится по следующей ссылке.
Весь процесс базовой настройки разбит по кейсам, итог выполнения которых — работоспособный Exchange сервер. Будут реализованы возможности отправки и получения электронной почты, а также выполнены условия для подключения клиентов. Виду объема необходимой конфигурации, весь материал разбит на две статьи. В первой части рассматриваются следующие вопросы:

• Добавление обслуживаемого домена (accepted domains)
• Настройка соединителя отправки (send connector)
• Настройка внешних URL адресов Exchange сервера

Во второй:

• Выпуск SSL сертификатов для Exchange сервера
• Настройка политики адресов электронной почты

Добавление обслуживаемого домена (accepted domains)

Обслуживаемый домен (accepted domains) — это домен, который используется Exchange организацией для получения и отправки почтового трафика. В рамках него (типы Authoritative и Internal Relay) могут формироваться почтовые адреса пользователей, общих почтовых ящиков, групп распространения и других объектов Exchange которым возможно назначить почтовый адрес.
По умолчанию, сразу же после развертывания, доступен лишь один обслуживаемый домен:

Обслуживаемые домены (accepted domains) Exchange

Имя его соответствует домену Active Directory. Всего существует три типа обслуживаемых доменов:

1. Уполномоченный домен (Authoritative)
2. Домен внутренней ретрансляции (InternalRelay)
3. Внешний домен ретрансляции (ExternalRelay)

Домены первого типа полностью обслуживаются Exchange организацией. При поступлении на него входящего письма происходит поиск почтового адреса в глобальном каталоге Active Directory. В случае его отсутствия будет возвращен NDR (Not Delivery Report).

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

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

Если письмо будет доставляться в Exchange организацию, а домен получателя отсутствует в обслуживаемых доменах, оно автоматически будет отклонено с ошибкой 550 5.7.54 SMTP; Unabletorelayrecipientinnon—accepteddomain.

Сам процесс добавления домена необходимого типа выглядит следующим образом:

Добавление обслуживаемого домена в Exchange

Настройка соединителя отправки (send connector)

В Exchange инфраструктуре коннекторы или соединители выполняют задачи обработки входящего и исходящего почтового потока, также участвуют внутри транспортного потока Exchange. Чтобы почтовая инфраструктура могла взаимодействовать с внешними системами по протоколу SMTP, необходимо создать новый соединитель отправки. Для этого следует перейти в раздел почтовый поток (mailflow), во вкладку исходящие почтовые соединители (sendconnectors)

Исходящие почтовые соединители Exchange

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

• Внутренний (Internal)
• Внешний (Internet)
• Партнерский (Partner)

Создание нового почтового соенденителя в Exchange

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

Внешний тип предполагает отправку почты во вне организации, например удаленному почтовому серверу через Интернет.

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

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

Конфигурация доставки почтового соединителя Exchange

Внизу страницы присутствует чек-бокс с включением конфигурации Use the external DNS lookup settings on servers with transport roles. Задействование данной опции позволит не использовать конфигурацию DNS серверов сетевого интерфейса Exchange сервера, а применить настройки из конфигурации самого сервера. Они задаются на странице Servers, в первом же разделе Servers:

Настройка конфигурации сервера Exchange

Необходимая вкладка называется DNS lookups:

Задание внешних DNS серверов в Exchange

Следующий шаг заключается в задании адресного пространства, за которое ответственен соединитель. В случае если создаваемый тип соединителя внутренний или партнерский, задаться конкретный почтовый домен. Например, partnerdomain.com. Если же используется *, коннектор будет обсуживать все существующее пространство имен. Если в конфигурации присутствует несколько коннекторов, один из которых обслуживает пространство *, а второй с partnerdomain.com, приоритет получит последний.

Задание адресного пространства в соединителе отправки Exchange

Чек-бокс Scopedsendconnector даст возможность привязать коннектор к определенному сайту Active Directory, в котором находится сам Exchange. Для базовой настройки Exchange инфраструктуры этот параметр не требуется.

Задание адресного пространства выглядит следующим образом:

Указание адресного пространства в соединителе отправки Exchange

Далее, задаем сервер или сервера Exchange которые могут использовать данный соединитель:

Привязывание исходящего соединителя к серверу Exchange

В моем случае, у меня один и едиснтвенный Exchange сервер с ролью Hub Transport Service:

Указание сервера Exchange в соединителе отправки

Конфигурация исходящего соединителя завершена:

Созданный исходящий Exchange соединитель

Важно учесть, что со стороны сети, Exchange сервер должен иметь доступ по 25-му порту в Интернет (NAT). На Exchange сервер должен быть «проброшен» сделан DNAT с 25-го порта с публичного IP.  Публичный IP используемый в NAT и DNAT должны совпадать.

Помимо правильной сетевой конфигурации необходимо корректно настроить публичную DNS зону почтового домена. Для обмена с внешними почтовыми системами необходимо добавить два типа записей — MX и А.

• Запись типа А должна иметь значение внешнего IP адреса, с которого сделан DNAT на приватный адрес Exchange сервера. В случае применения пограничного Edge сервера, DNAT делается на него;
• MX запись указывает на A запись.

Настройка внешних URL адресов Exchange сервера

Базовая настройка Exchange Server не заканчивается добавлением обслуживаемого домена и настройкой соединителей. Необходимо задать корректные URL адреса для подключения клиентов. Для этого перейдем в настройки конфигурации:

Настройка конфигурации сервера Exchange

Выберем сервер и нажмем на «карандаш» открыв страницу настроек. Далее, необходимо перейти в настройки OutlookAnywhere и задаем внешний домен для подключения клиентов:

Задание настроек Outlook Anywhere для Exchange

Данный домен, в последствии, будет использоваться для публикации Exchange сервера. Этот процесс будет описан в будущей статье.

Задание внешнего домена требуется и для веб каталогов Exchange сервера. Для этого необходимо перейти в конфигурацию virtual directories и найти «гаечный ключ»:

Задание внешнего домена для виртуальных каталогов Exchange

На открывшейся странице задаем необходимую конфигурацию:

Указание внешнего домена для виртуальных каталогов Exchange

Задание внешнего домена по которому будет доступна Exchange инфраструктура необходимо для дальнейшего выпуска SSL сертификатов.

На этом пока все. Если у вас возникли какие-либо вопросы, пожалуйста, пишите в комментарии.

Базовая настройка Exchange Server 2019. Часть 2

Источник: https://ait.in.ua/on-premise/exchange/bazovaya-nastrojka-exchange-server-2019-chast-1.html