Легко использовать аутентификацию Kerberos для доступа к SharePoint, когда служба каталога AD выступает в роли хранилища удостоверений. Протокол аутентификации Kerberos представляет собой высокопроизводительный и полностью готовый к работе механизм аутентификации Windows Server и Kerberos — самый безопасный механизм аутентификации, поддерживаемый AD. Более подробная информация о технологии Kerberos приведена во врезке «10 важных особенностей технологии Kerberos».

Специалисты Microsoft рекомендуют использовать аутентификацию Kerberos в окне Central Administration в Windows SharePoint 3.0 (WSS 3.0). К сожалению, когда пользователь выбирает аутентификацию Kerberos, система выводит на экран не совсем понятное сообщение о том, что администратор должен настроить учетную запись пула приложений, чтобы Kerberos смог функционировать, если учетная запись этого пула приложений не Network Services. Более того, не дается ссылок на какую-либо документацию, где разъяснялось бы, что нужно сделать, чтобы заставить аутентификацию Kerberos работать. Видимо, для усложнения задачи статья Microsoft о том, как настроить сервер Microsoft Office SharePoint Server 2007 (MOSS) так, чтобы использовать аутентификацию Kerberos (см. support.microsoft.com/?kbid=832769), содержит следующий текст: «Вам следует выбрать аутентификацию NTLM (менеджер NT LAN)». Не очень логично, не так ли?

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

Системные требования

Чтобы запустить аутентификацию Kerberos в сети Windows, требуется несколько компонентов, которые показаны на рис. 1. Если вы используете AD, у вас, вероятно, все уже есть: центр доверия, называемый центром распределения ключей Key Distribution Center, KDC (о нем рассказано в статье Microsoft «Как работает пятая версия протокола аутентификации Kerberos» на technet2.microsoft.com/windowsserver/en/library/4a1daa3e-b45c-44ea-a0b6-fe8910f92f281033.mspx?pf=true), клиенты, которые поддерживают аутентификацию Kerberos, служба времени, TCP/IP, служба DNS, интегрированная с AD, и возможность настроить имена Service Principal Names (SPN). KDC помогает обеспечить безопасную коммуникацию между двумя клиентами. Каждый контроллер домена DC уже является KDC. KDC использует отметки времени в процессе аутентификации, потому что AD полагается на службу времени для обеспечения работы таких процессов службы каталогов, как репликация. Если вы уже используете AD, служба времени скорее будет настроена для правильного функционирования AD. Вдобавок, скорее всего, у вас есть интегрированная с AD служба имен DNS, уже работающая в сети. Конечно, вы можете работать с серверами BIND DNS вместе с AD. Если вы используете BIND DNS, все, что вам нужно сделать для запуска Kerberos, — это добавить записи SRV для каждого домена AD, особенно это важно для поддержки протоколов LDAP и Kerberos. Информацию о том, как настроить сервер BIND DNS, чтобы он поддерживал Kerberos, можно найти в статье «Configure BIND DNS to Answer Active Directory Queries» по адресу www.linuxquestions.org/linux/answers/Networking/Configure_BIND_DNS_to_Answer_Active_Directory_Queries).  

И наконец, все клиентские системы от Windows 2000 и более поздние поддерживают Kerberos. Kerberos — это открытый стандарт, что позволяет надеяться — такие дополнительные клиенты, как Mac OS X, Sun Microsystems Solaris и Red Hat Linux, также поддерживают Kerberos. Убедившись, что ваша сеть отвечает основным требованиям, можно перейти к настройке.

Первые шаги для поддержки аутентификации Kerberos

Первым делом при настройке Kerberos задается один или несколько SPN и каждое Web-приложение SharePoint настраивается на использование Kerberos. Шаги повторяются для всех реализаций MOSS/WSS 3.0. Прежде чем вникать в то, как реализовать эти два первых этапа конфигурации, важно понять базовую архитектуру Web-приложения MOSS/WSS и ее соотношение с архитектурой сайта на базе Internet Information Server (IIS), на котором приложение запускается.

