Использование Kerberos для проверки подлинности SharePoint

Хотя SharePoint предлагает несколько вариантов проверки подлинности и зон аутентификации, двумя общепринятыми вариантами выбора для корпоративной реализации в сценариях интрасети являются протокол NTLM и Kerberos. Оба эти протокола используются совместно со встроенной проверкой подлинности Windows по классической схеме Запрос/Ответ. Протокол NTLM использует метабазу IIS, генерирующую маркер с вызовом, который она отправляет клиенту, клиент отвечает маркером, а контроллер домена проверяет подлинность данного ответа. В протоколе NTLM необходимо шифрование имен пользователей и паролей перед их передачей, а также повторная проверка подлинности (новый маркер) при получении доступа к новому сетевому ресурсу. Протокол Kerberos, с другой стороны, основывается на системе билетов, когда клиент и сервер получают доступ к доверенному центру авторизации под названием Центр распределения ключей (Key Distribution Center, KDC), который отвечает на запросы клиента и выдает билеты, которые могут использоваться клиентом для подключения к сетевым ресурсам. Для протокола Kerberos не требуется повторная проверка подлинности для получения доступа к нескольким ресурсам.

В большинстве документов советуют использовать протокол NTLM, если только нет необходимости, например, для узлов с соглашениями о высоком уровне безопасности служб. Даже в этом случае, если как следует разобраться, имеется смысл использовать протокол NTLM: его легче внедрять, он требует дополнительных этапов проверки, а также уменьшает проблемы, связанные с технической поддержкой. Например, в базе знаний 832769 сказано: "… или если вы не можете настроить имя участника-службы (SPN), выбрать проверку подлинности с помощью протокола NTLM. Если вы выбираете проверку подлинности с помощью протокола Kerberos и не можете настроить SPN, только администраторы сервера смогут произвести проверку подлинности узла SharePoint". Инструкции являются технически точными, но это не означает, что настройка имен SPN является чрезмерно сложной, или что вы должны избегать использования протокола Kerberos, пока кто-то вас не заставит внедрить его. Но в действительности, если вы понимаете принципы, внедрение протокола Kerberos не является таким уж сложным занятием.

Существует множество веских причин, почему вы должны перейти на Kerberos, или использовать протокол Kerberos с самого начала в новой реализации, но в большинстве случаев все сводится к вопросам производительности или безопасности. При возникновении дополнительных сложностей с нагрузкой пользователей или топологией, протокол NTLM может вызвать проблемы с производительностью, потому что проверка подлинности на основе протокола NTLM, по сути своей, требует несколько циклов передачи данных между метабазой IIS и контроллером домена во многих случаях использования SharePoint, например, при получении доступа веб-приложения к веб-компоненту SharePoint или пользовательской веб-службе. Возможность возникновения проблем с производительностью особенно высока, если доступ к контроллеру домена осуществляется через медленное подключение или связь с большими задержками. С точки зрения безопасности, система на основе билетов (Kerberos) с прямым делегированием сетевых ресурсов является более безопасной, нежели системы, использующие шифрование пользовательских учетных данных. Она также быстрее, потому что использует один билет для получения доступа к нескольким сетевых ресурсов.

Множество установок запускаются с протоколом NTLM вместо протокола Kerberos, потому что использование топологий планирования, распределения размеров серверов, поставщиков поддержки безопасности (SSP) и других деталей уже кажется страшной задачей, а дополнительные сложности вообще покажутся чрезмерными. Данное утверждение имеет смысл. В конце концов, реализации на основе протокола Kerberos имеют свои проблемы. Взгляните на статьи 871179, 962943 и 832769, имеющиеся в базе знаний для получения информации о некоторых проблемах, которые могут быть настолько серьезными, например, как синий экран с ошибкой STOP. Даже существующая документация, например, подробное руководство Microsoft по реализации протокола Kerberos, не содержит информации о метабазе IIS версии 7 и более поздних версий, в которых используется функция проверки подлинности в режиме ядра и изменен способ обработки имен SPN. Но не волнуйтесь, если вы понимаете фундаментальные концепции использования протокола Kerberos приложением SharePoint, то реализация и настройка вам покажется сравнительно несложной. В данной статье рассматриваются важные компоненты архитектуры и содержатся некоторые детали настройки, которые помогут вам начать работу. Корпорация Microsoft уже опубликовала документацию с поэтапными инструкциями, а также статьи 832769 и 953130 в базе знаний KB, которые вы можете использовать в качестве дополнительной информации.

