Это первая часть статьи о том, как настроить на сервере ISA Server 2006 поддержку ограниченного делегирования Kerberos
Одним из основных улучшений в новой версии ISA-сервере является поддержка делегирования учетных данных Kerberos пользователей, проходящих аутентификацию на ISA-сервере с помощью пользовательских сертификатов. ISA Server 2006 поддерживает Ограниченное Делегирование Kerberos (Kerberos Constrained Delegation – KCD), что позволяет пользователям предъявлять пользовательские сертификаты ISA-серверу и автоматически переносить учетные данные пользователя на нужный web-сервер. Это предотвращает повторное предъявление учетных данных.
В ISA 2004, когда пользователь проходит аутентификацию на ISA-сервере с помощью пользовательского сертификата, учетные данные не передавались на web-сервер. Если web-сервер также требовал аутентификацию, пользователю приходилось вводить учетные данные во второй раз. Для пользователей, регистрирующихся в web-браузерах, это было небольшим неудобством, однако для мобильных устройств Windows это становилось большой проблемой. Помимо этого, тот факт, что пользователям нужно было вручную вводить учетные данные, говорит о проблеме безопасности, поскольку злоумышленник мог подглядеть учетные данные при вводе.
Другая проблема, которую решает поддержка KCD в новой версии ISA-сервера, связана с предоставлением пользовательских сертификатов и настройками Active Directory. Для предоставления полной безопасности при использовании пользовательских сертификатов в ISA 2004 вам было необходимо разворачивать инфраструктуру пользовательских сертификатов, а затем пройти через сложный процесс привязки сертификата в учетной записи пользователя в Active Directory. При использовании KCD вам не нужно привязывать сертификат к учетной записи пользователя. Таким образом, происходит огромное сокращение администраторских задач.
ЗАМЕЧАНИЕ: В данной и последующих статьях об аутентификации с помощью пользовательского сертификата я буду использовать термин пользовательский сертификат, а не клиентский сертификат. Термин «клиентский сертификат» сбивает с толку и не является точным. Какой клиент? Компьютер-клиент? Пользователь-клиент? Служба-клиент? Какая разница между аутентификацией компьютера и аутентификацией пользователя? Разве компьютер, предъявляющий свой сертификат серверу в некоторых сценариях, не является «клиентом» этого сервера? Можно ли назвать это тип аутентификации «аутентификацией с помощью клиентского сертификата»? Используя термин пользовательский сертификат, я точно определяю тип сертификата и способ его использования.
Зачем же нужно использовать аутентификацию с помощью пользовательских сертификатов?
KCD – это одна из двух самых необходимых функций, которую нужно проверить до рассмотрения идеи внедрения решений более низкого уровня, таких, как, например, продуктов Blue Coat. Другая такая функция – это функция распределения нагрузки web-серверов. Единственным недостатком в момент написания было практически полное отсутствие документации о работе механизма KCD с web-публикациями ISA-сервера. Теперь можно найти информацию о том, как настроить Active Directory на разрешение делегирования. Я не знаю как вы, но, будучи специалистом по сетевой безопасности, я не трачу время на Active Directory и ее внутреннее устройство, поэтому, что делать с этой информацией, я не знаю.
Я потратил почти 12 часов на то, чтобы понять это и, в конце концов, сдался, поскольку время поджимало. Я запросил помощи у двух сотрудников Microsoft, Ави Яаара и Томера Ширана. Они объяснили, как решить проблему, и теперь я могу рассказать вам о том, как опубликовать внешние Exchange-серверы в сценарии с внутренними и внешними Exchange-серверами.
Стоит отметить, что команда разработчиков Microsoft Exchange официально не поддерживает такой сценарий внедрения. Причина в том, что для того, чтобы такой сценарий работал, мы обязаны включить встроенную аутентификацию на доступ к папке /Exchange на внешних и внутренних серверах Exchange. Однако, я надеюсь, что в будущем данный сценарий будет полностью поддерживаться. Не смотря на отсутствие поддержки от разработчиков Exchange, он работает, поэтому если хотите, можете опробовать его уже сейчас в тестовых условиях для проверки того, что на продуктивной системе не будет никаких проблем.
В данной статье я буду использовать то же самое сетевое окружение, которое я применял всегда до этого. Вот некоторые ключевые элементы конфигурации, необходимые для ее работы:
В данной статье я построил сеть на основе предыдущих статей, так что я предполагаю, что у вас сетевая инфраструктура отлажена, внедрены компьютерные сертификаты, установлен ISA-сервер и вы готовы вносить необходимые изменения в Active Directory и создавать правила web-публикации.
Тестовая сеть должна выглядеть так:
Рисунок 1
В Таблице 1 указана важная информация о конфигурации каждого компьютера в сети.
| Имя компьютера | DC | BEEXCAHNGE2003 | FE1EXCHANGE | FE2EXCHANGE | ISA2006SE** |
|---|---|---|---|---|---|
| Иформация об IP-адресе | IP-адрес: 10.0.0.2/24 Шлюз по умолчанию: 10.0.0.1 DNS: 10.0.0.2 | IP-адрес: 10.0.0.3/24 Шлюз по умолчанию: 10.0.0.1 DNS: 10.0.0.2 | IP-адрес: 10.0.0.4/24 Шлюз по умолчанию: 10.0.0.1 DNS: 10.0.0.2 | IP-адрес: 10.0.0.5/24 Шлюз по умолчанию: 10.0.0.1 DNS: 10.0.0.2 | Внешний IP-адрес 192.168.1.71/24 Шлюз по умолчанию: 192.168.1.60/24 Внутренний IP-адрес: 10.0.0.1/24 DNS: 10.0.0.2* |
| ОС | Windows Server 2003 SP1 | Windows Server 2003 SP1 | Windows Server 2003 SP1 | Windows Server 2003 SP1 | Windows Server 2003 SP1 |
| Установленные сетевые службы | DHCP DNS Корпоративный центр сертификации IAS WINS Active Directory CMAK | Microsoft Exchange Server 2003 SP2 Настроен как внутренний Exchange-сервер | Microsoft Exchange Server SP2 Настроен как первый из двух внешних Exchange-серверов | Microsoft Exchange Server SP2 Настроен как второй из двух внешних Exchange-серверов | ISA Server 2006 Enterprise Edition единственный член массива CSS Член домена (рекомендуется) |
| Установленные сертификаты | Сертификат центра сертификации для корпоративного центра сертификации, установленного на контроллере домена | Сертификат центра сертификации для корпоративного центра сертификации, установленного на контроллере домена | Сертификат центра сертификации для корпоративного центра сертификации, установленного на контроллере домена Сертификат Web-сайта с именем owa.msfirewall.org, установленный на web-сайте по умолчанию | Сертификат центра сертификации для корпоративного центра сертификации, установленного на контроллере домена Сертификат Web-сайта с именем owa.msfirewall.org, установленный на web-сайте по умолчанию | Сертификат центра сертификации для корпоративного центра сертификации Сертификат Web-сайта с именем owa.msfirewall.org, установленный в хранилище сертификатов для использования его на web-приемнике |
| Замечания: | DC – это контроллер домена данной сети, в которой все компьютеры являются членами домена msfirewall.org. Active Directory установлена в функциональном уровне Windows Server 2003 Все дополнительные сетевые службы, необходимые ISA-серверу, установлены на DC. Это не является конфигурацией с высоким уровнем безопасности. Например, DHCP-серверы лучше располагать на компьютере, не являющимся контроллером домена Некоторые службы, такие как CMAK и IAS, установлены для поддержки настроек, не обсуждаемых в данной статье. | BEEXCHANGE2003 – это внутренний Exchange-сервер в том же самом домене, что и другие серверы. Он является внутренним Exchange-сервером для двух внешних Exchange-серверов. Обратите внимание, что данная конфигурация не является предпочтительной. В зависимости от количества почтовых ящиков, может потребоваться наличие двух и более внутренних Exchange-серверов. | FE1EXCHANGE – это первый из двух внешних Exchange-серверов. На этом компьютере расположена серверная часть сайтов OWA и RPC/HTTP-прокси. | FE1EXCHANGE – это первый из двух внешних Exchange-серверов. На этом компьютере расположена серверная часть сайтов OWA и RPC/HTTP-прокси. | * Крайне важно, чтобы на ISA-сервере был настроен один адрес DNS-сервера, и был он настроен только на внутреннем интерфейсе, который должен располагаться в самом верху списка адаптеров. **Имя сервера отражает использование Standard Edition, но это используется только в тестовых условиях. В данной статье на компьютере ISA2006SE установлен ISA Server 2006 Enterprise Edition. ISA-сервер является членом домена, что, в общем, более безопасно. Некоторые возможности ISA Server 2006 уменьшают более низкую безопасность в случает отсутствия членства в домене, но не удаляют ее совсем. Обратите внимание, что шлюзом по умолчанию в моей тестовой сети является внутренний адрес ISA-сервера. Это сделано только для тестовой среды. Вы должны настроить шлюз по умолчанию сначала для тестовой, а потом для актуальной среды. |
Таблица 1: Информация о настройках тестовых компьютеров
Для работы аутентификации с помощью пользовательских сертификатов с ограниченным делегированием Kerberos вам нужно сделать следующее:
В данной части мы настроим учетные записи компьютеров для доверительных отношений при делегировании, а во второй части мы создадим правила web-публикации и проверим конфигурацию.
Внешние Exchange-серверы должны быть настроены на доверие билету Kerberos, полученному от имени пользователя, который прошел аутентификацию с помощью пользовательского сертификата на ISA-сервере. Помимо этого, внутренний Exchange-сервер должен быть настроен на доверие билету Kerberos, полученному от внешних Exchange-серверов.
В теории все просто, однако при попытке настроить все это у вас может возникнуть ощущение, что вы попали в заколдованный круг, который к тому же еще и вращается с большой скоростью.
Причина в том, что в Active Directory все запутано. Почему? Да потому, что для того, чтобы настроить внешние Exchange-серверы на доверие к ISA-серверу, я должен выполнять настройки на учетной записи ISA-сервера в Active Directory. Проще говоря, для того, чтобы Алиса доверяла Бобу, я должен настроить Боба на доверие Алисе. Не проще ли настроить доверительные отношения сразу у Алисы?
Поняли ли вы или нет, но это работает именно так. Для того, чтобы внешние Exchange-серверы доверяли билетам ISA-сервера, выполните следующее:
Рисунок 2
Рисунок 3
Рисунок 4
Рисунок 5
Рисунок 6
Рисунок 7
Вы успешно настроили учетную запись ISA-сервера на сообщение внешним Exchange-серверам, что они теперь могут доверять билетам ISA-сервера, полученных им от пользователей, аутентифицировавшихся на ISA-сервере с помощью пользовательских сертификатов.
Теперь нам нужно настроить внутренний Exchange-сервер на доверие билетам, предоставляемых внешними Exchange-серверами. Для этого выполните следующее:
Рисунок 8
В первой части статьи о настройке ISA Server 2006 на поддержку ограниченного делегирования Kerberos я рассказал об основных принципах и требованиях для работы ограниченного делегирования Kerberos. Далее мы рассмотрели детали настройки необходимых доверительных отношений для того, чтобы делегирование Kerberos правильно установилось между ISA-сервером и внешними Exchange-серверами и между внешними Exchange-серверами и внутренним Exchange-сервером. В следующей (и, обещаю, последней) части статьи мы создадим правила web-публикации и протестируем конфигурацию. До встречи!
www.isaserver.org
Tags: dns, Exchange, ISA Server