Настройка проверки подлинности Kerberos. Базовая конфигурация (SharePoint Server 2010)

 

Применимо к: SharePoint Server 2010

Последнее изменение раздела: 2017-01-18

В первом сценарии для двух веб-приложений SharePoint Server 2010 будет настроено использование протокола Kerberos для проверки подлинности запросов клиентов. С целью демонстрации для одного веб-приложения будет настроено использование стандартных портов (80/443), а для другого — нестандартного порта (5555). Этот сценарий будет основой всех остальных сценариев, в которых предполагается выполнение описанных ниже действий.

В этом сценарии выполняются следующие действия:

• Настройка двух веб-приложений с зонами по умолчанию, использующих для проверки подлинности протокол Kerberos

• Создание двух тестовых семейств сайтов, по одному в каждом веб-приложении

• Проверка настройки IIS для веб приложения

• Проверка возможности выполнения веб-приложением проверки подлинности клиентов и использования для нее протокола Kerberos

• Настройка веб-части просмотра RSS для отображения RSS-каналов и удаленного веб-приложения

• Обход каждого веб-приложения и проверка поиска контента в каждом тестовом семействе сайтов

Контрольный список конфигурации

Область конфигурации	Описание
DNS	Зарегистрируйте запись DNS A для виртуального IP-адреса (VIP) балансировки сетевой нагрузки веб-приложений
Active Directory	Создайте учетные записи служб для пула приложений IIS веб-приложений Зарегистрируйте имена участников службы для веб-приложений в учетной записи службы, созданной для пула приложений IIS веб-приложений Настройте ограниченное делегирование Kerberos для учетных записей служб
Веб-приложение SharePoint	Создайте управляемые учетные записи SharePoint Server Создайте приложение-службу поиска SharePoint Создайте веб-приложения SharePoint
IIS	Убедитесь, что проверка подлинности Kerberos включена Убедитесь, что проверка подлинности в режиме ядра отключена Установите сертификаты для SSL
Клиент Windows 7	Убедитесь, что URL-адреса находятся в зоне интрасети или что для зоны настроена автоматическая интегрированная проверка подлинности Windows
Конфигурация брандмауэра	Откройте порты брандмауэра, чтобы пропускать трафик HTTP через порты по умолчанию и через порты, не являющиеся портами по умолчанию Убедитесь, что клиенты могут подключаться к портам Kerberos в Active Directory
Протестируйте проверку подлинности для браузера	Убедитесь, что проверка подлинности правильно работает в браузере Проверьте сведения о входе в систему в журнале событий безопасности веб-сервера С помощью средств стороннего производителя проверьте правильность настройки проверки подлинности Kerberos
Проверьте индекс и запросы поиска SharePoint Server	Проверьте доступность браузера с серверов индекса Передайте пример контента и выполните обход Проверьте поиск
Проверьте делегирование WFE	Настройте источники RSS-каналов для каждого семейства веб-сайтов Добавьте веб-части представления RSS на главную страницу каждого семейства сайтов

Пошаговые инструкции по настройке

Настройка DNS

Настройте DNS для веб-приложений в своей среде. В этом примере используются 2 веб-приложения, http://portal и http://teams:5555, которые оба разрешаются в один виртуальный IP-адрес балансировки сетевой нагрузки (192.168.24.140/24)

Общие сведения о настройке DNS см. в статье, описывающей управление записями DNS (Возможно, на английском языке).

Веб-приложения SharePoint Server

http://portal — настройте новую запись DNS A для веб-приложения портала. В этом примере узел "portal" настроен для разрешения виртуального IP-адреса балансировки сетевой нагрузки.

http://teams:5555 — настройте новую запись DNS A для веб-приложения группы

Настройка Active Directory

Далее нужно настроить в используемой среде учетные записи Active Directory для веб-приложений. Рекомендуется настроить каждое веб-приложение так, чтобы оно работало в своем собственном пуле приложений IIS с собственным контекстом безопасности (удостоверение пула приложений).

Учетные записи службы приложения-службы SharePoint

В нашем примере два веб-приложения SharePoint Server работают в двух отдельных пулах приложений IIS, используя удостоверения своих собственных пулов приложений.

