Защита с использованием протокола Kerberos

🕛 20.01.2009, 17:04

До сих пор в этой главе описывались основы защиты Active Directory без обсуждения фактического механизма, который осуществляет защиту. Основной механизм аутентификации в Active Directory - это протокол Kerberos. Протокол Kerberos был впервые разработан инженерами Массачусетского Технологического института (MIT) в конце 80-х годов. Текущая версия Kerberos - это версия 5 (Kerberos v5), которая описана в документе RFC 1510. Реализация Kerberos в Windows Server 2003 полностью совместима с документом RFC-1510 с некоторыми расширениями для аутентификации открытых (public) ключей.

Протокол Kerberos является заданным по умолчанию опознавательным протоколом для Active Directory систем Windows 2000 Windows Server 2003. Всякий раз, когда клиент с системой Windows 2000, или более поздней, подтверждает свою подлинность в Active Directory, он использует протокол Kerberos. Другой протокол, использующийся для подтверждения подлинности в Active Directory, - это NTLM, который поддерживается для обратной совместимости с клиентами, пользующимися более старыми версиями операционных систем. Протокол Kerberos имеет множество преимуществ по сравнению с NTLM.
* Взаимная аутентификация. При использовании протокола NTLM аутентификация происходит только в одном направлении, т.е. сервер подтверждает подлинность клиента. При использовании протокола Kerberos клиент может также подтверждать подлинность сервера, гарантируя, что сервер, который отвечает на запрос клиента, является правильным сервером. * Более эффективный доступ к ресурсам. Когда пользователь обращается к сетевому ресурсу в сети, использующему протокол NTLM (например, Microsoft Windows NT 4), то сервер, на котором расположен ресурс, должен контактировать с контроллером домена для проверки разрешения на доступ данного пользователя. В сети, использующей Kerberos, клиент соединяется с контроллером домена и получает билет на сетевое соединение, чтобы получить доступ к серверу ресурса. Это означает, что сервер ресурса не должен соединяться с контроллером домена. * Улучшенное управление доверительными отношениями. Доверительные отношения NTLM всегда односторонние, не транзитивные, они конфигурируются вручную. Доверительные отношения Kerberos конфигурируются автоматически, поддерживаются между всеми доменами леса и являются транзитивными и двусторонними. Кроме того, доверительные отношения Kerberos могут быть сконфигурированы между лесами и доменами Kerberos Windows Server 2003 и другими реализациями протокола Kerberos. * Делегированная аутентификация. Когда клиент подключается к серверу, используя аутентификацию NTLM, сервер может использовать сертификаты клиента для доступа к ресурсам, расположенным только на локальном сервере. С аутентификацией Kerberos сервер может использовать сертификаты клиента для доступа к ресурсам, расположенным на другом сервере.

Примечание. Windows Server 2003 поддерживает аутентификацию через протокол SSL/TLS (Secure Sockets Layer/Transport Layer Security - Защищенные сокеты/Защита транспортного уровня), аутентификацию Digest и аутентификацию Passport. Так как эти службы используются в среде интернета для аутентификации служб информационного интернет-сервера от Microsoft (IIS - Internet Information Services) версии 6.0, то эти опознавательные опции обсуждаться не будут.

Введение в протокол Kerberos

В системе, основанной на протоколе Kerberos, имеется три компонента. Во-первых, клиент, который должен получить доступ к сетевом ресурсам. Во-вторых, сервер, который управляет сетевыми ресурсами и гарантирует, что только должным образом заверенные и уполномоченные пользователи могут получать доступ к ресурсу. Третий компонент - центр распределения ключей (KDC - Key Distribution Center), который служит центральным местом хранения пользовательской информации и главной службой, подтверждающей подлинность пользователей.

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

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

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

Одной из проблем общего секрета является то, что пользователь и сервер, управляющий сетевым ресурсом, должны иметь какой-либо способ владения общим секретом. Если пользователь пробует получить доступ к ресурсу на определенном сервере, то учетная запись пользователя может быть создана на сервере с паролем, который знает только пользователь. Когда пользователь попытается обратиться к ресурсам на этом сервере, он может представить общий секрет (пароль) и получить доступ к ресурсу. Однако в корпоративной среде могут быть тысячи пользователей и сотни серверов. Управление различными общими секретами всех этих пользователей было бы непрактичным. Протокол Kerberos справляется с этой проблемой, используя центр распределения ключей (KDC - Key Distribution Center). Служба KDC выполняется как служба сервера в сети и управляет общими секретами всех пользователей в сети. KDC имеет одну центральную базу данных для всех учетных записей пользователей сети и хранит общий секрет каждого пользователя (в форме одностороннего кэша пароля пользователя). Когда пользователю требуется получить доступ к сети и сетевым ресурсам, служба KDC подтверждает, что пользователь знает общий секрет, а затем подтверждает подлинность пользователя.