Типичный экземпляр MOSS содержит многочисленные Web-приложения. Например, одно Web-приложение назначается для поддержки SharePoint Central Administration, а другое — для провайдера SharePoint Shared Service Provider (SSP). Вы создаете эти два Web-приложения, когда устанавливаете и настраиваете MOSS. Чтобы позволить пользователям взаимодействовать с MOSS, создаются одно или несколько Web-приложений. Пользователи регистрируются в этих приложениях. Кроме того, вы создаете еще одно Web-приложение, если хотите запустить функцию MySite. Каждое Web-приложение — это Web-сайт IIS 6.0. Хотя интерфейс MOSS/WSS 3.0 позволяет создать функцию MySite в SSP, мастер установки посоветует вам создать отдельное Web-приложение. Это замечательная идея, особенно для упрощения восстановления после сбоя системы.

Неотъемлемой частью IIS 6.0 или более нового Web-сайта является его пул приложений. Каждому Web-сайту IIS 6.0 присваивается свой пул. Для безопасности и стабильности пул приложения отделяет рабочий процесс одного или нескольких Web-сайтов от настроек и контента этих Web-сайтов. Хотя можно назначить более одного Web-приложения IIS одному пулу приложений, следует настроить каждое Web-приложение MOSS на использование его собственного пула приложений. Внутри пула приложений указывается учетная запись пользователя для запуска процесса Web-сайта. По умолчанию IIS задает встроенную учетную запись Network Service для пула приложений. Однако Microsoft не рекомендует такую конфигурацию для Web-приложений MOSS/WSS 3.0. Вместо этого каждый пул приложений использует уникальную доменную пользовательскую учетную запись и должен быть назначен для единственного Web-приложения. Просмотрите статью Microsoft «Plan for administrative and service accounts (Office SharePoint Server)» по адресу technet2.microsoft.com/Office/en-us/library/f07768d4-ca37–447a-a056–1a67d93ef5401033.mspx?mfr=true.

Что такое SPN?

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

В Kerberos 5 различные части SPN разделяются прямым слэшем: класс/хост: порт/имя. Имя класса представляет собой значение, такое как HOST, HTTP или LDAP. HOST — это особое имя и всегда представляет встроенные службы, запускаемые на компьютере, зарегистрированном в AD. Любое другое имя класса действует как псевдоним имени HOST. Полезно задать понятное имя класса, чтобы различать особые виды служб, которые наверняка у вас будут, такие как службы http. Например, Microsoft Internet Explorer (IE) и IIS используют имя класса HTTP для Kerberos. Заметим, что имя класса HTTP и протокол http не одно и то же. Таким образом, можно использовать HTTP как имя класса для службы http и службы https.

Следующая часть SPN — это имя хоста, но не следует путать его с именем класса HOST; имя хоста может включать номер порта. Два типа имен хоста, которые нужно зарегистрировать для SPN, — имя NetBIOS (имя компьютера) и полное доменное имя Fully Qualified Domain Name (FQDN). Регистрация обоих позволит гарантировать, что пользователь, который подключается по любому из этих двух имен, будет аутентифицироваться с помощью Kerberos.

Также можно включить номер порта, если требуется ограничить SPN особым портом или если используются нестандартные порты для конкретного Web-приложения. Например, если сайт вашего центрального администрирования размещается на порту 35000, можно включить это требование в зарегистрированных SPN на сайте SharePoint Central Administration. Вот более подробный пример: если Central Administration размещается на компьютере с именем CA01 в домене fabrikam.com на порту 35000, SPN для этого сайта будут HTTP/CA01.fabrikam.com:35000 и HTTP/CA01:35000.

Последний элемент «имя» в SPN используется редко, кроме служб, которые реплицируются. Можно без опаски пренебречь частью «имя» в SPN для имен SPN, предназначенных для MOSS.

