Конфигурирование Kerberos в Windows Server 2003

Как говорилось выше, протокол Kerberos по умолчанию задан в качестве опознавательного протокола для клиентов с системами Windows 2000, или более поздними, которые входят в Active Directory. Вы можете сконфигурировать несколько свойств Kerberos через политику безопасности домена. Чтобы обратиться к параметрам настройки политики Kerberos, откройте пункт Domain Security Policy (Политика безопасности домена) из инструментов администрирования и разверните папку Account Policies (Политики учетных записей) (см. рис. 8-7). Вам станут доступны следующие политики.

Рис. 8-7. Конфигурирование параметров настройки протокола Kerberos через Domain Security Policy (Политика безопасности домена)

• EnforceUserLogonRestrictions(Усиление ограничений пользовательского входа в систему). Эта политика устанавливает опцию службы KDC, по которой при каждом запросе на билет сеанса проверяются установки прав пользователя на целевом компьютере. Если эта политика включена, то пользователь, запрашивающий билет сеанса, должен иметь права Allow Log On Locally (Разрешить локальный вход), если он вошел в систему в интерактивном режиме, или права Access This Computer From The Network (Доступ к этому компьютеру из сети) на целевом компьютере. Эти права назначаются в меню Local Policies\User Rights Assignment (Локальные политики\ Назначение прав пользователей) в пункте Domain Security Policy (Политика безопасности домена). По умолчанию эта политика включена.
• MaximumLifetimeForServiceTicket(Максимальный срок годности служебного билета). Эта политика устанавливает максимальное время (в минутах), в течение которого билет сеанса может использоваться для доступа к определенной службе. Если установлен нуль минут, то срок годности билета никогда не окончится. Если установлено ненулевое количество минут, то оно должно быть больше, чем 10 минут, и меньше или равно значению, установленному для параметра Maximum Lifetime For User Ticket (Максимальный срок годности для пользовательского билета). По умолчанию эта установка составляет 600 минут (10 часов).
• MaximumLifetimeForUserTicket(Максимальный срок годности для пользовательского билета). Эта политика устанавливает максимальное время (в часах), в течение которого может использоваться TGT-билет пользователя. После того как истечет срок годности TGT-биле-та, существующий билет должен быть возобновлен, иначе нужно затребовать новый билет в центре KDC. По умолчанию эта установка составляет 10 часов.
• MaximumLifetimeForUserTicketRenewal(Максимальный срок, в течение которого возможно обновление пользовательского билета). Эта политика устанавливает время (в днях), в течение которого TGT-билет может быть возобновлен (вместо получения нового TGT-биле-та). По умолчанию эта установка составляет 7 дней.
• MaximumToleranceForComputerClockSynchronization(Максимально допустимое расхождение в показаниях компьютерных часов). Эта политика устанавливает максимальную разницу во времени (в минутах) между временем на компьютере клиента и временем на контроллере домена, обеспечивающем аутентификацию по протоколу Kerberos, которую протокол Kerberos считает допустимой. Если разница во времени между показаниями этих двух компьютеров больше, чем допустимый уровень, все билеты Kerberos будут отвергнуты. По умолчанию эта установка составляет 5 минут. Имейте в виду, что в случае изменения этой установки при перезапуске компьютера она возвратится к заданному по умолчанию значению.

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

Интеграция с инфраструктурой открытых ключей

В основе протокола Kerberos лежит опознавательная модель с общим секретом. Это обеспечивает превосходную защиту, но налагает одно важное ограничение на обеспечение доступа к сети Windows Server 2003. Это ограничение состоит в том, что каждый пользователь, который обращается к сети, должен иметь учетную запись в базе данных учетных записей службы KDC. Если пользователь не существует в базе данных, ему нельзя предоставить доступ к сети.
Эта модель хорошо работает в тех компаниях, в которых все пользователи, входящие в сеть, известны, и учетная запись может быть создана для каждого пользователя. Однако многие компании расширяют список пользователей, имеющих доступ к сетевым ресурсам, включая в него пользователей, которые не являются служащими. Компания может вступить в краткосрочное партнерство с другой компанией, и ей потребуется обеспечить доступ к сетевым ресурсам для служащих другой компании. Или компания захочет предоставить доступ к ресурсам, имеющимся в сети компании, определенным клиентам. В этих сценариях список людей, которым требуется доступ к сети, может быть очень длинным, так что создание учетной записи для каждого из пользователей будет непрактичным.