Примечание. В терминологии Kerberos центральным сервером, управляющим учетными записями пользователя, является служба KDC. В реализации Kerberos сервера Windows Server 2003 этот сервер называется контроллером домена. Каждый контроллер домена Active Directory является KDC. В Kerberos граница, определенная пользовательской базой данных, расположенной на одном KDC, называется областью (realm). В терминологии Windows Server 2003 эта граница называется доменом.

Каждая служба KDC состоит из двух отдельных служб: службы аутентификации (AS - Authentication Service) и службы предоставления билетов (TGS - Ticket-Granting Service). Служба AS отвечает за начальный вход клиента в систему и выдает билет TGT (TGT - Ticket-Granting Ticket) клиенту. Служба TGS отвечает за все билеты сеанса, которые используются для доступа к ресурсам в сети Windows Server 2003.

Служба KDC хранит базу данных учетных записей, которая используется для аутентификации протоколом Kerberos. В реализации Kerberos Windows Server 2003 база данных управляется агентом системы каталога (DSA - Directory System Agent), который выполняется в пределах процесса LSA на каждом контроллере домена. Клиенты и приложения никогда не получают прямой доступ к базе данных учетных записей - все запросы идут через агента DSA, используя один из интерфейсов Active Directory. Каждый объект в пределах базы данных учетных записей (фактически, каждый атрибут каждого объекта) защищен с помощью списка ACL. Агент DSA гарантирует, что любые попытки обращения к базе данных учетных записей должным образом санкционированы.

Совет. Когда Active Directory устанавливается на первом контроллере домена в домене, создается специальная учетная запись, которая называется krbtgt. Эта учетная запись не может быть удалена или переименована, ее никогда нельзя разрешать (enable). При создании этой записи назначается пароль, который регулярным образом автоматически изменяется. Этот пароль используется для создания секретного ключа, предназначенного для шифрования и расшифровки билетов TGT, выдаваемых всеми контроллерами домена в домене.

Аутентификация на базе протокола Kerberos

На компьютерах с системой Microsoft Windows 2000 Professional или Windows XP Professional, на серверах с Windows 2000 Server или Windows Server 2003 аутентификация по протоколу Kerberos начинается с того, что служба LSA вызывает провайдера защиты Kerberos. Когда пользователь входит в систему, впечатывая имя пользователя и пароль, компьютер клиента применяет одностороннее хэширование к паролю пользователя для создания секретного ключа, который кэшируется в надежной памяти на компьютере. Одностороннее хэширование означает, что пароль не может быть восстановлен исходя из хэш-значения (hash).

Для осуществления процесса входа клиента в систему клиент и сервер выполняют следующие действия.
1. Провайдер Kerberos SSP на рабочей станции посылает опознавательное сообщение службе KDC (см. рис. 8-1). Это сообщение включает: - имя пользователя; * область (realm) пользователя (имя домена); * запрос на TGT-билет; * предварительные опознавательные данные, которые включают метку времени.

Предварительные опознавательные данные зашифрованы с помощью секретного ключа, полученного из пользовательского пароля.