В терминах AD, SPN — это значения, автоматически записываемые в ServicePrincipalName, многозначный атрибут учетной записи компьютера, когда тот регистрируется в домене AD. Например, workstation01 в домене fabrikam.com будет иметь два автоматически прописанных SPN: HOST/WORKSTATION01 и HOST/workstation01.fabrikam.com. Серверы, зарегистрированные в домене, также будут иметь записи HOST SPN и, вероятно, символический класс, такой как SMTPSVC. В силу этой автоматической регистрации ваш клиент AD может использовать Kerberos для аутентификации в домене. Более того, NT AUTHORITYNETWORK SERVICE (также известная как Network Service) действует от имени компьютера в сети и, следовательно, перенимает настройки SPN компьютера.

Меня могут спросить, если SPN уже в Network Service, к чему трудиться и устанавливать SPN, если пул приложений IIS может использовать эту запись для идентификации? Microsoft рекомендует использовать учетную запись клиента AD для каждого пула приложений, поддерживающего Web-приложение MOSS. Хотя у нас нет специальной информации по этому поводу, мы полагаем, что Microsoft препятствует использованию Network Service для данной цели, потому что это потребовало бы задать некоторые разрешения для этой вездесущей и обладающей низкими привилегиями учетной записи. Таким образом, когда вы задаете учетную запись для удостоверения Application Pool, которое будет обеспечивать аутентификацию Kerberos, нужно задать SPN для этой учетной записи. Во время начальной аутентификации между браузером клиента и Web-приложением IIS использует SPN для формирования билета Kerberos начиная с ключа KDC и сеанса от имени зарегистрированного пользователя.

Настройки SPN

С помощью программы для командной строки setspn, которая поставляется с Windows 2003 SP1 и последующими версиями (и как дополнительный инструмент для Windows 2000), можно создавать, читать, обновлять и удалять SPN. Процесс создания относится к регистрации SPN. На рис. 2 показан процесс регистрации.

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

В случае хоста, названного corpweb и corpweb.fabrikam.com, если учетная запись приложения, заданная для MOSS Application Pool, представляет собой fabrikamPortalAppPool, следующие команды SetSPN подготавливают учетную запись для аутентификации Kerberos:

setspn -A HTTP/corpweb fabrikamPortalAppPool
setspn -A HTTP/corpweb.fabrikam.com fabrikamPortalAppPool

Первая команда устанавливает класс HTTP и имя NetBIOS Web-сервера для пользовательской учетной записи fabrikamPortalAppPool. Вторая команда устанавливает класс HTTP и полное имя хоста (имя DNS) для портала с той же пользовательской учетной записью. После регистрации пользовательской учетной записи с требуемым SPN вводим следующую команду:

setspn -L portalapppol

и получаем следующие результаты:

Registered ServicePrincipalNames for CN=PORTALAPPPOOL, OU=SVCACCOUNTS,
DC=FABRIKAM, DC=COM:
HTTP/corpweb
HTTP/corpweb.fabrikam.com

Ключ -L показывает отличительное имя учетной записи PortalAppPool и SPN, зарегистрированные для этой учетной записи. Синтаксис команды наводит на мысль о том, что вы можете запускать команду setspn только для имен компьютеров. Однако это работает и для пользовательских учетных записей, как показано в предыдущем примере.

Настройки SPN для MOSS

Чтобы MOSS поддерживал аутентификацию Kerberos, нужно запустить команду setspn для учетных записей пула приложений, которые вы создали для Web-приложений MOSS, с целью регистрации опубликованных имен. В типичной установке MOSS Web-приложениями, которые требуют записей SPN для учетных записей ассоциированных пулов приложений, являются SharePoint 3.0 Central Administration, SSP, MySite и портал. Опубликованные имена включают FQDN, так как он появляется в DNS (т. е. corpweb.fabrikam.com), имя NetBIOS (т. е. corpweb) и любые другие FQDN, какие только могут быть ассоциированы с сайтом портала (например, запись DNS CNAME для portal.fabrikam.com, которая разрешается в corpweb.fabrikam.com, или адреса заголовка хоста).

