Настройка проверки подлинности Windows на сервере отчетов

Статья
06/13/2017

По умолчанию службы Reporting Services принимают запросы, в которых заданы параметры проверки подлинности NTLM или Согласования. Если в развертывание входят клиентские приложения и браузеры, в которых используются поставщики безопасности, то можно использовать значения по умолчанию без дополнительной настройки. Если нужно использовать другого поставщика безопасности для встроенной безопасности Windows (например, требуется применять протокол Kerberos напрямую) или если значения по умолчанию были изменены, и нужно восстановить первоначальные настройки, то можно использовать сведения данного раздела, чтобы указать настройки проверки подлинности на сервере отчетов.

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

Должны выполняться также следующие дополнительные условия.

Свойству атрибута AuthenticationType файлов SeportServer.config должно быть задано значение RSWindowsNegotiate, RSWindowsKerberos или RSWindowsNTLM. По умолчанию файл конфигурации RSReportServer.config включает настройку RSWindowsNegotiate, если учетной записью службы сервера отчетов является учетная запись NetworkService или LocalSystem. В противном случае используется настройка RSWindowsNTLM. Можно добавить RSWindowsKerberos, если имеются приложения, в которых используется только проверка подлинности протокола Kerberos.

Важно!

Использование RSWindowsNegotiate приведет к ошибке проверки подлинности протокола Kerberos, если служба сервера отчетов настроена на запуск с доменной учетной записью пользователя и для учетной записи не зарегистрировано имя участника-службы (SPN). Дополнительные сведения см. в разделе Разрешение ошибок проверок подлинности протокола Kerberos при соединении с сервером отчетов в этом разделе.
Платформа ASP.NET должна быть настроена для проверки подлинности Windows. По умолчанию файлы Web.config для веб-службы сервера отчетов и диспетчера отчетов включают <параметр authentication mode="Windows".> Если изменить его на <authentication mode="Forms">, проверка подлинности Windows для служб Reporting Services выполнена не будет.
Файлы Web.config для веб-службы сервера отчетов и диспетчера отчетов должны иметь <идентификатор impersonate= "true" />.
Клиентское приложение или браузер должны поддерживать встроенную безопасность Windows.

Чтобы изменить настройки проверки подлинности сервера отчетов, измените XML-элементы и значения в файле RSReportServer.config. Чтобы реализовать определенные сочетания, можно копировать и вставить примеры из этого раздела.

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

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

Расширенная защита для проверки подлинности

Начиная с версии SQL Server 2008 R2 доступна поддержка расширенной защиты для проверки подлинности. Функционал SQL Server поддерживает привязку каналов и служб для повышения уровня защиты проверки подлинности. Функционал Reporting Services следует использовать в ОС с поддержкой расширенной защиты. Конфигурация служб Reporting Services для расширенной защиты определяется параметрами файла RSReportServer.config. Это можно сделать как в текстовом редакторе, так и при помощи средств WMI API. Дополнительные сведения см. в статье Extended Protection for Authentication with Reporting Services.

Настройка сервера отчетов на использование встроенной безопасности Windows

Откройте файл конфигурации RSReportServer.config в текстовом редакторе.
Найдите <Authentication>.
Выберите и скопируйте наиболее подходящую из следующих XML-структур. RSWindowsNegotiate, RSWindowsNTLM и RSWindowsKerberos можно указывать в любом порядке. Включите сохраняемость проверки подлинности, если нужно проверить подлинность соединений, а не каждого отдельного запроса. При сохраняемости проверки подлинности все запросы, для которых требуется проверка подлинности, разрешены в продолжение существования соединения.

Первая XML-структура является настройкой по умолчанию, если учетной записью службы сервера отчетов является учетная запись NetworkService или LocalSystem:
```
<Authentication>  
      <AuthenticationTypes>  
             <RSWindowsNegotiate />  
      </AuthenticationTypes>  
      <EnableAuthPersistence>true</EnableAuthPersistence>  
</Authentication>  
```
Вторая XML-структура является настройкой по умолчанию, если учетной записью службы сервера отчетов не является учетная запись NetworkService или LocalSystem:
```
<Authentication>  
      <AuthenticationTypes>  
             <RSWindowsNTLM />  
      </AuthenticationTypes>  
      <EnableAuthPersistence>true</EnableAuthPersistence>  
```
</Проверки подлинности>