Рис. 8-1. Получение билета Kerberos TGT
2. Когда сообщение достигдет сервера, сервер исследует имя пользователя, а затем проверяет базу данных каталога в поисках своей копии секретного ключа, связанного с данной учетной записью пользователя. Сервер расшифровывает зашифрованные в сообщении данные с помощью секретного ключа и проверяет временную метку. Если расшифровка прошла успешно, и временная метка отличается от текущего времени на сервере в пределах 5 минут, сервер готов подтвердить подлинность пользователя. Если расшифровка окажется неудачной, это означает, что пользователь ввел неправильный пароль, и аутентификация потерпит неудачу. Если временная метка отличается более чем на 5 минут от текущего времени на сервере, то аутентификация также потерпит неудачу. Причина такой маленькой разницы во времени состоит в том, что она должна предотвратить возможную попытку перехвата опознавательного пакета с последующим повторением его в более позднее время. Заданная по умолчанию максимальная допустимая разница во времени, составляющая 5 минут, может быть сконфигурирована в политике защиты домена. 3. После аутентификации пользователя сервер посылает клиенту сообщение, которое включает ключ сеанса и TGT (см. рис. 8-1). Ключ сеанса - это ключ шифрования, который клиент будет использовать для взаимодействия с KDC вместо секретного ключа клиента. TGT - это билет сеанса, который предоставляет пользователю доступ к контроллеру домена. В течение срока службы TGT клиент предъявляет TGT контроллеру домена всякий раз, когда ему требуется обратиться к сетевым ресурсам. Полное сообщение от сервера зашифровано с помощью секретного ключа пользователя. Кроме того, билет TGT зашифрован с помощью долгосрочного секретного ключа сервера. 4. Когда пакет прибывает на компьютер клиента, секретный ключ пользователя используется для расшифровки пакета. Если расшифровка прошла успешно и временная метка допустима, то компьютер пользователя предполагает, что центр KDC надежно идентифицировал пользователя, потому что ему знаком его секретный ключ. Ключ сеанса затем кэшируется на локальном компьютере, пока не кончится срок его действия или пока пользователь не сделает выход из системы рабочей станции. Этот ключ сеанса будет использоваться для шифрования всех будущих подключений к центру KDC, т.е. клиент больше не должен помнить секретный ключ, и он удаляется из кэша рабочей станции. Билет TGT сохраняется в зашифрованной форме в кэше рабочей станции.

Примечание. Протокол Kerberos включает в себя Authentication Service (AS) Exchange (Коммутатор аутентификационной службы), который является подпротоколом, предназначенным для выполнения начальной аутентификации пользователя. Только что описанный процесс использует подпротокол AS Exchange. Начальное сообщение, посланное клиентом к центру KDC, называется сообщением KRB_AS_REQ. Ответ сервера клиенту называется сообщением KRB_AS_REP. * 5. Пользователь был опознан, но он все еще не имеет никакого доступа к сетевым ресурсам. TGT - это билет сеанса, который предоставляет доступ к центру KDC, но чтобы получить доступ к каким-либо другим сетевым ресурсам, пользователь должен получить другой билет сеанса от KDC центра (см. рис. 8-2.) Рабочая станция клиента посылает запрос на билет сеанса к центру KDC. Запрос включает имя пользователя, билет TGT, предоставленный в процессе аутентификации, имя сетевой службы, к которой пользователь хочет получить доступ, и временную метку, которая зашифрована с использованием ключа сеанса, полученного в процессе AS Exchange.

Рис. 8-2. Получение билета сеанса Kerberos для сетевого ресурса
6. Служба KDC расшифровывает билет TGT, используя свой долгосрочный ключ. Затем она извлекает ключ сеанса из билета TGT и расшифровывает временную метку, чтобы убедиться, что клиент использует правильный ключ сеанса, и гарантировать, что временная метка допустима. Если ключ сеанса и временная метка приемлемы, то KDC готовит билет сеанса для доступа к сетевой службе. 7. Билет сеанса включает две копии ключа сеанса, который клиент будет использовать для соединения с требуемым ресурсом. Первая копия ключа сеанса зашифрована, используя ключ сеанса клиента, полученный в процессе начального входа в систему. Вторая копия ключа сеанса предназначена для сетевой службы и включает информацию о доступе пользователя. Эта часть билета сеанса зашифрована, используя секретный ключ сетевой службы, который неизвестен рабочей станции клиента, но известен и службе KDC и сетевой службе, потому что сервер, на котором расположен ресурс, является членом сферы KDC. 8. Рабочая станция клиента кэширует обе части билета сеанса в памяти.

Примечание. Процесс, описанный в шагах с 5-го по 8-ой, использует подпротокол Ticket-Granting Service Exchange (Коммутатор службы предоставления билетов ). Запрос на билет сеанса, посланный клиентом, называется сообщением KRB_TGS_REQ; ответ сервера - сообщением KRB_TGS_REP.
9. Теперь клиент предъявляет билет сеанса сетевой службе для получения доступа (см. рис. 8-3.)