Используйте номер порта в имени хоста SPN для Web-приложений, которые публикуются по нестандартным портам. Если конкретное Web-приложение использует порт 80 или 443, нет необходимости указывать номер порта.

В предыдущем разделе о регистрации двух SPN я привел простой пример. Еще можно обратиться к статье «Configuring Kerberos for SharePoint 2007: Part 1 — Base Configuration for SharePoint» (blogs.msdn.com/martinkearn/archive/2007/04/23/configuring-kerberos-for-sharepoint-2007-part-1-base-configuration-for-sharepoint.aspx), чтобы посмотреть другой пример команд SPN для экземпляра MOSS. Автор статьи Мартин Керн предлагает настроить SPN для учетной записи SharePointFarm Services. Однако мне не пришлось убедиться, что это необходимо для первоначальной настройки поддержки аутентификации Kerberos.

Подготовка Web-приложений

Теперь, когда ваши SPN заданы, следующий шаг — настройка стандартного провайдера Windows каждого Web-приложения на использование Kerberos. Можно завершить эту задачу из SharePoint Central Administration в такой последовательности: Central Administration, Application Management, Authenticatoin Providers. Из раскрывающегося меню Web Application в панели инструментов выбираем каждое Web-приложение, а затем указываем зону Default для провайдера Windows.

На Web-странице Edit Authentication следует убедиться, что выбрана интегрированная аутентификация Windows Integrated Authentication, затем нужно выбрать Negotiate (Kerberos). Этот режим означает, что Web-приложение будет пытаться использовать аутентификацию Kerberos. Если аутентификация не будет выполняться, Web-приложение перейдет к аутентификации NTLM. Если активированы протоколы аутентификации, отличные от Windows Integrated Authentication, такие как базовая и краткая проверка подлинности, а браузер клиента не может поддерживать Kerberos или NTLM, сервер позволит браузеру испытать базовую или краткую проверку подлинности.

Если поддерживается аутентификация Kerberos для Web-приложения, поддерживающего провайдера распределенной службы, потребуется запустить команду stsadm, чтобы активировать Kerberos:

STSADM.exe -o SetSharedWebService
Authn -negotiate

Это четвертый шаг в статье Мартина Керна, о которой упоминалось выше. Заметим, что Мартин упоминает дополнительные шаги, необходимые для настройки делегирования Kerberos (шаг 2 и часть шага 5). Однако ни один из этих шагов не является необходимым для первоначальной конфигурации MOSS, чтобы обеспечивалась поддержка Kerberos.

Когда делегирование Kerberos необходимо

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

Чтобы разобраться с делегированием, рассмотрим заимствование прав. Заимствование прав — это доступ с учетной записью зарегистрированного пользователя к ресурсам. Заимствование прав необходимо, когда служебная учетная запись (например, пула приложений MOSS) подключается к внутренним системам от имени пользователя. При этом требуется, чтобы пользователи задействовали свою учетную запись для связи с внутренним сервером. Делегирование просто расширяет заимствование прав за пределы одной системы.

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

Сценарий № 1. Пользователь регистрируется в сети Windows. Он может запустить Microsoft Word и открыть документ Word, размещенный на ресурсе общего доступа. Клиентский компьютер содержит билет Kerberos, сформированный при входе каждого пользователя в систему (он называется Ticket-granting ticket, TGT). Когда зарегистрированный пользователь хочет получить доступ к документу Word на ресурсе общего доступа, он (посредством локальной службы безопасности клиентского компьютера) общается со службой предоставления билета, т. е. сервером KDC. KDC использует дополнительные билеты Kerberos, чтобы помочь взаимной аутентификации между клиентом и файловым сервером, содержащим документ Word. Каждый DC в домене AD работает как KDC. Хотя подобное объяснение того, как происходит взаимодействие клиента и файлового сервера, кажется упрощенным, оно показывает, что в этом случае необходимы базовые службы Kerberos, а не делегирование.