Третья XML-структура указывает все пакеты безопасности, используемые во встроенной безопасности Windows:
```
      <AuthenticationTypes>  
             <RSWindowsNegotiate />  
             <RSWindowsKerberos />  
             <RSWindowsNTLM />  
      </AuthenticationTypes>  
```
Четвертая XML-структура задает NTLM только для развертываний, которые не поддерживают протокол Kerberos или обходят ошибки проверки подлинности протокола Kerberos:
```
      <AuthenticationTypes>  
             <RSWindowsNTLM />  
      </AuthenticationTypes>  
```
Вставьте его поверх существующих записей для <Authentication>.

Также невозможно использование синтаксиса Custom с типами RSWindows.
При необходимости измените параметры расширенной защиты. По умолчанию расширенная защита отключена. Если эти записи отсутствуют, возможно, на данном компьютере не установлена версия служб Reporting Services с поддержкой расширенной защиты. Дополнительные сведения см. в разделе Extended Protection for Authentication with Reporting Services.
```
      <RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>  
      <RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>  
```
Сохраните файл.
Если настроено масштабное развертывание, повторите вышеперечисленные шаги для остальных серверов отчетов, входящих в конфигурацию развертывания.
Перезапустите сервер отчетов, чтобы очистить все открытые сеансы.

Разрешение ошибок проверок подлинности протокола Kerberos при соединении с сервером отчетов

На сервере отчетов, настроенном для проверки подлинности протоколов Negotiate или Kerberos, клиентское соединение с сервером отчетов завершится неудачей в случае ошибки проверки подлинности Kerberos. Известно, что ошибки проверки подлинности протокола Kerberos происходят вследствие следующих причин.

Служба сервера отчетов выполняется с доменной учетной записью пользователя Windows, и для учетной записи не зарегистрировано имя участника-службы (SPN).
Сервер отчетов настроен на режим RSWindowsNegotiate.
Браузер выбирает протокол Kerberos вместо NTLM в заголовке проверки подлинности в запросе, посылаемом серверу отчетов.

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

Вы можете убедиться, что возникла ошибка проверки подлинности Kerberos, удалив <RSWindowsNegotiate /> из файла конфигурации и повторно установив подключение.

Если неполадка подтверждается, ее можно устранить следующими способами:

Зарегистрируйте имя участника-службы для службы сервера отчетов, которая запускается от учетной записи пользователя домена. Дополнительные сведения см. в разделе Регистрация имени субъекта-службы (SPN) для сервера отчетов.
Измените учетную запись службы для запуска под встроенной учетной записью, такой как сетевая служба. Встроенные учетные записи сопоставляют имя участника-службы HTTP с именем участника-службы Host, которое определяется при соединении компьютера с сетью. Дополнительные сведения см. в статье Настройка учетной записи службы (SSRS Configuration Manager).
Используйте NTLM. Как правило, NTLM функционирует в случаях, когда проверка подлинности протокола Kerberos заканчивается неуспешно. Чтобы задействовать NTLM, удалите RSWindowsNegotiate из файла RSReportServer.config и проверьте, что указан только RSWindowsNTLM. Если выбран этот подход, то можно продолжить использовать учетную запись пользователя домена для службы сервера отчетов, даже если для него не определено имя участника-службы (SPN).

Информация в журнале

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

Атрибут управления учетными записями

Определите, определен ли необходимый атрибут учетной записи служб Reporting Services в Active Directory. Просмотрите файл журнала трассировки служб Reporting Services и найдите значение записи для атрибута управления учетными записями. Значение записи приведено в десятичном формате. Необходимо преобразовать десятичное значение в шестнадцатеричный формат и найти его в разделе MSDN, где описан атрибут управления учетными записями.