Компоненты и зависимости проверки подлинности

Начнем с обзора зависимостей в архитектуре SharePoint, использующей встроенную проверку подлинности Windows. На самом базовом уровне, с протоколом NTLM или Kerberos, имеется клиент, выполняющий запросы веб-страницы SharePoint.aspx, использующей метабазы .NET и IIS в фоновом режиме. В свою очередь, страница использует данные настроек сервера SQL Server и базы данные содержимого. Способ обработки запросов службами IIS в контексте SharePoint 2007 относительно проверки подлинности показан на рис. 1. Если браузер клиента выполняет веб-запрос, запускается поток в метабазе IIS, а объекты, относящиеся к запросу, например, маркер, содержащийся в объекте IIdentity, который находится в объекте IPrincipal, прикреплены к потоку. Программными средствами доступ к объектам IIdentity и IPrincipal осуществляется через свойство HttpContext.User, а оба объекта и свойство настраиваются модулями проверки подлинности, которые являются частью конвейера .NET, как показано на рис. 1.

Рис. 1. Общие компоненты проверки подлинности и поток данных в SharePoint

Ниже приведено описание потока данных:

1. Браузер клиента инициирует подключение к серверу переднего плана SharePoint (обрабатывается метабазой IIS через конвейер .NET) с помощью анонимного запроса HTTP GET.
2. Если зона настроена на анонимный доступ (например, для сценариев Интернет), метабаза IIS продолжает обработку запроса. В противном случае метабаза IIS выдаст ошибку 401.2 и сделает запрос на проверку подлинности у браузера клиента.
3. Браузер клиента получит запрос и в зависимости от зоны и соответствующих условий, проверит подлинность клиента. Основным способом является выполнение команды AcquireCredentialsHandle и ввод имени пользователя/пароля, затем маркер проверки подлинности передается обратно в SharePoint через IIS.
4. Метабаза IIS ожидает ответа в диалоге с HTTP и принимает маркер проверки подлинности, а затем разрешает или запрещает доступ. На этом этапе IIS передает запрос в SharePoint через конвейер .NET.
5. Если на запрашиваемой странице имеется веб-компонент, для которого необходим доступ к серверным базам данных SQL, SharePoint проходит проверку подлинности с помощью сервера SQL Server и получает доступ к базам данных. Характер проверки подлинности SQL варьируется в соответствии с вариантами настройки. Например, вы можете настроить проверку подлинности сервера SQL Server или встроенную проверку подлинности Windows с помощью протокола NTLM или Kerberos. Я расскажу о специфике протоколов Kerberos и NTLM в этой статье далее.

Ключевая мысль о механизмах проверки подлинности в SharePoint заключается в том, что здесь играют роль три слоя: браузер клиента, метабаза IIS с конвейером .NET и сервер SQL Server. Для возвращения скомпилированной страницы .aspx, производится проверка подлинности и авторизация между клиентом, метабазой IIS и сервером SQL Server. Иногда процесс упрощается, например, при использовании протокола NTLM в случае, если сервер SQL Server находится на том же физическом сервере, что и метабаза IIS. В этом случае существует только один прыжок из клиента в метабазу IIS. Для получения дополнительных сведений о проверке подлинности в .NET, просмотрите статью Инструкции: проверка подлинности Windows в ASP.NET 2.0.

NTLM и Kerberos

Теперь, после того как мы рассмотрели базовый механизм, используемый Windows Server, IIS и .NET при проверке подлинности и авторизации пользователей, давайте посмотрим, как он подходит в контексте встроенной проверки подлинности Windows с протоколами NTLM и Kerberos. Как уже упоминалось, основное отличие протокола NTLM от Kerberos заключается в том, что протокол NTLM использует механизм Запрос/Ответ, требующий проверки подлинности и авторизации для получения доступа к любому сетевому ресурсу. А протокол Kerberos использует систему билетов, которая выполняет проверку подлинности один раз и затем производит авторизацию с помощью делегирования. Не пугайтесь, если это различие покажется непонятным, далее я все разъясню. На рис. 2 показано, каким образом SharePoint обрабатывает запросы при использовании протокола NTLM.