Сценарий № 2. Клиентское приложение аутентифицируется в приложении промежуточного уровня, и последнее получает данные от одного или более приложений на внутреннем сервере. В этом случае клиентское приложение — это Web-браузер или офисное приложение; приложение промежуточного уровня — это портал MOSS, а приложением на внутреннем сервере может быть специализированное решение (например, Project Server) или слой служб интеграции, которые осуществляют доступ к внутренней системе.

Сценарий № 3. Служебная учетная запись имеет доступ к ресурсам от имени пользователя. Этот процесс называется моделью с доверенными подсистемами. Подсистема (или внутреннее приложение) доверяет служебной учетной записи промежуточного уровня, и таким образом служебная учетная запись может найти данные для пользователя с помощью удостоверения служебной учетной записи и передать их пользователю. Этот сценарий хорошо масштабируется, но его следует применять только для возврата данных, которые не обязательно защищать пользовательскими учетными записями или которые не требуют аудита «по пользователю».

Итак, где же требуется делегирование? Первый сценарий, в котором одно приложение имеет доступ к ресурсу общего доступа, не включает в себя делегирование. Пользователь регистрируется в системе, а на другом компьютере нет службы, действующей от имени пользователя, чтобы аутентифицироваться на ресурсе общего доступа, который содержит документ Word. Во втором сценарии делегирование необходимо для поддержки однократной регистрации single sign-on (SSO) и для аутентификации на удаленных ресурсах от имени зарегистрировавшегося пользователя. В третьем сценарии модели доверенных подсистем делегирование не является необходимым, потому что служебная учетная запись не выступает от имени пользователя.

Как настроить делегирование Kerberos

Настройка делегирования для пользовательской учетной записи пула приложений для Web-приложения SharePoint относительно проста. Самый легкий способ активировать это делегирование — перейти к свойствам учетной записи в оснастке Active Directory Users and Computers.

Возможны два варианта, зависящие от функционального уровня домена. Если вы управляете доменом Windows 2000 или домен Windows 2003 работает на функциональном уровне домена Windows 2000, выберите вкладку Account и в разделе Account Options установите флажок Account is trusted for delegation. Если домен работает на функциональном уровне домена Windows 2003, выберите вкладку Delegation в диалоговом окне свойств пользователя, как показано на экране. Если вкладки нет, а домен находится на функциональном уровне Windows 2003, необходимо вернуться назад и установить SPN для служебной учетной записи. На вкладке Delegation требуется выбрать один из приведенных ниже вариантов.

Do not trust this user for delegation. Этот вариант выбран по умолчанию и не позволяет пользовательской учетной записи принимать на себя роль другого пользователя в любых внутренних системах.

Trust this user for delegation to any service (Kerberos only). Этот вариант позволяет с помощью одной пользовательской учетной записи выступать от имени другого пользователя любого серверного приложения, поддерживающего аутентификацию Kerberos. Срок использования данного варианта ограничен, потому что ключ сессии Kerberos действует 10 часов. Однако ограничения на целевой объект нет. Учетная запись пула приложений будет пытаться получить доступ к использующему Kerberos внутреннему целевому объекту от имени другого пользователя.

Trust this user for delegation to specified services only. Этот вариант ограничивает учетную запись пула приложений одним или несколькими целевыми объектами. Кейт Браун в книге «The.NET Developer’s Guide to Windows Security» (изд-во Addison Wesley, 2005) пишет, что этот вариант ограничивает делегирование не только по времени, но и в пространстве. Я специально говорю «целевой объект», а не «внутренняя система», потому что единственным целевым объектом ограниченного делегирования является SPN. Два типичных целевых объекта — либо компьютеры, на которых активирована запись SPN, либо пользовательские учетные записи. Если вашей целью является ограничение делегирования для внутренних систем, которые используют учетную запись пула приложений, то у вас есть выбор: можете зарегистрировать SPN для целевой учетной записи, как было описано выше, или выбрать одно из существующих SPN, заданных для целевых внутренних компьютеров.

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

  • пользователи получают доступ к системе серверной части приложения через FQDN;
  • вы можете впоследствии ограничить делегирование, назначая специальный порт, по которому «слушает» внутренняя служба;
  • внутренняя служба использует обычное имя службы (класса SPN), не зарегистрированное в настройке SPN по умолчанию на целевой системе;
  • вы хотите ограничить делегирование определенными учетными записями, а не конкретными целевыми компьютерами.

