На главную страницу
 
  Главная 
  Новости 
  Статьи  RSS
  Программное обеспечение 
  Форум 
  Опросы 
  Полезные ссылки 
MSExchange.ru ISADocs.ru WinSecurity.ru NetDocs.ru

Exchange 5.5
Exchange 2000
Exchange 2003
Exchange 2007
Общее
Exchange 2010

Поиск по сайту


Авторизация

Запомнить меня на этом компьютере
  Забыли свой пароль?
  Регистрация

Подписка

Изменение параметров

Статистика

Hits 2084285
9729
Hosts 1617528
2219
Visitors 166594
2699

9

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


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

Версия для печати Версия для печати

Эта статья переведена силами и средствами компании Red Line Software. Размещение данного переведенного материала на других сайтах без разрешения компании Red Line Software запрещается.

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

В этой статье мы продолжим с того места, на котором остановились во второй части. Мы создадим новый сертификат 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.

Рисунок 3.1: Предупреждение безопасности сертификатаРисунок 3.1: Предупреждение безопасности сертификата

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

Рисунок 3.2: Страница входа в OWA 2007Рисунок 3.2: Страница входа в OWA 2007

Из-за проблемы с сертификатами 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), то ваше соединение будет оборвано.

Рисунок 3.3: Отключение LAN соединенияРисунок 3.3: Отключение LAN соединения

Давайте попробуем еще раз войти в 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 кластера.

Рисунок 3.4: Определение правил портаРисунок 3.4: Определение правил порта

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

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

Рисунок 3.5: Альтернативные имена объекта на странице свойств сертификата CAS01Рисунок 3.5: Альтернативные имена объекта на странице свойств сертификата CAS01
Рисунок 3.6: Альтернативные имена объекта в CAS01 через Exchange Management ShellРисунок 3.6: Альтернативные имена объекта в CAS01 через Exchange Management Shell

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

Примечание:
Так как нам нужен сертификат, в котором множество 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.

Рисунок 3.7: Создание запроса для нового SAN сертификатаРисунок 3.7: Создание запроса для нового SAN сертификата

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

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

Certutil –setreg policy\EditFlags –EDITF_ATTRIBUTESUBJECTALTNAME2

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

Рисунок 3.8: Изменение EditFlags в Microsoft CAРисунок 3.8: Изменение EditFlags в Microsoft CA

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

Figure 3.9: Перезапуск службы сертификации МайкрософтРисунок 3.9: Перезапуск службы сертификации Майкрософт

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

Рисунок 3.10: Страница Microsoft Certificates WelcomeРисунок 3.10: Страница Microsoft Certificates Welcome

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

Рисунок 3.11: Запрос сертификатаРисунок 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).

Рисунок 3.12: Выбор второй опции на странице Advanced Certificate RequestРисунок 3.12: Выбор второй опции на странице Advanced Certificate Request

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

Рисунок 3.13: Запуск запроса сертификатаРисунок 3.13: Запуск запроса сертификата

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

Рисунок 3.14: Скачивание выданного СертификатаРисунок 3.14: Скачивание выданного Сертификата

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

Import-ExchangeCertificate –Path c:\certnew.p7b

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

Рисунок 3.15Рисунок 3.15

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

Get-ExchangeCertificate -Thumbprint  | FL 
Рисунок 3.16: SAN Сертификат – Подробная информацияРисунок 3.16: SAN Сертификат – Подробная информация

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

Enable-ExchangeCertificate –Thumbprint  -Services “IIS, POP, IMAP”
Рисунок 3.17: Включение SAN сертификатаРисунок 3.17: Включение SAN сертификата

Теперь сертификат включен для этих служб, но только в первом сервере 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).

Рисунок 3.18: Выбираем Export в контекстном менюРисунок 3.18: Выбираем Export в контекстном меню

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

Рисунок 3.19: Экспортирование приватного ключаРисунок 3.19: Экспортирование приватного ключа

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

Рисунок 3.20: Выбор формата для использованияРисунок 3.20: Выбор формата для использования

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

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

Рисунок 3.21: Ввод пароля в целях защиты приватного ключаРисунок 3.21: Ввод пароля в целях защиты приватного ключа

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

Рисунок 3.22: Определение пути для .PFX файлаРисунок 3.22: Определение пути для .PFX файла

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

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

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

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

Рисунок 3.23: Импорт сертификатаРисунок 3.23: Импорт сертификата

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

Рисунок 3.24: Сертификат импортированРисунок 3.24: Сертификат импортирован

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

Enable-ExchangeCertificate –Thumbprint  -Services “IIS, POP, IMAP”
Рисунок 3.25: Включение SAN сертификата во втором сервере Client AccessРисунок 3.25: Включение SAN сертификата во втором сервере Client Access

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

Рисунок 3.26: Вход в OWA 2007 без предупреждений безопасностиРисунок 3.26: Вход в OWA 2007 без предупреждений безопасности

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

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

Рисунок 3.27Рисунок 3.27

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

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

Рисунок 3.28: Настройка Outlook прошла успешноРисунок 3.28: Настройка Outlook прошла успешно

Теперь, когда профиль 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.

Рисунок 3.29: Зависимые от Autodiscovery функции работают правильноРисунок 3.29: Зависимые от Autodiscovery функции работают правильно

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

Рисунок 3.30: XML файл Autodiscovery используемый профилем OutlookРисунок 3.30: XML файл Autodiscovery используемый профилем Outlook

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

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

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

Test-ActiveSyncConnectivity –ClientAccessServer 

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

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

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

Test-ActiveSyncConnectivity –ClientAccessServer  | FL

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

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





Рейтинг:  
1.7 (голосов 3)  
 1   2   3   4   5    

Автор: Генрик Валзер (Henrik Walther)
Генрик Валзер (Henrik Walther) является Microsoft Exchange MVP и работает в качестве Старшего Технического Консультанта в Interprise, Золотом Партнере Microsoft, расположенном в Дании. Вы можете посетить его web-сайт по адресу: www.exchange-faq.dk (на датском).
Эта статья переведена и опубликована с разрешения www.msexchange.org

Эта статья переведена силами и средствами компании Red Line Software. Размещение данного переведенного материала на других сайтах без разрешения компании Red Line Software запрещается.





Работает на «Битрикс: Управление сайтом»
Работает на «Битрикс:
 Управление сайтом»
© MSExchange.ru, 2005-2010