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

Хотя SharePoint предлагает несколько вариантов проверки подлинности и зон аутентификации, 2-мя принятыми вариациями выбора для корпоративной реализации в сценариях интрасети являются протокол 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.

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

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

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

Браузер клиента инициирует подключение к серверу фронтального плана SharePoint (обрабатывается метабазой IIS через сборочный поток .NET) при помощи анонимного запроса HTTP GET.
Если зона настроена на анонимный доступ (к примеру, для сценариев Веб), метабаза IIS продолжает обработку запроса. В неприятном случае метабаза IIS выдаст ошибку 401.2 и сделает запрос на проверку подлинности у браузера клиента.
Браузер клиента получит запрос и зависимо от зоны и соответственных критерий, проверит подлинность клиента. Главным методом является выполнение команды AcquireCredentialsHandle и ввод имени юзера/пароля, потом маркер проверки подлинности передается назад в SharePoint через IIS.
Метабаза IIS ждет ответа в диалоге с HTTP и воспринимает маркер проверки подлинности, а потом разрешает либо воспрещает доступ. На этом шаге IIS передает запрос в SharePoint через сборочный поток .NET.
Если на запрашиваемой страничке имеется веб-компонент, для которого нужен доступ к серверным базам данных 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.

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

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

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

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

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

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

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

Внедрение Kerberos для проверки подлинности SharePoint
Прирастить
Рис. 3. Проверка подлинности на базе протокола Kerberos

Как и в случае с протоколом NTLM, браузер клиента делает анонимный запрос HTTP GET, используя имя компьютера (FQDN либо псевдоним).
Сервер фронтального плана выдает ошибку 401.2 и сообщение — WWW-Authenticate: Согласуйте заголовок и/либо параметр WWW-Authenticate. Заголовок Kerberos значит, что имеется поддержка проверки подлинности на базе протокола Kerberos. Вы должны настроить его для серверов фронтального плана в центре администрирования, о чем я писал выше.
Клиент связывается с Центром рассредотачивания ключей в контроллере домена и запрашивает билет для SPN, который основан на инфы, отправленной браузером клиента, представляющей собой имя компьютера.
Если Центр рассредотачивания ключей обнаруживает совпадающее имя SPN, он зашифровывает билет и возвращает его.
Браузер клиента делает средство проверки подлинности и посылает его с билетом службы в IIS-сервер, который, в свою очередь, дешифрирует билет, определяет достоверность и инспектирует возможности (перечень контроля доступа) на запрашиваемый ресурс.
Если доступ разрешен, метабаза IIS, через службу веб-приложений, связывается с сервером SQL, а служба запрашивает билет для сервера SQL Server от Центра рассредотачивания ключей.
Если имя SPN найдено, Центр рассредотачивания ключей возвращает билет, применяемый веб- приложением для запроса базы данных содержимого, и при помощи делегирования персонифицирует юзера.
Сервер 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 состоит из 3-х частей: класс службы, определяющий тип службы, имя компьютера, на котором запущена служба, и порт. Сведя все составляющие вкупе, получаем последующий синтаксис service class/host: port. Для среды SharePoint 2-мя подходящими именами являются HTTP и MSSqlSvc. Имена службы не являются случайными и определяются как особые псевдонимы для службы. Имя компьютера — имя FQDN либо NetBIOS, дополнительно включающие порт. При регистрации имен SPN, рекомендуется регистрировать SPN как для имен компьютера NetBIOS, так и FQDN, так как, невзирая на применяемый клиентом метод, они могут получить доступ к ресурсам на мотивированном компьютере.

Ранее я гласил, что пока вы не запустите пул приложений под учетной записью сетевой службы, вам придется регистрировать имена SPN. Это разъясняется тем, что когда компьютер заходит в домен Active Directory, имена SPN создаются автоматом для учетной записи компьютера в формате HOST/ и HOST/. Ввиду того, что учетная запись сетевой службы выступает как компьютер в сети, имена 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/:1433 и MSSQLSvc//:1433, предполагая, что ваш экземпляр будет использовать стандартный порт — 1433. Хотя вы сможете использовать средство setspn либо ADSIEdit для установки SPN, setspn обычно является наилучшим вариантом, так как оно инспектирует синтаксис. При использовании ADSIEdit, напротив, вы вписываете имена SPN конкретно в атрибут servicePrincipalName. Для сотворения 2-ух имен SPN сделайте команду setspn-A MSSQLSvc/:1433 and setspn-A MSSQLSvc/:1433 , где именованием юзера является учетная запись службы 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, которые нужно зарегистрировать для каждого ресурса.

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

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

Нужно держать в голове о нескольких вещах при настройке имен SPN. Во-1-х, имена SPN регистрируются для веб-узла с поддержкой SharePoint аналогичным образом, что и для веб-узла IIS. Принципиально указать правильное имя компьютера и учетную запись, под которой работает пул приложений для каждого узла. Если вы используете несколько заголовков узла, удостоверьтесь в том, что имена SPN заданы для их всех. Во-2-х, необязательно указывать порты для HTTP и HTTPS, но вы должны указать хоть какой пользовательский порт. И в-3-х, вам придется настроить несколько дополнительных зависимостей, к примеру, изменение реестра для метабазы 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%System32inetsrvconfigApplicationHost.config (сейчас графический интерфейс недоступен). Соответственная запись показана ниже.

useAppPoolCredentials=»true» />

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

Также необходимо вспомнить еще об одной детали; если в вашей конфигурации употребляется олицетворение подлинности ( в web.config) также сборочный поток в встроенном режиме, вы должны установить значение атрибута validateIntegratedModeConfiguration в «false» либо запустить странички .aspx на конвейере в традиционном режиме.

Заключение

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

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.