Windows .NET Server и Kerberos

Начиная с Windows 2000 в операционных системах Microsoft применяется протокол Kerberos. Он представляет собой открытый протокол аутентификации, определенный в RFC 1510, выпущенном Internet Engineering Task Force (IETF). В Kerberos реализовано много полезных функций защиты, в том числе взаимная аутентификация и регистрация с помощью смарт-карт. Kerberos функционирует на многих платформах, так что его можно использовать для процедуры единой регистрации — single sign-on (SSO). Данный протокол поддерживает делегирование или переадресацию аутентификации. Благодаря новым встроенным функциям делегирования Windows .NET Server 2003, Kerberos станет еще более эффективным инструментом идентификации пользователей в среде Windows.

Делегирование

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

Типичный пример использования делегирования — возможность распечатать файл, расположенный на другом сервере, направив запрос на принт-сервер. Без делегирования принт-сервер вынужден предъявлять свои идентификационные данные для аутентификации на файл-сервере и, следовательно, может получить отказ в доступе к файлу. Благодаря делегированию, принт-сервер может обратиться к файлу, предъявив учетные данные пользователя. В современном мире, ориентированном на Internet, таких примеров гораздо больше. Делегирование может с успехом применяться в любом многоуровневом приложении на базе Web — для передачи пользовательских запросов из Web-узла в базу данных на внутреннем сервере сети или проверки почтового ящика через Web-интерфейс, такой, как Microsoft Outlook Web Access (OWA).

В будущем Web-службы станут более распространенными, и потребность в делегировании аутентификации будет возрастать. Для Web-служб необходимы распределенные архитектуры, обеспечивающие доступ к данным и другим ресурсам широкому кругу пользователей, которые обращаются к Web-службам через открытые протоколы Internet, такие, как HTTP и SMTP. Размещение данных на Web-серверах — не лучшее решение для подобных сред. Для Web-служб требуются приложения с многоуровневой структурой и возможностью многократно использовать идентификационные данные посетителя на всех уровнях приложения.

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

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

Недостатки механизма делегирования Windows 2000

И все же механизм делегирования Windows 2000 используется редко. Отчасти это связано с тем, что лишь немногие администраторы хорошо разбираются в нем. Другая причина — нехватка ряда важных параметров для настройки системы безопасности.

Если компьютеру Windows 2000 доверено делегирование, он может связаться от лица пользователя с любой службой на любом другом компьютере домена Windows 2000. Другими словами, если администратор Windows 2000 доверяет компьютеру, то делегирование может быть только полным; степени делегирования настроить нельзя. Например, чтобы извлечь персональную информацию пользователя из сервера базы данных Microsoft SQL Server, учетная запись computer сервера Web-приложений Windows 2000 должна быть доверенной для делегирования. Однако возможности сервера Web-приложений Windows 2000 не ограничиваются лишь извлечением данных из SQL Server от лица пользователя; он может установить контакты с другими серверами, такими, как файл-серверы и серверы приложений, и получать данные или проводить транзакции без ведома пользователя. Положение еще более осложнится, если сервер Web-приложений станет объектом злоупотреблений программиста внутри предприятия и будет захвачен взломщиком.

Еще одно препятствие заключается в том, что в Web-сценарии Windows 2000 делегирование Kerberos допускается только в том случае, если пользователь аутентифицируется на Web-сервере с помощью процедур Kerberos или типа Basic. Если для аутентификации пользователей на Web-сервере применяется более надежный протокол Digest, то делегирование невозможно. В протоколе аутентификации Digest (совместимом с Microsoft Internet Explorer 5.0 и Microsoft Internet Information Services (IIS) 5.0 и более поздними версиями) используется метод запроса и подтверждения, который (в отличие от аутентификации Basic) передает имя и пароль пользователя по каналу HTTP в зашифрованном виде. Необходимо также помнить, что применять Kerberos между браузером и Web-сервером можно только в том случае, если браузер поддерживает Kerberos и может обращаться к Kerberos KDC. Последнее требование в Internet-сценариях выполнить нелегко: немногие компании соглашаются открыть свои KDC для пользователей из Internet. Кроме того, единственный совместимый с Kerberos браузер — IE версий 5.0 и выше.

Для устранения этой проблемы в Windows .NET Server реализованы два новых встроенных расширения протокола Kerberos, именуемых расширениями Service-for-User (S4U) — Service-for-User-to-Proxy (S4U2Proxy) и Service-for-User-to-Self (S4U2Self). В скором времени компания Microsoft планирует представить спецификации обоих новых расширений на рассмотрение комитета IETF. Новые расширения Kerberos доступны лишь в доменах Windows .NET Server уровня функционирования Functionality Level 2 (стандартный функциональный уровень Windows .NET Server) — в сущности, это означает, что все контроллеры домена (DC) работают на Windows .NET Server.