Рис. 8-3. Доступ к сетевой службе
10. Сетевая служба расшифровывает ключ сеанса, зашифрованный в билете сеанса, используя долгосрочный ключ, которым она владеет совместно с центром KDC. Если эта расшифровка прошла успешно, то сетевая служба знает, что билет выдан доверенной службой KDC. Затем сетевая служба расшифровывает лексему доступа пользователя, используя ключ сеанса, и проверяет пользовательский уровень доступа. Запрос клиента включает также временную метку, которая зашифрована с помощью ключа сеанса и проверена сервером.

Примечание. Процесс, описанный в шагах 9 и 10, использует под-протокол Client/Server (CS) Exchange. Запрос клиента называется сообщением KRB_AP_REQ.

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

Дополнительная информация. Вы можете посмотреть содержимое кэша клиента, используя инструменты, доступные для загрузки на веб-сайте Microsoft. Инструмент KList.exe предоставляет интерфейс командной строки для просмотра и удаления билетов Kerberos. Инструмент Kerberos Tray (Kerbtray.exe) обеспечивает для просмотра билетов графический интерфейс пользователя (GUI). На рисунке 8-4 показан пример информации, предоставленной инструментом Kerberos Tray. Инструмент Kerberos Tray доступен по адресу http://www.microsoft.com/ windows2000/techinjo/reskit/tools/existing/kerbtray-o.asp , а инструмент KList доступен по адресу http://www.microsoft.co7n/windows2000/techinfo/reskit/tools/ existing /klist-o. asp.

Процесс получения доступа к сетевому ресурсу показывает, что центр KDC вовлечен только в процесс начального входа в систему клиента, когда клиент первый раз пробует обращаться к ресурсу, расположенному на определенном сервере. Когда пользователь впервые входит в систему, ему выдается билет TGT, который предоставляет клиенту доступ к центру KDC в течение срока службы билета. Когда клиент пробует соединиться с сетевым ресурсом, он снова входит в контакт с KDC и получает билет сеанса для доступа к этому ресурсу. Билет сеанса включает лексему доступа пользователя. Когда эта лексема предъявляется серверу, на котором расположен ресурс, сервер определяет уровень доступа к ресурсу, который должен иметь данный пользователь.

Аутентификация, пересекающая границы домена

Тот же самый опознавательный процесс применяется и в том случае, когда при подтверждении подлинности пользователя пересекаются границы домена. Например, компания может иметь лес с тремя доменами, как показано на рисунке 8-5.

Рис. 8-5. Аутентификация, пересекающая границы домена

Если пользователь, имеющий учетную записью в домене Fabrikam.com, перейдет в домен NAmerica.Contoso.com и попытается войти в сеть, рабочая станция клиента сможет соединиться с контроллером домена в домене Fabrikam.com. В этом случае компьютер клиента посылает начальный запрос входа в систему на контроллер домена NAmerica.Contoso.com. Контроллер домена определяет, что учетная запись пользователя расположена в домене Fabrikam.com, так что нужно переправить запросы рабочей станции клиента к этому домену. Если все домены были сконфигурированы с прямыми доверительными отношениями (shortcut trusts), то контроллер домена может напрямую направить компьютер клиента к контроллеру домена в домене Fabrikam.com. Однако если прямых доверительных отношений не было создано, то нет и прямого доверительного отношения между доменами NAmerica.Contoso.com и Fabrikam.com. В этом случае контроллер домена NAmerica направит компьютер клиента к контроллеру домена в домене Contoso.com. Направление включает ключ сеанса, предоставляющий доступ к контроллеру домена в домене Contoso.com. Ключ сеанса создается, когда домен NAmerica добавляется к лесу Contoso.com и создаются начальные доверительные отношения между этими двумя доменами. Ключ сеанса гарантирует, что запрос на вход в систему исходит от доверенного домена. Затем компьютер клиента посылает опознавательный запрос к домену Contoso.com. Теперь клиент направляется к контроллеру домена в домене Fabrikam.com. Снова это направление включает ключ сеанса, необходимый для доступа к контроллеру домена. Далее компьютер клиента посылает запрос TGT на свой домашний контроллер домена в Fabrikam.com.

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

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

Делегирование аутентификации

