headermask image
Рекомендую: Фриланс-биржа | Кэшбэк-сервис | Интернет-бухгалтерия

Управление коннекторами получения (часть 3)

Настройка параметров ведения логов коннектора получения

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

  1. Откройте консоль Exchange Management Console.
  2. Разверните вкладку конфигурации сервера.
  3. Нажмите Hub Transport.
  4. Выберите доступный hub transport справа и нажмите Свойства.
  5. Перейдите по вкладке Параметры ведения логов. В разделе параметров ведения логов мы можем изменить путь к месту, в котором будет храниться коннектор получения или коннектор отправки, нажав кнопку Обзор (рисунок 01).

exchange_3_1.png

Рисунок 01

Теперь, когда мы знаем, где файлы логов будут храниться, мы можем получить свойства любого коннектора получения, и у нас также есть опция под названием Уровень протокола записи логов, которая по умолчанию имеет значение None, мы изменим его на Verbose (рисунок 02). Используйте режим Verbose только во время диагностики, в противном случае оставьте значение этой опции как None.

 

exchange_3_2.png

Рисунок 02

Теперь, мы можем отправить тестовое сообщение, используя SMTP команды, которые рассматривали ранее в этой серии, и сможем отслеживать весь процесс взаимодействия в журнале регистрации, как показано на рисунке 03.

echange_3_3.jpg

 

 

Рисунок 03

Настройка аутентификации и разрешений

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

Коннекторы получения используют 7 (семь) различных типов аутентификации, коими являются: отсутствие аутентификации, TLS, интегрированная, базовая аутентификация, базовая аутентификация по TLS, аутентификация Exchange Server (Gssapi и Mutual Gssapi) и внешняя авторизация (External Authoritative). Эти методы аутентификации предлагаются клиенту во время сеанса SMTP, и после того как аутентификация выполнена, назначаются разрешения. Чтобы настроить метод аутентификации, который будет использоваться определенным коннектором получения, следуйте этим шагам:

  1. Откройте консоль Exchange Management Console.
  2. Разверните вкладку конфигурации сервера.
  3. Нажмите на Hub Transport.
  4. Нажмите на коннекторе получения и выберите свойства.
  5. Перейдите по вкладке Аутентификация (рисунок 04).

 

echange_3_4.png

Рисунок 04

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

Метод аутентификации Ответ EHLO
Безопасность транспортного уровня (Transport Layer Security – TLS) 250-STARTTLS
Базовая аутентификация 250-Auth Login
Интегрированная аутентификация Windows 250-Auth NTLM
Внешне защищенная (Externally Secured) 250-Auth 250 XEXCH50

Итак, мы посмотрели, как настраивать методы аутентификации, которые могут применяться к коннекторам получения, теперь мы настроим сервер внутренней ретрансляции (internal relay server), это может быть полезно в ситуациях, когда каким-либо пользователям/принтерам/серверам необходимо отправить сообщение с помощью сервера внутренней ретрансляции. Мы создадим коннектор внутренней ретрансляции с чистого листа, а затем поработаем с некоторыми настройками, чтобы посмотреть, как настраивать методы аутентификации и разрешения для соответствия вашим потребностям.

Давайте создадим внутренний коннектор получения. Этот коннектор буде принимать подключения на порте 25, однако подключения будут исходить от определенных машин (172.16.171.1 – 172.16.171.20 в нашем примере). Мы также укажем различные FQND; для этого внутреннего коннектора получения мы будем использовать relay.apatricio.local, следующую команду можно использовать для создания коннектора:

New-ReceiveConnector ‘Usage:Client ‘Bindings:0.0.0.0:25 ‘RemoteIPRanges:172.16.171.1-172.16.171.20 ‘FQDN:relay.apatricio.local ‘Server srv-ex01 ‘ProtocolLoggingLevel:Verbose ‘Name:’Internal Relay’

Теперь, когда мы создали коннектор получения, мы можем перейти к любой машине, принадлежащей к указанному диапазону удаленных IP, и получим сообщения нашего нового коннектора получения. Мы можем проверить информацию FQND, отображенную в первой строке (рисунок 05).

echange_3_5.jpg

Рисунок 05

Итак, давайте теперь откроем программу просмотра событий на нашем сервере Exchange Server, и увидим ошибку под номером 12014 и MSExchangeTransport Source. Эта ошибка возникает, потому что у нас пока нет сертификата для relay.apatricio.local FQDN. Мы можем пока избежать этого сообщения об ошибке, настроив внутренний коннектор получения на использование базовой аутентификации и интегрированной аутентификации Windows, как показано на рисунке 06. Мы поиграем с TLS и сертификатами для этого подключения в следующей части.

 

echange_3_6.png

Рисунок 06