Расширение S4U2Proxy

Механизм делегирования Windows 2000 позволяет клиенту Kerberos передать службе билет ticket-granting ticket (TGT) пользователя. Kerberos TGT — мощное средство обеспечения безопасности, цифровое свидетельство, подтверждающее, что Kerberos KDC проверил личность пользователя и разрешает пользователю запросить билеты для службы. С помощью TGT служба может получить билет для самой себя и других служб от имени пользователя. В Windows 2000 обладатель TGT имеет еще больше возможностей, так как Microsoft использует TGT для передачи информации о пользователе, необходимой для управления доступом (они указаны в поле Privilege Attribute Certificate (PAC) билета и содержат сведения о членстве пользователя в универсальной и глобальной группах).

Расширение S4U2Proxy позволяет службе повторно использовать служебный билет пользователя, чтобы запросить новый билет из KDC. Другими словами, отпадает необходимость передавать службе TGT пользователя, как это было в Windows 2000. Служба может передать билет пользователя в KDC, и этого достаточно, чтобы идентифицировать пользователя в KDC.

В том виде, в каком расширение S4U2Proxy описано до сих пор, оно имеет тот же недостаток, что и Windows 2000: служба-посредник может обратиться к любой другой службе от имени аутентифицированного пользователя. Чтобы устранить этот пробел, был реализован механизм уточненного, или выборочного, делегирования. Администратор Windows .NET Server может указать, каким службам или службе на компьютере разрешается доступ от имени пользователя.

Настройка выборочного делегирования

Открыв окно свойств учетной записи компьютера или службы в Windows .NET Server (из оснастки Active Directory Users and Computers консоли управления Microsoft Management Console, MMC), можно увидеть новую вкладку Delegation. Этой вкладки нет в диалоговом окне Properties обычной учетной записи пользователя. Она появляется лишь в том случае, если с учетной записью связано основное имя службы Service Principal Name (SPN).

Как показано на Экране 1, существует три способа настройки делегирования с помощью вкладки Delegation.

Экран 1. Настройка делегирования в Win .NET Server.

• Выбрать пункт Do not trust this computer for delegation, чтобы запретить делегирование.
• Выбрать пункт Trust this computer for delegation to any service (Kerberos only), чтобы разрешить полное делегирование, подобно тому, как это сделано в Windows 2000. Этот режим устанавливается по умолчанию.
• Выбрать пункт Trust this computer for delegation to specified services only для уточненного делегирования. Это новый режим Windows .NET Server.

Если выбран третий пункт (выборочное делегирование), то можно указать службы, для которых разрешено делегирование. Следует щелкнуть кнопку Add, чтобы открыть диалоговое окно Add Services. Список служб поначалу пуст. Нужно щелкнуть на вкладке Users or Computers, чтобы открыть диалоговое окно Object Picker (выбор объектов) Active Directory (AD), из которого можно выбрать соответствующие SPN. Разрешается выбирать только SPN компьютеров, входящих в один домен с компьютером администратора. Например, на Экране 1 видно, что выбраны SPN нескольких служб Lightweight Directory Access Protocol (LDAP), работающих на контроллерах домена Qnet.

Windows .NET Server хранит имена SPN, для которых разрешено делегирование, в новом атрибуте объекта «учетная запись AD», названном msDS-AllowedToDelegateTo. Выяснить, каково содержимое этого многозначного атрибута, можно с помощью ADSI Edit комплекта Win.NET Server Support Tools (который представляет собой оснастку MMC). На Экране 2 показаны SPN служб LDAP, которые я связал доверительными отношениями делегирования с компьютером Qnet-dc9. Получив запрос делегирования для билета конкретной службы, службы аутентификации Kerberos сравнивают имена SPN в запросе билета Kerberos с именами SPN в атрибуте msDS-AllowedToDelegateTo учетной записи компьютера или службы. Если они не совпадают, то службы аутентификации Kerberos отвергают запрос делегирования. SPN учетной записи хранятся в атрибуте msDS-AllowedToDelegateTo.

Расширение S4U2Self

При делегировании Kerberos в среде Windows 2000 на базе Web возникает проблема: для аутентификации на Web-сервере клиент должен применять метод Kerberos или Basic. Поставляемый вместе с Windows NET Server Web-сервер IIS 6.0 обеспечивает другие режимы аутентификации, в том числе Microsoft .NET Passport, Digest и Certificate. Благодаря комбинации расширений S4U2Proxy и S4U2Self, эти режимы аутентификации можно использовать с делегированием Kerberos.

