Аутентификация по протоколу Kerberos: делегирование и диагностика

.

Вкратце делегирование сводится к следующему. Пользователь обращается к тому или иному приложению, а затем это приложение обращается к другой службе от имени (в контексте) данного пользователя. Характерный пример — это веб-сайт, обращающийся к базе данных SQL Server. Можно представить себе ситуацию, когда любое обращение к базе данных выполняется всякий раз в контексте учетной записи той или иной службы. На самом же деле все происходит иначе: каждый запрос к базе данных осуществляется в контексте пользователя, обратившегося к веб-узлу. Дополнительную информацию о работе с протоколом Kerberos в каталоге AD можно найти в статье «Kerberos в Active Directory», опубликованной в Windows IT Pro/RE № 11 за 2010 год. В рамках данной статьи мы будем исходить из того, что, если не указано иное, наш лес AD функционирует под управлением системы Windows Server 2003 или более поздней, а серверы приложений — под управлением системы Server 2003 или более новых версий. В системе Server 2003 в средства Kerberos, реализованные в AD, внесено множество усовершенствований.

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

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

Как уже отмечалось, самый типичный пример делегирования сводится к следующему. Пользователь обращается к приложению (обычно речь идет о веб-приложении), которое затем обращается к некоему ресурсу, например к базе данных SQL Server. Чтобы получить соединение с базой данных, приложение должно представить учетные данные. Часто соединение устанавливается с использованием выделенной учетной записи службы с правом чтения и записи всех необходимых данных внутри базы данных, как показано на рисунке 1. После этого приложение становится ответственным за контроль над элементами управления доступом непосредственно к данным, поскольку учетная запись службы имеет доступ ко всем объектам.

Рисунок 1. Обращение к данным с использованием учетной записи службы

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

Чтобы обратиться к системе SQL Server на рисунке 2, веб-сервер должен получить билет службы для службы SQL Server. Этот билет службы должен быть сгенерирован для пользователя, обращающегося к веб-приложению (скажем, для User 1), но не для учетной записи службы веб-сервера. Таким образом, веб-сервер представляет билет службы пользователя User 1, который использовался для доступа к сайту (скажем, www.contoso.com), центру распространения ключей Key Distribution Center (KDC) и запрашивает билет службы системы SQL Server. KDC оценивает настройки делегирования в AD для данного веб-сервера; если имеется разрешение на делегирование полномочий системе SQL Server, KDC принимает представленный билет службы в качестве доказательства того, что полномочия данного пользователя проверены, и возвращает новый билет службы для обращения данного пользователя к системе SQL Server. Этот обмен информацией представлен на рисунке 3.

Рисунок 2. Обращение к данным с использованием делегирования Kerberos

Рисунок 3. Обмен сообщениями при делегировании Kerberos

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

В соответствии с принимаемой по умолчанию настройкой вкладки Delegation, которая доступна в оснастке Active Directory Users and Computers консоли Microsoft Management Console (MMC), система не доверяет пользователю в вопросах, касающихся делегирования. Это означает, что службы, выполняемые в контексте соответствующей учетной записи, не могут делегировать проверку подлинности. В системе Windows 2000 Server имеется настройка Trust this user for delegation to any service (Kerberos only), которую можно увидеть на экране 1. Если эта функция включена, служба может от имени пользователя запросить билет службы для доступа к любой службе сети. Пользоваться рассматриваемой функцией небезопасно, поэтому старайтесь по возможности не применять ее.

Экран 1. Активизация функции ограниченного делегирования

Предпочтительная настройка, представленная на экране 1, предусматривает использование ограниченного делегирования с помощью настройки Trust this user for delegation to specific services only. Эта настройка предписывает учетной записи службы (или компьютера) запрашивать делегирование проверки подлинности только службами, указанными в списке. В рассматриваемом нами случае билеты службы могут запрашиваться только от имени других пользователей для службы SQL Server на Web-сайте sql.contoso.com. Нажав кнопку Add, вы должны отыскать пользователя (то есть учетную запись службы) или компьютер, являющийся хостом службы, для доступа к которой хотите санкционировать делегирование. В данном случае я выбрал учетную запись службы SQL Server. Как показано на экране 2, вы увидите список имен участников служб Service Principal Name (SPN), определенный выделенному пользователю или компьютеру, где вы можете выбрать службы, для доступа к которым будет выполняться аутентификация.