Рис. 2. Проверка подлинности NTLM в SharePoint

Как видно из рис. 2, использование протокола NTLM требует наличия контроллера домена с возможностью проверки подлинности пользователей. Если домен работает в стандартном режиме, по умолчанию на контроллере домена или другом сервере потребуется наличие глобального каталога. Вот вам и еще одна потенциальная проблема с производительностью в дополнение к проблеме двойного прыжка, потому что после установления связи с контроллером домена, запросы проверки подлинности перенаправляются на сервер глобального каталога, если глобальный каталог не доступен локально. С медленными сетевыми каналами может использоваться много ресурсов и большая часть пропускной способности. Вы можете попытаться выжать дополнительные уровни производительности с помощью проверки подлинности с протоколом NTLM, например, заменив значение записи реестра MaxConcurrentApi, но это не объясняет фундаментальной необходимости в протоколе NTLM для использования схемы Вызов/Ответ, а также не решает соответствующие проблемы с производительностью при работе с большими нагрузками.

Ниже представлены детали проверки подлинности с протоколом NTLM для учетных записей в одном домене:

1. Процесс начинается, как упоминалось выше, когда браузер клиента инициирует подключение к серверу SharePoint с метабазой IIS и конвейером .NET с помощью запроса HTTP GET и пытается произвести анонимную проверку подлинности.
2. Метабаза IIS отклоняет анонимный запрос с ошибкой 401.2 и отправляет запрос обратно для проверки подлинности с помощью протокола NTLM (WWW-Authenticate: NTLM).
3. Браузер клиента получает запрос и вызывает компонент InitializeSecurityContext для создания маркера проверки подлинности, в который входит имя домена и компьютера, и затем отправляет маркер проверки подлинности в метабазу IIS.
4. Метабаза IIS принимает детали и отправляет клиенту запрос NTLM.
5. Клиент отправляет ответ на запрос (опять используется маркер проверки подлинности), зашифрованный паролем пользователя.
6. На данном этапе метабазе IIS необходимо совершить диалог с контроллером домена. Она отправляет имя пользователя клиента, запрос и ответ на запрос.
7. Контролер домена получает хэш пароля пользователя и сравнивает его с ответом на запрос, который был зашифрован с помощью учетных данных пользователя. Если они совпадают, контроллер домена выдает сообщение об успешной проверке метабазе IIS, и метабаза IIS может начать диалог с браузером клиента.
8. После чего веб-приложение проверяется сервером SQL Server и может получить доступ к базе данных содержимого, в которой сохранены данные для страницы .aspx.

Если вы когда-нибудь пытались настроить протокол Kerberos на веб-странице центра администрирования для базовой установки, вы должны знать, что после выбора протокола Kerberos вместо NTLM, появится сообщение, в котором будет говориться о том, что вы должны настроить учетную запись пула приложений для разрешения работы протокола Kerberos, если только пул приложений не работает в контексте сетевой службы. Это может быть вызвано способом выполнения проверки подлинности на основе протокола Kerberos с использованием необходимых имен SPN. Как в WSS, так и в MOSS, веб-приложение является веб-узлом IIS, назначенным для пула приложений, который работает в контексте встроенной учетной записи или учетной записи пользователя. Имеется возможность, но не рекомендуется, назначить несколько веб-узлов для одного пула приложений. Если вы не внесете изменения, метабаза IIS использует учетную запись сетевой службы для пулов приложений, а не уникальную учетную запись домена. Однако чтобы протокол Kerberos работал в среде SharePoint, вы должны установить уникальное имя SPN в учетной записи пула приложений.

На практике связь на основе протокола Kerberos основана на использовании клиентов и сервера с поддержкой Kerberos, Центра распределения ключей, который выступает в роли промежуточного звена проверки подлинности, и имен SPN. Технические детали немного сложнее. Например, для протокола Kerberos требуется интеграция DNS с Active Directory или BIND с записями SRV, TCP/IP и служба времени. Скорее всего, если вы используете Windows Server 2003 или 2008 с интегрированной системой DNS, у вас уже имеются необходимые компоненты, и вам просто нужно их настроить. На рис. 3 показаны различные компоненты и поток данных при проверке подлинности на основе протокола Kerberos в среде SharePoint.

