Настройка брандмауэров ISA (ISA 2006 RC) для поддержки аутентификации сертификатов пользователей с использованием ограниченного делегирования Kerberos (часть 2) — сценарий публикации внешнего/внутренн

Обсудите эту статью на веб-доске по адресу http://tinyurl.com/zlcw6.

Настройка брандмауэров ISA (ISA 2006 RC) для поддержки аутентификации сертификатов пользователей с использованием ограниченного делегирования (часть 1) — Сценарий публикации Front-end/Eack-end Exchange Server

В части 1 этой серии из двух частей о том, как опубликовать пару интерфейсных серверов Exchange в конфигурации внешнего/внутреннего Exchange с использованием брандмауэра ISA для обеспечения аутентификации сертификата пользователя, я обсуждал преимущества аутентификации сертификата пользователя, улучшения, которые новый брандмауэр ISA привносит в сценарии аутентификации сертификатов пользователей, а также базовые требования для того, чтобы решение заработало.

В этой статье мы закончим обсуждением следующих тем:

• Настройка каталогов Exchange и создание правил веб-публикации
• Исправление правил веб-публикации
• Тестирование конфигурации
• Расширенные параметры аутентификации сертификата пользователя

Настройка каталогов Exchange и создание правил веб-публикации

Для поддержки ограниченного делегирования Kerberos серверы Exchange FE и BE должны быть настроены для поддержки встроенной проверки подлинности в каталоге /Exchange. Если вы проверите конфигурацию на своих серверах FE и BE Exchange, вы увидите, что это не конфигурация по умолчанию, и если вы позвоните в PSS с проблемой, они, вероятно, скажут вам, что эта конфигурация не поддерживается, и вам следует не включать встроенную аутентификацию в этих каталогах. Это шанс, которым вы пользуетесь при развертывании конфигурации с высоким уровнем безопасности, но я ожидаю, что команда Exchange предоставит обновленные рекомендации и информацию о конфигурации, которые сделают эту конфигурацию поддержкой в будущем.

Единственная проблема, которую я видел с этой конфигурацией (до сих пор), заключается в том, что когда вы нажимаете ссылку «Выход из системы» в интерфейсе OWA, вы видите ошибку «Страница не найдена» в браузере. Я еще не занимался устранением неполадок по этой проблеме, но я планирую опубликовать статью об OWA на следующей неделе, в которой мы публикуем один сервер OWA с помощью KCD, так что к тому времени я должен решить эту проблему, или я по крайней мере, я смогу объяснить свои выводы и посмотреть, сможет ли сообщество найти решение.

Вам необходимо изменить методы аутентификации, разрешенные в каталоге /Exchange на всех серверах FE и BE Exchange. Выполните следующие шаги на каждом сервере Exchange, чтобы установить параметр проверки подлинности:

1. Нажмите «Пуск» и выберите «Администрирование». Щелкните Диспетчер информационных служб Интернета (IIS).
2. В консоли диспетчера информационных служб Интернета (IIS) разверните имя сервера, а затем разверните узел Веб-сайты. Разверните веб-сайт по умолчанию и щелкните узел Exchange. Щелкните правой кнопкой мыши узел Exchange и выберите Свойства.
3. В диалоговом окне «Свойства Exchange» перейдите на вкладку «Безопасность каталога». Нажмите кнопку «Изменить» во фрейме «Аутентификация и управление доступом».
4. В диалоговом окне «Методы проверки подлинности» установите флажок «Встроенная проверка подлинности Windows» и нажмите «ОК».

фигура 1

5. Повторите эту процедуру на каждом сервере Exchange.

Теперь мы готовы создать правило веб-публикации. Как и в предыдущей серии статей, мы будем использовать мастер веб-клиента Exchange для публикации сайтов OWA и RPC/HTTP. Обратите внимание, что я уже создал веб-ферму в предыдущей серии статей, упомянутой ранее в этой статье. Если вы хотите узнать, как создать веб-ферму, используемую в правиле веб-публикации, которое мы собираемся создать, ознакомьтесь с этой статьей.

Выполните следующие шаги, чтобы создать правила веб-публикации:

1. В консоли ISA Firewall разверните узел Arrays, а затем разверните имя массива. Щелкните узел «Политика брандмауэра», а затем щелкните вкладку «Задачи» на панели задач. На вкладке Задачи щелкните ссылку Опубликовать доступ к веб-клиенту Exchange.
2. На странице Вас приветствует мастер нового правила публикации Exchange введите имя правила в текстовом поле Имя правила публикации Exchange. В этом примере мы назовем правило Exchange Farm. Позже вы увидите, что потребуются некоторые изменения в именах правил, чтобы точно определить, для чего предназначены конкретные правила. Нажмите «Далее».
3. На странице «Выбор служб» выберите параметр «Exchange Server 2003» в раскрывающемся списке «Версия Exchange». Установите флажки Outlook Web Access и Outlook RPC/HTTP(s) в параметрах почтовых служб веб-клиента. Нажмите «Далее».

фигура 2

4. На странице «Тип публикации » выберите параметр «Опубликовать ферму серверов веб-серверов с балансировкой нагрузки» и нажмите «Далее».

Рисунок 3

5. На странице «Безопасность подключения к серверу» выберите «Использовать SSL для подключения к опубликованному веб-серверу или ферме серверов». Эта опция указывает брандмауэру ISA пересылать запрос на подключение по защищенному каналу SSL, и это является наилучшей практикой брандмауэра ISA. Если вы не выбрали эту опцию, соединение будет перенаправлено по незащищенному каналу.

   Хотя учетные данные пользователя в этом сценарии не подвергаются риску, поскольку мы используем KCD, данные, перемещаемые по ссылке, легко доступны другому пользователю с помощью анализатора сети (анализатора протоколов). По этой причине, если нет веских соображений безопасности для включения опции низкой безопасности (подумайте о последствиях этого утверждения), вы всегда должны использовать SSL от брандмауэра ISA до опубликованного веб-сервера.

   Нажмите «Далее».
   
   
   
   

Рисунок 4

6. На странице «Сведения о внутренней публикации» введите общее/субъектное имя сертификата веб-сайта, связанного с веб-сайтами FE Exchange Server. В этом примере сертификат веб-сайта, связанный с веб-сайтами FE Exchange Server, имеет общее/субъектное имя owa.msfirewall.org. Вы должны правильно ввести общее/тематическое имя на этой странице, иначе вы получите 500 Internal Server Error при подключении к сайту.

   Нажмите «Далее».
   
   

Рисунок 5

7. На странице «Указать ферму серверов» выберите созданную ранее ферму серверов в раскрывающемся списке «Выберите ферму серверов Exchange, которую вы хотите опубликовать». Нажмите кнопку «Изменить». Если вы ранее ввели IP-адреса для членов фермы серверов, вам потребуется изменить записи с IP-адресов на NetBIOS или полные доменные имена для членов фермы серверов.

   Причина этого в том, что эти имена должны совпадать с именами участников-служб, зарегистрированными для этих серверов. NetBIOS и полные доменные имена для серверов FE Exchange Server автоматически регистрируются как http/ SPN, поэтому нет необходимости запускать утилиту setspn на этих машинах.

   После внесения необходимых изменений нажмите «ОК» в диалоговом окне «Свойства фермы FE Exch», а затем нажмите « Далее» на странице «Указать ферму серверов ».
   
   
   
   

Рисунок 6

8. На странице сведений об общедоступном имени введите общее/субъектное имя сертификата, который будет привязан к веб-прослушивателю. В этом сценарии общее/субъектное имя в сертификате, привязанном к веб-прослушивателю, — owa.msfirewall.org, поэтому мы вводим это имя в текстовое поле Общедоступное имя. Это имя, которое пользователи будут использовать для доступа к сайтам OWA и RPC/HTTP, как внутренним, так и внешним, как описано в этой серии статей. Убедитесь, что во внешней и внутренней зонах DNS есть соответствующие записи DNS для этого имени. Подробности о настройке DNS можно найти здесь.

   Нажмите «Далее».
   
   

Рисунок 7

9. На странице веб-прослушивателя выберите прослушиватель, который мы создали здесь. В этом примере имя веб-прослушивателя — Exch Farm SSL Listener. После завершения работы мастера нам нужно будет внести некоторые изменения в веб-прослушиватель, чтобы правила веб-публикации OWA и RPC/HTTP работали при использовании одного IP-адреса на внешнем интерфейсе брандмауэра ISA.

   Нажмите «Далее» на странице «Выбор веб-прослушивателя».
   
   

Рисунок 8