Во вкладке «Группы разрешений» у нас есть пять различных групп разрешений, которые мы назначаем коннектору получения. Эти предопределенные группы разрешений представляют собой набор объектов, которые могут включать пользователей, компьютеры и группы безопасности, и они определяют разрешения общеизвестных SID (Security Identifier), например (разрешение группы пользователей Exchange – это группа аутентифицированных пользователей в AD). Использование этих групп разрешений является рекомендуемым решением для большинства компаний, однако мы не можем изменять эти группы разрешений с помощью консоли Exchange Management Console.

Во вкладке групп разрешений мы лишь подтвердим, кому разрешено подключение к нашему коннектору получения. В клиентском коннекторе только пользователям ‘Exchange Users’ разрешено подключение по умолчанию (рисунок 07).

 

echange_3_7.png

Рисунок 07

Поскольку у нас есть подходящий способ аутентификации и разрешение, назначенное пользователям Exchange Users, мы можем его протестировать. Для этого мы можем использовать Outlook Express, чтобы создать поддельную учетную запись, используя поддельную учетную запись сервера POP3 Server, чтобы просто протестировать протокол SMTP. Убедитесь, что адрес ответа, используемый в учетной записи Outlook Express, принадлежит к текущему списку принимаемых доменов (Accepted Domains) в вашей организации Exchange, а также, что вы используете правильное имя пользователя и пароль, и, наконец, настройте учетную запись на использование аутентификации с помощью опции ‘Мой сервер требует аутентификации’.

 

echange_3_8.png

Рисунок 08

Теперь можно отправить сообщение на любой почтовый адрес, и сообщение будет отправлено. Как узнать, что аутентификация работает? Очень просто! Во время создания коннектора получения мы настроили уровень записи логов на Verbose. Теперь вы поняли, почему я сказал очень просто, не так ли? Просто посмотрите журналы регистрации и увидите процесс аутентификации, как показано на рисунке 09.

 

echange_3_9.jpg

Рисунок 09

Стандартная конфигурация работает в большинстве сценариев, однако иногда для соответствия требованиям компании необходимо настроить определенный свод разрешений на коннекторе получения. Мы можем настроить разрешения коннектора получения двумя способами: с помощью Exchange Management Shell или AdsiEdit.msc.

Первым способом будет использование Exchange Management Shell. Чтобы посмотреть текущие разрешения коннектора получения выполните команду:

Get-ReceiveConnector <connector-Name> | Get-ADPermission

Для работы с разрешениями используйте команду Add-ADPermission, чтобы добавить записи в этот список и Remove-ADPermissions, чтобы удалить элементы из списка.

Вторым способом установки разрешений коннектора получения будет использование AdsiEdit.msc (по умолчанию он идет с Windows Support Tools, процесс его установки можно найти на Adsiedit Overview).

Используя ADSIEdit.msc мы можем поиграть с разрешениями коннектора получения:

  1. Откройте AdsiEdit.msc.
  2. Разверните вкладку конфигурации.
  3. Разверните CN=Services.
  4. Разверните CN=Microsoft Exchange.
  5. Разверните CN=<Organization name>.
  6. Разверните CN=Exchange Administrative Group (FYDIBOHF23SPDLT).
  7. Разверните CN=<Server Name>.
  8. Разверните CN=Protocols.
  9. Разверните CN=SMTP Receive Connectors.
  10. С правой стороны мы видим все коннекторы получения данного сервера (рисунок 10).

 

echange_3_10.jpg

Рисунок 10

  1. Правой клавишей нажмите на коннекторе получения и выберите свойства.
  2. Перейдите по вкладке Безопасность, и в списке вы увидите все идентификаторы безопасности (Security Identifiers) каждой группы разрешений, которые были ассоциированы с коннектором получения, а также все предоставленные разрешения.

Теперь мы легко можем работать с разрешениями с помощью Adsiedit.msc вместо Exchange Management Shell, работа с которой немного сложнее.

Заключение

В этой части мы посмотрели, как настраивать параметры ведения логов в коннекторе получения, а также как настраивать разрешения с помощью AdsiEdit и Exchange Management Shell.

Автор: Дэвид Дэвис (David Davis)

Постовой

В распространенных в последнее время блогах, seo блог nodar.name в моем ридере занимает уверенную позицию. Там действительно есть что почитать, из наиболее интересного в последнее время Подсветка ссылок.

Похожие посты
  • Управление коннекторами получения (Receive Connectors) (часть 1)
  • Exchange Server 2010: Управление архивными ящиками, часть 2
  • Exchange Server 2010: Управление архивными ящиками, часть 1
  • Exchange Server 2010: Управление архивными ящиками, часть 3
  • Управление коннекторами получения (часть 4)
  • Управление коннекторами получения (часть 2)
  • Управление групповыми политиками с помощью Advanced Group Policy Management (AGPM) v4, часть 2
  • Настройка уникального имени для SMTP баннера каждого коннектора получения в Exchange Server
  • Управление групповыми политиками с помощью Advanced Group Policy Management (AGPM) v4, часть 3
  • Управление динамическим пулом MAC-адресов в Hyper-V