Экран показывает ограниченное делегирование (т. е. выбран флажок Trust this user for delegation to specified services only) для внутренней системы с пользовательским FQDN-именем BackEnd01.Server.Sys. Создано два порта для двух SPN: служба usahsvulm268 слушает по порту 4000, служба BackEnd01.Server.Sys слушает по порту 45000.

Когда и как настраивать перенос протокола

Когда один или более пользователей, получающих доступ к порталу Web-приложений, не могут задействовать Kerberos со своих клиентских компьютеров или когда внешние Web-серверы не предусматривают аутентификацию, интегрированную с Windows, можно использовать функцию подмены протокола Kerberos, Kerberos Protocol Transition. Первый случай относительно редок. Во втором случае некоторые маршрутизаторы или межсетевые экраны не позволят вам настроить аутентификацию ни Kerberos, ни даже NTLM. В таких ситуациях выбор конфигурации IIS с использованием базовой аутентификации по SSL — лучшее, что можно сделать. После того как IIS аутентифицирует пользователя с применением базовой аутентификации, функция подмены протокола Kerberos позволит внешним Web-серверам наладить аутентификацию Kerberos от имени пользователя.

Настройка подмены протокола проста. На экране у варианта Trust this user for delegation to specified services only есть два переключателя, которые позволяют выбрать либо Use Kerberos only, либо Use any authentication protocol. Если выбрать Use Kerberos only, то ограниченное делегирование будет работать только при входящей аутентификации пользователя. Выбор переключателя Use any authentication protocol, как показано на экране, позволяет использовать подмену протокола так, что приложение промежуточного уровня (в данном случае MOSS) изменяет входящую аутентификацию Kerberos на другой вариант аутентификации, такой как базовая аутентификация или NTLM.

Для получения службой билета на заимствование прав ее учетная запись должна иметь привилегию act as part of operating system. Если ее нет, служба получит только билет идентификации.

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

Билета идентичности обычно бывает достаточно, если все, что нужно, — это разрешить подмену протокола. Посмотрите на рис. 4, и вы поймете, что необходимо сделать для поддержки подмены протокола. После выбора конфигурации Kerberos желательно свериться со врезкой «Проверка и диагностика неисправностей Kerberos», дабы убедиться, что вы все сделали правильно.

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

Рик Снеддон (rick.sneddon@eds.com) — старший специалист по инфраструктуре компании EDS. Имеет сертификат MCSE.

Этан Вилански (ewilansky@windowsitpro.com) — редактор Windows IT Pro и директор по технологиям компании EDS и ее подразделения Technology Strategy and Architecture