10. На странице Authentication Delegation выберите вариант ограниченного делегирования Kerberos в раскрывающемся списке Выберите метод, используемый ISA Server для аутентификации на опубликованном веб-сервере. В текстовом поле Введите имя принципа службы (SPN), используемое ISA Server для ограниченного делегирования Kerberos, примите запись по умолчанию http/*. Это необходимо, поскольку мы публикуем веб-ферму Exchange FE Server, в которой веб-службы Exchange работают в контекст локальной системной учетной записи.

    Нажмите «Далее» на странице «Делегирование аутентификации».
    
    

Рисунок 9

11. На странице User Sets примите значение по умолчанию All Authenticated Users и нажмите Next.
12. Нажмите «Готово» на странице «Завершение работы мастера нового правила публикации Exchange».
13. Нажмите OK в диалоговом окне, указывающем, что для этого необходимо настроить имена участников-служб Active Directory.
14. Нажмите кнопку «ОК» еще раз в диалоговом окне, указывающем, что для этого необходимо настроить имена участников-служб Active Directory.
15. Нажмите «Применить», чтобы сохранить изменения и обновить политику брандмауэра.
16. Нажмите «ОК» в диалоговом окне «Применить новую конфигурацию».

Исправление правил веб-публикации

Есть еще несколько вещей, которые нам нужно сделать, чтобы решение заработало. На данный момент правило веб-публикации OWA с использованием KCD работает прямо из коробки, и вы можете протестировать его сейчас, чтобы подтвердить, если хотите. Однако вы обнаружите, что правило веб-публикации RPC/HTTP не работает. Есть две проблемы:

• Настройки по умолчанию в веб-прослушивателе требуют аутентификации всех пользователей.
• Параметр делегирования аутентификации в правиле веб-публикации RPC/HTTP установлен на ограниченное делегирование Kerberos.
• Условие правила установлено на Все аутентифицированные пользователи.

Нам необходимо внести изменения в конфигурацию веб-прослушивателя и правила веб-публикации RPC/HTTP, поскольку клиент Outlook RPC/HTTP не поддерживает аутентификацию сертификата пользователя. Из-за этого у нас потенциально есть два варианта:

• Отключите предварительную аутентификацию на брандмауэре ISA для соединений RPC/HTTP.
• Настройте резервный метод проверки подлинности для подключений RPC/HTTP.

Мы можем отключить предварительную аутентификацию на брандмауэре ISA для соединений RPC/HTTP. Это было бы неудачно, так как одним из основных преимуществ использования брандмауэра ISA в сети является предотвращение атак со стороны анонимных пользователей, которые хотят скомпрометировать серверы FE Exchange.

Возможным решением этой проблемы было бы предоставление резервного механизма, чтобы клиенты, которые не могут пройти аутентификацию с помощью ограниченного делегирования Kerberos, могли бы использовать другую форму аутентификации, например обычную аутентификацию. В интерфейсе брандмауэра ISA Server 2006 есть предположение, что это возможно в конфигурации веб-прослушивателя.

Чтобы просмотреть этот возможный вариант, дважды щелкните правило веб-публикации Exchange Farm RPC/HTTP(s) и перейдите на вкладку Listener. На вкладке Прослушиватель нажмите кнопку Свойства. В диалоговом окне «Свойства прослушивателя SSL Exch Farm» перейдите на вкладку «Аутентификация».

Обратите внимание, что на вкладке Аутентификация у вас есть возможность Использовать резервный метод аутентификации. Установите этот флажок и нажмите кнопку «Настроить».

Рисунок 10

Откроется диалоговое окно «Метод резервной аутентификации SSL». Здесь вы можете выбрать методы аутентификации HTTP: Basic, Digest и Integrated. Поскольку клиент Outlook RPC/HTTP поддерживает базовую аутентификацию, давайте установим флажок Basic, как показано на рисунке ниже.

Рисунок 11

Нажмите «ОК» в диалоговом окне «Метод резервной аутентификации SSL», а затем нажмите «ОК» в диалоговом окне «Свойства прослушивателя SSL Exch Farm».

Ух ху! Похоже, все может сработать. Единственное, что нам нужно сделать сейчас, чтобы мы могли предварительно аутентифицировать соединения RPC/HTTP на брандмауэре ISA, это изменить опцию делегирования аутентификации на делегирование базовой аутентификации. В диалоговом окне свойств RPC/HTTP(S) фермы Exchange щелкните вкладку Делегирование проверки подлинности.

О, нет! Если вы нажмете стрелку вниз для метода, используемого ISA Server для аутентификации в раскрывающемся списке опубликованного веб-сервера, вы обнаружите, что у вас есть три варианта:

• Нет делегирования, но клиент может аутентифицироваться напрямую. Это не поможет, потому что мы хотим предварительно аутентифицировать пользователя на брандмауэре ISA и делегировать базовые учетные данные этого пользователя RPC/HTTP на FE Exchange Server.
• Нет делегирования, и клиент не может аутентифицироваться напрямую. Это определенно не поможет, потому что нам нужно, чтобы клиент Outlook RPC/HTTP аутентифицировался где-то, если не на брандмауэре ISA, то на самом FE Exchange Server.
• Ограниченное делегирование Kerberos Это не может работать, так как клиент Outlook RPC/HTTP не поддерживает проверку подлинности сертификата пользователя.

Обсудите эту статью на веб-доске по адресу http://tinyurl.com/zlcw6.

Чего здесь не хватает, так это возможности делегировать базовые учетные данные для аутентификации. Возможно, это ошибка RC, которая будет исправлена в окончательной версии брандмауэра ISA Server 2006. Но в настоящее время невозможно выполнить предварительную аутентификацию соединений RPC/HTTP на брандмауэре ISA, когда KCD включен на веб-прослушивателе. Конечно, вы всегда можете создать второго прослушивателя, но для этого потребуется второй IP-адрес и второй сертификат.

Рисунок 12

Здесь важно отметить, что ограничение действует только при наличии одного IP-адреса, привязанного к внешнему интерфейсу брандмауэра ISA. Если у вас более одного IP-адреса, вы можете создать второй веб-прослушиватель. Однако для этого необходимо, чтобы общее/субъектное имя в сертификате, привязанном ко второму веб-прослушивателю, отличалось от имени первого веб-прослушивателя, и вам потребуется внести необходимые изменения в DNS, чтобы завершить работающее решение.

Чтобы все заработало в нашем текущем сценарии, нам нужно внести три изменения:

• Измените конфигурацию веб-прослушивателя, чтобы не всем пользователям требовалось проходить аутентификацию. Это не повлияет на безопасность правила веб-публикации OWA, поскольку правило требует аутентификации всех пользователей.
• Измените правило веб-публикации RPC/HTTP, чтобы клиенты RPC/HTTP могли проходить аутентификацию непосредственно на сервере FE Exchange.
• Измените правило веб-публикации RPC/HTTP, чтобы для правила не требовалась проверка подлинности.

Выполните следующие шаги, чтобы внести эти изменения:

1. Дважды щелкните правило Exchange Farm RPC/HTTP(S) в консоли брандмауэра ISA.
2. В диалоговом окне «Свойства Exchange Farm RPC/HTTP(S)» щелкните вкладку «Прослушиватель».
3. На вкладке Прослушиватель нажмите кнопку Свойства.
4. В диалоговом окне «Свойства прослушивателя SSL Exch Farm» перейдите на вкладку «Аутентификация».
5. На вкладке «Аутентификация» нажмите кнопку «Дополнительно».
6. В диалоговом окне «Дополнительные параметры аутентификации» снимите флажок «Требовать аутентификацию всех пользователей ». Нажмите ОК.

Рисунок 13

7. Нажмите «ОК» в диалоговом окне «Свойства прослушивателя SSL Exch Farm».
8. Перейдите на вкладку Делегирование аутентификации.
9. На вкладке «Делегирование аутентификации» выберите вариант «Нет делегирования, но клиент может аутентифицироваться напрямую» в раскрывающемся списке «Метод, используемый ISA Server для аутентификации на опубликованном веб-сервере ».

Рисунок 14

10. Нажмите на вкладку Пользователи.
11. На вкладке «Пользователи» щелкните запись «Все прошедшие проверку» в списке пользователей и нажмите кнопку «Удалить». Нажмите кнопку Добавить.
12. В диалоговом окне «Добавить пользователей» дважды щелкните запись «Все пользователи» и нажмите «Закрыть».

Рисунок 15

13. Нажмите «ОК» в диалоговом окне «Свойства Exchange Farm RPC/HTTP(S)».
14. Появится диалоговое окно, указывающее, что веб-прослушиватель все еще требует аутентификации. Причина этого в том, что изменения, которые мы внесли в веб-прослушиватель, еще не были зарегистрированы. Нажмите OK, чтобы продолжить.

Рисунок 16

15. Нажмите «Применить», чтобы сохранить изменения и обновить политику брандмауэра.
16. Нажмите «ОК» в диалоговом окне «Применить новую конфигурацию».

Протестируйте конфигурацию

Чтобы проверить конфигурацию, запустите клиентское приложение Outlook RPC/HTTP. После завершения соединения используйте встроенный фильтр журнала брандмауэра ISA, чтобы увидеть трафик, который имел место за последние 5-10 минут. Вы увидите что-то вроде того, что показано на рисунке ниже.

Рис. 17 (Щелкните изображение, чтобы увеличить его)

Хотя здесь мало пользы для устранения неполадок подключений RPC/HTTP, следует отметить, что даже если попытка подключения успешна, все, что вы видите здесь, — это неудачные попытки подключения для правила веб-публикации Exchange Farm RPC/HTTP(S). Я включаю эту информацию здесь, чтобы предупредить вас, что если что-то не так с вашим правилом веб-публикации RPC/HTTP, не принимайте записи журнала брандмауэра ISA за чистую монету, поскольку как в рабочих, так и в нерабочих сценариях файлы журналов будут указывать, что соединения связанные с правилом веб-публикации, потерпели неудачу.

Вы можете проверить окно состояния подключения к серверу Exchange на клиентском компьютере, чтобы убедиться, что подключение использует RPC/HTTP, как показано на рисунке ниже.

Рисунок 18

Теперь запустите соединение OWA из клиента Windows XP. В отличие от того, что мы видим с соединениями RPC/HTTP, файлы журналов на брандмауэре ISA показывают успешные соединения для аутентифицированного пользователя, как показано на рисунке ниже.

Рис. 19 (Щелкните изображение, чтобы увеличить его)

Расширенные параметры аутентификации сертификата

Я оставил этот раздел напоследок, так как он на самом деле не был связан с тем, о чем я хотел поговорить в этой статье. Тем не менее, я хотел включить некоторую интересную информацию о значительном улучшении расширенной обработки брандмауэра ISA Server 2006 пользовательских сертификатов в сценарии аутентификации пользовательских сертификатов.

Чтобы просмотреть эти параметры, щелкните узел «Политика брандмауэра» на левой панели консоли и перейдите на вкладку «Панель инструментов». На вкладке «Панель инструментов» щелкните раздел «Сетевые объекты», а затем щелкните папку «Веб-прослушиватели». Дважды щелкните запись прослушивателя SSL Exch Farm.

В диалоговом окне «Свойства прослушивателя SSL Exch Farm» перейдите на вкладку «Аутентификация». На вкладке «Аутентификация» нажмите кнопку «Дополнительно». кнопка. В диалоговом окне «Дополнительные параметры проверки подлинности» щелкните вкладку «Список доверенных сертификатов клиента ». Вы увидите, что показано на рисунке ниже.

Рисунок 20

Обратите внимание на две опции на этой странице:

• Принять любой клиентский сертификат, которому доверяет компьютер ISA Server.
• Принимать только клиентские сертификаты, которым доверяют корневые центры сертификации, выбранные ниже

Это мощная опция, и она связана с тем, что я сказал в начале первой части этой серии статей, состоящей из двух частей, о том, как можно использовать аутентификацию с помощью сертификата пользователя, чтобы гарантировать, что только корпоративным управляемым устройствам разрешено подключаться к опубликованному веб-сайту через Брандмауэр ISA.

Например, предположим, что я хочу, чтобы к моему сайту OWA (или OMA, или ActiveSync) подключались только управляемые машины. Один из способов сделать это — удалить все записи в хранилище доверенных корневых сертификатов машины, кроме сертификата ЦС для нашего корпоративного ЦС. Это может создать проблему, если мы хотим получить доступ к другим безопасным сайтам через наш брандмауэр ISA. Хотя это не должно создавать особых проблем, так как вы вообще не должны работать с брандмауэром ISA, для функции автоматического обновления, включенной в Windows, требуется как минимум корневой центр сертификации, который выпускает сертификат для сайта Microsoft Update. Могут быть и другие обстоятельства, когда вам могут понадобиться другие корневые центры сертификации в списке корневых доверенных лиц брандмауэра ISA.

Лучший способ справиться с этой проблемой — выбрать параметр «Принимать только клиентские сертификаты, которым доверяют корневые центры сертификации», выбранные ниже, а затем выбрать корпоративный ЦС. Поскольку это относится только к веб-прослушивателю, это не влияет на хранилище сертификатов машины. В примере, обсуждаемом в этой серии статей, я бы выбрал сертификат ЦС dc.msfirewall.org. Любой компьютер, на котором представлен сертификат пользователя, выданный другим корневым ЦС, даже если этот ЦС включен в хранилище сертификатов компьютеров доверенных корневых центров сертификации, не будет считаться доверенным, и попытка аутентификации завершится неудачно.

Рисунок 21

Перейдите на вкладку Ограничения клиентского сертификата. На этой вкладке у вас есть возможность принять сертификат клиента только в том случае, если он соответствует хотя бы одному из определенных ограничений. Когда вы нажимаете кнопку «Добавить», вы можете добавлять ограничения на основе:

• Эмитент
• Предмет
• Расширенное использование ключей
• Расширения

На рисунке ниже вы видите, что я настроил ограничение, чтобы принимались только сертификаты пользователя на основе OID сертификата пользователя. Ограничения сертификатов пользователей могут работать с параметрами или вместо них, которые вы настраиваете на вкладке «Список доверия сертификатов клиента ».

Рисунок 22

Прежде чем оставить тему расширенных параметров аутентификации с помощью сертификата пользователя, я хотел бы обсудить еще одну конфигурацию. В этом сценарии вы включаете аутентификацию на основе HTML-форм, а также настраиваете правило, требующее сертификата пользователя. Рассмотрим эту «полуторафакторную» аутентификацию. Пользователь должен иметь сертификат пользователя на своем компьютере и должен иметь возможность вводить действительные учетные данные пользователя.

Я называю это «полуторафакторной» аутентификацией, потому что она не совсем обеспечивает безопасность двухфакторной аутентификации, потому что, если кто-то украдет компьютер, у него будет сертификат, и поэтому ему нужно будет только угадать имя пользователя и пароль. Напротив, при полной двухфакторной аутентификации, если кто-то украдет компьютер, он вряд ли получит смарт-карту вместе с компьютером и, следовательно, останется без смарт-карты и пароля.

Преимущество требования сертификата пользователя при использовании проверки подлинности на основе форм заключается в том, что вы можете использовать утилиту проверки подлинности на основе форм, в то же время гарантируя, что только корпоративные управляемые компьютеры могут подключаться. Для этого перейдите в свойства веб-прослушивателя и щелкните вкладку «Аутентификация». На вкладке «Аутентификация» вы настраиваете метод, используемый клиентами для аутентификации на ISA Server, как аутентификацию с помощью формы HTML, как показано на рисунке ниже.

Рисунок 23

Этот метод работает с ограниченным делегированием Kerberos. Перейдите на вкладку «Делегирование аутентификации » и выберите параметр «Ограниченное делегирование Kerberos» в раскрывающемся списке «Метод, используемый ISA Server для аутентификации на опубликованном веб-сервере ».

Рисунок 24

Последний шаг — щелкнуть вкладку «Трафик», а затем поставить галочку в поле «Запрос сертификата клиента SSL», как показано на рисунке ниже. Когда на брандмауэре ISA настроена аутентификация на основе форм и сертификата пользователя, пользователь сначала выберет свой сертификат, а затем появится форма. Имя в сертификате пользователя должно совпадать с именем, используемым пользователем для аутентификации в брандмауэре ISA.

Рисунок 25

Я знаю, что дал лишь набросок того, как работать с новыми расширенными опциями аутентификации сертификатов брандмауэра ISA, но я хотел дать вам представление о том, что будет дальше. В будущем я напишу серию пошаговых статей о том, как использовать эти расширенные параметры сертификата в различных сценариях публикации.

Обсудите эту статью на веб-доске по адресу http://tinyurl.com/zlcw6.

Резюме

В этой серии статей я рассмотрел принципы и процедуры, связанные с настройкой брандмауэра ISA для поддержки аутентификации сертификата пользователя при подключении к веб-сервисам Exchange. В этой статье мы подробно рассмотрели правила веб-публикации и то, как настроить эти правила, чтобы и OWA, и RPC/HTTP работали, когда в правиле веб-публикации OWA включена аутентификация сертификата пользователя. Мы закончили обсуждением некоторых интересных новых расширенных параметров аутентификации с помощью сертификата пользователя. В будущем я дам несколько пошаговых руководств о том, как использовать эти расширенные возможности аутентификации с помощью сертификата пользователя, включенные в новый брандмауэр ISA. Спасибо! -Том.

Настройка брандмауэров ISA (ISA 2006 RC) для поддержки аутентификации сертификатов пользователей с использованием ограниченного делегирования (часть 1) — Сценарий публикации Front-end/Eack-end Exchange Server