Инфраструктура открытых ключей (PKI - Public Key Infrastructure) стала основным средством для решения проблемы предоставления доступа к сети пользователям, не имеющим учетной записи пользователя. Система PKI отходит от модели аутентификации с общим секретом и заменяет ее опознавательной моделью, основанной на сертификате. В системе PKI пользователи аутентифицируются на основании того факта, что они имеют правильный сертификат. Система PKI основана на трех основных концепциях: открытые (public) и личные (private) ключи, цифровые сертификаты и сертификационные власти (СА - certificate authorities). PKI начинается с концепции, согласно которой каждый пользователь или компьютер, вовлеченный в информационный обмен, имеют два ключа: личный ключ и открытый ключ. Личный ключ известен только одному пользователю. Его можно сохранить на жестком диске компьютера, как часть роумингового (roaming) профиля, или на устройстве типа смарт-карты. Открытый ключ доступен любому, кто его попросит. Личные и открытые ключи связаны, но нет никакого способа извлечь личный ключ из открытого ключа. Эти ключи используются различными способами.

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

Другой способ применения состоит в использовании цифровой подписи и печати для сообщений, посылаемых между двумя пользователями. Цифровая подпись используется для гарантии подлинности отправителя сообщения и целостности сообщения. Чтобы создать цифровую подпись, все сообщение подвергается математическому хэшированию. Хэш является «сверткой сообщения», или цифровым дайджестом (digest), который зашифрован с помощью личного ключа отправителя сообщения. Зашифрованный хэш посылается вместе с сообщением как цифровая подпись. Когда адресат получает сообщение, к нему применяется тот же самый хэш, создавая второй дайджест сообщения. Затем используется открытый ключ отправителя для расшифровки цифровой подписи. Если дайджест сообщения получателя идентичен расшифрованной подписи, то целостность и подлинность сообщения подтверждены.

Второй компонент PKI — цифровой сертификат. Цель применения сертификата состоит в том, чтобы идентифицировать владельца сертификата. Когда человек или компания обращаются к сертификационным властям (СА) для получения сертификата, СА-власти подтверждают подлинность человека или компании, запрашивающей сертификат. Когда
пользователю предоставляется сертификат, он получает соответствующий открытый ключ, а также личный ключ для сертификата. Сертификат подписан сертификационными властями с помощью цифровой подписи, добавляя к сертификату штамп подлинности СА-властей. Текущий стандарт для сертификатов -Х.509 v3. Сертификат включает информацию о человеке, компьютере или службе, для которых он был выпущен, информацию о самом сертификате (дата истечения срока годности) и информацию об СА-властях, выпустивших данный сертификат.

Сертификаты, необходимые для инфраструктуры PKI, выпускаются властями СА, которые являются сетевыми серверами, управляющими предоставлением и отменой удостоверений. Из-за важности PKI для интернета в настоящее время доступно множество СА-властей, включая популярные коммерческие СА типа Verisign и Thawte. Большинство интернет-клиентов, таких как Microsoft Internet Explorer, автоматически сконфигурированы доверять удостоверениям, выпущенным коммерческими властями С А. Вы можете установить свои собственные СА-вла-сти, используя Windows Server 2003. Сертификационная служба, поставляемая с Windows Server 2003, является СА-властью с полной функциональностью, которая может использоваться для выдачи удостоверений людям, работающим в пределах вашей компании, представляющим организации партнера.

Дополнительная информация. Планирование и развертывание инфраструктуры PKI требует значительных усилий. Windows Server 2003 обеспечивает опцию для создания PKI с использованием СА-властей предприятия, интегрированных в Active Directory. Развертывая СА-власти предприятия, можно сконфигурировать политики для автоматизации большинства административных усилий, связанных с выдачей и возобновлением удостоверений. Веб-сайт компании Microsoft и Help And Support Center (Центр справки и поддержки) в Windows Server 2003 содержат детальную информацию, необходимую для установки инфраструктуры PKI.
Одна из главных причин использования сертификатов состоит в том, чтобы позволить пользователям, не имеющим учетной записи в Active Directory, получать доступ к ресурсам в сети Windows Server 2003. Например, вы захотите установить безопасный веб-сайт, чтобы партнерские организации или клиенты могли получить доступ к некоторой конфиденциальной информации, касающейся вашей сети. Однако в Windows Server 2003 разрешение на доступ к сетевым ресурсам можно предоставлять только участникам безопасности. Нет никакой опции, позволяющей назначить разрешения, основываясь исключительно на сертификатах. Вы можете предоставить доступ к ресурсам для пользователей, имеющих удостоверения и не имеющих учетных записей пользователя Active
Directory, путем отображения сертификата на учетную запись пользователя и использованием учетной записи для назначения разрешений.