Расширение S4U2Self располагает службой, известной как смена протокола (protocol transition), которая позволяет комбинировать любой из перечисленных выше протоколов аутентификации IIS на внешнем конце соединения с IIS с протоколом аутентификации Kerberos на внутреннем конце соединения. Другими словами, при любом способе аутентификации пользователя в IIS, его данные могут применяться IIS для обращения к внутреннему серверу через Kerberos. В основе этого новшества лежит возможность приложения или службы запросить в Kerberos KDC новый служебный билет от имени учетной записи пользователя, определенной в домене или в лесу, независимо от протокола аутентификации, применяемого на внешнем конце. Описанная мной процедура напоминает регистрацию без пароля, но следует помнить, что, прежде чем приложение или служба смогут запросить в KDC служебный билет от лица пользователя, приложение или служба должны аутентифицировать пользователя. Кроме того, приложение или служба должны располагать действительным Kerberos TGT.

Настройка смены протокола

Настроить смену протокола сравнительно легко. Следует воспользоваться параметрами Use Kerberos only и Use any authentication protocol на Экране 1, чтобы отключить или активизировать смену протокола, соответственно.

Для корректной смены протокола учетная запись службы или приложения, запрашивающего новый билет от лица пользователя, должна отвечать двум условиям. Во-первых, служебная запись должна иметь полномочие Act as part of the operating system. В противном случае служба получит от KDC только идентификационный маркер, но не маркер имперсонализации.

Во-вторых, чтобы внести данные о контроле доступа в новый билет пользователя, учетной записи службы необходимо иметь разрешение на перечисление групп, членом которых является пользователь. Чтобы дать учетной записи такое разрешение, следует внести учетную запись в ACL атрибута объекта «пользователь» Token

GroupsGlobalAndUniversal и добавить учетную запись в группу Pre-Windows 2000 Compatible Access.

Пример сценария

Новые службы Kerberos можно испытать в тестовой среде. На Экране 3 показан тестовый сценарий, который состоит из Web-браузера, работающего на клиенте, простого приложения COM+, выполняемого на сервере IIS 6.0, и базы данных SQL Server на внутреннем сервере. Страница Active Server Pages (ASP) вызвала запрос к базе данных, определенный в приложении COM+. Клиент, IIS-сервер и система SQL Server были членами одного домена.

Экран 3. Пример сценария.

Цель тестового сценария аутентификации — дать пользователю возможность зарегистрироваться на IIS с помощью любого допустимого протокола и позволить IIS задействовать Kerberos и делегирование Kerberos для аутентификации в приложении COM+ и базе данных SQL Server. Такая система работоспособна лишь при наличии в IIS новых расширений S4U2Proxy и S4U2Self (т. е. если Web-сервер работает на Windows .NET Server). В Таблице 1 приведены сведения о необходимом программном обеспечении и конфигурациях.

Таблица 1. Настройка примера сценария.

Компонент	Требования к программному обеспечению и параметры настройки
Браузер	Должен быть совместим с методами аутентификации Basic, Digest, Certificate (Secure Sockets Layer-SSL), .NET Passport или Kerberos. Учетная запись пользователя должна быть в составе домена.
Web-сервер	Web-сервер должен работать на Windows .NET Server (третья бета-версия или выше), в том числе IIS 6.0. Назначая параметры делегирования для учетной записи компьютера, следует выбрать режим Trust this computer for delegation to specified services only и режим Use any authentication protocol. Нужно также указать имена SPN службы SQL Server сервера БД. Web-приложение должно обеспечивать аутентификацию Basic, Digest, Certificate (SSL), .NET Passport и Kerberos. Пользователь должен обладать соответствующими правами доступа к Web-узлу. Web-сервер должен быть членом домена.
Приложение COM+	Следует установить уровень Delegate имперсонализации приложения COM+. Пользователь должен иметь соответствующие права доступа к COM+ DLL.
Сервер базы данных	Сервер баз данных должен работать с Windows .NET Server или Windows 2000 и SQL Server 2000. SQL Server должен быть настроен на интегрированную аутентификацию Windows. Служба SQL Server должна иметь зарегистрированный SPN (т. е. SPN, на который указывают параметры делегирования учетной записи computer Web-сервера). Пользователь должен иметь соответствующие права доступа к базе данных. Сервер базы данных должен быть членом домена.

Расширения Kerberos в Windows .NET Server подчеркивают важную роль, которая принадлежит Kerberos в структуре будущих продуктов Microsoft. Благодаря расширениям, потребители Web-служб могут использовать любой протокол для аутентификации в Web-службе на базе Microsoft. На внутреннем конце расширения позволяют Web-службам максимально эффективно применять Kerberos и функции SSO и делегирования.

Жан де Клерк — консультант корпорации Compaq, специалист по проблемам безопасности продуктов семейства Microsoft BackOffice. С ним можно связаться по адресу: jan.declercq@compaq.com.