Экран 2. Выбор служб для осуществления делегирования

Смена протокола

Смена протокола — добавленная функция системы AD Kerberos, которую корпорация Microsoft реализовала в версии Windows Server 2003. Пока что при рассмотрении нашего примера в ситуациях, когда возникала необходимость обращения приложения c www.contoso.com к SQL Server в контексте текущего пользователя, веб-сервер предъявлял веб-приложению билет службы для данного пользователя, обеспечивающий получение билета службы системы SQL Server, как показано на рисунке 3. Такой сценарий возможен лишь в том случае, если пользователь удостоверяет свою подлинность сайту по протоколу Kerberos. Если же пользователь выполняет процедуру аутентификации в ходе регистрации на основе форм с применением другого протокола, скажем NTLM, или, может быть, иного механизма, такого как маркер RSA SecurID, веб-приложение не может получить билет службы от имени пользователя, ибо протокол Kerberos в подобной ситуации не используется.

Чтобы задействовать этот сценарий, пользователь может изменить настройки учетной записи службы или учетной записи компьютера для выполнения смены протокола; при этом учетная запись службы или компьютера сможет запросить билет службы для той или иной службы, не получая билет службы от пользователя. Вместо того чтобы представить веб-сайту билет службы для данного пользователя, учетная запись службы представляет собственный билет на получение билета Ticket-Granting Ticket (TGT) и запрашивает билет службы для себя от имени пользователя. На рисунке 4 показан последовательный ряд запросов и ответов Kerberos в момент выполнения смены протокола.

Рисунок 4. Обмен сообщениями при смене протокола

Важно отметить, что вследствие уязвимости смены протокола данная служба доступна лишь в сочетании с ограниченным делегированием Kerberos. Чтобы настроить смену протокола, необходимо в процессе включения функции ограниченного делегирования вместо настройки Use Kerberos only выбрать настройку Use any authentication protocol. Уязвимость данной конфигурации связана с тем, что пользователь предоставляет приложению возможность отрапортовать центру распространения ключей об успешной проверке полномочий пользователя вне зависимости от того, была ли такая проверка выполнена на самом деле. Для ограничения связанного с этим риска необходимо настроить службы, которым приложение может сообщить об успешной проверке подлинности, в виде билета службы.

Чтобы гарантировать успешное выполнение обмена, представленного на рисунке 4, необходимо наряду с указанием настроек учетной записи службы выполнить ряд дополнительных предварительных условий. Во первых, учетная запись службы должна иметь возможность получать данные о членстве в группах пользователя, для которого она пытается получить билет службы. Эта возможность предоставляется через членство в группе AD Windows Authorization Access. Данной группе делегируется доступ с правом чтения к атрибуту AD tokenGroupsGlobalAndUniversal.

Далее для фактического выполнения процедуры делегированной аутентификации учетной записи службы требуются привилегии безопасности Act as Part of the Operating System (SeTcbPrivilege) и Impersonate a Client After Authentication (SeImpersonatePrivilege). Особой уязвимостью отличается привилегия Act as Part of the Operating System; по умолчанию она предоставляется только учетной записи SYSTEM. Если это право будет предоставлено учетной записи службы, выполняющей веб-приложение, и если это приложение будет скомпрометировано, злоумышленник получит полный доступ к серверу. Обычно в приложениях, которые активно используют смену протокола, например в средствах обеспечения процедуры однократной регистрации (SSO), предусмотрена специальная служба, которая выполняется с использованием учетной записи SYSTEM и осуществляет необходимые вызовы по протоколу Kerberos от имени веб-приложения.

Диагностика Kerberos

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

