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

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

Если вы хотите получать уведомления о том, когда Том Шиндер выпустит следующую часть этой серии статей, подпишитесь на нашу рассылку новостей ISAserver.org в режиме реального времени.

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

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

Еще одна важная проблема, которую решает поддержка KCD нового брандмауэра ISA, связана с предоставлением пользовательских сертификатов и конфигурацией Active Directory. Чтобы в полной мере использовать аутентификацию сертификата пользователя в ISA 2004, вам нужно было развернуть сертификат пользователя, а затем пройти довольно сложный процесс привязки этого сертификата к учетной записи пользователя в Active Directory. С KCD вам не нужно привязывать этот сертификат к учетной записи пользователя. Это приводит к значительному сокращению накладных расходов администратора.

ПРИМЕЧАНИЕ:
На протяжении всей этой серии и во всех будущих статьях, которые я буду писать об аутентификации с помощью сертификата пользователя, я буду использовать термин « сертификат пользователя», а не «сертификат клиента». Термин «сертификат клиента» сбивает с толку и не является конкретным. Какой тип клиента? Машинный клиент? Пользовательский клиент? Клиент службы? В чем разница между аутентификацией компьютера и аутентификацией пользователя? Разве вызывающий компьютер, который представляет свой сертификат машины целевому серверу, в некоторых сценариях не является «клиентом» целевого сервера? Является ли этот тип аутентификации аутентификацией «клиентский сертификат»? Используя термин «сертификат пользователя», я очень четко указываю тип требуемого сертификата и то, как этот сертификат пользователя используется на практике.

Зачем развертывать аутентификацию сертификата пользователя?

Почему вы хотите использовать аутентификацию сертификата пользователя?

• Проверка подлинности сертификата пользователя не позволяет пользователям входить в свои почтовые ящики с помощью OWA с неуправляемого устройства. Кошмаром для каждого специалиста по сетевой безопасности Microsoft является мысль о том, что какой-нибудь незадачливый пользователь в аэропорту бросит монету в общедоступный интернет-киоск и установит кейлоггер на устройстве, чтобы украсть имя пользователя и пароль исполнительного пользователя.
• Вы можете настроить свои клиенты Windows Mobile с пользовательскими сертификатами, чтобы только управляемые мобильные устройства Windows могли аутентифицироваться с помощью брандмауэра ISA. Это легко сделать, поскольку вы можете развернуть свой собственный ЦС предприятия, а затем настроить брандмауэр ISA так, чтобы он доверял только сертификатам, выданным небольшой группе центров сертификации (таких как Microsoft), от которых пользователи не смогут получить пользовательские сертификаты. В этом случае брандмауэр ISA принимает только сертификат пользователя, выданный вашим ЦС. Мы рассмотрим, как использовать некоторые новые функции брандмауэра ISA Server 2006, чтобы контролировать, какие пользовательские сертификаты действительны для соединений с брандмауэром ISA.
• Смарт-карты содержат сертификаты пользователей. Функция KCD позволяет вам использовать смарт-карты для входа пользователей на веб-сайты, публикуемые брандмауэром ISA, включая все веб-службы Exchange Server и веб-службы SharePoint Portal Server.

KCD — одна из двух отличных функций, которую вы должны проверить, прежде чем даже рассматривать более низкое решение, такое как Blue Coat. Другой обязательной функцией, включенной в новый брандмауэр ISA, является функция балансировки нагрузки веб-фермы, которую я обсуждал в своей предыдущей статье. Единственным недостатком в то время, когда я писал эту статью, было то, что почти не было доступной документации о том, как на самом деле заставить механизм KCD работать с веб-публикацией брандмауэра ISA. Текущая общедоступная информация указывает на то, что вы должны настроить Active Directory, чтобы разрешить делегирование. Не знаю, как вы, но как человек, занимающийся сетевой безопасностью и инфраструктурой, я не провожу чертовски много времени с Active Directory и ее внутренней работой, поэтому я понятия не имел, что делать с этой информацией..

Я потратил около 12 часов, пытаясь понять это для себя, но, в конце концов, сдался, потому что у меня заканчивалось время на «вращение колеса». Я заручился помощью двух прекрасных сотрудников Microsoft, Ави Яара и Томера Ширана. Они помогли мне собрать воедино части, чтобы я мог показать вам, как публиковать ваши FE Exchange Servers в сценарии развертывания front-end/back-end Exchange Server.

На данный момент я должен отметить, что команда Microsoft Exchange официально не поддерживает этот сценарий развертывания. Причина этого в том, что для того, чтобы это работало, мы должны включить встроенную аутентификацию в каталоге /Exchange на серверах FE и BE Exchange. Однако я надеюсь, что когда-нибудь в будущем этот сценарий станет полностью поддерживаемым. Независимо от уровня поддержки со стороны команды Exchange, это работает, поэтому, если вы хотите опробовать его сейчас в своих лабораториях, чтобы показать, что это не оказывает неблагоприятного воздействия на вашу производственную среду, тогда приступайте к делу.

Предположения и требования

В этой статье я буду использовать ту же сетевую среду, которую я изложил в серии статей «Публикация Outlook Web Access и Outlook RPC/HTTP с брандмауэрами ISA Server 2006 Enterprise Edition с использованием проверки подлинности на основе форм (одночленный массив без NLB). В этой конфигурации сети есть несколько ключевых элементов, которые необходимы для работы:

• Все машины должны быть членами одного и того же домена Active Directory. Вы не можете стать смешным и создать страшную хорк «одностороннее доверие», которая создает иллюзию безопасности. Если у вас есть сомнения по поводу присоединения брандмауэров ISA к домену из-за распространенной дезинформации, тогда зайдите и прочитайте Белую книгу , развенчивающую миф о том, что брандмауэр ISA не должен быть членом домена. После того, как вы прочитаете этот документ, вы больше никогда не будете беспокоиться о присоединении массивов брандмауэра ISA к домену.
• Домен должен быть установлен на функциональном уровне Windows Server 2003.
• Вы развернули PKI, чтобы назначить машину и сертификаты пользователей.

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

Напомню, лабораторная среда выглядит так:

фигура 1

В таблице 1 представлена основная информация о конфигурации каждой машины в лаборатории.

Таблица 1: Информация о конфигурации лабораторных машин

Чтобы проверка подлинности сертификата пользователя с ограниченным делегированием Kerberos работала, вам необходимо сделать следующее:

• Настройте учетные записи компьютеров, которые будут доверенными для делегирования
• Настройте каталоги /Exchange и создайте правила веб-публикации.
• Протестируйте конфигурацию

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

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

Настройте учетные записи компьютеров, которые будут доверенными для делегирования

Серверы FE Exchange должны быть настроены так, чтобы доверять билету Kerberos, полученному от имени пользователя, который прошел аутентификацию с помощью сертификата пользователя на брандмауэре ISA. Кроме того, BE Exchange Server должен быть настроен так, чтобы доверять билету Kerberos, полученному от FE Exchange Servers.

Процесс кажется простым в концепции, но когда вы на самом деле пытаетесь настроить эти доверительные отношения, вы чувствуете, что находитесь в центре вертушки и вращаетесь так быстро, как только можете.

Причина этого в том, что у парней из Active Directory все наоборот. Почему назад? Наоборот, потому что, когда я настраиваю серверы FE Exchange так, чтобы они доверяли билетам брандмауэра ISA, я настраиваю учетную запись машины брандмауэра ISA в Active Directory. Это все равно, что сказать, что для того, чтобы заставить Алису доверять Бобу, я пойду к Бобу, чтобы создать это доверие. Не лучше ли обратиться к Алисе, чтобы создать такое доверие?

Независимо от того, имеет ли это какой-то смысл или нет, именно так мы должны поступать. Чтобы создать доверие FE Exchange Servers к билетам брандмауэра ISA, выполните следующие шаги:

1. На контроллере домена ( DC в нашем сценарии) нажмите «Пуск», а затем выберите «Администрирование». Щелкните ссылку Пользователи и компьютеры Active Directory.
2. В консоли «Пользователи и компьютеры Active Directory» разверните имя домена и щелкните узел «Компьютеры». В правой панели консоли дважды щелкните имя брандмауэра ISA. В этом примере брандмауэр ISA называется ISA2006SE.

фигура 2

3. В диалоговом окне ISA2006SE щелкните вкладку Делегирование. На вкладке Делегирование выберите параметр Доверять этому компьютеру только делегирование указанным службам. Затем выберите параметр «Использовать любой протокол аутентификации». После выбора этих двух параметров нажмите кнопку «Добавить».

Рисунок 3

4. В диалоговом окне «Добавить службы» нажмите кнопку «Пользователи или компьютеры».

Рисунок 4

5. В диалоговом окне Select Users or Computers введите NetBIOS-имена интерфейсных серверов Exchange. В этом примере NetBIOS-имена интерфейсных серверов Exchange — FE1EXCHANGE и FE2EXCHANGE2003. Если вы не помните имена своих собственных серверов FE Exchange, вы можете найти их с помощью кнопки «Дополнительно». Нажмите ОК.

Рисунок 5

6. В диалоговом окне «Добавить службы » прокрутите список доступных служб и найдите службу http. Удерживая нажатой клавишу CTRL, выберите все серверы Exchange FE. Нажмите ОК.

Рисунок 6

7. На вкладке Delegation учетной записи компьютера брандмауэра ISA теперь вы должны увидеть имена обоих серверов FE Exchange, а тип службы должен быть указан как http. Нажмите ОК.

Рисунок 7

Теперь вы успешно настроили учетную запись компьютера брандмауэра ISA, чтобы сообщить машинам FE Exchange Servers, чтобы они доверяли билетам брандмауэра ISA, которые он получает от имени пользователя, который прошел аутентификацию в брандмауэре ISA с использованием аутентификации сертификата пользователя.

Следующим шагом является настройка BE Exchange Server так, чтобы он доверял билетам, предоставляемым FE Exchange Servers. Для достижения этой цели выполните следующие шаги:

1. В консоли «Пользователи и компьютеры Active Directory» дважды щелкните один из серверов FE Exchange. В этом примере мы дважды щелкнем учетную запись компьютера FE1EXCHANGE.
2. В диалоговом окне «Свойства FE1EXCHANGE» щелкните вкладку «Делегирование». На вкладке Делегирование выберите параметр Доверять этому компьютеру только делегирование указанной службе, а затем выберите параметр Использовать любой протокол проверки подлинности. Нажмите кнопку Добавить.
3. В диалоговом окне «Добавить службы» нажмите кнопку «Пользователи или компьютеры».
4. В диалоговом окне Select Users or Computers введите имя компьютера BE Exchange. Если вы не помните имя, используйте кнопку «Обзор», чтобы найти машину.
5. В диалоговом окне «Добавить службы» выберите службу http для компьютера BE Exchange и нажмите «ОК».
6. Нажмите OK в диалоговом окне свойств FE1EXCHANGE.

Рисунок 8

7. Повторите процедуру для всех остальных серверов FE Exchange.

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

Резюме

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

подпишитесь на нашу рассылку новостей ISAserver.org в режиме реального времени