Увеличить
Рис. 3. Проверка подлинности на основе протокола Kerberos

1. Как и в случае с протоколом NTLM, браузер клиента выполняет анонимный запрос HTTP GET, используя имя компьютера (FQDN или псевдоним).
2. Сервер переднего плана выдает ошибку 401.2 и сообщение — WWW-Authenticate: Согласуйте заголовок и/или параметр WWW-Authenticate. Заголовок Kerberos означает, что имеется поддержка проверки подлинности на основе протокола Kerberos. Вы должны настроить его для серверов переднего плана в центре администрирования, о чем я писал выше.
3. Клиент связывается с Центром распределения ключей в контроллере домена и запрашивает билет для SPN, который основан на информации, отправленной браузером клиента, представляющей собой имя компьютера.
4. Если Центр распределения ключей обнаруживает совпадающее имя SPN, он зашифровывает билет и возвращает его.
5. Браузер клиента создает средство проверки подлинности и отправляет его с билетом службы в IIS-сервер, который, в свою очередь, дешифрует билет, определяет достоверность и проверяет полномочия (список контроля доступа) на запрашиваемый ресурс.
6. Если доступ разрешен, метабаза IIS, через службу веб-приложений, связывается с сервером SQL, а служба запрашивает билет для сервера SQL Server от Центра распределения ключей.
7. Если имя SPN найдено, Центр распределения ключей возвращает билет, используемый веб- приложением для запроса базы данных содержимого, и с помощью делегирования персонифицирует пользователя.
8. Сервер SQL Server проверяет билет, полученный от веб-приложения, и подтверждает его подлинность. При успешном выполнении сервер SQL Server отправляет данные обратно на сервер, а конвейер .NET компилирует страницу .aspx и отправляет ее браузеру.

Понимание имен SPN

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

Имя SPN является строкой уникального идентификатора для службы, которая работает на сервере. Оно хранится в Active Directory в виде атрибута с множественными значениями учетной записи пользователя под названием Service-Principal-Name (имя участника-службы). Множество служб на компьютере или большое количество компьютеров различаются при помощи их уникальных имен SPN. Возможно, я переоцениваю важность имен SPN, но тому есть причина. Некорректно настроенные имена SPN приводят к нарушению проверки подлинности на основе протокола Kerberos. Если вы установите два идентичных имени SPN, или забудете установить имя SPN, или неправильно зададите часть имени SPN, проверка подлинности не заработает.

Рассмотрим пример имен SPN и то, каким образом протокол Kerberos использует их. Имя SPN состоит из трех частей: класс службы, определяющий тип службы, имя компьютера, на котором запущена служба, и порт. Сведя все компоненты вместе, получаем следующий синтаксис service class/host: port. Для среды SharePoint двумя подходящими именами являются HTTP и MSSqlSvc. Имена службы не являются произвольными и определяются как специальные псевдонимы для службы. Имя компьютера — имя FQDN или NetBIOS, дополнительно включающие порт. При регистрации имен SPN, рекомендуется регистрировать SPN как для имен компьютера NetBIOS, так и FQDN, потому что, несмотря на используемый клиентом способ, они могут получить доступ к ресурсам на целевом компьютере.

Ранее я говорил, что пока вы не запустите пул приложений под учетной записью сетевой службы, вам придется регистрировать имена SPN. Это объясняется тем, что когда компьютер входит в домен Active Directory, имена SPN создаются автоматически для учетной записи компьютера в формате HOST/<NetBIOSname> и HOST/<FQDN>. Ввиду того, что учетная запись сетевой службы выступает как компьютер в сети, имена SPN действительны и для нее. Однако не рекомендуется использовать локальную учетную запись сетевой службы из-за вопросов безопасности, и потому, что это может привести к нарушениям в работе некоторых сценариев. Например, если вы восстанавливаете или подключаете базу данных содержимого, настроенную под учетной записью сетевой службы, вы должны добавить учетную запись в локальную группу "Администраторы" сервера SQL Server, а затем удалить ее после подключения базы данных. В большинстве существующей документации рекомендуется использовать учетные записи домена.

Настройка серверной части

