Если вы пропустили предыдущие статьи данной серии, пожалуйста, прочитайте:
В предыдущей статье мы видели, как управлять правами с помощью Exchange Management Shell и AdsiEdit.msc. В данной статье мы будем персонализировать разрешения на коннекторе получения различными способами без использования группы разрешений по умолчанию.
В Exchange Server 2007 есть набор предопределенных групп разрешений, что упрощает администрирование, делая возможным определять требуемые разрешения одним щелчком мыши. Когда у нас более одного сервера, это может вызвать проблемы, так как некоторые организации нуждаются в более строгих коннекторах получения, чем можно получить с помощью процедур, описанных в данной статье. Если вам не слишком важна такая возможность, настойчиво рекомендуется работать с группами разрешений по умолчанию, доступными через Exchange Management Console или Exchange Management Shell.
Предположим, что мы хотим AD группе под названием Grp_Relay разрешить передаваться в Exchange Server 2007. Для этого нам нужно продолжить настройку разрешений группы получения приписыванием дополнительных пользователей в список по умолчанию.
Замечание: Если вы используете более одного HUB-транспорта для данного коннектора получения, все изменения должны быть сделаны во всех NLB узлах для обеспечения одинакового режима аутентификации и разрешений.
Прежде всего, нам нужно удалить все известные группы на вкладке разрешений коннектора получения в Exchange Management Console. Для этого мы можем открыть свойства коннектора Internal Relay и убедиться, что во вкладке разрешений не отмечено ни единой группы.
Теперь давайте вернемся к AdsiEdit.msc и щелкнем правой кнопкой мыши на коннектор Internal Relay и щелкнем на Properties. Щелкните на вкладку Security и добавьте группу Grp_Relay из Active Directory. Убедитесь, что группа обладает, по крайней мере, следующими разрешениями (Рисунок 01):
Рисунок 01
Далее, только пользователи, принадлежащие к группе Grp_Relay, смогут отправлять сообщения с помощью коннектора получения Internal Relay. Если какой-либо пользователь, не принадлежащий к этой группе, попытается отправить сообщение, его попросят ввести пароль несколько раз; вы сможете проверить ошибку в файле журнала коннектора получения. Ошибка будет содержать следующие данные:
Входящая аутентификация не состоялась, так как клиент домен\имя пользователя не получил разрешения.
Если в вашем случае некоторые серверы должны работать с Exchange Server без использовании аутентификации, вы можете проделать ту же процедуру, что описана выше, для выдачи разрешения для анонимного пользователя на вкладке Security коннектора получения.
Замечание: Вообще-то, разрешение анонимного доступа к Exchange Server – не слишком хорошо. Убедитесь, что только определенный набор серверов сможет использовать этот коннектор путем соответствующей настроив RemoteIPRanges в коннекторе получения.
Настройка TLS в коннекторе получения
Теперь, когда мы видели, как правильно настраивать методы и группы аутентификации в коннекторе получения, перейдем к включению TLS в коннекторе получения. Сперва давайте посмотрим на свойства в коннекторе получения Internal Relay, а затем перейдем к вкладке Authentication и проверим опцию TLS (Рисунок 02).
Рисунок 02
Теперь давайте попробуем соединиться с этим коннектором получения, в котором FQDN определяется как relay.apatricio.local (Apatricio.local – это мое FQDN имя). Давайте просто используем первую команду SMTP, EHLO example.org, и мы увидим, что STARTTLS не показывается, что означает, что даже при включенном TLS на коннекторе получения мы не можем его прямо сразу использовать (Рисунок 03)
Рисунок 03
После этого соединения мы можем перейти к Event Viewer нашего Exchange Server, и событие с EventID 12014 (Рисунок 04) будет здесь указано, а сообщение об ошибке даст нам понять, что сейчас в нашей среде происходит. Ответ прост – отсутствует сертификат с тем именем, которое настроено в FQDN данного коннектора получения.
Рисунок 04
Давайте исправим это. Я предполагаю, что используется внутренний PKI, и для получения нового SMTP сертификата с помощью Exchange Management Shell нужно использовать следующую команду:
New-ExchangeCertificate ‘GenerateRequest ‘Path c:\cert.req ‘SubjectName ‘cn=relay.apatricio.local’ ‘FriendlyName ‘Internal Relay Certificate’ ‘PrivateKeyExportable:$True
Теперь давайте запросим сертификат, созданный на Web-странице центра сертификации:
Давайте импортируем новый сертификат, для чего используем команду:
Import-ExchangeCertificate ‘Path:C:\certnew.cer
Замечание: Имя файла и путь приводятся для примера, вы должны использовать то имя файла и тот путь, которые вы использовали на предыдущем шаге.
Чтобы служба SMTP начала использовать только что созданный сертификат, используется Exchange Management Shell. Для включения нужно просто скопировать Thumbprint, показанный, когда мы импортировали запрос в прошлом шаге, и использовать следующую команду:
Enable-ExchangeCertificate ‘Thumbprint <Thumbprint> -Services SMTP
Когда вам предложат изменить сертификат SMTP по умолчанию, просто введите N и нажмите enter.
Давайте проверим наши изменения, для этого снова соединимся с коннектором получения Internal Relay и введем первую команду SMTP, ehlo example.org. Заметили изменения? Наверняка: теперь Exchange Server нам предлагает STARTTLS. Мы также можем перейти к Event Viewer и увидеть, что транспортной ошибки, которую мы видели ранее, теперь нет.
Рисунок 05
Давайте теперь вернемся к Outlook Express для подтверждения решения. В свойствах аккаунта Outlook Express мы должны использовать имя FQDN в поле Outgoing mail (SMTP), и это имя должно разрешаться клиентом, и оно должно совпадать с именем, используемым недавно размещенным сертификатом (Рисунок 06).
Рисунок 06
Второй шаг, который необходимо предпринять, — это проверить опцию This server requires a secure connection (SSL) на вкладке Advanced, как показано на Рисунке 07.
Рисунок 07
Теперь давайте отправим сообщение с помощью Outlook Express. Нам не нужно получать его на клиенте Outlook Express, так как мы не настроили нужный POP3 сервер, а только SMTP. Если сообщение исчезнет из папки Outbox – это хороший знак, но давайте также проверим файлы журнала: мы увидим, что сообщение было отправлено с помощью TLS, как показано на Рисунке 08.
Рисунок 08
В этой статье мы видели, как избежать события с ID 12014, когда мы настраиваем FQDN в коннекторе получения, как настроить специальную группу для работы с конкретным коннектором получения, а также как настраивать сертификат и проверять файлы журнала, чтобы убедиться в правильности функционирования конфигурации.
Источник http://www.msexchange.org
Tags: Exchange