Для мониторинга функционирования Kerberos, а также для диагностики часто используются две утилиты — Klist и Kerbtray. Klist — утилита командной строки, встроенная в Windows. Этот инструмент позволяет видеть все билеты, кэшированные в данный момент для сеанса, а также просматривать билет на получение билета TGT. Чтобы просмотреть кэшированные билеты, достаточно запустить программу klist; для просмотра TGT нужно запустить klist tgt. При необходимости очистки кэшированных билетов (а также TGT) выполните команду klist purge. Очистка билетов дает возможность, не выходя из системы, получить новый TGT с обновленными данными по членству в группах.

Утилита Kerbtray входит в набор ресурсов Microsoft Windows Server 2003 Resource Kit, а также в набор Microsoft Windows 2000 Server Resource Kit. Kerbtray представляет те же данные, что и Klist; однако Kerbtray выполняется в системной панели задач и отображает данные в графическом, а не в текстовом представлении.

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

Дубликаты имен SPN часто появляются в ситуациях, когда системы объединяются в одном домене, а затем присоединяются к другому домену леса, оставляя в старом домене «висячую» учетную запись компьютера. Дубликаты могут появляться и в том случае, когда имя SPN вручную вводится в несколько учетных записей пользователей или компьютеров. Когда центр распространения ключей получает запрос на билет службы и находит несколько объектов, содержащих заданное имя SPN, в системный журнал контроллера домена записывается событие, подобное тому, которое представлено на экране 3.

Экран 3. Событие Duplicate SPN

Существует целый ряд различных способов поиска и удаления повторяющихся в лесу имен SPN. В статье Microsoft «Event ID 11 in the System log of domain controllers» (support.microsoft.com/kb/321044) рассматривается несколько методов обработки события, показанного на экране 3.

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

Kerberos в значительной степени полагается на службу имен доменов. Имена участников службы задаются в контексте имени службы DNS (например, http/www.contoso.com). Если вы зайдете на сайт www.contoso.com через URL, отличный от www.contoso.com, протокол Kerberos не будет функционировать корректно. В случаях когда требуется обеспечить возможность просмотра приложений с использованием имени их хоста, часто прибегают к такому решению: для имени хоста (скажем, http/www) определяют также имя участника службы (SPN), с тем чтобы пользователям не приходилось вводить полное доменное имя Fully Qualified Domain Name (FQDN) соответствующей службы. Надо отметить, что метод Kerberos неприменим, если доступ к службе осуществляется по IP-адресу. В таких случаях аутентификация обычно проводится по протоколу NTLM.

Когда осуществляется возврат к средствам аутентификации на базе NTLM, приложения, реализующие делегирование Kerberos, но не поддерживающие смену протокола, дают сбой. Иногда NTLM используется не потому, что возникла проблема с использованием протокола Kerberos, а вследствие ошибки в настройке либо сервера, либо браузера. Для диагностики подобных сбоев можно применять, например, бесплатно распространяемую утилиту Fiddler. Ее можно загрузить с сайта www.fiddler2.com.

Немало хлопот доставляет и чрезмерное разрастание маркеров (token bloat). Спецификация Kerberos предусматривает хранение данных о членстве пользователя в группах (наряду с прочими сведениями) в разделе PAC (Privilege Attribute Certificate) предоставленного данному пользователю билета на получение билета, а значит, и в билетах служб. В статье Microsoft «New resolution for problems with Kerberos authentication when users belong to many groups» (support.microsoft.com/kb/327825) рассказывается о том, как осуществляется корректировка параметра реестра Max-TokenSize и как выполняется расчет вклада каждой группы в общий размер маркера. Но надо сказать, что, хотя с помощью корректировки можно на время снять данную проблему, лучше пойти по другому пути — пересмотреть стратегию членства в группах, принятую в вашей организации.

Простые решения

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

Брайан Десмонд (brian@briandesmond.com) — старший консультант компании Moran Technology Consulting (Чикаго). Имеет сертификат Directory Services MVP. Автор книги «Active Directory», ведет блог www.briandesmond.com