Сначала вы должны настроить проверку подлинности на основе протокола Kerberos на сервере SQL Server, переносите ли вы существующую ферму или устанавливаете новую. Сервер SQL Server должен соответствовать выше упомянутым требованиям, например, должен быть подключен к домену, иметь доступ к контроллеру домена, который также является и Центром распределения ключей, и т.д. В большинстве сред эти требования выполнены по умолчанию при использовании Active Directory с интегрированной системой DNS. Вам не нужно детально настраивать протокол Kerberos, если в вашей среде используются только серверы SharePoint переднего плана, а серверы приложений не используются, например, на которых работают службы Excel или службы отчетов SQL. Стандартного имени SPN, созданного при подключении сервера SQL Server к домену, достаточно для основного подключения переднего плана или фонового подключения.

Настройка протокола Kerberos на сервере SQL Server является сравнительно несложной задачей. Сначала вы устанавливаете соответствующие имена SPN, проверяете факт того, что используется протокол Kerberos, а не стандартный протокол NTLM. Вы должны задать имя NetBIOS и FQDN в формате MSSQLSvc/<NetBIOS_Name>:1433 и MSSQLSvc//<FQDN-hostname.domain.local>:1433, предполагая, что ваш экземпляр будет использовать стандартный порт — 1433. Хотя вы можете использовать средство setspn или ADSIEdit для установки SPN, setspn обычно является лучшим вариантом, потому что оно проверяет синтаксис. При использовании ADSIEdit, напротив, вы вписываете имена SPN непосредственно в атрибут servicePrincipalName. Для создания двух имен SPN выполните команду setspn-A MSSQLSvc/<NetBIOS_Name>:1433 <domain>\<username> and setspn-A MSSQLSvc/<FQDNe>:1433 <domain>\<username>, где именем пользователя является учетная запись службы SQL.

Для подтверждения факта того, что трафик сервера SQL Server использует Kerberos, вы можете отследить трафик с помощью анализатора пакетов, например, Wireshark, воспользоваться средством Kerbtray.exe или проверить журналы событий. Если вы подключаетесь к экземпляру SQL с помощью SQL Server Management Studio, в журнале событий безопасности должна появиться запись Event ID 540, в которой будет отмечено, что в процессе входа и проверке подлинности использовался протокол Kerberos. Дополнительные сведения по этой процедуре приведены в статье Настройка проверки подлинности с помощью протокола Kerberos для SQL.

Настройка сервера переднего плана и сервера приложений

Обеспечив то, что протокол Kerberos работает на сервере SQL Server, вы можете переходить к настройке среды SharePoint, установив имена SPN для пулов приложений, активировав протокол Kerberos для поставщиков поддержки безопасности (SSP) и веб-приложений, и приступить к выполнению заключительных шагов. Настройка SPN аналогична тому, что вы делали в учетной записи службы сервера SQL Server, но для настройки представлено гораздо больше имен SPN. Вспомните имена SPN, созданные на основании того, что может ввести пользователь в адресную строку браузера клиента, поэтому мы должны задать имена SPN для каждой записи, которую пользователь может ввести в адресную строку для входа на узел. Сюда входят имена FQDN, NetBIOS и псевдонимы в виде заголовков узла. На рис. 4 отображен пример типов ресурсов и имена SPN, которые необходимо зарегистрировать для каждого ресурса.

Увеличить

Рис. 4. Имена SPN для базовой фермы MOSS

Необходимо помнить о нескольких вещах при настройке имен SPN. Во-первых, имена SPN регистрируются для веб-узла с поддержкой SharePoint аналогичным образом, что и для веб-узла IIS. Важно указать правильное имя компьютера и учетную запись, под которой работает пул приложений для каждого узла. Если вы используете несколько заголовков узла, убедитесь в том, что имена SPN заданы для них всех. Во-вторых, необязательно указывать порты для HTTP и HTTPS, но вы должны указать любой пользовательский порт. И в-третьих, вам придется настроить несколько дополнительных зависимостей, например, изменение реестра для метабазы IIS для обеспечения формирования имен SPN с пользовательскими портами и обновление для поддержки SSP. Дополнительные сведения об этом можно найти в статье Настройка проверки подлинности на основе протокола Kerberos (Office SharePoint Server).