Веб-приложения (зона по умолчанию)	Удостоверение пула приложений IIS
http://portal	vmlab\svcPortal10App
http://teams:5555	vmlab\ svcTeams10App

Имена участников службы

Для каждой учетной записи службы настройте набор имен участников службы, сопоставляемых именам узлов DNS, назначенным каждому веб-приложению.

Для настройки нового имени участника службы используйте SetSPN, средство командной строки Windows Server 2008. Полное объяснение использования SetSPN см. в статье Setspn (Возможно, на английском языке). Сведения об улучшениях SetSPN в Windows Server 2008 см. в статье, описывающей новые возможности SETSPN.EXE в Windows Server 2008 (Возможно, на английском языке).

Все веб-приложения SharePoint Server, независимо от номера порта, используют следующий формат имени участника службы:

• HTTP/<имя узла DNS>

• HTTP/<Полное доменное DNS-имя>

Пример:

• HTTP/portal

• HTTP/portal.vmlab.local

Для веб-приложений, работающих через нестандартные порты (отличающиеся от 80/443), зарегистрируйте дополнительные имена участников службы с номером порта:

• HTTP/<имя узла DNS>:<порт>

• HTTP/<Полное доменное DNS-имя>:<порт>

Пример:

• HTTP/teams:5555

• HTTP/teams.vmlab.local:5555

В нашем примере для двух учетных записей, созданных на предыдущем шаге, настроены следующие имена участников службы:

Узел DNS	Удостоверение пула приложений IIS	Имена участников службы
Portal.vmlab.local	vmlab\svcPortal10App	HTTP/portal HTTP/portal.vmlab.local
Teams.vmlab.local	vmlab\ svcTeams10App	HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555

Для создания имен участников службы были выполнены следующие команды:

SetSPN -S HTTP/Portal vmlab\svcportal10App

SetSPN -S HTTP/Portal.vmlab.local vmlab\svcportal10App

SetSPN -S HTTP/Teams vmlab\svcTeams10App

SetSPN -S HTTP/Teams.vmlab.local vmlab\ svcTeams10App

SetSPN -S HTTP/Teams:5555 vmlab\ svcTeams10App

SetSPN -S HTTP/Teams.vmlab.local:5555 vmlab\ svcTeams10App

В данном примере использован новый параметр командной строки, -S, введенный в Windows Server 2008, проверяющий существование имени участника службы перед созданием имени участника службы для учетной записи. Если имя участника службы уже существует, новое имя участника службы не будет создано и появится сообщение об ошибке.

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

Имена участников службы и SSL

Имена участников службы Kerberos часто путают с URL-адресами веб-приложений http, так как синтаксис форматов имен участников службы и URI очень похож, но важно понимать, что это два отдельных и уникальных понятия. Имена участников службы Kerberos используются для идентификации службы, и если эта служба является http-приложением, используется схема служб "HTTP" независимо от того, используется ли для доступа к службе SSL или нет. Это означает, что даже при доступе к веб-приложению с помощью "https://someapp" не следует использовать имя участника службы HTTPS, например "HTTPS/someapp".

Настройка ограниченного делегирования Kerberos для учетных записей компьютеров и служб

В зависимости от сценария некоторые функции в SharePoint Server 2010 могут потребовать правильной работы ограниченного делегирования. Например, если веб-часть просмотра RSS настроена для отображения RSS-канала из источника, прошедшего проверку подлинности, для использования канала источника понадобится делегирование. В других ситуациях может потребоваться настроить ограниченное делегирование, чтобы разрешить приложениям-службам (таким как службы Excel) делегировать удостоверение клиента серверным системам.

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

На следующей схеме принципиально показывается, что будет настраиваться в этом сценарии:

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

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

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

Тип участника	Имя участника	Делегаты для службы
Пользователь	svcPortal10App	HTTP/Portal HTTP/Portal.vmlab.local HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555
Пользователь	svcTeams10App	HTTP/Portal HTTP/Portal.vmlab.local HTTP/Teams HTTP/Teams.vmlab.local HTTP/Teams:5555 HTTP/Teams.vmlab.local:5555