Одна из причин сложности доступа к сетевым службам состоит в том, что сетевая служба может быть распределена между несколькими серверами. Например, клиент для получения информации соединяется с крайним сервером внешнего интерфейса цепочки серверов, который должен подключиться к серверу базы данных, являющимся другим концом этой цепочки. Чтобы пользователь получил доступ только к санкционированной информации, для обращения к крайнему серверу базы данных должны использоваться «верительные грамоты» пользователя (вместо «верительных грамот» сервера внешнего интерфейса). В системе Windows 2000 протокол Kerberos обеспечивает это двумя способами: путем использования прокси-билетов (proxy tickets) и ретранслированных билетов (forwarded tickets). Если прокси-билеты разрешены, то клиент пошлет запрос на билет сеанса к центру KDC, требуя доступ к крайнему серверу. Служба KDC предоставит билет сеанса и установит на билете флажок PROXIABLE. Затем клиент представит билет сеанса серверу внешнего интерфейса, который использует его для доступа к информации, расположенной на крайнем сервере. Главная проблема с про-кси-билетами состоит в том, что клиент должен знать отличительные характеристики крайнего сервера. Другой вариант состоит в использовании ретранслированных билетов. Если эти билеты разрешены, то кли
ент посылает запрос AS Exchange к центру KDC, требуя билет TGT, позволяющий серверу внешнего интерфейса обратиться к крайним серверам. Служба KDC создает билет TGT и посылает его клиенту для пересылки серверу внешнего интерфейса, который использует билет TGT для получения билета сеанса, позволяющего обратиться к крайнему серверу от имени клиента.

Имеется два существенных недостатка, связанных с реализацией делегирования аутентификации в системе Windows 2000. Первый недостаток состоит в том, что делегирование аутентификации может использоваться только в том случае, если клиент аутентифицирован через протокол Kerberos. Клиенты с системами Windows NT, Microsoft Windows 95 и Windows 98 не могут использовать делегирование аутентификации. В Windows Server 2003 клиент может использовать любой опознавательный протокол. Второй недостаток системы Windows 2000 касается защиты делегирования. В Windows 2000 после получения сервером внешнего интерфейса ретранслированного билета от центра KDC он может использовать его для доступа к любой сетевой службе от имени клиента. Windows Server 2003 имеет опцию, ограничивающую делегирование, т.е. учетную запись можно сконфигурировать так, что это делегирование будет применяться только для определенных сетевых служб (основываясь на основных именах служб). Ограниченное делегирование доступно в случае, если функциональный уровень домена установлен на функциональный уровень Windows Server 2003.

Для успешного делегирования аутентификации нужна гарантия, что и учетная запись пользователя, и учетная запись компьютера (или службы) сконфигурированы так, чтобы поддерживать делегирование аутентификации. Для этого обратитесь к окну Properties (Свойства) пользователя через инструмент Active Directory Users And Computers (Пользователи и компьютеры Active Directory), выберите вкладку Account (Учетная запись), а затем просмотрите список Account Options (Опции учетной записи). Удостоверьтесь, что oпция Account Is Sensitive And Cannot Be Delegated (Учетная запись точна и не может быть делегирована) не выбрана. (По умолчанию опция не выбрана.) Чтобы сконфигурировать учетную запись службы для делегирования, нужно определить, является ли учетная запись, используемая службой для входа в систему, нормальной учетной записью пользователя, или она является учетной записью LocalSystem. Если служба выполняется под нормальной учетной записью пользователя, обратитесь к вкладке Account пользователя и удостоверьтесь, что опция Account Is Sensitive And Cannot Be Delegated не выбрана. (По умолчанию она не выбрана.) Если служба выполняется под учетной записью LocalSystem, то делегирование было сконфигурировано в окне Properties компьютерной учетной записи (см. рис. 8-6). Чтобы реализовать уровень аутентификации Windows 2000, выберите опцию Trust This Computer For Delegation To Any Service (Kerberos Only) (Доверять этому компьютеру при делегиро
вании к любой службе (Только протокол Kerberos)). Чтобы реализовать усовершенствованный уровень аутентификации Windows Server 2003, выберите опцию Trust This Computer For Delegation To Specified Services Only (Доверять этому компьютеру только при делегировании к указанной службе). Затем укажите, должен ли клиент подтверждать подлинность только с использованием протокола Kerberos, или он может использовать любой другой протокол, а затем выбрать службы (основываясь на основных именах служб, зарегистрированных в Active Directory), которым компьютер может представлять делегированные «верительные грамоты».