Отправка через Client Frontend коннектор в Exchange 2013 для трастовых пользователей

Для отправки сообщений от почтовых клиентов по SMTP с авторизацией в Exchange используется отдельный коннектор, который называется Client Frontend. Он использует стандартный для Submission порт 587 и предоставляет возможность авторизоваться для отправки сообщений. Однако здесь есть небольшая проблема. В случае, когда отправку через этот коннектор пытается осуществить пользователь с Linked-ящиком, который авторизуется в другом лесу по доверию (типичная картина для ресурсного леса), используя SMTP-клиент (например Thunderbird), возникает ошибка вида:

550 5.7.1 Client does not have permissions to send as this sender

Самое интересное, что по IMAP или POP3, клиент при этом будет корректно авторизоваться.

Для того, чтобы устранить эту проблему, необходимо явно выдать права. Однако не на коннектор, что кажется вполне логичным (я сам долго и упорно смотрел в этом направлении), а на отключенный объект в ресурсном лесу. Оказывается на нем не хватает разрешения «Send as» для учетной записи из леса с учетными записями, а ведь именно от ее имени и должна осуществляться отправка с точки зрения коннектора. Так что для устранения данной проблемы достаточно просто предоставить право «Send as» для учетной записи из леса учетных записей на отключенную учетную запись в ресурсном лесу. Можно, например, сделать это через оснастку «Active directory Users and Computers» с помощью вкладки «Безопасность» 🙂

sendas

Реклама

Небольшая особенность GAL и RecipientFilter или не отображаются вложенные группы

Microsoft определяет GAL, как хранилище записей о группах, пользователях, контактах в организации Microsoft Exchange:

The global address list (GAL) is a directory that contains entries for every group, user, and contact within an organization’s implementation of Microsoft Exchange.

Механизм работы с GAL достаточно гибкий и позволяет гранулировано управлять попаданием объектов в глобальный список. А добавленная в Exchange 2010 технология Address Book Policy, позволяющая осуществлять разделение адресных книг, значительно расширила возможности работы с адресными книгами.

Это хорошо видно на примере командлета New-GlobalAddressList, который создает новый GAL Так, данный командлет позволяет задать фильтр, который будет определять, какие объекты попадут в созданный GAL. На странице документации приведен пример такого фильтра:

New-GlobalAddressList -Name GAL_AgencyB -RecipientFilter {((RecipientType -eq "UserMailbox") -and (CustomAttribute15 -eq "AgencyB"))}

В данном случае, в создаваемый GAL попадут все объекты класса UserMailbox (почтовые ящики) у которых в Active Directory атрибут «CustomAttribute15» имеет значение «AgencyB».

И вот тут кроется одна маленькая особенность. Если GAL будет создан подобным образом, то он не будет содержать другие объекты, например группы. Для того, чтобы можно было увидеть группы, обычно создается дополнительный список адресов с помощью командлета New-AddressList. Однако, если в этой ситуации попытаться просмотреть членство в группах через адресную книгу Outlook, представленных в созданном адресном списке для групп, то можно обнаружить, что вложенное членство групп не отображается. То есть, например, если в группе существуют вложенные подгруппы, то с их отображением возникнет проблема.

Корни этой проблемы растут из фильтра GAL, заданного ранее, который ограничивает участие только объектами класса UserMailbox. Таким образом, в данной ситуации более правильным вариантом является вот такой фильтр:

((CustomAttribute15 -eq ‘AgencyB’) -and ((RecipientType -eq ‘UserMailbox’) -or (ObjectClass -eq ‘Group’)))

Для изменения уже существующего GAL можно воспользоваться командой:

Get-GlobalAddressList GAL_AgencyB | Set-GlobalAddressList -RecipientFilter «((CustomAttribute15 -eq ‘AgencyB’) -and ((RecipientType -eq ‘UserMailbox’) -or (ObjectClass -eq ‘Group’)))»

Подобный фильтр можно расширять, так, чтобы включить еще и контакты с переговорными, можно воспользоваться таким фильтром:

((CustomAttribute15 -eq ‘AgencyB’) -and ((ObjectClass -eq ‘Contact’) -or (RecipientType -eq ‘UserMailbox’) -or (ObjectClass -eq ‘Group’) -or (RecipientDisplayType -eq ‘ConferenceRoomMailbox’)))

Exchange 2013 и лимиты сообщений

В Exchange максимальный размер почтовых сообщений определяется многими параметрами. Подробно лимиты сообщений рассмотрены здесь — http://technet.microsoft.com/en-us/library/bb124345%28v=exchg.150%29.aspx.

Однако есть еще несколько важных факторов. При работе с веб-службами (OWA, Active-Sync, EWS) начинают действовать другие ограничения. Так, например, для Outlook Web App есть отдельные ограничения на объем передаваемых данных.

В данной статье — http://technet.microsoft.com/en-us/library/hh529949%28v=exchg.150%29.aspx, рассматриваются параметры, отвечающие за ограничения на размер сообщений при работе с веб-службами.

До Exchange 2013 этого было достаточно. В Exchange 2013 появился еще один фактор, который необходимо учесть. Помимо, сосбтвенно, самих приложений Outlook Web App, EWS и Active-Sync, теперь существуют еще и прокси для них (вспоминаем новую архитектуру и особенности нового CAS — http://blogs.technet.com/b/exchange/archive/2013/01/25/exchange-2013-client-access-server-role.aspx). Прокси также имеет свои ограничения, поэтому, помимо параметров заданных в конфигурационных файлах в директории «%ExchangeInstallPath%\ClientAccess\«, необходимо задать аналогичные параметры в соответсвующих файлах в директории «%ExchangeInstallPath%\FrontEnd\HttpProxy«.

Таким образом таблица принимает следующий вид:

ActiveSync %ExchangeInstallPath%\ClientAccess\Sync\web.config MaxDocumentDataSize (в байтах)
maxRequestLength (в килобайтах)
%ExchangeInstallPath%\FrontEnd\HttpProxy\sync\web.config maxRequestLength (в килобайтах)
Exchange Web Services %ExchangeInstallPath%\ClientAccess\exchweb\ews\web.config
и
%ExchangeInstallPath%\HttpProxy\ews\web.config
maxAllowedContentLength (в байтах)
Outlook Web App %ExchangeInstallPath%\ClientAccess\Owa\web.config maxReceivedMessageSize (в байтах)
maxAllowedContentLength (в байтах)
maxStringContentLength (в байтах)
maxRequestLength (в килобайтах)
%ExchangeInstallPath%\FrontEnd\HttpProxy\owa\web.config maxAllowedContentLength (в байтах)
maxRequestLength (в килобайтах)

Однако, и это еще не все. Дополнительные ограничения на объем передаваемых данных также задаются на уровне IIS. В данном случае это параметр maxAllowedContentLength (http://www.iis.net/configreference/system.webserver/security/requestfiltering/requestlimits#005).