| Новые программы oszone.net |  |
В первой части этого цикла статей я предоставлю вам некоторую базовую информацию о том, как Exchange Direct push работает и какие шаги необходимо выполнить на сайте Exchange и IIS, чтобы опубликовать Microsoft Exchange Active Sync. Exchange Server 2003 предоставляет безопасный доступ к почтовым ящикам сервера Exchange Server для мобильных устройств с клиентами Windows Mobile 5 и более новых версий. С каждой версией Exchange Server компания Microsoft расширяет и упрощает работу с мобильными устройствами, но всегда остается один и тот же вопрос о том, как обеспечить безопасный мобильный доступ с клиентов Mobile к вашей внутренней сети. Самые лучшие рабочие возможности Windows Mobile для Exchange Server 2003 идут с пакетом обновления Service Pack 2. Exchange Server 2007 предлагает гораздо больше улучшенных и новых мобильных функций Windows, чем его предшественник. Одним из решений является использование сервера ISA Server 2006, который обладает широким спектром опций безопасности, начиная от HTTPS-Bridging для предварительной аутентификации клиентов и заканчивая доступом только к одному URL. В этой статье мы расширим безопасность доступа нашего мобильного клиента с помощью клиентских сертификатов на мобильном устройстве. Только мобильный клиент с действительным клиентским сертификатом от нашего внутреннего доверенного центра сертификации может иметь доступ к Exchange Server. Всегда есть возможность расширять безопасность, если ISA будет доверять только сертификатам с издающего сертификаты компонента безопасности. Я расскажу, как это делать, немного позже. На сайте ExchangeНа сервере Exchange Server нужно выполнить лишь несколько шагов. Запустить диспетчера Exchange System Manager и перейти в свойства мобильной службы. Вы должны включить Direct Push через HTTP(s), чтобы разрешить доступ для клиентов Windows Mobile. Ваше мобильное устройство Windows Mobile должно иметь пятую или более позднюю версию с MSFP (Безопасность службы сообщений и пакет функций (Messaging Security and Feature Pack)). Обратите внимание:если вы хотите расширить безопасность вашей среды Exchange так, чтобы отказывать в доступе к серверу Exchange Server некоторым мобильным клиентам, прочтите эту статью. В качестве необязательного, но рекомендуемого шага вы должны также включить безопасность устройств (Device Security) для повышения уровня безопасности ваших мобильных устройств.
Рисунок 1: Включение Direct Push по HTTP(s) Есть несколько опций, которые можно активировать и ввести в действие. Вы должны решить, какие из этих опций будут полезны для вашей организации Exchange и ваших мобильных пользователей. В качестве рекомендуемой минимальной длины пароля следует принуждать пользователей использовать не менее 8 знаков для паролей, при этом пароли должны содержать буквы и цифры.
Рисунок 2: Параметры безопасности устройств На мой взгляд, хорошей идеей будет вытеснение устройства после каждого количества x неудачных попыток входа. Вытеснение после восьми попыток будет отличной стартовой точкой. Для расширенного администрирования мобильных устройств Windows Mobile следует обратить внимание на выходящего вскоре диспетчера Microsoft System Center Mobile Device Manager 2008. С помощью диспетчера Microsoft System Center Mobile Device Manager (SYMDM) вы сможете централизованно управлять всеми частями мобильных устройств Windows Mobile. Вы можете найти дополнительную информацию о WMDC на данном веб сайте. Microsoft System Center Mobile Device Manager требует клиентов Windows Mobile версии 6.1 и выше. На сайте IISПоскольку мы хотим защитить трафик между сервером Exchange Server и устройством Windows Mobile, мы должны издать сертификат веб сервера, который будет использоваться для защиты коммуникации. IIS нужен сертификат для стандартного веб сайта. Так как мы используем внутренний центр сертификации Enterprise CA в этой статье, можно запросить сертификат с этого центра сертификации. Если у вас отсутствует внутренний CA, можно также использовать инструмент, который генерирует самоподписываемые сертификаты (self signed certificates). Одним из примеров такого инструмента является SELFSSL из пакета ресурсов IIS6. Если вы используете самоподписываемый сертификат, его также необходимо импортировать и в хранилище сертификатов доверенного корневого центра сертификации на Exchange и ISA серверах. Рисунок 3: SSL сертификат для стандартного IIS веб сайта Обратите внимание:имя, которое вы используете здесь, также является частью общего имени (Common Name - CN) на сертификате. Следует помнить, что необходимо использовать это имя в правиле публикации ISA в поле ‘to’. ДилеммаMicrosoft Exchange Active Sync требует, чтобы для каждой виртуальной директории Exchange защита SSL не использовалась. Это означает, что если вы не требуете SSL, пользователи смогут получать доступ к OWA с SSL или без него. Это не должно создавать проблем, если вы уверены в том, что ISA Server не разрешает HTTP доступ к веб сайту OWA. Если вам не нравится такой параметр, можно внедрить SSL на стандартном веб сайте Exchange и использовать Microsoft Exchange Active sync после выполнения определенной работы. Читайте здесь о том, как это сделать. Краткая заметка, нужно создать дополнительную виртуальную директорию для Exchange Active Sync. Вам нужно скопировать стандартную /Exchange виртуальную директорию в новую директорию и после этого направить Exchange Active Sync на новую виртуальную директорию. Это делается путем изменения ключа системного реестра. Рисунок 4: Не требуйте SSL на виртуальном веб сайте Exchange Вам также нужно включить использование клиентских сертификатов. Включите опцию Требовать клиентские сертификаты и Включить сопоставление клиентских сертификатов. Нажмите Изменить и OK (вам не нужно здесь ничего менять; вам лишь нужно нажать Изменить и OK, чтобы включить функцию).
Рисунок 5: Требование клиентских сертификатов В качестве последнего шага нам нужно включить службу сопоставления директорий Windows в свойствах раздела веб сайта, во вкладке объекта компьютера IIS в диспетчере IIS.
Рисунок 6: Включение службы сопоставления директорий Windows Ограниченное делегирование Kerberos (Kerberos constrained delegation)Так как мы используем клиентские сертификаты, ISA должен брать на себя процесс аутентификации и аутентифицировать пользователя, поэтому мы должны использовать KCD (Kerberos constrained delegation). Это тоже одна из причин, по которой сервер ISA Server должен быть членом домена Active Directory. Откройте оснастку пользователей и компьютеров Active Directory (DSA.MSC), перейдите к объекту ISA Server ‘ Делегирование и включите «доверять» для процесса делегирования для HTTP и W3SVC процесса сервера Exchange Server.
Рисунок 7: KCD Если вы не видите вкладку делегирования, вам нужно включить Расширенный вид в DSA.MSC. Запрос сертификата для правила публикации ISAВ качестве следующего шага нам нужно выполнить запрос на сервере ISA Server для публичного имени правила публикации. Вы должны запросить сертификат с CN=публичным именем, которое используется в качестве внешнего имени сервера в конфигурации мобильных устройств для EAS.
Рисунок 8: Запрос сертификата на ISA Server Если вы не можете открыть веб сайт certsrv на сервере ISA Server, вам нужно создать правило брандмауэра, которое позволит HTTPS с LOCALHOST к серверу CA. ЗаключениеВ этой статье я попытался показать вам, как использовать Exchange Active Sync с ISA Server 2006 и Exchange Server 2003 SP2 и клиентскими сертификатами. Сочетание ISA Server 2006 и клиентских сертификатов дает вам максимальную безопасность для Exchange Active Sync. Как вы видели, для включения Exchange Active Sync в этой конфигурации требуются определенные шаги. Здесь также есть определенные ловушки в виде неверных сертификатов и неправильно настроенного KCD, но я надеюсь, что эта статья даст вам четкое понимание того, как применять данное решение в вашей среде. Дополнительные ссылки:
Теги:
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.
|
|