Чтобы настроить делегирование, можно использовать оснастку "Active Directory — пользователи и компьютеры". Щелкните правой кнопкой мыши каждую учетную запись службы и откройте диалоговое окно свойств. В этом диалоговом окне появится вкладка для делегирования (обратите внимание, что эта вкладка появляется, только если объекту назначено имя участника службы, компьютеры обладают именем участника службы по умолчанию). На вкладке делегирования выберите Доверять этому пользователю делегирование указанных служб, затем выберите Использовать любой протокол проверки подлинности.

Нажмите кнопку Добавить, чтобы добавить службы, делегирование которым будет разрешено для пользователя (учетной записи службы). Для выбора имени участника службы найдите объект, к которому относится имя участника службы. В нашем случае выполняется попытка делегирования HTTP-службе, что означает выполнение поиска для учетной записи службы пула приложений IIS, которому имя участника службы было назначено на предыдущем шаге.

В диалоговом окне Выбор пользователей или компьютеров щелкните Пользователи и компьютеры, найдите учетные записи службы пула приложений IIS (в нашем примере vmlab\svcPortal10App и vmlab\svcTeams10App), а затем нажмите кнопку ОК.

Будет предложено выбрать службы, назначенные объектам, по имени участника службы.

В диалоговом окне Добавление служб нажмите кнопку Выбрать все, а затем нажмите кнопку ОК. Обратите внимание, что при возвращении в диалоговое окно делегирования не будут видны все выбранные имена участников служб. Чтобы просмотреть все выбранные имена участников служб, установите флажок Развернутый в нижнем левом углу.

Выполните эти действия для каждой учетной записи службы в среде, для которой требуется делегирование. В нашем примере это список учетных записей служб

Настройка SharePoint Server

После настройки Active Directory и DNS приходит пора создать веб-приложение в ферме SharePoint Server 2010. В этой статье предполагается, что установка SharePoint Server к этому моменту выполнена, а топология фермы и поддерживающая инфраструктура, например балансировка нагрузки, настроены. Дополнительные сведения об установке и настройке фермы SharePoint см. в статье, описывающей развертывание SharePoint Server 2010.

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

Перед созданием своих веб-приложений настройте учетные записи служб, созданные на предыдущих этапах, как управляемые учетные записи в SharePoint Server. Заблаговременное выполнение этого действия позволит пропустить его при создании самих веб-приложений.

Действия для настройки управляемой учетной записи

1. В центре администрирования щелкните элемент Безопасность.

2. В разделе Общая безопасность щелкните элемент Настройка управляемых учетных записей.

3. Щелкните Зарегистрировать управляемую запись и создайте управляемую учетную запись для каждой учетной записи службы. В этом примере мы создали пять управляемых учетных записей служб:

   Учетная запись	Назначение
   VMLAB\svcSP10Search	Учетная запись службы поиска SharePoint
   VMLAB\svcSearchAdmin	Учетная запись службы администрирования SharePoint
   VMLAB\svcSearchQuery	Учетная запись службы запросов SharePoint
   VMLAB\svcPortal10App	Учетная запись пула приложений IIS веб-приложения Portal
   VMLAB\svcTeams10App	Учетная запись пула приложений IIS веб-приложения Teams

   Примечание

   Управляемые учетные записи SharePoint Server 2010 не совпадают с управляемыми учетными записями служб Windows Server 2008 R2 Active Directory.

Создание приложения-службы поиска SharePoint Server

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

Создание веб-приложения

В центре администрирования перейдите в элемент Управление веб-приложениями раздела Управление приложениями. На панели инструментов выберите Создать и создайте веб-приложение. Убедитесь в выполнении следующих настроек:

• Выберите Классический режим проверки подлинности.

• Настройте порт и заголовок узла для каждого веб-приложения.

• Выберите Согласование в качестве поставщика проверки подлинности.

• В пуле приложений выберите Создать пул приложений и выберите управляемую учетную запись, созданную в предыдущем шаге.

В этом примере были созданы два веб-приложения со следующими настройками:

Параметр	Веб-приложение http://Portal	Веб-приложение http://Teams
Проверка подлинности	Классический режим	Классический режим
Веб-сайт IIS	Имя: SharePoint – Portal – 80 Порт: 80 Заголовок узла: Portal	Имя: SharePoint – Teams – 5555 Порт: 80 Заголовок узла: Teams
Конфигурация безопасности	Поставщик проверки подлинности: согласование Разрешить анонимный доступ: нет Использовать SSL: нет	Поставщик проверки подлинности: согласование Разрешить анонимный доступ: нет Использовать SSL: нет
Публичный URL-адрес	http://Portal:80	http://Teams:5555
Пул приложений	Имя: SharePoint – Portal80 Учетная запись безопасности: vmlab\svcPortal10App	Имя: SharePoint – Teams5555 Учетная запись безопасности: vmlab\svcTeams10App

При создании нового веб-приложения также создается новая зона, зона по умолчанию, настроенная для использования поставщиком проверки подлинности Windows. Поставщика и его настройки для зоны можно видеть при управлении веб-приложением, сначала выбирая веб-приложение, затем щелкая Поставщики проверки подлинности на панели инструментов. В диалоговом окне поставщиков проверки подлинности перечислены все зоны для выбранного веб-приложения вместе с поставщиком проверки подлинности для каждой зоны. После выбора зоны появятся параметры проверки подлинности для этой зоны.

При неправильной настройке параметров Windows и неправильном выборе NTLM при создании веб-приложения, можно использовать диалоговое окно правки проверки подлинности для зоны, чтобы переключить для зоны значение с "NTLM" на "Согласование". Если в качестве режима проверки подлинности не был выбран классический режим, необходимо либо создать новую зону, расширяя веб-приложение на новый веб-сайт IIS, либо удалить и заново создать веб-приложение.

Создание семейств веб-сайтов

Чтобы проверить правильность работы проверки подлинности, понадобится создать хотя бы одно семейство веб-сайтов в каждом веб-приложении. Создание и настройка семейства веб-сайтов не повлияет на функциональные возможности Kerberos, поэтому следуйте существующим указаниям по созданию семейства веб-сайтов, приведенным в статье, описывающей создание семейства веб-сайтов (SharePoint Foundation 2010).

Для этого примера было настроено два семейства веб-сайтов:

Веб-приложение	Путь семейства веб-сайтов	Шаблон семейства веб-сайтов
http://portal	/	Портал публикации
http://teams:5555	/	Сайт группы

Создание альтернативных сопоставлений доступа

Для веб-приложения портала будет настроено использование HTTPS, а также HTTP, чтобы продемонстрировать работу делегирования с защищенными службами SSL. Чтобы настроить SSL, веб-приложению портала понадобится второе сопоставление для альтернативного доступа SharePoint Server (AAM) для конечной точки HTTPS.

Действия для настройки сопоставлений для альтернативного доступа

1. В центре администрирования выберите элемент Управление приложениями.

2. В элементе Веб-приложения щелкните настроить сопоставления для альтернативного доступа.

3. В раскрывающемся списке Выбор набора сопоставлений альтернативного доступа выберите Изменить набор сопоставлений альтернативного доступа.

4. Выберите веб-приложение портала.

5. Щелкните на верхней панели инструментов Изменить общедоступные URL-адреса.

6. В свободной зоне добавьте для веб-приложения URL-адрес https. Этот URL-адрес будет именем сертификата SSL, которое будет создано в следующих шагах.

7. Нажмите кнопку Сохранить.

   URL-адрес HTTPS должен появиться в списке зон для веб-приложения.

Конфигурация IIS

Установка сертификатов SSL

Для каждого веб-приложения, использующего SSL, понадобится настроить сертификат SSL для каждого SharePoint Server, на котором размещена служба веб-приложения. И снова тема настройки сертификата SSL и доверия сертификата находится вне рамок этого документа. Ссылки на материалы о настройке сертификатов SSL в IIS см. в разделе "Настройка" данного документа.

Убедитесь, что проверка подлинности Kerberos включена

Проверка включения проверки подлинности Kerberos на веб-сайте

1. Откройте диспетчер IIS.

2. Выберите для проверки веб-сайт IIS.

3. В режиме просмотра возможностей IIS дважды щелкните Проверка подлинности.