Журнал трассировки служб Reporting Services будет выглядеть примерно следующим образом:
```
appdomainmanager!DefaultDomain!8f8!01/14/2010-14:42:28:: i INFO: The UserAccountControl value for the service account is 590336  
```
Например, десятичное значение можно преобразовать в шестнадцатеричное с помощью калькулятора Microsoft Windows. Калькулятор поддерживает несколько режимов, где имеются переключатели «Dec» и «Hex». Установите переключатель в положение «Dec», вставьте или введите десятичное значение из файла журнала и переведите переключатель в положение «Hex».
Откройте раздел Атрибут управления учетными записями , чтобы получить атрибут для учетной записи службы.

Имена участников-служб, настроенные в Active Directory для учетной записи служб Reporting Services

Чтобы включить SPN в файл журнала трассировки служб Reporting Services, можно временно включить функцию расширенной защиты служб Reporting Services.

Внесите изменения в файл конфигурации rsreportserver.config, задав следующие параметры:

<RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>   
<RSWindowsExtendedProtectionScenario>Any</RSWindowsExtendedProtectionScenario>

Перезапустите службу Службы Reporting Services .

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

<RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel>  
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>

Дополнительные сведения см. в разделе Extended Protection for Authentication with Reporting Services.

Как браузер выбирает Negotiated Kerberos или Negotiated NTLM

При использовании браузера Internet Explorer для подключения к серверу отчетов, он указывает Negotiated Kerberos или NTLM в заголовке проверки подлинности. NTLM используется вместо протокола Kerberos, когда:

Запрос передан в локальный сервер отчетов.
Запрос передан по IP-адресу компьютера сервера отчетов вместо заголовка узла или имени сервера.
Программа брандмауэра блокирует порты, используемые для проверки подлинности протокола Kerberos.
Протокол Kerberos не включен в операционной системе конкретного сервера.
Домен содержит старые версии клиентских и серверных операционных систем Windows, которые не поддерживают проверку подлинности протокола Kerberos, встроенную в новые версии операционной системы.

Кроме того, Internet Explorer может выбрать Negotiated Kerberos или NTLM в зависимости от настроек URL-адреса, ЛВС и прокси-сервера.

URL-адрес сервера отчетов

Если URL-адрес содержит полное доменное имя, то Internet Explorer выбирает NTLM. Если URL-адрес указывает localhost, то Internet Explorer выбирает NTLM. Если URL-адрес указывает сетевое имя компьютера, то Internet Explorer выбирает Negotiate, и успех или неудача зависит от существования имени участника-службы (SPN) для учетной записи службы сервера отчетов.

Настройки локальной сети и прокси-сервера на клиенте

Настройки локальной сети и прокси-сервера, установленные в браузере Internet Explorer, могут определить выбор NTLM вместо протокола Kerberos. Но поскольку настройки локальной сети и прокси-сервера различны в пределах организации, невозможно точно определить настройки, которые привели к ошибкам проверки подлинности протокола Kerberos. Например, в организации могут принудительно применяться настройки прокси-сервера, которые преобразуют URL-адреса из URL-адресов интрасети в URL-адреса полного доменного имени, разрешаемые через интернет-соединения. Если для различных типов URL-адресов используются разные поставщики проверки подлинности, то некоторые соединения могут оказаться успешными вопреки ожиданиям.

Если возникают ошибки соединения, которые можно объяснить сбоями проверки подлинности, можно применить различные сочетания настройки локальной сети и прокси-сервера, чтобы обнаружить проблему. В Internet Explorer настройки локальной сети и прокси-сервера находятся в диалоговом окне Настройки локальной сети , которое можно открыть, нажав кнопку Настройки LAN на вкладке Подключения окна Свойства: Интернет.

Внешние ресурсы

Дополнительные сведения о Kerberos и серверах отчетов см. на странице Развертывание решений бизнес-аналитики с помощью SharePoint, служб Reporting Services и сервера мониторинга PerformancePoint с Kerberos.

См. также:

Проверка подлинности с использованием сервера отчетов
Предоставление разрешений на сервер отчетов в собственном режиме
RSReportServer Configuration File
Настройка обычной аутентификации на сервере отчетов
Настройка нестандартной аутентификации или аутентификации с помощью форм на сервере отчетов
Extended Protection for Authentication with Reporting Services

Поделиться через