Бөлісу құралы:

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

  • Мақала

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

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

Кроме того, необходимо выполнить следующие требования:

  • Файлы RSReportServer.config должны иметь AuthenticationType значение 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 для веб-службы сервера отчетов должны содержать параметр <identity impersonate= "true" />.

  • Клиентское приложение или браузер должны поддерживать встроенную безопасность Windows.

  • На веб-портале не требуется дополнительная конфигурация.

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

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

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

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

Начиная с SQL Server 2008 R2 (10.50.x), доступна поддержка расширенной защиты для проверки подлинности. Функционал SQL Server поддерживает привязку каналов и служб для повышения уровня защиты проверки подлинности. Функционал Reporting Services следует использовать в ОС с поддержкой расширенной защиты. Конфигурацию служб Reporting Services для расширенной защиты можно определить с помощью определенных параметров в файле RSReportServer.config. Вы можете обновить файл, изменив файл или с помощью API WMI. Дополнительные сведения см. в статье "Расширенная защита для проверки подлинности с помощью служб Reporting Services".

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

  1. Откройте файл конфигурации RSReportServer.config в текстовом редакторе.

  2. Найдите параметр <Authentication>.

  3. Выберите и скопируйте наиболее подходящую из следующих 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>
</Authentication>

    Третья XML-структура указывает все пакеты безопасности, используемые во встроенной безопасности Windows:

    <AuthenticationTypes>
    <RSWindowsNegotiate />
    <RSWindowsKerberos />
    <RSWindowsNTLM />
</AuthenticationTypes>

    Четвертая структура XML указывает NTLM только для развертываний, которые не поддерживают Kerberos или работают с ошибками проверки подлинности Kerberos:

    <AuthenticationTypes>
    <RSWindowsNTLM />
</AuthenticationTypes>

  4. Вставьте его на место существующих элементов <Authentication>.

    Нельзя использовать Custom с типами RSWindows .

  5. При необходимости измените параметры расширенной защиты. По умолчанию расширенная защита отключена. Если эти записи отсутствуют, текущий компьютер может не работать с версией служб Reporting Services, которая поддерживает расширенную защиту. Дополнительные сведения см. в статье "Расширенная защита для проверки подлинности с помощью служб Reporting Services"

    <RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>

  6. Сохраните файл.

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

  8. Перезапустите сервер отчетов, чтобы очистить все открытые сеансы.

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

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

  • Служба сервера отчетов выполняется в качестве учетной записи пользователя домена Windows и не зарегистрировала имя субъекта-службы (SPN) для учетной записи.

  • Сервер отчетов настроен на режим RSWindowsNegotiate.

  • Браузер выбирает протокол Kerberos вместо NTLM в заголовке проверки подлинности в запросе, посылаемом серверу отчетов.

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

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

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

  • Зарегистрируйте имя участника-службы для службы сервера отчетов, которая запускается от учетной записи пользователя домена. Дополнительные сведения см. в разделе "Регистрация имени субъекта-службы" для сервера отчетов.

  • Измените учетную запись службы для запуска под встроенной учетной записью, такой как сетевая служба. Встроенные учетные записи сопоставляют имя участника-службы HTTP с именем участника-службы Host, которое определяется при соединении компьютера с сетью. Дополнительные сведения см. в разделе "Настройка учетной записи службы " (Диспетчер конфигурации сервера отчетов)".

  • Используйте NTLM. NTLM обычно работает в тех случаях, когда проверка подлинности Kerberos завершается ошибкой. Чтобы задействовать NTLM, удалите RSWindowsNegotiate из файла RSReportServer.config и проверьте, что указан только RSWindowsNTLM. Если вы выберете этот подход, вы можете продолжать использовать учетную запись пользователя домена для службы сервера отчетов, даже если для нее не определено имя субъекта-службы.

Чтобы свести итоги, выполните команды, аналогичные следующему примеру. Замените значения соответствующим образом.

setspn -S HTTP/<SSRS Server FDQN> <SSRS Service Account>
setspn -S HTTP/<host header for Report server web site> <SSRS Service Account>
setspn -S HTTP/<SharePoint Server FDQN> <SharePoint Application Pool Account>
setspn -S HTTP/<host header for SharePoint site>  <SharePoint Application Pool Account>
setspn -S HTTP/Dummy <Claims to Windows Taken Service Account>

Сведения о журнале

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

Атрибут User-Account-Control

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

  • Запись журнала трассировки служб Reporting Services выглядит примерно так:

    appdomainmanager!DefaultDomain!8f8!01/14/2010-14:42:28:: i INFO: The UserAccountControl value for the service account is 590336

  • Например, десятичное значение можно преобразовать в шестнадцатеричное с помощью калькулятора Microsoft Windows. Калькулятор Windows поддерживает несколько режимов, в которые отображаются Dec параметры и Hex параметры. Dec Выберите параметр, вставьте или введите десятичное значение, которое вы нашли в файле журнала, а затем выберите параметр Hex.

  • Затем см. статью Атрибут User-Account-Control, чтобы получить атрибут для учетной записи службы.

Имена субъектов-служб, настроенные в 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>

Дополнительные сведения см. в статье "Расширенная защита для проверки подлинности с помощью служб Reporting Services".

Выбор браузера "Согласование Kerberos" или "Согласование 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, могут определить выбор NTLM вместо протокола Kerberos. Тем не менее, поскольку параметры локальной сети и прокси-сервера зависят от организаций, невозможно точно определить точные параметры, которые способствуют ошибкам проверки подлинности Kerberos. Например, ваша организация может применять параметры прокси-сервера, которые преобразуют URL-адреса из URL-адресов интрасети в полные URL-адреса доменного имени, которые разрешаются через Интернет-подключения. Если для разных типов URL-адресов используются разные поставщики проверки подлинности, может возникнуть ошибка некоторых подключений при их сбое.

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

Дополнительные сведения о серверах отчетов Kerberos и серверах отчетов

Связанный контент