10 ВАЖНЫХ особенностей Kerberos

  1. Kerberos — промышленный стандарт, изначально разработанный в Массачусетском технологическом институте (Massachusetts Institute of Technology, MIT) в 1980-х годах. Текущая версия Kerberos 5 описана в RFC 1510.
  2. Если вы регистрируетесь в домене AD с компьютера, управляемого Windows 2000 или более новой версией, вы, вероятно, будете использовать протокол аутентификации Kerberos 5, чтобы получить доступ к огромному массиву ресурсов сети — ресурсам домена AD, файлам общего доступа, службам печати, Microsoft IIS и даже ресурсам, защищенным IPSec.
  3. На сегодня Kerberos — самый безопасный механизм аутентификации, поддерживаемый AD.
  4. Kerberos — лучший выбор для реализации сервера Microsoft Office SharePoint 2007 (MOSS) в корпоративной и межкорпоративной сетях, где пользователи регистрируются с использованием домена AD.
  5. Kerberos — единственный протокол аутентификации Windows, который обеспечивает ограниченное делегирование (также известное как double-hop authentication) и подмену протокола.
  6. Windows Integrated Authentication — это расширенный набор протоколов Kerberos и NTLM.
  7. Режимы Digest и Basic authentication протокола Kerberos (расширенные при помощи TLS/SSL в целях безопасности) не являются частью Windows Integrated Authentication, но доступны через Security Support Provider Interface (SSPI) в Windows.
  8. Аутентификация Kerberos для Web-сайта требует, чтобы использовался браузер Microsoft Internet Explorer 5.0 или более новый. Mozilla Firefox и другие браузеры также поддерживают аутентификацию Kerberos.
  9. Kerberos работает как в варианте с паролем, так и для аутентификации, основанной на смарт-картах.
  10. В греческой мифологии Kerberos/Cerberus (Цербер) — греческий бог Гедес, трехголовый сторожевой пес, охраняющий врата в подземный мир.

Тестирование и устранение неполадок Kerberos

Тестирование и устранение неполадок являются важной частью завершения настройки Kerberos. Регистрация активности Kerberos — первая и, вероятно, ключевая технология устранения неполадок. Обратитесь к статье Microsoft «Troubleshooting Kerberos Errors» (http://mail.yandex.ru/r?url=http%3A%2F%2Fwww.microsoft.com%2Ftechnet%2Fprodtechnol%2Fwindowsserver2003%2Ftechnologies%2Fsecurity%2Ftkerberr.mspx%23ene&ids=1560000000446951593&fs=inbox). В частности, рекомендую посмотреть разделы «How to enable Kerberos event logging on a specific computer» и «Debug Output». Вы активируете протоколирование Kerberos на сервере MOSS, действующем как Web-интерфейс. Здесь есть список инструментов (с краткими описаниями), которые могут пригодиться при тестировании и устранении неполадок аутентификации Kerberos. Даже Event Viewer является важным источником для устранения неполадок во многих операциях системы. Обратившись к Kerberos, я обнаружил, что Event Viewer — очень значимый инструмент для тестирования делегирования. Мы управляем Event Viewer на проверяемой системе, чтобы выяснить, работает ли делегирование Kerberos.

Kerbtray.exe — Kerberos Tray является инструментом с графическим интерфейсом, доступным в Microsoft Windows Server 2003 Resource Kit, который показывает информацию билета для компьютера с Kerberos 5 в реализации Microsoft. Это позволяет просмотреть и удалить кэш билета, используя значок Kerberos Tray, размещенный в области уведомлений рабочего стола. Это полезно, если у пользователя проблемы с доступом к системе, в которой пароль служебной учетной записи был изменен. Наводя курсор на значок, можно посмотреть, сколько времени осталось до истечения действия начального билета TGT. Также значок меняется за час до того, как Local Security Authority (LSA) обновит билет.

Klist — Kerberos List представляет собой инструмент командной строки. Его можно использовать для просмотра и удаления билетов Kerberos, предоставленных в текущей сессией работы с системой.

Klist имеет следующий синтаксис:

klist [tickets | tgt | purge] [-?]

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

  • билет TGT для Kerberos Key Distribution Center (KDC) в Windows;
  • билет TGT для Ksserver в UNIX.

NetMON.exe — Network Monitor 3.0 — это анализатор протоколов, который позволяет захватывать сетевой трафик, просматривать и анализировать его и устранять сетевые неполадки. Эта возможность реализована в комплекте с Windows Server или расширенной версией в Microsoft Systems Management Server. Загрузить Network Monitor 3.0 можно по адресу http://mail.yandex.ru/r?url=http%3A%2F%2Fwww.microsoft.com%2Fdownloads%2Fdetails.aspx%3FFamilyID%3Daa8be06d-4a6a-4b69-b861–2043b665cb53%26DisplayLang%3Den&ids=1560000000446951593&fs=inbox