Имеется еще два основных этапа, которые вы должны выполнить для того, чтобы протокол Kerberos заработал в вашей среде. Вы должны настроить учетные записи компьютера и некоторые учетные записи служб для поддержки делегирования, а также вы должны настроить свою ферму для поддержки протокола Kerberos в центре администрирования. Идея делегирования в протоколе Kerberos заключается в том, что если пользователь отправляет запрос на конечный ресурс, а некоторые промежуточные учетные записи должны обработать данный запрос, то эти промежуточные учетные записи должны иметь доверие для делегирования от имени пользователя. Вы можете настроить учетную запись для выполнения делегирования с помощью оснастки "Пользователи и компьютеры Active Directory" под администратором домена. Выберите пункт Trust this user/computer (Доверять этому пользователю/компьютеру) для делегирования любой службы (Kerberos) во вкладке Delegation (Делегирование) учетной записи пользователя или компьютера. Вы должны активировать функцию делегирования для учетных записей компьютеров серверов переднего плана, серверов приложений и SQL Server, для пулов приложений (SSPAdmin, MySite, различных веб-приложений) и для учетной записи служб фермы.

Кроме того, вы должны установить разрешения в Component Services (Службы компонентов). В стандартных настройках установите параметр Impersonation Level = Delegate. В IIS WAMREG Admin Service, перейдите на вкладку Security и назначьте разрешения Local Activation учетным записям пула приложений. Дополнительные сведения приведены в статьях KB 917409 и 920783 базы знаний.

После активации функции делегирования пришло время заключительного этапа — установке Kerberos в качестве предпочтительного протокола для SSP и веб-приложений. Для новой установки вы можете сделать это на узле центра администрирования SharePoint в мастере настройки продуктов и технологий SharePoint. В противном случае, перейдите на вкладку Authentication Providers в пункт Application Management, находящийся в центре администрирования, щелкните Default и установите метод Negotiate (Kerberos). Не забываем выполнить команду iisreset /noforce для того, чтобы изменения вступили в силу в пуле приложений, и протокол Kerberos был активирован для SSP.

Изменения в IIS 7 и Windows Server 2008

До сих пор я ограничивался средой SharePoint 2007 на Windows Server 2003 и IIS 6. Если вы переходите на Windows Server 2008 и IIS 7, то придется выполнить некоторые изменения в настройках. Возможно, наиболее заметное изменение заключается в том, что IIS 7 поддерживает проверки подлинности Kerberos в режиме ядра. Во время проверки подлинности в режиме ядра, учетная запись сетевой службы (на самом деле это вышеупомянутая учетная запись компьютера) дешифрует билеты, если вы только не указали иного. Проверка подлинности в режиме ядра активируется по умолчанию при переходе на IIS 7 или при установке новой фермы. Напомним, что учетная запись сетевой службы является локальной. Если вы запускаете один сервер, начинается дешифрование. На ферме, однако, происходит сбой, потому что вы должны использовать учетные записи домена, которые могут проверяться Центром распределения ключей. Это изменение также означает, что вы можете выполнить переход протокола (клиенты используют проверку подлинности в метабазе не на основе протокола Kerberos и IIS, а IIS использует протокол Kerberos для связи с сервером, используя учетную запись сетевой службы, так как она уже имеет привилегии LocalSystem).

Для настройки протокола Kerberos в вашей ферме SharePoint, на которой работает метабаза IIS 7, вы должны вручную изменить файл %WinDir%\System32\inetsrv\config\ApplicationHost.config (на данный момент графический интерфейс недоступен). Соответствующая запись показана ниже.

<system.webServer>
<security>
<authentication>
<windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />
</authentication>
</security>
</system.webServer>

Не забываем выполнить команду iisreset /noforce для того, чтобы изменения вступили в силу, и проверяем наличие последних обновлений решения такой проблемы, как синий экран, подробно описанной в статье 962943 базы знаний.

Также нужно вспомнить еще об одной детали; если в вашей конфигурации используется олицетворение подлинности (<identity impersonate="true" /> в web.config) а также конвейер в интегрированном режиме, вы должны установить значение атрибута validateIntegratedModeConfiguration в "false" или запустить страницы .aspx на конвейере в классическом режиме.

Заключение

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