Choose an Authentication Mode
Applies to: SQL Server (all supported versions)
During setup, you must select an authentication mode for the Database Engine. There are two possible modes: Windows Authentication mode and mixed mode. Windows Authentication mode enables Windows Authentication and disables SQL Server Authentication. Mixed mode enables both Windows Authentication and SQL Server Authentication. Windows Authentication is always available and cannot be disabled.
Configuring the Authentication Mode
If you select Mixed Mode Authentication during setup, you must provide and then confirm a strong password for the built-in SQL Server system administrator account named sa. The sa account connects by using SQL Server Authentication.
If you select Windows Authentication during setup, Setup creates the sa account for SQL Server Authentication but it is disabled. If you later change to Mixed Mode Authentication and you want to use the sa account, you must enable the account. Any Windows or SQL Server account can be configured as a system administrator. Because the sa account is well known and often targeted by malicious users, do not enable the sa account unless your application requires it. Never set a blank or weak password for the sa account. To change from Windows Authentication mode to Mixed Mode Authentication and use SQL Server Authentication, see Change Server Authentication Mode.
Connecting Through Windows Authentication
When a user connects through a Windows user account, SQL Server validates the account name and password using the Windows principal token in the operating system. This means that the user identity is confirmed by Windows. SQL Server does not ask for the password, and does not perform the identity validation. Windows Authentication is the default authentication mode, and is much more secure than SQL Server Authentication. Windows Authentication uses Kerberos security protocol, provides password policy enforcement with regard to complexity validation for strong passwords, provides support for account lockout, and supports password expiration. A connection made using Windows Authentication is sometimes called a trusted connection, because SQL Server trusts the credentials provided by Windows.
By using Windows Authentication, Windows groups can be created at the domain level, and a login can be created on SQL Server for the entire group. Managing access from at the domain level can simplify account administration.
When possible, use Windows authentication.
Connecting Through SQL Server Authentication
When using SQL Server Authentication, logins are created in SQL Server that are not based on Windows user accounts. Both the user name and the password are created by using SQL Server and stored in SQL Server. Users connecting using SQL Server Authentication must provide their credentials (login and password) every time that they connect. When using SQL Server Authentication, you must set strong passwords for all SQL Server accounts. For strong password guidelines, see Strong Passwords.
Three optional password policies are available for SQL Server logins.
User must change password at next login
Requires the user to change the password the next time that the user connects. The ability to change the password is provided by SQL Server Management Studio. Third-party software developers should provide this feature if this option is used.
Enforce password expiration
The maximum password age policy of the computer is enforced for SQL Server logins.
Enforce password policy
The Windows password policies of the computer are enforced for SQL Server logins. This includes password length and complexity. This functionality depends on the NetValidatePasswordPolicy API, which is only available in Windows Server 2003 and later versions.
To determine the password policies of the local computer
On the Start menu, click Run.
In the Run dialog box, type secpol.msc, and then click OK.
In the Local Security Settings application, expand Security Settings, expand Account Policies, and then click Password Policy.
The password policies are described in the results pane.
Disadvantages of SQL Server Authentication
If a user is a Windows domain user who has a login and password for Windows, they must still provide another (SQL Server) login and password to connect. Keeping track of multiple names and passwords is difficult for many users. Having to provide SQL Server credentials every time that one connects to the database can be annoying.
SQL Server Authentication cannot use Kerberos security protocol.
Windows offers additional password policies that are not available for SQL Server logins.
The encrypted SQL Server Authentication login password, must be passed over the network at the time of the connection. Some applications that connect automatically will store the password at the client. These are additional attack points.
Advantages of SQL Server Authentication
Allows SQL Server to support older applications and applications provided by third parties that require SQL Server Authentication.
Allows SQL Server to support environments with mixed operating systems, where all users are not authenticated by a Windows domain.
Allows users to connect from unknown or untrusted domains. For instance, an application where established customers connect with assigned SQL Server logins to receive the status of their orders.
Allows SQL Server to support Web-based applications where users create their own identities.
Allows software developers to distribute their applications by using a complex permission hierarchy based on known, preset SQL Server logins.
Using SQL Server Authentication does not limit the permissions of local administrators on the computer where SQL Server is installed.
Настройка проверки подлинности Windows на сервере отчетов Configure Windows Authentication on the Report Server
По умолчанию службы Службы Reporting Services Reporting Services принимают запросы, в которых определена проверка подлинности Negotiate или NTLM. By default, Службы Reporting Services Reporting Services accepts requests that specify Negotiate or NTLM authentication. Если в развертывание входят клиентские приложения и браузеры, в которых используются поставщики безопасности, то можно использовать значения по умолчанию без дополнительной настройки. If your deployment includes client applications and browsers that use these security providers, you can use the default values without additional configuration. Если нужно использовать другого поставщика безопасности для встроенной безопасности Windows (например, требуется применять протокол Kerberos напрямую) или если значения по умолчанию были изменены, и нужно восстановить первоначальные настройки, то можно использовать сведения данного раздела, чтобы указать настройки проверки подлинности на сервере отчетов. If you want to use a different security provider for Windows integrated security (for example, if you want to use Kerberos directly), or if you modified the default values and want to restore the original settings, you can use the information in this topic to specify authentication settings on the report server.
Чтобы использовать встроенную безопасность Windows, каждый пользователь, обращающийся к серверу отчетов, должен иметь правильную локальную или доменную учетную запись Windows или входить в локальную или доменную группу Windows. To use Windows integrated security, each user who requires access to a report server must have a valid Windows local or domain user account or be a member of a Windows local or domain group account. В группу можно включать учетные записи, относящиеся к другим доменам, если эти домены являются доверенными. You can include accounts from other domains as long as those domains are trusted. Учетные записи должны иметь доступ к компьютеру, на котором размещен сервер отчетов. Впоследствии учетным записям нужно назначить роли, чтобы обеспечить им доступ к специфическим операциям сервера отчетов. The accounts must have access to the report server computer, and must be subsequently assigned to roles in order to gain access to specific report server operations.
Должны выполняться также следующие дополнительные условия. The following additional requirements must also be met:
Атрибуту AuthenticationType файлов RSReportServer.config должно быть присвоено значение RSWindowsNegotiate, RSWindowsKerberos или RSWindowsNTLM. The RSReportServer.config files must have AuthenticationType set to RSWindowsNegotiate, RSWindowsKerberos, or RSWindowsNTLM. По умолчанию файл конфигурации RSReportServer.config включает настройку RSWindowsNegotiate , если учетной записью службы сервера отчетов является учетная запись NetworkService или LocalSystem. В противном случае используется настройка RSWindowsNTLM . By default, the RSReportServer.config file includes the RSWindowsNegotiate setting if the Report Server service account is either NetworkService or LocalSystem; otherwise, the RSWindowsNTLM setting is used. Можно добавить RSWindowsKerberos , если имеются приложения, в которых используется только проверка подлинности протокола Kerberos. You can add RSWindowsKerberos if you have applications that only use Kerberos authentication.
Использование RSWindowsNegotiate приведет к ошибке проверки подлинности протокола Kerberos, если служба сервера отчетов настроена на запуск с доменной учетной записью пользователя и для учетной записи не зарегистрировано имя участника-службы (SPN). Using RSWindowsNegotiate will result in a Kerberos authentication error if you configured the Report Server service to run under a domain user account and you did not register a Service Principal Name (SPN) for the account. Дополнительные сведения см. в разделе Разрешение ошибок проверок подлинности протокола Kerberos при соединении с сервером отчетов в этом разделе. For more information, see Resolving Kerberos Authentication Errors When Connecting to a report server in this topic.
Файлы Web.config для веб-службы сервера отчетов должны содержать параметр . The Web.config files for the Report Server Web service must have .
Клиентское приложение или браузер должны поддерживать встроенную безопасность Windows. The client application or browser must support Windows integrated security.
веб-портал web portal дополнительная настройка не требуется. The веб-портал web portal does not need additional configuration.
Чтобы изменить настройки проверки подлинности сервера отчетов, измените XML-элементы и значения в файле RSReportServer.config. To change the report server authentication settings, edit the XML elements and values in the RSReportServer.config file. Чтобы реализовать определенные сочетания, можно копировать и вставить примеры из этого раздела. You can copy and paste the examples in this topic to implement specific combinations.
Настройки по умолчанию работают лучше всего, если клиентский и серверный компьютер находятся в одном и том же домене или в доверенном домене, а сервер отчетов разворачивается для доступа из внутренней сети, защищенной корпоративным брандмауэром. The default settings work best if all client and server computers are in the same domain or in a trusted domain and the report server is deployed for intranet access behind a corporate firewall. Для передачи учетных данных Windows необходимо использовать доверенные и одиночные домены. Trusted and single domains are a requirement for passing Windows credentials. Учетные данные можно передавать несколько раз в том случае, если для серверов включен протокол Kerberos версии 5. Credentials can be passed more than one time if you enable the Kerberos version 5 protocol for your servers. В противном случае учетные данные можно передать только один раз до истечения срока их действия. Otherwise, credentials can be passed only one time before they expire. Дополнительные сведения о настройке учетных данных для нескольких подключений к компьютерам см. в разделе Задание учетных данных и сведений о соединении для источников данных отчета. For more information about configuring credentials for multiple computer connections, see Specify Credential and Connection Information for Report Data Sources.
Следующие параметры настраиваются для сервера отчетов, работающего в собственном режиме. The following instructions are intended for a native mode report server. Если развертывание сервера отчетов производилось в режиме интеграции с SharePoint, то необходимо пользоваться настройками проверки подлинности по умолчанию, в которых задана встроенная безопасность Windows. If the report server is deployed in SharePoint integrated mode, you must use the default authentication settings that specify Windows integrated security. Сервер отчетов использует внутренние функции модуля проверки подлинности Windows по умолчанию для поддержки серверов отчетов в режиме интеграции с SharePoint. The report server uses internal features in the default Windows Authentication extension to support report servers in SharePoint integrated mode.
Расширенная защита для проверки подлинности Extended Protection for Authentication
Начиная с SQL Server 2008 R2 SQL Server 2008 R2 , доступна поддержка расширенной защиты для проверки подлинности. Beginning with SQL Server 2008 R2 SQL Server 2008 R2 , support for Extended Protection for Authentication is available. Функция SQL Server SQL Server использует привязку каналов и служб для повышения уровня защиты проверки подлинности. The SQL Server SQL Server feature supports the use of channel binding and service binding to enhance protection of authentication. Функции Службы Reporting Services Reporting Services можно использовать в ОС, поддерживающей расширенную защиту. The Службы Reporting Services Reporting Services features need to be used with an operating system that supports Extended Protection. Службы Reporting Services Reporting Services определяется параметрами в файле RSReportServer.config. configuration for extended protection is determined by settings in the RSReportServer.config file. Это можно сделать как в текстовом редакторе, так и при помощи средств WMI API. The file can be updated by either editing the file or using WMI APIs. Дополнительные сведения см. в статье Extended Protection for Authentication with Reporting Services. For more information, see Extended Protection for Authentication with Reporting Services.
Настройка сервера отчетов на использование встроенной безопасности Windows To configure a report server to use Windows integrated security
Откройте файл конфигурации RSReportServer.config в текстовом редакторе. Open RSReportServer.config in a text editor.
Найдите параметр . Find .
Выберите и скопируйте наиболее подходящую из следующих XML-структур. Copy one of the following XML structures that best fits your needs. RSWindowsNegotiate, RSWindowsNTLMи RSWindowsKerberos можно указывать в любом порядке. You can specify RSWindowsNegotiate, RSWindowsNTLM, and RSWindowsKerberos in any order. Включите сохраняемость проверки подлинности, если нужно проверить подлинность соединений, а не каждого отдельного запроса. You should enable authentication persistence if you want to authenticate the connection rather than each individual request. При сохраняемости проверки подлинности все запросы, для которых требуется проверка подлинности, разрешены в продолжение существования соединения. Under authentication persistence, all requests that require authentication will be allowed for the duration of the connection.
Первая XML-структура является настройкой по умолчанию, если учетной записью службы сервера отчетов является учетная запись NetworkService или LocalSystem: The first XML structure is the default configuration when the Report Server service account is either NetworkService or LocalSystem:
Вторая XML-структура является настройкой по умолчанию, если учетной записью службы сервера отчетов не является учетная запись NetworkService или LocalSystem: The second XML structure is the default configuration when the Report Server service account is not NetworkService or LocalSystem:
Третья XML-структура указывает все пакеты безопасности, используемые во встроенной безопасности Windows: The third XML structure specifies all of the security packages that are used in Windows integrated security:
Четвертая XML-структура задает NTLM только для развертываний, которые не поддерживают протокол Kerberos или обходят ошибки проверки подлинности протокола Kerberos: The fourth XML structure specifies NTLM only for deployments that do not support Kerberos or to work around Kerberos authentication errors:
Вставьте его на место существующих элементов . Paste it over the existing entries for .
Также невозможно использование синтаксиса Custom с типами RSWindows . Note that you cannot use Custom with the RSWindows types.
При необходимости измените параметры расширенной защиты. Modify as appropriate the settings for extended protection. По умолчанию расширенная защита отключена. Extended protection is disabled by default. Если эти записи отсутствуют, возможно, на компьютере не установлена версия служб Службы Reporting Services Reporting Services с поддержкой расширенной защиты. If these entries are not present, the current computer may not be running a version of Службы Reporting Services Reporting Services which supports extended protection. Дополнительные сведения см. в разделе Extended Protection for Authentication with Reporting Services. For more information, see Extended Protection for Authentication with Reporting Services
Сохраните файл. Save the file.
Если настроено масштабное развертывание, повторите вышеперечисленные шаги для остальных серверов отчетов, входящих в конфигурацию развертывания. If you configured a scale-out deployment, repeat these steps for other report servers in the deployment.
Перезапустите сервер отчетов, чтобы очистить все открытые сеансы. Restart the report server to clear any sessions that are currently open.
Устранение ошибки проверки подлинности Kerberos, при соединении с сервером отчетов Resolving Kerberos Authentication Errors When Connecting to a Report Server
На сервере отчетов, настроенном для проверки подлинности протоколов Negotiate или Kerberos, клиентское соединение с сервером отчетов завершится неудачей в случае ошибки проверки подлинности Kerberos. On a report server that is configured for Negotiate or Kerberos authentication, a client connection to the report server will fail if there is a Kerberos authentication error. Известно, что ошибки проверки подлинности протокола Kerberos происходят вследствие следующих причин. Kerberos authentication errors are known to occur when:
Служба сервера отчетов выполняется с доменной учетной записью пользователя Windows, и для учетной записи не зарегистрировано имя участника-службы (SPN). The Report Server service runs as a Windows domain user account and you did not register a Service Principal Name (SPN) for the account.
Сервер отчетов настроен на режим RSWindowsNegotiate . The report server is configured with the RSWindowsNegotiate setting.
Браузер выбирает протокол Kerberos вместо NTLM в заголовке проверки подлинности в запросе, посылаемом серверу отчетов. The browser chooses Kerberos over NTLM in the authentication header in the request it sends to the report server.
Можно заметить ошибку, если включить ведение журнала протокола Kerberos. You can detect the error if you enabled Kerberos logging. Другой признак ошибки — многократное получение запроса для ввода учетных данных с последующим появлением пустого окна браузера. Another symptom of the error is that you are prompted for credentials multiple times and then see an empty browser window.
Наличие ошибки проверки подлинности протокола Kerberos можно подтвердить, удалив из файла конфигурации и повторив попытку соединения. You can confirm that you are encountering a Kerberos authentication error by removing from your configuration file and reattempting the connection.
Если неполадка подтверждается, ее можно устранить следующими способами: After you confirm the problem, you can address it in the following ways:
Зарегистрируйте имя участника-службы для службы сервера отчетов, которая запускается от учетной записи пользователя домена. Register an SPN for the Report Server service under the domain user account. Дополнительные сведения см. в статье Регистрация имени субъекта-службы (SPN) для сервера отчетов. For more information, see Register a Service Principal Name (SPN) for a Report Server.
Измените учетную запись службы для запуска под встроенной учетной записью, такой как сетевая служба. Change the service account to run under a built-in account such as Network Service. Встроенные учетные записи сопоставляют имя участника-службы HTTP с именем участника-службы Host, которое определяется при соединении компьютера с сетью. Built-in accounts map HTTP SPN to the Host SPN, which is defined when you join a computer to your network. Дополнительные сведения см. в разделе Настройка учетной записи службы (диспетчер конфигураций служб SSRS). For more information, see Configure a Service Account (SSRS Configuration Manager).
Используйте NTLM. Use NTLM. Как правило, NTLM функционирует в случаях, когда проверка подлинности протокола Kerberos заканчивается неуспешно. NTLM will generally work in cases where Kerberos authentication fails. Чтобы задействовать NTLM, удалите RSWindowsNegotiate из файла RSReportServer.config и проверьте, что указан только RSWindowsNTLM . To use NTLM, remove RSWindowsNegotiate from the RSReportServer.config file and verify that only RSWindowsNTLM is specified. Если выбран этот подход, то можно продолжить использовать учетную запись пользователя домена для службы сервера отчетов, даже если для него не определено имя участника-службы (SPN). If you choose this approach, you can continue to use a domain user account for the Report Server service even if you do not define an SPN for it.
Информация в журнале Logging information
Имеется несколько источников информации, включаемой в журнал, которые могут помочь в решении проблем, связанных с протоколом Kerberos. There are several sources of logging information that can help resolve Kerberos related issues.
Атрибут управления учетными записями User-Account-Control Attribute
Определите, задан ли необходимый атрибут учетной записи служб Службы Reporting Services Reporting Services в Active Directory. Determine if the Службы Reporting Services Reporting Services service account has the sufficient attribute set in Active Directory. Просмотрите файл журнала трассировки служб Reporting Services и найдите значение записи для атрибута управления учетными записями. Review the reporting services service trace log file to find the value logged for the UserAccountControl attribute. Значение записи приведено в десятичном формате. The value logged is in decimal form. Необходимо преобразовать десятичное значение в шестнадцатеричный формат и найти его в разделе MSDN, где описан атрибут управления учетными записями. You need to convert the decimal value to hexadecimal form and then find that value in the MSDN topic describing User-Account-Control Attribute.
Журнал трассировки служб Reporting Services будет выглядеть примерно следующим образом: The reporting services service trace log entry will look similar to the following:
Например, десятичное значение можно преобразовать в шестнадцатеричный формат с помощью калькулятора Microsoft Microsoft Windows. One option for converting the value Decimal value to hexadecimal form is to us the Microsoft Microsoft Windows Calculator. Калькулятор поддерживает несколько режимов, где имеются переключатели «Dec» и «Hex». Windows Calculator supports several modes that show the ‘Dec’ option and ‘Hex’ options. Установите переключатель в положение «Dec», вставьте или введите десятичное значение из файла журнала и переведите переключатель в положение «Hex». Select the ‘Dec’ option, paste or type in the decimal value you found in the log file and then select the ‘Hex’ option.
Откройте раздел Атрибут управления учетными записями , чтобы получить атрибут для учетной записи службы. Then refer to the topic User-Account-Control Attribute to derive the attribute for the service account.
Имена участников-служб, настроенные в Active Directory для учетной записи служб Reporting Services SPNs Configured in Active Directory for the Reporting Services service account.
Чтобы включить имя участника зеркального отображения в файл журнала трассировки служб Службы Reporting Services Reporting Services , можно временно включить функцию расширенной защиты Службы Reporting Services Reporting Services . To log the SPNs in the Службы Reporting Services Reporting Services service trace log file, you can enable the Службы Reporting Services Reporting Services Extended Protection feature temporarily.
Внесите изменения в файл конфигурации rsreportserver.config , задав следующие параметры: Modify the configuration file rsreportserver.config by setting the following:
Перезапустите службу Службы Reporting Services Reporting Services . Restart the Службы Reporting Services Reporting Services service.
Если дальнейшей необходимости в использовании расширенной защиты нет, восстановите параметры по умолчанию и перезапустите учетную запись службы Службы Reporting Services Reporting Services . If you don’t want to continue using Extended Protection, then set the configuration values back to defaults and restart the Службы Reporting Services Reporting Services Service account.
Как браузер выбирает Negotiated Kerberos или Negotiated NTLM How the Browser Chooses Negotiated Kerberos or Negotiated NTLM
При использовании браузера Internet Explorer для подключения к серверу отчетов, он указывает Negotiated Kerberos или NTLM в заголовке проверки подлинности. When you use Internet Explorer to connect to the report server, it specifies either Negotiated Kerberos or NTLM on the authentication header. NTLM используется вместо протокола Kerberos, когда: NTLM is used instead of Kerberos when:
Запрос передан в локальный сервер отчетов. The request is sent to a local report server.
Запрос передан по IP-адресу компьютера сервера отчетов вместо заголовка узла или имени сервера. The request is sent to an IP address of the report server computer rather than a host header or server name.
Программа брандмауэра блокирует порты, используемые для проверки подлинности протокола Kerberos. Firewall software blocks ports used for Kerberos authentication.
Протокол Kerberos не включен в операционной системе конкретного сервера. The operating system of a particular server does not have Kerberos enabled.
Домен содержит старые версии клиентских и серверных операционных систем Windows, которые не поддерживают проверку подлинности протокола Kerberos, встроенную в новые версии операционной системы. The domain includes older versions of Windows client and server operating systems that do not support the Kerberos authentication feature built into newer versions of the operating system.
Кроме того, Internet Explorer может выбрать Negotiated Kerberos или NTLM в зависимости от настроек URL-адреса, ЛВС и прокси-сервера. In addition, Internet Explorer might choose either Negotiated Kerberos or NTLM depending on how you configured URL, LAN, and proxy settings.
URL-адрес сервера отчетов Report Server URL
Если URL-адрес содержит полное доменное имя, то Internet Explorer выбирает NTLM. If the URL includes a fully qualified domain name, Internet Explorer selects NTLM. Если URL-адрес указывает localhost, то Internet Explorer выбирает NTLM. If the URL specifies localhost, Internet Explorer selects NTLM. Если URL-адрес указывает сетевое имя компьютера, то Internet Explorer выбирает Negotiate, и успех или неудача зависит от существования имени участника-службы (SPN) для учетной записи службы сервера отчетов. If the URL specifies the network name of the computer, Internet Explorer selects Negotiate, which will succeed or fail depending on whether an SPN exists for the Report Server service account.
Настройки локальной сети и прокси-сервера на клиенте LAN and Proxy Settings on the Client
Настройки локальной сети и прокси-сервера, установленные в браузере Internet Explorer, могут определить выбор NTLM вместо протокола Kerberos. LAN and proxy settings that you set in Internet Explorer can determine whether NTLM is chosen over Kerberos. Но поскольку настройки локальной сети и прокси-сервера различны в пределах организации, невозможно точно определить настройки, которые привели к ошибкам проверки подлинности протокола Kerberos. However, because LAN and proxy settings vary across organizations, it is not possible to precisely determine the exact settings that contribute to Kerberos authentication errors. Например, в организации могут принудительно применяться настройки прокси-сервера, которые преобразуют URL-адреса из URL-адресов интрасети в URL-адреса полного доменного имени, разрешаемые через интернет-соединения. For example, your organization might enforce proxy settings that transform URLs from intranet URLs to fully-qualified domain name URLs that resolve over Internet connections. Если для различных типов URL-адресов используются разные поставщики проверки подлинности, то некоторые соединения могут оказаться успешными вопреки ожиданиям. If different authentication providers are used for different types of URLs, you might find that some connections succeed when you would have expected them to fail.
Если возникают ошибки соединения, которые можно объяснить сбоями проверки подлинности, можно применить различные сочетания настройки локальной сети и прокси-сервера, чтобы обнаружить проблему. If you encounter connection errors that you think are due to authentication failures, you can try different combinations of LAN and proxy settings to isolate the problem. В Internet Explorer настройки локальной сети и прокси-сервера находятся в диалоговом окне Настройки локальной сети , которое можно открыть, нажав кнопку Настройки LAN на вкладке Подключения окна Свойства: Интернет. In Internet Explorer, LAN and proxy settings are on the Local Area Network (LAN) Settings dialog box, which you open by clicking LAN settings on the Connection tab of Internet Options.