Модель «Транспортные разрешения» в Exchange 2007

Применимо к: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Последнее изменение раздела: 2007-08-27

В этом разделе приведены подробные сведения о модели разрешений транспорта в 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 показаны отношения между членами групп, указанными в маркере доступа, и разрешения, выданные этим группам по отношению к объекту доступа.

Рисунок 1   Компоненты авторизации транспорта в Exchange 2007

Сеансы, прошедшие проверку подлинности, и сообщения, прошедшие проверку подлинности

Центральным понятием в модели транспорта 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.

Рисунок 2   Процесс проверки подлинности и авторизации в сеансе SMTP

Настройки проверки подлинности

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

Проверка подлинности для получающих соединителей

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

В таблице 1 приведен список механизмов проверки подлинности, которые можно настроить для получающего соединителя. Чтобы настроить механизм проверки подлинности для получающего соединителя, используйте вкладку Проверка подлинности в свойствах получающего соединителя в консоли управления Exchange или параметр AuthMechanism в командлете Set-ReceiveConnector командной консоли Exchange.

Таблица 1   Механизмы проверки подлинности для получающих соединителей

Проверка подлинности для отправляющих соединителей интеллектуальных узлов

Для отправляющего соединителя параметр SmartHostAuthMechanism определяет, как выполняется проверка подлинности отправляющего сервера на интеллектуальном узле назначения. Параметр SmartHostAuthMechanism может иметь только одно значение. Если параметр SmartHostAuthMechanism настроен, проверка подлинности должна пройти успешно, прежде чем можно будет отправить почту. Если механизм проверки подлинности, используемый отправляющим сервером Exchange 2007, не поддерживается интеллектуальным узлом, сервер не отправит сообщения электронной почты и сеанс будет завершен. Если механизм проверки подлинности, используемый отправляющим сервером Exchange 2007, поддерживается, но проверка подлинности не выполняется, сервер также не отправит сообщения электронной почты и сеанс будет завершен.

В таблице 2 приведен список механизмов проверки подлинности, которые можно настроить для отправляющего соединителя. Чтобы настроить механизм проверки подлинности для отправляющего соединителя, используйте диалоговое окно Настройка проверки подлинности для интеллектуального узла на вкладке Сеть в свойствах отправляющего соединителя в консоли управления Exchange или параметр SmartHostAuthMechanism в командлете Set-SendConnector командной консоли Exchange.

Таблица 2   Механизмы проверки подлинности для соединителей интеллектуальных узлов

Протокол 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 в маркере доступа сеанса обновляются. В таблице 4 приведен список разрешений, которые могут быть предоставлены сеансу, устанавливающему подключение к получающему соединителю.

Таблица 4   Разрешения получающего соединителя

Разрешения отправляющего соединителя

Отправляющий соединитель обрабатывает исходящие сообщения для других серверов. Отправитель может установить сеанс либо с анонимным получателем, либо с получателем, прошедшим проверку подлинности. Если проверка подлинности сеанса выполнена успешно, набор идентификаторов SID в маркере доступа сеанса обновляется. Разрешения отправляющего соединителя определяют типы заголовков, которые могут быть включены в сообщение при отправке сообщения через данный соединитель. Сообщения, отправляемые другим серверам Exchange в организации или серверам в организации Exchange, с которой установлены доверительные отношения, в сценарии лесов с перекрестными связями обычно могут включать все типы заголовков. Сообщения, отправляемые в Интернет или серверу SMTP, не являющемуся сервером Exchange, не могут включать все заголовки. Если заголовки включены в сообщение, функция брандмауэра заголовков в Exchange 2007 удалит их. В таблице 5 приведен список разрешений, которые могут быть предоставлены сеансу, устанавливающему подключение к отправляющему соединителю.

Таблица 5   Разрешения отправляющего соединителя

Группы разрешений

Группа разрешений — это предустановленный набор разрешений, которые могут быть предоставлены на получающем соединителе. Группы разрешений используются только для получающих соединителей. Использование групп разрешений упрощает настройку разрешений на получающих соединителях. Свойство PermissionGroups определяет группы или роли, которые могут посылать сообщения на получающий соединитель, и разрешения, которые выданы данным группам. Набор групп разрешений в Exchange 2007 предопределен. Это означает, что создавать дополнительные группы разрешений невозможно. Кроме того, изменять составляющие группы разрешений и связанные разрешения также невозможно.

В таблице 6 приведен список групп разрешений, членов группы разрешений и связанных разрешений, имеющихся в Exchange 2007.

Таблица 6   Группы разрешений для получающих соединителей и связанные разрешения

Типы использования соединителей

При создании нового соединителя можно указать тип его использования. Тип использования определяет параметры по умолчанию для соединителя. В тип использования входят доверенные идентификаторы SID, разрешения, назначенные данным идентификаторам SID, и механизм проверки подлинности.

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

Таблица 7   Типы использования получающего соединителя

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

Таблица 8   Типы использования отправляющего соединителя

Если выбирается пользовательский тип использования для отправляющего или получающего соединителя, необходимо вручную настроить метод проверки подлинности и доверенные 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 см. следующие разделы:

• Add-ADPermission

• Get-ADPermission

• Remove-ADPermission

Настройка разрешений при помощи редактора ADSI

Редактор интерфейсов службы Active Directory (ADSI) — это консоль управления Microsoft, поставляемая вместе со средствами поддержки Windows. Редактор ADSI используется как редактор низкого уровня для изменения свойств объектов Active Directory или ADAM, которые в других интерфейсах управления не отображаются. Редактор ADSI следует использовать только опытным администраторам.

Редактор ADSI можно использовать для просмотра и изменения списков ACL для отправляющих или получающих соединителей. Открыв редактор ADSI, вы находите объект соединителя. Соединители Exchange 2007 хранятся в разделе конфигурации службы каталогов. Отправляющие соединители хранятся в виде объектов в контейнере «Подключения». Получающие соединители хранятся в виде дочерних объектов транспортного сервера Exchange 2007.

Изменение разрешений получающего соединителя в редакторе ADSI:

1. Найдите получающи соединитель:

   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

2. Выберите получающий соединитель в области результатов. Щелкните его правой кнопкой мыши и выберите Свойства.

3. Перейдите на вкладку Безопасность. Появится следующее окно:

   

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

5. Выберите разрешения, которые нужно назначить данной учетной записи, и установите флажок в столбце Разрешить.

Изменение разрешений отправляющего соединителя в редакторе ADSI:

1. Найдите отправляющий соединитель:

   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

2. Выберите отправляющий соединитель в области результатов. Щелкните его правой кнопкой мыши и выберите Свойства.

3. Перейдите на вкладку Безопасность. Появится следующее окно:

   

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

5. Выберите разрешения, которые нужно назначить данной учетной записи, и установите флажок в столбце Разрешить.

Устранение неполадок, связанных с разрешениями

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

Таблица 9   Часто встречающиеся сообщения протокола об отклонении команд и их причины

Дополнительные сведения

Для получения дополнительных сведений см. следующие разделы:

• Отправляющие соединители

• Получающие соединители

• Set-SendConnector

• Set-ReceiveConnector

• Add-ADPermission

• Get-ADPermission

• Управление принятыми доменами