4. Выберите параметр Проверка подлинности Windows, который должен быть включен.

5. Справа в разделе Действия выберите Поставщики. Убедитесь, что вверху списка находится строка Согласование.

Проверка отключения проверки подлинности в режиме ядра

Проверка подлинности в режиме ядра в SharePoint Server 2010 не поддерживается. Для всех веб-приложений SharePoint Server следует по умолчанию отключить проверку подлинности в режиме ядра на всех соответствующих веб-сайтах IIS. Даже если веб-приложение было настроено на существующем веб-сайте IIS, SharePoint Server отключает проверку подлинности в режиме ядра при предоставлении нового веб-приложения для существующего сайта IIS.

Действия для проверки отключения проверки подлинности в режиме ядра

1. Откройте диспетчер IIS.

2. Выберите для проверки веб-сайт IIS.

3. В режиме просмотра возможностей IIS дважды щелкните Проверка подлинности.

4. Выберите параметр Проверка подлинности Windows, который должен быть включен.

5. Щелкните Дополнительные параметры.

6. Убедитесь, что отключены и EAP, и проверка подлинности в режиме ядра.

Настройка брандмауэра

Перед тестированием проверки подлинности убедитесь, что клиенты могут получать доступ к веб-приложениям SharePoint Server, используя настроенные порты HTTP. Кроме того, убедитесь, что клиенты могут проходить проверку подлинности в Active Directory и запрашивать билеты Kerberos от KDC через стандартные порты Kerberos.

Откройте порты брандмауэра, чтобы пропускать трафик HTTP через порты по умолчанию и через порты, не являющиеся портами по умолчанию

Обычно, чтобы разрешить получение запросов через порты TCP 80 и TCP 443, нужно настроить брандмауэр на каждом интерфейсном веб-сервере. Откройте брандмауэр Windows в режиме повышенной безопасности и перейдите к следующим правилам для входящих подключений:

• Службы Интернета (входящий трафик HTTP)

• Службы Интернета (входящий трафик HTTPS)

Убедитесь, что в используемой среде открыты соответствующие порты. В нашем примере для доступа к SharePoint Server используется HTTP (порт 80), поэтому данное правило было включено.

Кроме того, нам нужно открыть порт, не являющийся портом по умолчанию, но используемый в нашем примере (TCP 5555). Если веб-сайты работают через нестандартные порты, также понадобится разрешить трафик HTTP через эти порты.

Обеспечение для клиентов возможности подключаться к портам Kerberos в Active Directory

Чтобы использовать проверку подлинности Kerberos, клиентам понадобится запросить билеты предоставления билета (TGT) и билеты (ST) у центра распространения ключей (KDC), используя UDP или TCP, порт 88. По умолчанию при установке роли Active Directory в Windows Server 2008 и более поздних версиях для этой роли будут настроены следующие правила входящих подключений, чтобы разрешить это взаимодействие по умолчанию:

• Центр распространения ключей Kerberos — PCR (TCP-входящие)

• Центр распространения ключей Kerberos — PCR (UDP-входящие)

• Центр распространения ключей Kerberos (TCP-входящие)

• Центр распространения ключей Kerberos (UDP-входящие)

Убедитесь, что в используемой среде эти правила включены и что клиенты могут подключаться к KDC (контроллер домена), используя порт 88.

Тестирование проверки подлинности для браузера

Теперь, после настройки Active Directory, DNS и SharePoint Server, можно протестировать правильность настройки проверки подлинности Kerberos, перейдя в свои веб-приложения. При тестировании в браузере убедитесь в выполнении следующих условий:

1. Тестовый пользователь вошел в систему компьютера Windows XP, Vista или Windows 7, присоединенного к домену, в котором установлен SharePoint Server, или вошел в домен, являющийся доверенным для домена SharePoint Server.

2. Тестовый пользователь использует Internet Explorer 7.0 или более поздней версии (Internet Explorer 6.0 больше не поддерживается в SharePoint Server 2010, см. статью, описывающую планирование поддержки браузеров (SharePoint Server 2010)).

3. В браузере включена встроенная проверка подлинности Windows. На вкладке Дополнительно в окне Свойства обозревателя убедитесь, что в разделе "Безопасность" установлен флажок Разрешить встроенную проверку подлинности Windows*:

4. Местная интрасеть настроена для автоматического входа клиентов в систему. В свойствах Internet Explorer на вкладке Безопасность выберите Местная интрасеть и нажмите кнопку Другой. Прокрутите вниз и убедитесь, что установлен флажок Автоматический вход в сеть только в зоне интрасети.

   Примечание

   Можно настроить автоматический вход и для других зон, но тема рекомендаций для зон безопасности IE находится вне рамок данной статьи. В настоящей демонстрации для всех тестов будет использоваться зона интрасети.

5. Убедитесь, что флажок Автоматически определять принадлежность к интрасети установлен в пункте Свойства обозревателя->Безопасность->Местная интрасеть->Узлы.

6. При использовании полного доменного имени для доступа к веб-приложениям SharePoint Server убедитесь, что полные доменные имена включены в зону интрасети, или явно задайте включение с помощью подстановочного знака (например, “*.vmlab.local”).

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

Журналы безопасности интерфейсных веб-серверов

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

KList

KList — это служебная программа командной строки, включенная в стандартную установку Windows Server 2008 и Windows Server 2008 R2, которую можно использовать для вывода списка и очистки билетов Kerberos на данном компьютере. Для запуска KLIST откройте окно командной строки в Windows Server 2008 и введите Klist.

Если нужно очистить кэш билетов, запустите Klist с необязательным параметром purge: Klist purge

KerbTray

KerbTray — это бесплатная служебная программа, входящая в комплект ресурсов Windows Server 2000 Resource Kit Tool, который можно установить на клиентский компьютер для просмотра кэша билетов Kerberos. Загрузите и установите, используя ссылку Windows 2000 Resource Kit Tool: Kerbtray.exe (Возможно, на английском языке). После установки выполните следующие действия:

1. Перейдите на веб-сайты, использующие проверку подлинности Kerberos.

2. Запустите KerbTray.exe.

3. Просмотрите кэш билетов Kerberos, щелкнув правой кнопкой мыши значок KerbTray на панели задач и выбрав List Tickets (Список билетов).

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

   URL-адрес веб-сайта	Имя участника-службы
   http://portal	HTTP/Portal.vmlab.local
   http://teams:5555	HTTP/Teams.vmlab.local

Fiddler

Fiddler — это бесплатный анализатор трафика HTTP, который можно загрузить со следующего адреса: http://www.fiddler2.com/fiddler2/ (Возможно, на английском языке). Fiddler позволяет просмотреть, как клиент и сервер согласовывают проверку подлинности Kerberos, а также как клиент передает серверу билеты Kerberos в HTTP-заголовках каждого запроса. Чтобы проверить правильность работы проверки подлинности Kerberos с помощью fiddler, выполните следующие действия:

1. Загрузите и установите Fiddler (www.fiddlertool.com (Возможно, на английском языке)) на клиентском компьютере.

2. Выйдите из системы настольного компьютера и войдите обратно, чтобы очистить все кэшированные подключения к веб-серверу и заставить браузер согласовать проверку подлинности Kerberos и выполнить проверку подлинности.

3. Запустите Fiddler.

4. Откройте Internet Explorer и отройте веб-приложение (http://portal в нашем примере).

В Fiddler должны появиться запросы к интерфейсному веб-серверу SharePoint Server и его ответы.

Первый HTTP 401 — это попытка браузера выполнить запрос GET без проверки подлинности. В ответе сервер отправляет обратно "HTTP 401 – unauthorized", показывая в этом ответе, какие методы проверки подлинности он поддерживает. В следующем запросе клиент повторяет отправку предыдущего запроса, но в этот раз в заголовках запроса передается билет для веб-приложения. При успешной проверке подлинности сервер отправит обратно запрошенный ресурс.

NetMon 3.4

NetMon 3.4 — это бесплатный анализатор сетевых пакетов от Майкрософт, который можно загрузить в Центре загрузки Майкрософт: Microsoft Network Monitor 3.4 (Возможно, на английском языке).

NetMon позволяет увидеть весь обмен запросами и ответами TCP с KDC и веб-серверами SharePoint Server, создавая полное представление о трафике, образующем полный запрос проверки подлинности. Чтобы проверить работу проверки подлинности Kerberos с помощью netmon, выполните следующие действия:

1. Загрузите и установите NetMon 3.4 (Microsoft Network Monitor 3.4 (Возможно, на английском языке)).

2. Выйдите из системы клиента и снова зайдите, чтобы очистить кэш билетов Kerberos. Дополнительно можно использовать KerbTray, чтобы очистить кэш билетов, щелкнув правой кнопкой мыши значок KerbTray и выбрав Purge Tickets (Очистить билеты).

3. Запустите NetMon в режиме администратора. Щелкните правой кнопкой мыши ярлык NetMon и выберите Запуск от имени администратора.

4. Запустите новый захват интерфейсов, подключающихся к контроллеру Active Directory используемой среды и интерфейсным веб-серверам.

5. Откройте Internet Explorer и перейдите в веб-приложение.

6. После отображения веб-сайта остановите захват и добавьте фильтр дисплея, чтобы показать кадры для проверки подлинности Kerberos и трафика HTTP.

7. Окно кадров должно содержать как трафик HTTP, так и трафик KerberosV5.

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

Чтобы четко показать имена участников служб, запрашиваемые при обращении клиента к ресурсу, защищенному SSL, можно использовать средство, подобное netmon, захватывающее трафик между клиентом и сервером, и проверить запросы билетов Kerberos.

1. Либо выйдите и снова войдите в систему клиентского компьютера, либо очистите все кэшированные билеты Kerberos с помощью KerbTray.

2. Запустите новый захват NetMon на клиентском компьютере. Не забудьте запустить NetMon с привилегиями администратора.

3. Перейдите в веб-приложение с помощью SSL (в этом примере https://portal.)

4. Остановите захват NetMon и проверьте трафик KerberosV5. Инструкции о фильтрации отображения захвата см. в разделе NetMon 3.4 этой статьи.

5. Найдите запрос TGS, отправленный клиентом. В запросе должно быть видно имя участника службы, запрошенное в параметре "Sname".

   Обратите внимание, что "Sname" — это HTTP/portal.vmlab.local, а не HTTPS/portal.vmlab.local.

Проверка индекса и запросов поиска SharePoint Server

Проверка доступности браузера с серверов индекса

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

Передача примера контента и выполнение обхода

В каждом семействе веб-сайтов передайте "затравочный" документ (который легко определяется при поиске) в библиотеку документов семейства сайтов. Например, создайте текстовый документ, содержащий слова "alpha, beta, delta", и сохраните его в библиотеке документов каждого семейства сайтов.

Затем перейдите в центр администрирования SharePoint и запустите полный обход для источника контента "Локальные сайты SharePoint" (который по умолчанию будет содержать два тестовых семейства веб-сайтов).

Проверка поиска

Если индексирование прошло успешно, искомые элементы должны появиться в индексе и журнал обхода не должен содержать ошибок.

Далее зайдите в каждое семейство веб-сайтов и выполните поиск затравочного документа. Каждый запрос поиска в семействе веб-сайтов должен возвращать переданный загрузочный документ.

Тестирование делегирования для интерфейсного веб-сервера

В качестве последнего шага этого сценария веб-часть просмотра RSS используется для каждого семейства веб-сайтов, чтобы гарантировать работу как локального, так и удаленного делегирования.

Настройка источников RSS-каналов для каждого семейства веб-сайтов

Для приложения портала нужно включить RSS-каналы для семейства веб-сайтов. Чтобы включить RSS-каналы, следуйте инструкциям в статье, описывающей управление RSS-каналами на сайте Office.com.

Включив RSS-каналы, создайте новый настраиваемый список и добавьте элемент списка для тестирования. Перейдите в меню панели инструментов "Список" и щелкните RSS-канал для просмотра RSS-канала. Скопируйте URL-адрес канала, чтобы использовать его в последующих шагах.

Выполните этот шаг для каждого семейства веб-сайтов.

Добавление веб-части представления RSS на главную страницу каждого семейства веб-сайтов

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