Windows Server 2003 обеспечивает два различных способа отображения сертификата на учетную запись пользователя.

• Однозначное отображение. В этом случае один сертификат отображается на одну учетную запись пользователя Windows Server 2003. При однозначном отображении вы должны назначить сертификат и создать учетную запись для каждого пользователя. Это может быть хорошим решением, если вы хотите дать доступ удаленным служащим компании к безопасным ресурсам через безопасный веб-сайт. Это не упрощает ваше администрирование, тем не менее, с помощью однозначного отображения имен можно управлять уровнем доступа каждого пользователя.
• Многозначное отображение. В этом случае несколько сертификатов отображаются на одно имя учетной записи Active Directory. Например, если вы создаете партнерские отношения с другой компанией, и служащим компании нужен доступ к безопасному веб-сайту, вы можете создать одну учетную запись пользователя. Затем вы можете с этой учетной записью связать такое количество сертификатов, какое захотите. Например, если та компания имеет свою собственную власть СА, вы можете создать правило, по которому все выданные ею удостоверения будут отображаться на одну учетную запись пользователя в вашем домене. Затем, используя эту запись, вы сможете назначать разрешения на сетевые ресурсы.

Совет. Можно отображать сертификаты на учетные запкси пользователя через инструмент Active Directory Users And Computers или Менеджер информационного сервера интернета (IIS) от Microsoft. В Active Directory Users And Computers используйте опцию Name Mappings (Отображение имен^, которая становится доступной при щелчке правой кнопкой мыши на учетной записи пользователя.

Интеграция со смарт-картами

Смарт-карты обеспечивают другой способ объединения инфраструктуры PKI с аутентификацией по протоколу Kerberos. Когда Kerberos используется без PKI, общий секрет между клиентом и службой KDC используется для шифрования обмена информацией с опознавательной службой при начальном входе в систему. Этот ключ получен из пароля пользователя, тот же самый ключ используется при шифровании и расшифровки информации. Смарт-карты используют модель инфраструктуры PKI, в которой и открытый, и личный ключи используются для шифрования и расшифровки информации, касающейся входа в систему.
Смарт-карта содержит открытый и личный ключи пользователя плюс сертификат Х.509 v3. Все это применяется при использовании пользователем смарт-карты для аутентификации в Active Directory. Процесс входа в систему начинается в тот момент, когда пользователь вставляет смарт-карту в устройство чтения смарт-карт и вводит свой личный идентификационный номер (PIN — personal identification number). Это интерпретируется властями LSA на компьютере как последовательность Ctrl+Alt+Del, и процесс входа в систему начинается.

Номер PIN используется для чтения сертификата пользователя и открытого и личного ключей со смарт-карты. Затем клиент посылает обычный TGT-запрос к службе KDC. Вместо посылки данных предварительной аутентификации (временная метка), зашифрованных с помощью секретного ключа пользователя, полученного из пароля, клиент посылает службе KDC открытый ключ и сертификат. Запрос TGT все еще включает в себя данные предварительной аутентификации, но он подписан с помощью личного ключа пользователя.

Когда сообщение достигает службы KDC, она проверяет сертификат клиента, чтобы убедиться в его правильности и в том, что СА-власти, выдавшие сертификат, являются доверенными властями. Служба KDC проверяет также цифровую подпись данных предварительной аутентификации, чтобы гарантировать подлинность отправителя сообщения и целостность сообщения. Если обе эти проверки дают положительный результат, служба KDC использует основное пользовательское имя (UPN), включенное в сертификат клиента, чтобы искать имя учетной записи в Active Directory. Если учетная запись пользователя правильна, то служба KDC подтверждает подлинность пользователя и посылает в ответ клиенту билет TGT, включающий ключ сеанса. Ключ сеанса зашифрован с помощью открытого ключа клиента, и клиент использует свой личный ключ для расшифровки информации. Затем этот ключ сеанса используется для всех подключений к службе KDC.

Совет. Установка входа в систему вашей сети с использованием смарт-карты требует значительного объема работы. Прежде всего, нужно развернуть СА-власти для выпуска сертификатов. Затем установить станции регистрации смарт-карт, где пользователи смогут получать свои смарт-карты, и где смарт-картам могут быть назначены правильные сертификаты и ключи. После начального развертывания нужно решить административные задачи, связанные с потерянными или забытыми картами. Смарт-карты обеспечивают превосходную дополнительную защиту вашей сети, но эта дополнительная защита связана со значительными административными усилиями.

Способность к взаимодействию с другими системами Kerberos

Поскольку в основе протокола Kerberos лежит открытый стандарт, он обеспечивает превосходные возможности для взаимодействия с другими системами, основанными на протоколе Kerberos. Любой из компонентов, который являются частью реализации протокола Kerberos Windows Server 2003, может быть заменен эквивалентным элементом, не принадлежащим системе Windows. Эти три компонента следующие:

• клиент Kerberos;
• центр распределения ключей Kerberos;
• сетевой ресурс, использующий протокол Kerberos для разрешений.

Имеются четыре возможных сценария взаимодействия.

• Клиенты Windows 2000 или Windows XP Professional могут входить на контроллер домена Windows Server 2003 и иметь доступ к ресурсам, расположенным на Windows Server 2003 или на других службах, в основе которых находится протокол Kerberos.
• Клиенты Windows 2000 или Windows XP Professional могут входить на KDC-центры, не принадлежащие Windows-платформе, и иметь доступ к ресурсам, расположенным на Windows Server 2003 или на других службах, в основе которых находится протокол Kerberos.
• Клиенты Kerberos, не принадлежащие Windows-платформе, могут входить на KDC-центры Windows Server 2003 и иметь доступ к ресурсам, расположенным на Windows Server 2003 или на других службах, в основе которых находится протокол Kerberos.
• Клиенты Kerberos, не принадлежащие Windows-платформе, могут взаимодействовать с реализациями Kerberos, не принадлежащими Windows-платформе, и иметь доступ к ресурсам, расположенных на Windows Server 2003 или на других службах, в основе которых находится протокол Kerberos.

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

Однако реализация Kerberos Windows Server 2003 позволяет легко взаимодействовать с другими реализациями Kerberos. Для этого нужно создать доверительные отношения между областями домена Windows Server 2003 и областью Kerberos, не принадлежащей Windows-платформе. Доверительные отношения сферы могут быть сконфигурированы как транзитивные или нетранзитивные, а так же как односторонние или двухсторонние. Чтобы сконфигурировать доверительные отношения с другой областью, откройте инструмент Active Directory Domains And Trusts (Домены и доверительные отношения Active Directory) и перей-
дите в окно Properties (Свойства) того домена, в котором вы хотите создать доверительные отношения. На вкладке Trusts (Доверительные отношения) щелкните на кнопке New Trust, запустив New Trust Wizard. С помощью мастера вы можете создать доверительные отношения со стороны Windows Server 2003 с другой областью Kerberos. На рисунке 8-8 показано окно Properties доверительного отношения области после его создания.

Рис. 8-8. Конфигурирование доверительного отношения между областями

Дополнительная информация. Microsoft обеспечивает пошаговое руководство для конфигурирования доверительных отношений Kerberos между областями. Это руководство, озаглавленное как «Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability» доступно на веб-сайте Microsoft по адресу http:// www.microsoft.com/technet/prodtechnol/Windows 2000serv/ howto/kerbstep.asp.

Безопасность протокола NTLM

Второй вариант аутентификации на контроллере домена Windows Server 2003 должен использовать NTLM-аутентификацию. Она поддерживается для совместимости с клиентскими компьютерами, на которых выполняются системы Windows NT 4, Windows 95 и Windows 98. Этот протокол используется в следующих ситуациях.

• Когда компьютер, на котором выполняются системы Windows 95, Windows 98 или Windows NT, подтверждает свою подлинность на контроллере домена Windows Server 2003. На компьютерах с системами Windows 95 и Windows 98 должна быть установлена служба Directory Services Client, или эти операционные системы смогут подтверждать подлинность только с использованием протокола LAN Manager.
• Когда компьютер, на котором выполняются системы Windows XP Professional или Windows Server 2003, подтверждает подлинность на Windows NT 4 Server.
• Когда любой клиент обращается к автономному серверу с системой Windows Server 2003.
• Когда клиент, на котором выполняются системы Windows XP Professional или Windows 2000, пробует войти на контроллер домена с Windows Server 2003, но не способен подтвердить подлинность, используя протокол Kerberos. В этом случае NTLM аутентификация может использоваться как альтернативный протокол.

Протокол NTLM значительно менее безопасен, чем Kerberos. С пакетом Windows NT 4 Service Pack 4 компания Microsoft представила новую версию протокола NTLM с именем NTLMv2. Эта новая версия включает дополнительную защиту, такую как создание уникального ключа сеанса каждый раз при установлении нового подключения, а также расширенный процесс обмена ключами для защиты ключей сеанса.