Экспорт (0) Печать
Развернуть все

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

SharePoint 2010
 

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

Последнее изменение раздела: 2011-09-08

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

ВажноImportant
Настройка для веб-приложений классической проверки подлинности Windows с помощью протокола Kerberos необходима, чтобы сценарии работали ожидаемым образом. В некоторых сценариях может использоваться проверка Windows на основе утверждений, но в этом случае результаты могут не соответствовать описанным в следующих сценариях.
ПримечаниеNote
При установке на сервере Windows Server 2008 может понадобиться установить следующее исправление для проверки подлинности Kerberos:
Проверка подлинности Kerberos закончилась неудачей с кодом ошибки 0X80090302 или 0x8009030f на компьютере с операционной системой Windows Server 2008 или Windows Vista при использовании алгоритма AES (http://support.microsoft.com/kb/969083/ru-ru)

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

  • Настройка двух веб-приложений с зонами по умолчанию, использующих для проверки подлинности протокол 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 для веб-приложений в своей среде. В этом примере используются 2 веб-приложения, http://portal и http://teams:5555, которые оба разрешаются в один виртуальный IP-адрес балансировки сетевой нагрузки (192.168.24.140/24)

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

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

Изображение записи DNS

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

Изображение записи DNS
ПримечаниеNote
Чтобы проверка подлинности Kerberos успешно работала в средах, где несколько веб-приложений работает с заголовками узлов и отдельными специальными учетными записями служб, важно обеспечить, чтобы записи DNS были записями A, а не псевдонимами CNAME. Объяснение известной проблемы использования CNAME с веб-приложениями, поддерживающими Kerberos, см. в статье Известные проблемы, связанные с конфигурацией Kerberos (SharePoint Server 2010).

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

В нашем примере два веб-приложения 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

ПримечаниеNote
См. в приложении объяснение рекомендаций настройки имен участников службы с номером порта и без него для HTTP-служб, работающих не через порты по умолчанию (80, 443). Технически правильным способом ссылки на HTTP-службу, работающую через нестандартные порты, является добавление номера порта в имя участника службы, но из-за известных проблем, описанных в приложении, нужно настроить имена участников службы и без порта. Обратите внимание, что в нашем примере имена участников службы без указания порта для веб-приложения teams не означает возможность доступа к службам через порты по умолчанию (80, 443).

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

 

Узел 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

ВажноImportant
Не настраивайте имена участников службы с HTTPS, даже если веб-приложение использует SSL.

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

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

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

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

В зависимости от сценария некоторые функции в 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

ПримечаниеNote
Может показаться избыточным настраивать делегирование службы самой себе, например делегирование учетной записи службы портала приложению-службы портала, но это необходимо в сценариях, где служба работает на нескольких серверах. Это позволяет реализовать сценарий, в котором одному серверу может понадобиться делегировать другому серверу, на котором работает эта же служба, например в случае обработки запроса в WFE и средства просмотра RSS, использующего в качестве источника данных локальное веб-приложение. В зависимости от топологии и конфигурации фермы существует возможность обслуживания запроса RSS другим сервером, для чего потребуется правильная работа делегирования.

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

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

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

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

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

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

После настройки 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

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

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

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

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

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

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

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

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

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

 

Параметр Веб-приложение 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 должен появиться в списке зон для веб-приложения.

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

Проверка включения проверки подлинности 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.

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

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

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

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

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

Чтобы использовать проверку подлинности 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 на вкладке Безопасность выберите Местная интрасеть и нажмите кнопку Другой. Прокрутите вниз и убедитесь, что установлен флажок Автоматический вход в сеть только в зоне интрасети.

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

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

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

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

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

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

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 — это бесплатный анализатор трафика 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 — это бесплатный анализатор сетевых пакетов от Майкрософт, который можно загрузить в Центре загрузки Майкрософт: 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.

Чтобы четко показать имена участников служб, запрашиваемые при обращении клиента к ресурсу, защищенному 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.

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

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

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

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

ПримечаниеNote
Если настроено приложение профиля пользователя (UPA) и выполнен обход хранилища профилей, не забудьте настроить соответствующие разрешения для UPA, чтобы разрешить учетной записи доступа к контенту доступ к данным профиля. Если разрешения для UPA не настроены, журналы обхода будут содержать ошибки, показывающие, что средству обхода не удалось получить доступ к службе профиля, так как при попытке доступа к службе был получен ответ HTTP 401. Этот ответ возвращается не из-за Kerberos, но из-за того, что у учетной записи доступа к контенту нет разрешений на чтение данных профиля.

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

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

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

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

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

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

Была ли вам полезна эта информация?
(1500 символов осталось)
Спасибо за ваш отзыв
Корпорация Майкрософт проводит интернет-опрос, чтобы выяснить ваше мнение о веб-сайте MSDN. Если вы желаете принять участие в этом интернет-опросе, он будет отображен при закрытии веб-сайта MSDN.

Вы хотите принять участие?
Показ:
© 2014 Microsoft