В этом разделе приведены подробные сведения о модели разрешений транспорта в Microsoft Exchange Server 2007. В Microsoft Exchange Server 2007 термин «транспорт» используется для обозначения процесса передачи сообщений с одного сервера на другой. При передаче сообщений с сервера почтовых ящиков на транспортный сервер-концентратор используется протокол MAPI. При передаче сообщений с одного транспортного сервера-концентратора на другой используется протокол SMTP. Каждый сеанс связи между серверами может включать дополнительный этап проверки подлинности. При запросах на подключение может понадобиться авторизация.
Проверка подлинности — это процедура определения отправителя сообщения. Если проверка подлинности не выполняется или если не удается ее выполнить, сообщение отправляется анонимно. Авторизация определяет, разрешить ли пользователю, программе или устройству, выполняющему подключение, доступ к определенным данным, функциям или службам. Доступ зависит от запрошенного действия. При проверке подлинности проверяются идентификаторы. Процесс авторизации определяет предоставляемый уровень доступа.
В Exchange 2007 протоколы SMTP и MAPI предоставляются службой Microsoft Exchange Transport. В сеансах связи по протоколам SMTP и MAPI служба Microsoft Exchange Transport использует модель авторизации Microsoft Windows для управления разрешениями во время сеанса. С точки зрения транспорта в Exchange 2007, авторизация связана с допустимостью и недопустимостью тех или иных команд или событий протоколов. Например, при авторизации проверяются разрешения, позволяющие отправителю посылать сообщения с указанного почтового ящика, или разрешения, задающие размер сообщений. Во время обмена данными по протоколам MAPI и SMTP Exchange 2007 может выполнять проверку подлинности сеанса. По результатам проверки подлинности группы разрешений для сеанса могут измениться. Это позволяет по-разному обрабатывать анонимные сообщения из Интернета и сообщения пользователей, прошедших проверку подлинности в организации Exchange, поскольку проверка подлинности предоставляет им различные группы разрешений.
По умолчанию пограничный транспортный сервер и транспортный сервер-концентратор ведут себя по-разному. Различие связано не с кодом. Причина его в том, что по умолчанию этим ролям приписаны различные наборы разрешений. Между серверами Exchange, входящими в один и тот же лес Active Directory, установлены доверительные отношения. Это означает, что разрешения, по умолчанию настроенные при установке, обеспечивают безопасную передачу почты в пределах леса.
Каждый сеанс связи, прошедший проверку подлинности, представляет собой маркер доступа, содержащий идентификаторы безопасности всех групп, в которые входят участники проверки подлинности. На рисунке 1 показаны отношения между членами групп, указанными в маркере доступа, и разрешения, выданные этим группам по отношению к объекту доступа.
Сеансы, прошедшие проверку
подлинности, и сообщения, прошедшие проверку подлинности
Центральным понятием в модели транспорта Exchange 2007 является различие между сеансами транспорта, прошедшими проверку подлинности, и сообщениями, прошедшими проверку подлинности. Сообщение может быть маркировано метаданными, показывающими, прошло ли сообщение проверку подлинности, или оно является анонимным. Когда один сервер выполняет проверку подлинности другого сервера, он затем может отправить сообщение и маркировать его метаданными, указывающими сведения о проверке подлинности. Получающий сервер определяет, установлено ли доверительное отношение для марки проверки подлинности. Если получающий сервер доверяет отправителю, марка остается без изменений. Если получающий сервер не доверяет отправителю, он заменяет марку проверки подлинности, добавленную отправителем, и указывает, что сообщение отправлено анонимно. В организации Exchange весь внутренний поток почты проходит между серверами, доверяющими марке проверки подлинности. Пограничный транспортный сервер, получающий сообщения из Интернета, не доверяет марке проверки подлинности анонимных серверов Интернета. В связи с этим пограничный транспортный сервер маркирует каждое сообщение как анонимное, прежде чем передать его транспортному серверу-концентратору по подключению с проверкой подлинности.
Схема процессов проверки
подлинности и авторизации транспорта сообщений
В Exchange 2007 для проверки подлинности сеанса SMTP есть следующие базовые механизмы:
- В сеансе MAPI можно использовать учетную запись и пароль
Windows. Также можно использовать расширение AUTH для SMTP. Это
включает проверку подлинности при помощи пароля, проверку
подлинности NTLM и проверку подлинности Kerberos.
- Можно использовать сертификат X.509 при помощи расширения
STARTTLS для SMTP. В таком случае сервер предоставляет сертификат
как часть согласования TLS. Клиент тоже может предоставлять
сертификат, но это необязательно.
- Можно использовать внешний механизм проверки подлинности. При
использовании внешней проверки подлинности задействуются механизмы,
не являющиеся частью Exchange, например, физическая защита сетей
или IPsec. Этот метод используется, если связь осуществляется по
идентифицированным маршрутам IP на выделенные отправляющие и
получающие соединители.
Отправляющий сервер транспорта может проходить проверку подлинности на получающем сервере транспорта перед отправкой сообщения. После проверки подлинности отправителя получающий сервер транспорта применяет разрешения, выданные отправителю, к маркеру доступа сеанса.
В Exchange 2007 поток почты управляется получающими и отправляющими соединителями. Соединители имеют список DACL, по которому определяются разрешения, связанные с отправкой и получением электронной почты. Самыми важными являются разрешения получающего соединителя. Список DACL на получающем соединителе определяет разрешения отправителя для сообщений, передаваемых через получающий соединитель. После того как сеанс связи SMTP с получающим соединителем установлен, сеанс начинается с маркера анонимного доступа к нему. Последующая успешная проверка подлинности изменяет маркер доступа. Если проверка подлинности сеанса не выполняется, группы разрешений в маркере доступа остаются прежними. Если проверка подлинности сеанса выполняется, ему выдаются разрешения, приписанные отдельной четной записи или роли, и разрешения, приписанные группам безопасности, в которые входит данная учетная запись.
Схема потока на рисунке 2 показывает, как сервер транспорта Exchange 2007 использует проверку подлинности и авторизацию во время сеанса SMTP.
Настройки проверки
подлинности
Набор механизмов проверки подлинности, настроенный для получающего соединителя, определяет механизмы, которые может использовать сеанс, в котором сообщения отправляются на получающий соединитель. Механизм проверки подлинности, настроенный для отправляющего соединителя, определяет, какой механизм будет использовать отправляющий соединитель при проверке подлинности на интеллектуальном узле.
Проверка подлинности для получающих соединителей
Для получающего соединителя можно настроить несколько механизмов проверки подлинности. Параметры проверки подлинности для получающего соединителя определяют набор механизмов проверки подлинности, которые сервер может использовать для проверки подлинности в сеансах, в которых сообщения отправляются на сервер. Отправляющий сервер определяет, какой механизм использовать.
В таблице 1 приведен список механизмов проверки подлинности, которые можно настроить для получающего соединителя. Чтобы настроить механизм проверки подлинности для получающего соединителя, используйте вкладку Проверка подлинности в свойствах получающего соединителя в консоли управления Exchange или параметр AuthMechanism в командлете Set-ReceiveConnector командной консоли Exchange.
Таблица 1 Механизмы проверки подлинности для получающих соединителей
| Механизм проверки подлинности | Описание |
|---|---|
|
Отсутствует |
Проверка подлинности не предлагается. |
|
Шифрование TLS |
Соединитель предоставляет клиентам STARTTLS. |
|
Встроенная проверка подлинности Windows |
Соединитель предоставляет клиентам AUTH плюс NTLM GSSAPI. GSSAPI позволяет клиентам использовать согласование NTLM или Kerberos. |
|
Обычная проверка подлинности |
Соединитель предлагает клиентам AUTH плюс LOGIN. Имя пользователя и пароль от клиента поступают в виде обычного текста. В этом механизме для подтверждения данных требуется учетная запись Windows. |
|
Обычная проверка подлинности с шифрованием TLS |
Это модификатор политики обычной проверки подлинности. Соединитель предлагает клиенту AUTH плюс LOGIN только после выполнения согласования TLS. Для этого механизма необходимо, чтобы шифрование TLS было установлено в качестве механизма проверки подлинности. |
|
Проверка подлинности сервера Exchange |
Соединитель предлагает EXPS плюс GSSAPI для серверов Exchange, на которых установлены более ранние версии Exchange Server, и X-ANONYMOUSTLS для клиентов серверов Exchange 2007. |
|
Внешняя проверка (например с помощью IPsec) |
В этом варианте все соединения считаются поступающими с других проверяющих серверов. |
Проверка подлинности для отправляющих соединителей интеллектуальных узлов
Для отправляющего соединителя параметр SmartHostAuthMechanism определяет, как выполняется проверка подлинности отправляющего сервера на интеллектуальном узле назначения. Параметр SmartHostAuthMechanism может иметь только одно значение. Если параметр SmartHostAuthMechanism настроен, проверка подлинности должна пройти успешно, прежде чем можно будет отправить почту. Если механизм проверки подлинности, используемый отправляющим сервером Exchange 2007, не поддерживается интеллектуальным узлом, сервер не отправит сообщения электронной почты и сеанс будет завершен. Если механизм проверки подлинности, используемый отправляющим сервером Exchange 2007, поддерживается, но проверка подлинности не выполняется, сервер также не отправит сообщения электронной почты и сеанс будет завершен.
В таблице 2 приведен список механизмов проверки подлинности, которые можно настроить для отправляющего соединителя. Чтобы настроить механизм проверки подлинности для отправляющего соединителя, используйте диалоговое окно Настройка проверки подлинности для интеллектуального узла на вкладке Сеть в свойствах отправляющего соединителя в консоли управления Exchange или параметр SmartHostAuthMechanism в командлете Set-SendConnector командной консоли Exchange.
Таблица 2 Механизмы проверки подлинности для соединителей интеллектуальных узлов
| Механизм проверки подлинности | Описание |
|---|---|
|
Отсутствует |
Разрешен анонимный доступ. |
|
Обычная проверка подлинности |
Соединитель должен использовать AUTH плюс LOGIN. При этом вы
обязаны сообщить имя пользователя и пароль. При обычной проверке
подлинности учетные данные отправляются в виде простого текста. Все
промежуточные узлы, на которых отправляющий соединитель проходит
проверку подлинности, должны принять имя пользователя и пароль.
Кроме того, если для параметра RequireTLS установлено
значение |
|
Обычная проверка подлинности с шифрованием TLS |
Это модификатор политики обычной проверки подлинности. Он требует, чтобы соединитель использовал шифрование TLS, прежде чем пытаться использовать AUTH. Кроме того, он требует, чтобы отправляющий сервер выполнит проверку сертификата X.509 для отправляющего сервера. Проверка сертификата включает в себя проверку списка отзыва сертификата (CRL) и сравнение идентификаторов сервера со списком интеллектуальных узлов, настроенных для соединителя, перед использованием AUTH. Одно из полных доменных имен (FQDN), входящих в список интеллектуальных узлов, должно присутствовать в сертификате, чтобы сравнение имени было выполнено успешно. Поэтому, если FQDN промежуточного узла указывает на запись MX, указанное доменное имя FQDN интеллектуального узла должно присутствовать в сертификате. |
|
Проверка подлинности сервера Exchange |
Соединитель должен использовать EXPS плюс GSSAPI для серверов Exchange, на которых установлены более ранние версии Exchange Server, и X-ANONYMOUSTLS для серверов Exchange 2007. |
|
Внешняя проверка (например с помощью IPsec) |
Сетевое подключение проверяется с использованием метода, не включенного в сервер Exchange. |
Протокол TLS
Протокол TLS описан в RFC 2246. TLS использует сертификаты X.509. Это разновидность электронных учетных данных. TLS может быть использован следующим образом:
- Только для обеспечения конфиденциальности.
- Для конфиденциальной проверки подлинности сервера, если
сертификат сервера подтвержден.
- Для взаимной конфиденциальной проверки подлинности сервера и
клиента, если подтверждены сертификаты и сервера, и клиента.
Во время передачи данных по протоколу SMTP клиент запускает команду SMTP STARTTLS для запроса согласования TLS для данного сеанса. Клиент получает от сервера сертификат X.509 как часть согласования протокола TLS. Затем согласно политике проверки подлинности клиента определяется, необходимо ли подтверждение сертификата получающего сервера и необходимо ли применение каких-либо критериев к сертификату, таких как сравнение имени.
Дополнительная часть согласования TLS позволяет получающему серверу также запросить сертификат отправляющего сервера. Если отправляющий сервер отправляет сертификат получающему серверу, локальная политика получающего сервера определяет, как проверяется сертификат и какие разрешения выдаются отправляющему серверу на основании проверки подлинности.
Когда для проверки подлинности сервера используется TLS, проверяется только сертификат получающего сервера. Если TLS используется для взаимной проверки подлинности, должны проверяться оба сертификата - и сертификат отправляющего сервера, и сертификат получающего.
Если TLS настроен для получающего соединителя Exchange 2007, сервер должен иметь сертификат X.509. Сертификат может быть подписан самим сервером или центром сертификации. Сервер Exchange ищет в локальном каталоге сертификат, соответствующий полному доменному имени соединителя. Отправляющий сервер выбирает, как использовать протокол TLS. Если Exchange использует TLS только для обеспечения конфиденциальности, клиент Exchange не проверяет сертификат. Например, если Exchange использует TLS между серверами центрального транспорта, применяя Kerberos по протоколу TLS, Exchange создает конфиденциальный канал между серверами, а сертификаты не проверяет. Проверка подлинности между серверами выполняется при помощи Kerberos после завершения работы протокола TLS.
Если требуется проверка подлинности TLS, Exchange должен проверить сертификат. Проверить сертификат Exchange может двумя способами: прямым доверием и проверкой X.509. Когда TLS используется для передачи данных между пограничным транспортным сервером и транспортным сервером-концентратором, Exchange для проверки сертификата использует метод прямого доверия.
Прямое доверие означает, что Exchange использует хранилище, которому доверяет, например, Active Directory или ADAM. Прямое доверие означает, что наличие сертификата в этом хранилище подтверждает сертификат. Когда используется прямое доверие, не имеет значения, кем подписан сертификат, самим сервером или центром сертификации. Когда сервер граничного транспорта вписывается в организацию Exchange, сертификат пограничного транспортного сервера публикуется в Active Directory, чтобы транспортные серверы-концентраторы его подтвердили. Служба Microsoft Exchange Edgesync обновляет ADAM, добавляя набор сертификатов транспортного сервера-концентратора, чтобы пограничный транспортный сервер их подтвердил.
Другой метод, используемый Exchange для проверки сертификатов — это проверка X.509. Если используется проверка X.509, сертификат должен быть подписан центром сертификации. Exchange использует проверку X.509 при проверке подлинности промежуточных узлов или при использовании безопасности домена. О безопасности домена рассказано в следующем разделе.
Безопасность домена
Безопасностью домена называется ряд функций Exchange 2007 и Microsoft Office Outlook, представляющих собой альтернативу S/MIME и другим средствам безопасности уровня сообщений, требующую достаточно малых затрат. Назначение безопасности домена состоит в том, чтобы предоставить администраторам способ управлять безопасными путями обмена сообщениями с деловыми партнерами через Интернет. После того как эти безопасные пути настроены, сообщения, успешно переданные по ним от отправителя, прошедшего проверку подлинности, пользователи в Outlook и Outlook Web Access видят в разделе защищенной почты домена.
Отправляющий соединитель проверяет, есть ли домен назначения в списке отправляющих доменов, настроенных в функции безопасности домена, если выполняются следующие условия:
- Отправляющий соединитель настроен так, чтобы направлять
сообщения, используя записи ресурсов MX системы DNS.
- Отправляющий соединитель настроен как защищенный доменом.
Если домен назначения есть в списке, транспортный сервер заставляет выполнять взаимную проверку подлинности TLS при отправке электронной почты на домен.
Принимающий сервер отвечает командой SMTP QUIT, если выполняются следующие условия:
- Exchange не может согласовать TLS
- Не удается выполнить проверку сертификата сервера или проверку
CRL.
Затем сообщения помещаются в очередь на отправляющем сервере. Очередь находится в состоянии повторной отправки. Так же сервер действует, если не удается проверить имя.
Если получающ9ий соединитель защищен доменом, транспортный сервер проверяет полученную почту. Затем транспортный сервер заставляет выполнить взаимную проверку подлинности TLS, если отправитель есть в списке получающих доменов, настроенных в функции безопасности домена. Если все эти проверки выполняются успешно, полученное сообщение помечается как защищенное доменом. Если отправитель не может согласовать TLS, или если не выполняется проверка сертификата сервера или проверка CRL, транспортный сервер отклоняет сообщение про помощи команды REJECT протокола SMTP. Неудачное завершение проверки имени также приводит к запуску команды REJECT протокола SMTP. Затем сервер Exchange отправляет сообщение с временной ошибкой SMTP (4xx) обратно на отправляющий сервер. Это означает, что отправляющий сервер должен будет повторить попытку позднее. Благодаря такому поведению временные сбои проверки CRL не приводят к тому, что отправителю сразу посылается NDR. Сбой лишь задерживает доставку сообщения.
Для получения дополнительных сведений см. раздел Управление безопасностью домена.
Внешняя проверка подлинности
Внешнюю проверку подлинности можно использовать, если вы уверены, что в сетевом подключении между серверами установлены доверительные отношения. Это может быть подключение, защищенное IPsec, или виртуальная частная сеть. Или же серверы могут располагаться в физически контролируемой сети с доверительными отношениями. Эта конфигурация полезна в следующих случаях:
- Создан поток электронной почты между сервером транспорта
Exchange 2007 и сервером Exchange более ранней версии или любым
другим сервером SMTP.
- Использование обычной проверки подлинности нежелательно.
Соединители Exchange, для которых настроена внешняя
проверка, должны использовать выделенные отправляющие и получающие
соединители, поскольку все подключения к соединителям считаются
безопасными. Поэтому отправляющие соединители, для которых
настроена внешняя проверка, должны использовать интеллектуальный
узел для маршрутизации сообщений. Кроме того, для соединителя
должны быть настроены IP-адреса интеллектуальных узлов назначения.
На получающих соединителях, для которых настроена внешняя проверка,
в качестве значения параметра RemoteIPRanges должен быть
установлен диапазон IP-адресов отправляющих серверов. TLS может
использоваться в сочетании с внешней проверкой подлинности для
повышения конфиденциальности сеанса. Сделать это можно в командной
консоли Exchange: нужно установить для параметра RequireTLS
значение $True.
Авторизация
Авторизация во время транспорта сообщений — это процесс, определяющий, разрешено ли запрошенное действие, например, отправка почты, в данном сеансе SMTP.
Разрешения транспорта в Exchange 2007
Службы транспорта в Exchange 2007 используют модель авторизации Windows в сеансе SMTP, чтобы определить, имеет ли право определенный отправитель передавать сообщения на определенный соединитель, определенному получателю. Сеанс SMTP получает начальный набор разрешений (анонимный). После проверки подлинности сеанса он получает дополнительные разрешения. Тем самым меняется набор действий, которые разрешены в сеансе.
В модели авторизации Windows разрешения выдаются через контроль доступа, при котором маркер доступа сравнивается со списками контроля доступа (ACL). Маркер доступа содержит набор участников безопасности. Участником безопасности может быть учетная запись пользователя, учетная запись компьютера или группа безопасности. Каждый участник безопасности имеет свой идентификатор безопасности (SID). Каждому сеансу приписывается маркер доступа. Списки ACL определяются на объекте соединителя в Active Directory или ADAM. DACL содержит набор записей управления доступом (ACE). Каждая запись ACE либо дает, либо отклоняет разрешение участнику безопасности. Когда транспортный сервер проверяет, имеет ли сеанс разрешение, скажем, отправлять почту, сервер вызывает проверку доступа Windows и предоставляет маркер доступа сеанса и DACL соединителя в качестве параметров вместе с запрошенным разрешением.
Эта процедура сходна с определением разрешения на чтение файла. Маркер доступа, файл DACL и запрошенное разрешение поступают в один API. API проверяет каждого участника безопасности, указанного в маркере доступа, по каждой записи ACE в DACL, чтобы определить, имеется ли запрошенное разрешение. В дополнение к SID Windows, которые предоставляет Active Directory, ADAM или локальная база данных диспетчера учетных записей (SAM) на компьютере, Exchange 2007 определяет дополнительные SID. Эти SID составляют логические группы. В таблице 3 перечислены SID, определенные Exchange 2007 для проверки подлинности транспорта.
Таблица 3 SID в Exchange 2007
| Отображаемое имя | SID | Логическая группа |
|---|---|---|
|
Сервер-партнер |
S-1-9-1419165041-1139599005-3936102811-1022490595-10 |
Отправляющие и получающие домены, настроенные в функции безопасности домена. |
|
Транспортные серверы-концентраторы |
S-1-9-1419165041-1139599005-3936102811-1022490595-21 |
Транспортные серверы-концентраторы в одной организации Exchange. |
|
Пограничные транспортные серверы |
S-1-9-1419165041-1139599005-3936102811-1022490595-22 |
Пограничные транспортные серверы, с которыми установлены доверительные отношения. |
|
Серверы со внешней безопасностью |
S-1-9-1419165041-1139599005-3936102811-1022490595-23 |
Доверенные сторонние серверы в том же авторизованном домене. |
|
Старые версии серверов Exchange |
S-1-9-1419165041-1139599005-3936102811-1022490595-24 |
Серверы Exchange Server 2003 в той же организации Exchange. |
Разрешения получающего соединителя
Получающие соединители обрабатывают входящие сеансы сервера. Сеанс может быть установлен отправителем, прошедшим проверку подлинности, или анонимным отправителем. Если сеанс успешно прошел проверку подлинности, идентификаторы SID в маркере доступа сеанса обновляются. В таблице 4 приведен список разрешений, которые могут быть предоставлены сеансу, устанавливающему подключение к получающему соединителю.
Таблица 4 Разрешения получающего соединителя
| Разрешение | Отображаемое имя | Описание |
|---|---|---|
|
ms-Exch-SMTP-Submit |
Отправлять сообщения серверу |
Сеанс должен иметь это разрешение, иначе невозможно будет отправить сообщения на данный получающий соединитель. Если сеанс не имеет этого разрешения, не удастся выполнить команду MAIL FROM. |
|
ms-Exch-SMTP-Accept-Any-Recipient |
Отправлять сообщения любому получателю |
Это разрешение позволяет сеансу передавать сообщения через данный соединитель. Если это разрешение не выдано, соединитель будет принимать только сообщения для получателей, входящих в разрешенные домены. |
|
ms-Exch-SMTP-Accept-Any-Sender |
Принимать любого отправителя |
Это разрешение позволяет сеансу обойти проверку на подмену адреса отправителя. |
|
ms-Exch-SMTP-Accept-Authoritative-Domain-Sender |
Принимать отправителей доверенного домена |
Это разрешение позволяет сеансу обойти проверку, запрещающую получение сообщений с адресов электронной почты доверенных доменов. |
|
ms-Exch-SMTP-Accept-Authentication-Flag |
Принимать флаг проверки подлинности |
Это разрешение позволяет серверам Exchange более ранних версий посылать сообщения от внутренних отправителей. Серверы Exchange 2007 признают эти сообщения внутренними. |
|
ms-Exch-Accept-Headers-Routing |
Принимать заголовки маршрутизации |
Это разрешение позволяет сеансу посылать сообщения с целыми заголовками получения. Если это разрешение не выдано, сервер удаляет все заголовки получения. |
|
ms-Exch-Accept-Headers-Organization |
Принимать заголовки организации |
Это разрешение позволяет сеансу посылать сообщения с целыми заголовками организации. Все заголовки организации начинаются с «X-MS-Exchange-Organization-». Если это разрешение не выдано, сервер удаляет все заголовки организации. |
|
ms-Exch-Accept-Headers-Forest |
Принимать заголовки леса |
Это разрешение позволяет сеансу посылать сообщения с целыми заголовками леса. Заголовки леса начинаются с «X-MS-Exchange-Forest-». Если это разрешение не выдано, сервер удаляет все заголовки леса. |
|
ms-Exch-Accept-Exch50 |
Принимать Exch50 |
Это разрешение позволяет сеансу посылать сообщения, содержащие команду XEXCH50. Эта команда необходима для взаимодействия с серверами Exchange 2000 Server и Exchange 2003. Команда XEXCH50 предоставляет такие данные, как уровень вероятности нежелательной почты (SCL). |
|
ms-Exch-Bypass-Message-Size-Limit |
Обходить предел размера сообщения |
Это разрешение позволяет сеансу посылать сообщения, размер которых превышает ограничения, настроенные для данного соединителя. |
|
Ms-Exch-Bypass-Anti-Spam |
Обходить защиту от нежелательной почты |
Это разрешение позволяет сеансу обходить фильтры защиты от нежелательной почты. |
Разрешения отправляющего соединителя
Отправляющий соединитель обрабатывает исходящие сообщения для других серверов. Отправитель может установить сеанс либо с анонимным получателем, либо с получателем, прошедшим проверку подлинности. Если проверка подлинности сеанса выполнена успешно, набор идентификаторов SID в маркере доступа сеанса обновляется. Разрешения отправляющего соединителя определяют типы заголовков, которые могут быть включены в сообщение при отправке сообщения через данный соединитель. Сообщения, отправляемые другим серверам Exchange в организации или серверам в организации Exchange, с которой установлены доверительные отношения, в сценарии лесов с перекрестными связями обычно могут включать все типы заголовков. Сообщения, отправляемые в Интернет или серверу SMTP, не являющемуся сервером Exchange, не могут включать все заголовки. Если заголовки включены в сообщение, функция брандмауэра заголовков в Exchange 2007 удалит их. В таблице 5 приведен список разрешений, которые могут быть предоставлены сеансу, устанавливающему подключение к отправляющему соединителю.
Таблица 5 Разрешения отправляющего соединителя
| Разрешение | Отображаемое имя | Описание |
|---|---|---|
|
ms-Exch-Send-Exch50 |
Отправлять Exch50 |
Это разрешение позволяет сеансу отправлять сообщения, содержащие команду EXCH50. Если это разрешение не выдано, сервер отправит сообщение, но не включит команду EXCH50. |
|
Ms-Exch-Send-Headers-Routing |
Отправлять заголовки маршрутизации |
Это разрешение позволяет сеансу отправлять сообщения с целыми заголовками маршрутизации. Если это разрешение не выдано, сервер удаляет все полученные заголовки. |
|
Ms-Exch-Send-Headers-Organization |
Отправлять заголовки организации |
Это разрешение позволяет сеансу отправлять сообщения с целыми заголовками организации. Все заголовки организации начинаются с «X-MS-Exchange-Organization-». Если это разрешение не выдано, отправляющий сервер удаляет все заголовки организации. |
|
Ms-Exch-Send-Headers-Forest |
Отправлять заголовки леса |
Это разрешение позволяет сеансу отправлять сообщения с целыми заголовками леса. Заголовки леса начинаются с «X-MS-Exchange-Forest-». Если это разрешение не выдано, отправляющий сервер удаляет все заголовки леса. |
Группы разрешений
Группа разрешений — это предустановленный набор разрешений, которые могут быть предоставлены на получающем соединителе. Группы разрешений используются только для получающих соединителей. Использование групп разрешений упрощает настройку разрешений на получающих соединителях. Свойство PermissionGroups определяет группы или роли, которые могут посылать сообщения на получающий соединитель, и разрешения, которые выданы данным группам. Набор групп разрешений в Exchange 2007 предопределен. Это означает, что создавать дополнительные группы разрешений невозможно. Кроме того, изменять составляющие группы разрешений и связанные разрешения также невозможно.
В таблице 6 приведен список групп разрешений, членов группы разрешений и связанных разрешений, имеющихся в Exchange 2007.
Таблица 6 Группы разрешений для получающих соединителей и связанные разрешения
| Название группы разрешений | Участники безопасности | Разрешения на пограничных транспортных серверах | Разрешения на транспортных серверах-концентраторах |
|---|---|---|---|
|
Анонимно |
Анонимные пользователи |
|
|
|
Пользователи Exchange |
Пользователи, прошедшие проверку подлинности (за исключением наиболее известных учетных записей) |
Недоступно |
|
|
Серверы Exchange |
Серверы Exchange 2007 |
Все разрешения получения |
|
|
Предыдущие версии серверов Exchange |
Серверы Exchange 2003 и Exchange 2000 |
Недоступно |
|
|
Партнер |
Партнерские учетные записи серверов |
|
|
Типы использования соединителей
При создании нового соединителя можно указать тип его использования. Тип использования определяет параметры по умолчанию для соединителя. В тип использования входят доверенные идентификаторы SID, разрешения, назначенные данным идентификаторам SID, и механизм проверки подлинности.
В таблице 7 приведен список типов использования для получающего соединителя. При выборе типа использования получающего соединителя группы разрешений назначаются соединителям автоматически. Кроме того, настраивается механизм проверки подлинности, используемый по умолчанию.
Таблица 7 Типы использования получающего соединителя
| Тип использования | Группы разрешений по умолчанию | Механизм проверки подлинности по умолчанию |
|---|---|---|
|
Клиент |
Пользователи Exchange |
|
|
Настраиваемый |
Отсутствует |
Отсутствует |
|
Внутренний |
|
Проверка подлинности сервера Exchange |
|
Интернет |
Анонимные пользователи Партнеры |
Отсутствует или внешняя проверка |
|
Партнеры |
Партнеры |
Неприменимо. Этот тип использования выбирается, если настроена взаимная проверка подлинности TLS с удаленным доменом. |
В таблице 8 приведен список типов использования для отправляющих соединителей. При выборе типа использования отправляющего соединителя группы разрешений назначаются соединителям автоматически. Кроме того, настраивается механизм проверки подлинности, используемый по умолчанию.
Таблица 8 Типы использования отправляющего соединителя
| Тип использования | Разрешения по умолчанию | Участники безопасности | Механизм проверки подлинности по умолчанию для интеллектуальных узлов |
|---|---|---|---|
|
Пользовательский |
Отсутствует |
Отсутствует |
Отсутствует |
|
Внутренний |
|
|
Проверка подлинности сервера Exchange |
|
Интернет |
Отправлять заголовки маршрутизации |
Анонимная учетная запись пользователя |
Отсутствует |
|
Партнеры |
Отправлять заголовки маршрутизации |
Серверы-партнеры |
Неприменимо. Этот тип использования выбирается, если настроена взаимная проверка подлинности TLS с удаленным доменом. |
Если выбирается пользовательский тип использования для отправляющего или получающего соединителя, необходимо вручную настроить метод проверки подлинности и доверенные SID и назначить разрешения этим идентификаторам SID. Если тип использования не указывается, для соединителя устанавливается настраиваемый тип использования.
Установка разрешений при помощи сценария Enable-CrossForestConnector
Сценарий Enable-CrossForestConnector.ps1 можно использовать для упрощения настройки разрешений на соединителях между лесами. То, как данный сценарий назначает разрешения, напоминает использование групп разрешений. Определенный набор разрешений назначается отправляющему или получающему соединителю. Набор разрешений можно изменить в соответствии с ситуацией подключения, изменив содержимое сценария Enable-CrossForestConnector.ps1. Для получения дополнительных сведений см. раздел Настройка соединителей в перекрестных лесах.
Установка разрешений при помощи командлета Add-AdPermission
Командлет Add-AdPermission в командной консоли Exchange — это глобальный командлет, который позволяет назначить разрешения объектам, хранящимся в Active Directory. Командлет Add-AdPermission можно использовать для того, чтобы предоставить отдельные разрешения отправляющему или получающему соединителю. Командлет Add-AdPermission обычно не используется для управления разрешениями транспорта. Однако он должен использоваться для настройки разрешений в следующих ситуациях:
- Создание потока почты в ситуации обмена между лесами.
- Принятие анонимной почты из Интернета, если отправитель входит
в доверенный домен.
Разрешения транспорта в Exchange 2007 являются частью расширенных прав, которые можно назначить при помощи данного командлета. Следующая процедура показывает, как в командлете Add-AdPermission установить разрешения для получающего соединителя транспортного сервера-концентратора так, чтобы можно было отправлять сообщения в анонимном сеансе.
Установка разрешений для получающего соединителя в среде управления Exchange-
Выполните следующую команду:
Копировать кодAdd-AdPermission -Identity "Default Hub1" -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights ms-Exch-SMTP-Submit,ms-Exch-SMTP-Accept-Any-Recipient,ms-Exch-Bypass-Anti-Spam
Командлет Get-AdPermission можно использовать для просмотра списка DACL отправляющего или получающего соединителя Выполните одну из следующих команд, чтобы получить разрешения, назначенные получающему соединителю, и просмотреть результат в форматированной таблице.
Просмотр расширенных разрешений для получающего соединителя в командной консоли Exchange-
Выполните одну из следующих команд:
Копировать кодGet-AdPermission -Identity "Default ServerName" | format-table -view User Get-AdPermission -Identity "Default ServerName" | format-table -view Identity
Командлет Remove-AdPermission можно использовать для удаления назначенных разрешений.
Для получения дополнительных сведений о настройке, просмотре и удалении разрешений в командной консоли Exchange см. следующие разделы:
Настройка разрешений при помощи редактора ADSI
Редактор интерфейсов службы Active Directory (ADSI) — это консоль управления Microsoft, поставляемая вместе со средствами поддержки Windows. Редактор ADSI используется как редактор низкого уровня для изменения свойств объектов Active Directory или ADAM, которые в других интерфейсах управления не отображаются. Редактор ADSI следует использовать только опытным администраторам.
Редактор ADSI можно использовать для просмотра и изменения списков ACL для отправляющих или получающих соединителей. Открыв редактор ADSI, вы находите объект соединителя. Соединители Exchange 2007 хранятся в разделе конфигурации службы каталогов. Отправляющие соединители хранятся в виде объектов в контейнере «Подключения». Получающие соединители хранятся в виде дочерних объектов транспортного сервера Exchange 2007.
Изменение разрешений получающего соединителя в редакторе ADSI:-
Найдите получающи соединитель:
CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<организация>\CN=Administrative Groups\CN=Exchange Administrative Group (FYDIBOHF23SPDLT)\CN=Servers\CN=<имя сервера>\CN=Protocols\CN=SMTP Receive Connectors
-
Выберите получающий соединитель в области результатов. Щелкните его правой кнопкой мыши и выберите Свойства.
-
Перейдите на вкладку Безопасность. Появится следующее окно:
-
Нажмите кнопку Добавить, чтобы выбрать пользователя или группу, которой будут предоставлены разрешения, или выберите существующий элемент в списке Группа или имя пользователя.
-
Выберите разрешения, которые нужно назначить данной учетной записи, и установите флажок в столбце Разрешить.
-
Найдите отправляющий соединитель:
CN=Configuration\CN=Services\CN=Microsoft Exchange\CN=<организация>\CN=Administrative Groups\CN=Exchange Administrative Group(FYDIBOHF23SPDLT)\CN=Routing Groups\CN=Routing Group (DWBGZMFD01QNBJR)\CN=Connections
-
Выберите отправляющий соединитель в области результатов. Щелкните его правой кнопкой мыши и выберите Свойства.
-
Перейдите на вкладку Безопасность. Появится следующее окно:
-
Нажмите кнопку Добавить, чтобы выбрать пользователя или группу, которой будут предоставлены разрешения, или выберите существующий элемент в списке Группа или имя пользователя.
-
Выберите разрешения, которые нужно назначить данной учетной записи, и установите флажок в столбце Разрешить.
Устранение неполадок, связанных с разрешениями
Во время передачи данных по протоколу сервер SMTP может отклонить некоторые команды из-за того, что нет нужных разрешений. В таблице 9 приводится список часто встречающихся сообщений протокола об отклонении и настройки разрешений, вызвавшие ошибку.
Таблица 9 Часто встречающиеся сообщения протокола об отклонении команд и их причины
| Ответ сервера SMTP | Причина |
|---|---|
|
530 5.7.1 Клиент не прошел проверку подлинности |
Отправитель, указанный в поле MAIL FROM протокола SMTP, не имеет разрешения на отправку сообщений данному серверу. Необходимо выдать пользователю разрешение ms-Exch-SMTP-Submit. |
|
535 5.7.3 Неудачная проверка подлинности |
При передаче данных по протоколу SMTP на этапе AUTH выяснилось, что предоставлены неверные учетные данные или что пользователь, прошедший проверку подлинности, не имеет разрешения на отправку сообщений данному серверу. |
|
550 5.7.1 Клиент не имеет разрешения на отправку сообщений данному серверу |
Отправитель, указанный в поле MAIL FROM протокола SMTP, прошел проверку подлинности, но не имеет разрешения на отправку сообщений данному серверу. |
|
550 5.7.1 Клиент не имеет разрешения на отправку сообщений от имени данного отправителя |
Отправитель, указанный в поле MAIL FROM протокола SMTP, представляет собой адрес доверенного домена. Однако сеанс не имеет разрешения ms-Exch-SMTP-Accept-Authoritative-Domain-Sender. Такое может произойти, если сообщение было отправлено из Интернета на пограничный транспортный сервер с адреса отправителя, для которого организация Exchange является доверенной. |
|
550 5.7.1 Клиент не имеет разрешения на отправку сообщений от имени или с этого адреса |
Пользователь, прошедший проверку подлинности, не имеет разрешения на отправку сообщения от имени отправителя, указанного в заголовке сообщения. Кроме того, сеанс не имеет разрешения ms-Exch-SMTP-Accept-Any-Sender. |
|
550 5.7.1. Не удалось передать |
Домен получателя, которому было адресовано сообщение, не входит в список разрешенных доменов, определенных для данной организации. Кроме того, сеанс не имеет разрешения ms-Exch-SMTP-Accept-Any-Recipient. |
Дополнительные сведения
Для получения дополнительных сведений см. следующие разделы: