Распределение нагрузки серверов Exchange 2007 Client Access с использованием технологии Windows Network Load-Balancing - Часть 3: Создание сертификатов и тестирование клиентских служб

Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте:

• Распределение нагрузки серверов Exchange 2007 Client Access с использованием технологии Windows Network Load-Balancing - Часть 1: Обзор кластеров Windows NLB
• Распределение нагрузки серверов Exchange 2007 Client Access с использованием технологии Windows Network Load-Balancing - Часть 2: Настраиваем кластер Windows NLB

В этой статье мы продолжим с того места, на котором остановились во второй части. Мы создадим новый сертификат subject alternative name (SAN), который состоит из всех необходимых Fully Qualified Domain Names (FQDN) и имен NetBIOS и установим их в оба узла в нашем NLB кластере. И, наконец, мы проведем тестирование, чтобы быть уверенными, что клиентские службы работают, как ожидается.

Тестирование установок Load-Balanced Client Access сервера

Прежде, чем мы продолжим разбирать настройку по шагам, неплохо было бы протестировать, работает ли наш NLB кластер так, как ожидается. Чтобы это сделать, откройте браузер в одном из серверов или клиентов, как вы сами предпочитаете, затем введите FQDN для NLB кластера, в моем случае это https://mail.ehlo.dk/owa. Как можно видеть на Рисунке 3.1, мы получим пару предупреждений безопасности, так как мы пытаемся войти в OWA 2007 через имя NLB кластера. Мы так поступаем, потому что FQDN не включен в единственный SSL сертификат, который установлен в каждом сервере Client Access с момента установки Exchange 2007. Мы исправим эту проблему позже, а сейчас давайте просто нажмем Yes.

Появится страница входа в систему, и теперь мы можем войти в OWA, введя имя пользователя и пароль, как показано на Рисунке 3.2

Из-за проблемы с сертификатами Exchange ActiveSync и Outlook Anywhere все еще не будут работать, поэтому нет смысла тестировать доступ из этих клиентов на этой стадии (мы сделаем это немного позже в статье).

Имитирование простоя первого узла в NLB кластере

Вход в OWA 2007, используя имя NLB кластера, не показывает нам больше, чем то, что мы можем соединиться с первым сервером Client Access в нашем NLB кластере. Чтобы проверить, была ли устранена проблема, которая существует в организациях только с одним развернутым Client Access сервером, нужно смоделировать неисправный Client Access сервер. Мы можем это сделать, отключив NLB LAN сетевой адаптер в первом сервере, как показано на Рисунке 3.3.

Примечание:
NLB LAN адаптер должен быть отключен в первом Client Access сервере в NLB кластере, так как этот сервер имеет самый высокий приоритет. Также заметим, что если вы соединены с сервером Client Access, используя удаленное соединение (remote desktop connection), то ваше соединение будет оборвано.

Давайте попробуем еще раз войти в OWA 2007 с отключенным сетевым адаптером. Если NLB кластер был настроен правильно, то появится страница входа в OWA 2007 и, кажется, все в порядке.

Мы можем сделать заключение, что NLB кластер работает нужным образом.

Роль Hub Transport сервера в узлах NLB кластера

Из-за экономии многие организации выбирают установку ролей как Client Access, так и Hub Transport server в одних и тех же физических блоках для того, чтобы поддерживать как можно меньшее общее количество серверов Exchange 2007. Если вы планируете поступить похожим образом и в то же время хотите сбалансировать загрузку серверов Client Access, используя NLB, то вы должны убедиться, что SMTP (и если используется безопасный SMTP ака TLS) исключены в ярлыке Port Rules на странице свойств NLB (Рисунок 3.4). Это потому, что Exchange 2007 Hub Transport серверы были разработаны с встроенной отказоустойчивостью (при условии, что один Hub Transport сервер не отвечает SMTP соединению, другой Hub Transport сервер на сайте будет отвечать), и поэтому распределение нагрузки с использованием NLB не нужно.

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

Создание нового SSL сертификата в первом узле

Мы должны создать новый сертификат, так как FQDN, используемый для доступа в серверы Client Access в нашем NLB кластере, не соответствует FQDN, заданному в поле общих имен или в поле альтернативных имен объекта в установленном по умолчанию SSL сертификате, который автоматически устанавливается в каждый сервер Client Access во время установки Exchange 2007 (Рисунок 3.5 и 3.6).

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

Примечание:
Так как нам нужен сертификат, в котором множество FQDN должны быть определенными, мы должны использовать сертификат альтернативных имен объекта (SAN). Во время написания этой статьи только горстка сторонних CA предлагали эти типы сертификатов, многие из которых перечислены в следующей KB статье:

http://support.microsoft.com/kb/929395.

Так как мы собираемся создать запрос для нового SAN сертификата, то для этой цели мы должны использовать New-ExchangeCertificate командлеты, так как IIS Manager не может создавать запросы для SAN сертификатов. Чтобы это сделать, запустите Exchange Management Shell, затем введите следующую команду (замените имена своими собственными):

New-ExchangeCertificate –GenerateRequest –SubjectName “C=dk, O=EHLO organization, CN=mailehlo.dk” –DomainName mail.ehlo.dk, autodiscover.ehlo.dk, cas01.ehlo.dk, cas02.ehlo.dk –FriendlyName “CAS SAN Certificate” –KeySize 1024 –Path c:\CAS_SAN_cert.req –PrivateKeyExportable:$true

После нажатия Enter, будет дан список новых сертификатов, как показано на Рисунке 3.7.

Запуск SAN сертификата для авторизации сертификатов Майкрософт

С помощью выполненного запроса SAN SSL сертификата мы можем запустить Microsoft CA или почти его. Дело в том, что по умолчанию Microsoft CA не может управлять сертификатами с SAN полем должным образом. Чтобы решить эту проблему залогинтесь в контроллере домена и откройте окно командной строки, затем введите следующую команду:

Certutil –setreg policy\EditFlags –EDITF_ATTRIBUTESUBJECTALTNAME2

После нажатия Enter вы увидите старые и новые значения, как на Рисунке 3.8.

Теперь перезапустите службу Certificate Services (CertSVC) в сервере Microsoft CA для того, чтобы изменения вступили в силу (Рисунок 3.9).

Теперь мы готовы для запуска запросов сертификата в Microsoft CA. Один из вариантов, как это можно сделать, это открыть браузер и ввести http://dc_name/center. На странице Welcome нажмите Request a certificate (Рисунок 3.10).

На странице Request a Certificate нажмите advanced certificate request (Рисунок 3.11).

На странице Advanced Certificate Request нажмите Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file (Рисунокe 3.12).

Теперь вставьте контент файла запроса сертификата в окно Base-64-encoded, как показано на Рисунке 3.13. Затем выберите Web Server в образце всплывающего меню сертификата и нажмите Submit.

Сертификат был выдан, и вы можете скачать DER или Base 64 encoded версию, нажав Download certificate или Download certificate chain. Давайте выберем Base 64 encoded, появляющийся после нажатия Download certificate chain (Рисунок 3.14).

Настало время импортировать выданный сертификат, используя Import-ExchangeCertificate командлет. Вводим следующую команду:

Import-ExchangeCertificate –Path c:\certnew.p7b

Теперь сертификат был импортирован в устройство запоминания персональных сертификатов.

Для подтверждения ожидаемых видов сертификата давайте введем следующую команду:

Get-ExchangeCertificate -Thumbprint  | FL 

И, наконец, нам необходимо включить сертификат для клиентских служб, наши пользователи будут использовать его для соединения со своими почтовыми ящиками. В данной установке я включу сертификат для OWA, EAS, Outlook Anywhere, POP3 и IMAP4. Чтобы это сделать, нам нужно ввести:

Enable-ExchangeCertificate –Thumbprint  -Services “IIS, POP, IMAP”

Теперь сертификат включен для этих служб, но только в первом сервере Client Access в вашем NLB кластере.

Импортирование и включение сертификата SAN SSL на втором Client Access сервере в NLB кластере

Для импортирования SAN сертификата во второй сервер Client Access в NLB кластере, нам, во-первых, нужно экспортировать его из первого сервера Client Access. Сделав это, нам необходимо убедиться, что мы экспортировали сертификат с его приватным ключом. Это делается открытием встроенного модуля Certificates. Для открытия встроенного модуля Certificates нажмите Start > Run и введите mmc.exe в первое открывшееся пустое окно MMC. Теперь нажмите File > Add/Remove Snap-in > Add > ВыберитеCertificates > Нажмите Add > Выберите Computer Account > НажмитеNext > Finish > Close и в конце OK. Откройте Certificates (Local Computer) > Personal, затем правой кнопкой мыши щелкните на сертификате, который будет экспортироваться. В появившемся контекстном меню выберите All Tasks > Export (Рисунок 3.18).

в Certificate Export Wizard нажмите Next. На странице Export Private Key выберите Yes, export the private key, как показано на Рисунке 3.19, затем нажмите Next.

На странице Export File Format выберите Personal Information Exchange – PKCS #12 (.PFX) и поставьте отметку напротив Include all certificates in the certificates path if possible, как показано на Рисунке 3.20. Нажмите Next.

Введите пароль и нажмите Next (Рисунок 3.21).

Примечание:
Запомните пароль, так как он вам понадобится при его импортировании во второй сервер Client Access.

Теперь задайте путь, куда вы хотите сохранить файл .PFX (Рисунок 3.22), затем нажмите Next.

В самом конце нажмите Finish.

С экспортированным сертификатом давай скопируем его в С: устройство второго сервера Client Access и затем откроем Exchange Management Shell в этом сервере. Для импорта сертификата введите следующую команду:

Import-ExchangeCertificate –Path c:\exported_cert.pfx –Password:(Get-Credential).password

После нажатия Enter, вас попросят ввести пароль, который вы задали раньше, как показано на Рисунке 3.23. Не имеет значения, какое имя пользователя вы задали, так как оно не используется в данном виде аутентификации.

После нажатия OK, сертификат был импортирован (Рисунок 3.24).

Теперь скопируйте список сертификата в буфер обмена, затем включите сертификат для необходимых служб, впечатав следующую команду (то же самое, что мы делали в первом сервере Client Access):

Enable-ExchangeCertificate –Thumbprint  -Services “IIS, POP, IMAP”

Теперь SAN был включен должным образом в обоих серверах, и если клиенты доверяют корневому CA из нашего внутреннего Microsoft CA, мы больше не должны получать предупреждения безопасности, когда входим в OWA через имя NLB кластера, как показано на Рисунке 3.26.

Тестирование возможности подключения Outlook 2007

Теперь, когда мы убедились, что доступ OWA 2007 работает должным образом, давайте продолжим и протестируем возможности подключения, используя Outlook 2007. Чтобы это сделать, давайте запустим Outlook 2007 на клиентском устройстве. На странице Auto Account Setup введите имя, Е-мэйл адрес и пароль для включенного почтового ящика пользователя в вашей установке и нажмите Next.

Используя службу Exchange 2007 Autodiscover, Outlook 2007 попробует автоматически настроить установки вашего профиля Outlook. Если все пойдет хорошо, настройка завершится в течение минуты, и вы увидите экран, похожий на тот, что показан на Рисунке 3.28.

Примечание:
Если клиент не доверяет корневому сертификату CA, то вы получите одно или два предупреждений безопасности во время этого процесса.

Теперь, когда профиль Outlook был настроен должным образом, нажмите Finish для запуска Outlook 2007. Открывая Outlook, давайте посмотрим, правильно ли работает служба autodiscover. Это можно сделать нажав правой кнопкой мыши на иконке Outlook в System tray и удерживая клавишу CTRL, затем в контекстном меню выбираем Test E-Mail AutoConfiguration. На странице Test E-mail AutoConfiguration введите ваш E-мэйл адрес и пароль, затем очистите Use Guesssmart и Secure Guesssmart Authentication и нажмите Test.

Через некоторое время вы будете проинформированы, верны ли URL к различным функциям Outlook, выведенные службой Autodiscovery. Как видно на Рисунке 3.29, Outlook AutoConfiguration, Out of Office (OOF), the Offline Address Book (OAB) и Unified Messaging зависят от службы Autodiscovery.

Если мы нажмем на ярлык XML, мы можем видеть контент XML файла Autodiscovery, используемого соответствующим профилем Outlook (Рисунок 3.30).

Тестирование возможности подключения Exchange ActiveSync

В этой статье мы не будем использовать мобильное устройство, работающее под Windows’ом для того, чтобы определить работает ли Exchange ActiveSync (EAS) ожидаемым образом. Вместо этого мы используем командлет Test-ActiveSyncConnectivity, который позволит нам имитировать полную синхронизацию мобильного устройства с определенным почтовым ящиком.

Для проверки возможности подключения Exchange ActiveSync через заданный тип сервера Client Access:

Test-ActiveSyncConnectivity –ClientAccessServer 

Как можно видеть на Рисунке 3.31 возможность подключения Exchange ActiveSync с почтовым ящиком работает хорошо через оба сервера Client Access (время задержки конечно не приемлемо, но это пробный вариант ).

Для более подробной информации о результатах теста введите:

Test-ActiveSyncConnectivity –ClientAccessServer  | FL

Ну вот, мы и достигли конца третьей части, которая была последней в этой статье о том, как развернуть Client Access сервер в NLB установке, установить допустимые SAN сертификаты и, наконец, проверить возможность подключения клиента. Надеюсь, вам понравилось!

Если вы хотите ознакомиться с остальными частями этой статьи, пожалуйста, прочитайте:

• Распределение нагрузки серверов Exchange 2007 Client Access с использованием технологии Windows Network Load-Balancing - Часть 1: Обзор кластеров Windows NLB
• Распределение нагрузки серверов Exchange 2007 Client Access с использованием технологии Windows Network Load-Balancing - Часть 2: Настраиваем кластер Windows NLB