Exchange 2007: receive connector’ы и включение релея для анонимных пользователей

Одно из самых приятных отличий Exchange 2007 от Exchange 2003 – receive connector’ы (соединители приёма).

Расскажу вкратце о том, чем они хороши, а также о том, куда пропала вкладка Relay Restrictions.

В славные времена Exchange 2003 настройки приёма сообщений по SMTP делались для всего сервера сразу. Конечно, можно было на одном Exchange создать несколько виртуальных SMTP серверов c разными настройками и прикрепить каждый виртуальный сервер к одному из локальных IP адресов сервера Exchnage. Но такой вариант редко был полезен.

В итоге, если в сети был хотя бы один умный МФУ, который умел отсылать результаты сканирования документов на почту, но при этом совершенно не подозревал об аутентификации, то рано или поздно приходилось делать страшное – разрешать отсылку писем без аутентификации всем подряд.

Вот как настраивалась аутентификация.

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

А вот так настраивался релей.

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

С выходом Exchange 2007 для любителей разрешать пользователям минимально необходимый набор действий наступило раздолье. Теперь можно создавать receive connector’ы с уникальными настройками аутентификации хоть для каждого устройства в сети.

Receive connector – это, фактически, набор правил для почтовых серверов с ролями Hub Transport и Edge Transport, которые объясняют серверам, что делать с полученными по SMTP(S)-протоколу сообщениями.

Согласно этим правилам серверы:

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

Receive connector’ы нужны исключительно для того, чтобы правильно разрулить поступающий на Hub Transport Server/Edge Transport Server SMTP-трафик. Это могут быть сообщения от соседних почтовых серверов, от почтовых серверов вне организации, от почтовых клиентов не умеющих работать с MAPI, от МФУ, от серверных приложений и т.д. и т.п.

Стоит помнить, о существенном ограничении – для каждого клиентского IP адреса должен быть активен только один receive connector.

Exchange упорно сопротивляется попыткам пересечь коннекторы.

В настройках коннектора можно разрешить принимать сообщения как от прошедших проверку (Exchange users), так и от неизвестных (Anonymous users) пользователей.

Загадочная вкладка Permission Groups.

Однако настроек релея в консоли управления больше нет. Более того, на поверку выясняется, что если прошедшие проверку пользователи (Exchange users) могут пользоваться коннектором, то им автоматически разрешён релей. А вот если галкой отмечена группа Anonymous users, то не прошедшие проверку пользователи хоть и могут отправлять почту, но только в пределах почтовой организаци.

Да и вообще всё это выглядит странно. Кто такие Exchange users и Partners, нет таких групп в AD. И если вкладка называется Permission Group, то какие «пермишены» получают эти группы если они отмечены галкой. И самый главный вопрос – как всё же разрешить анонимным пользователям отсылать сообщения наружу?

Давайте разбираться во всей этой путанице.

Начнём с того, что Exchange 2007, так же как и его предшественник, хранит большинство настроек в Active Directory (AD).  Receive connector’ы – не что иное, как объекты в AD. Их можно найти в разделе «конфигурация» с помощью оснастки adsiedit.msc из пакета support tools примерно по такому пути:

CN=SMTP Receive Connectors,CN=Protocols,CN=ExcServer1,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=ExchangeOrganizationName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain,DC=ru.

Консоль управления Exchange

А это adsiedit.msc, ничего не напоминает?

Так вот, когда вы расставляете галочки на вкладке Permission Groups свойств коннектора, эти самые «пермишен группы» получают заранее предопределённый разработчиками Exchange набор разрешений на объект  AD, соответствующий этому коннектору.

Увидеть действующие на коннектор разрешения можно как из PowerShell командой Get-ReceiveConnector «Receive Connector Name» | Get-ADPermission, так и открыв вкладку Security объекта коннектора в AdsiEdit – кому как удобнее.

Само-собой, в AD нет групп Exchange users, Anonymous users и некоторых других с вкладки Permission Groups, но им сопоставлены реально существующие в AD группы.

В хелпе есть замечательная табличка под номером 6, в которой объясняется, какой Permission группе какая доменная группа безопасности соответствует, и какие разрешения она получает, если отмечена галкой на вкладке Permission Groups.

Вот наиболее интересный кусок этой таблицы:

Permission group name	Security principals	Permissions granted on Edge Transport servers	Permissions granted on Hub Transport servers
Anonymous	Anonymous users	Submit messages to server Accept any sender Accept routing headers	Submit messages to server Accept any sender Accept routing headers
ExchangeUsers	Authenticated users (well-known accounts are excluded)	Not available	Submit messages to server Accept any recipient Bypass anti-spam filters

Несмотря на некоторые неточности в написании названий групп, из таблицы становится ясно, что группе Exchange users сопоставлена группа Authenticated users (Прошедшие проверку), а группе Anonymous users – группа ANONYMOUS LOGON (Анонимный вход).

А теперь обратите внимания на отличия в разрешениях, которые получают по умолчанию Anonymous users и Exchange users.

• Accept any sender. Анонимы могут использовать в качестве адреса отправителя что угодно, а авторизованные пользователи – только свой собственный почтовый адрес. И это понятно, проверить адрес анонима невозможно, а позволять прошедшим проверку пользователям шутки ради отсылать письма гендиректору с адреса vvputin@cremlin.ru не стоит.
• Bypass anti-spam filters. Письма прошедших проверку пользователей минуют проверку спамфильтром.
• Accept any recipient. И самое важное, прошедшие проверку пользователи могут посылать письма адресатам вне организации, а анонимы не могут.

Вот почему даже если  группа Anonymous  users отмечена галкой на вкладке Permission Groups, всё равно отослать письмо наружу без авторизации не получается.

Дело за малым, добавить этой группе недостающие разрешения на коннектор. Сделать это можно как из оснастки AdsiEdit, так и из консоли PowerShell .

Причём тут есть различия. В свойствах коннектора в AdsiEdit вы увидите опцию «Submit Messages to Any Recipient» и вам надо будет просто отметить её галкой.

Ставите галку здесь и релей разрешён.

А вот с PowerShell всё сложнее. Сначала нужно выяснить, как обозначается разрешение, соответствующее видимому имени (display name)  »Submit Messages to Any Recipient». Для этого придётся изучить таблицу 4 хелпа, из которой становится ясно, что нам нужно разрешение «ms-Exch-SMTP-Accept-Any-Recipient».

Permission	Display name	Description
ms-Exch-SMTP-Accept-Any-Recipient	Submit Messages to any Recipient	This permission allows the session to relay messages through this connector. If this permission isn’t granted, only messages addressed to recipients in accepted domains are accepted by this connector.

Потом придётся искать, какой командой можно поменять свойства безопасности receive connectora’а.

Хотя можно поступить проще, и подглядеть готовую командную строку на текнете. Вот она:

Get-ReceiveConnector «Receive Connector Name» | Add-ADPermission -User «NT AUTHORITYANONYMOUS LOGON» -ExtendedRights «Ms-Exch-SMTP-Accept-Any-Recipient»

Ну и напоследок напрашивается вопрос . Зачем всё так усложнять вместо того, чтобы сделать одну единственную галку в настройках receive connector’а – разрешить релей для неавторизованных пользователей?

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