Ескертпе
Бұл бетке кіру үшін қатынас шегін айқындау қажет. Жүйеге кіруді немесе каталогтарды өзгертуді байқап көруге болады.
Бұл бетке кіру үшін қатынас шегін айқындау қажет. Каталогтарды өзгертуді байқап көруге болады.
Применяется к: SQL Server
Исходный номер базы знаний: 811889
Сводка
Эта статья поможет устранить неполадки и устранить ошибку "Не удается создать контекст SSPI", возникающую при попытке подключиться к SQL Server с помощью проверки подлинности Windows. Эта ошибка обычно указывает, что интерфейс поставщика поддержки безопасности (SSPI) не может использовать проверку подлинности Kerberos для делегирования учетных данных клиента через TCP/IP или именованные каналы SQL Server.
В этой статье вы узнаете о распространенных причинах ошибок контекста SSPI, Именах субъектов службы (SPN) и их роли в проверке подлинности, а также о диагностике и исправлении ошибки.
Прежде чем приступить к устранению неполадок, ознакомьтесь с предварительными условиями и контрольным списком для устранения неполадок с подключением к SQL Server.
Симптомы
При удаленном подключении к экземпляру SQL Server при использовании проверки подлинности Windows вы получите следующее сообщение об ошибке:
Главное конечное имя неверно. Не удается создать контекст SSPI.
Причина
Эта ошибка обычно возникает, когда проверка подлинности Windows не использует протокол Kerberos для делегирования учетных данных клиента и не успешно возвращается к проверке подлинности NTLM. В большинстве случаев ошибка возникает из-за неправильно настроенного имени субъекта-службы (SPN).
Дополнительные сведения о SSPI, Kerberos и УСС см. в разделе ЧаВо.
Исправлена ошибка с помощью Диспетчера конфигурации Kerberos
Примечание.
Этот подход исправляет ошибку при постоянном получении этих сообщений об ошибках, а не периодически.
Подключения по протоколу Kerberos могут завершиться сбоем по различным причинам, например, неправильно настроенные SPN, проблемы с разрешением имен или недостаточные права для учетных записей запуска службы SQL Server. Microsoft Kerberos Configuration Manager (KCM) — это средство, которое помогает проверить причины ошибки и предоставляет параметры для устранения любых выявленных проблем.
Выполните следующие действия, чтобы устранить ошибку с помощью KCM.
На компьютере, на котором возникают проблемы с подключением, скачайте и установите Диспетчер конфигурации Kerberos.
Начните
KerberosConfigMgr.exeиз папки%SystemDrive%:\Program Files\Microsoft\Kerberos Configuration Manager. Затем используйте учетную запись домена с разрешениями для подключения к компьютеру SQL Server, к которому не удается подключиться.Выберите "Подключиться", оставив имя сервера и другие сведения, применимые к вашему сценарию, пустым, если вы используете KCM на компьютере SQL Server. Щелкните Подключиться, чтобы выполнить анализ. После получения необходимой информации KCM автоматически переключается на вкладку имени субъекта-службы и по умолчанию отображает сведения для SQL Server, SQL Server Reporting Services, Analysis Services и прослушивателей группы доступности. Чтобы устранить эту ошибку, снимите все параметры, кроме SQL Server.
Просмотрите результаты диагностики из средства с помощью столбца Status и выполните соответствующие действия, чтобы устранить проблему.
Состояние Дополнительная информация Действие Специалист Элемент, для которого установлен флажок, настроен правильно. Вы можете перейти к следующему элементу в выходных данных. Никаких действий не требуется Отсутствует обязательное имя субъекта-службы KCM сообщает об этом состоянии, когда SPN, указанный в столбце Обязательный SPN, отсутствует для учетной записи запуска SQL Server в Active Directory. 1. Выберите "Исправление", чтобы просмотреть сведения в диалоговом окне "Предупреждение".
2. Выберите "Да", чтобы добавить отсутствующее имя субъекта-службы в Active Directory.
3. Если у учетной записи домена есть необходимые разрешения для обновления Active Directory, необходимый SPN добавляется в Active Directory.
4. Если у учетной записи домена нет необходимых разрешений для обновления Active Directory, используйте Создать или Создать все, чтобы сгенерировать скрипт, который позволит администратору Active Directory добавить отсутствующие SPNs.
5. После добавления SPN, запустите Диспетчер конфигурации Kerberos еще раз, чтобы убедиться, что проблемы с SPN устранены.
6. Кроме того, можно использовать следующие команды:
— используетсяSETSPN -Q spnNameдля поиска имени участника-службы и ее текущих учетных записей.
— используетсяSETSPN -Dдля удаления имени участника-службы из неправильной учетной записи.Для использования конфигурации Kerberos необходимо включить протокол TCP Это происходит, если протокол TCP не включен на клиентском компьютере. Чтобы включить протокол TCP/IP для экземпляра SQL Server, выполните следующие действия.
1. В диспетчере конфигурации SQL Server в области консоли разверните Конфигурацию сети SQL Server.
2. В области консоли выберите .
3. В области сведений щелкните правой кнопкой мыши параметр TCP/IP и выберите пункт "Включить".
4. В области консоли выберите SQL Server Services.
5. В области сведений щелкните правой кнопкой мыши SQL Server (<имя> экземпляра), а затем выберите "Перезапустить ", чтобы остановить и перезапустить службу SQL Server.
Дополнительные сведения см. в разделе Включение или отключение сетевого протокола сервера.Динамический порт Это сообщение отображается для именованных экземпляров, использующих динамические порты (конфигурация по умолчанию). В средах, где необходимо использовать Kerberos для подключения к SQL Server, задайте именованный экземпляр на статический порт и используйте этот порт при регистрации SPN. Чтобы настроить экземпляр SQL Server для использования статического порта выполните следующие шаги:
1. В диспетчер конфигурации SQL Server в области консоли разверните узел "Конфигурация сети SQL Server", разверните протоколы для имени< экземпляра и дважды щелкните >.
2. В диалоговом окне Свойства TCP/IP проверьте параметр Прослушивать все на вкладке Протокол.
3. Если для параметра Прослушивать все задано значение Да, перейдите на вкладку IP-адреса и прокрутите страницу до нижней части окна программы Windows, чтобы найти параметр IPAll. Удалите текущее значение, содержащееся в поле Динамические TCP-порты, и задайте нужное значение в поле TCP-порт. Нажмите кнопку ОК и перезапустите экземпляр SQL Server, чтобы изменение этих параметров вступило в силу.
4. Если для параметра Прослушивать все задано значение Нет, перейдите на вкладку IP-адреса и проверьте каждый из IP-адресов, отображаемых в IP1, IP2. Для включенных IP-адресов удалите текущее значение, содержащееся в поле Динамические TCP-порты, и задайте нужное значение в поле TCP-порт. Нажмите кнопку ОК и перезапустите экземпляр SQL Server, чтобы изменение этих параметров вступило в силу.
Дополнительные сведения см. в разделе Настройка сервера для прослушивания определенного TCP-порта.Повторяющееся имя субъекта-службы Эта ситуация возникает, когда один и тот же SPN регистрируется в разных учетных записях в Active Directory. 1. Нажмите кнопку Исправить, просмотрите сведения в диалоговом окне Предупреждение и нажмите Да, если вы можете добавить отсутствующее имя субъекта-службы в Active Directory.
2. Если у вашей учетной записи домена есть необходимые разрешения для обновления Active Directory, то неправильный SPN удаляется.
3. Если у вашей учетной записи в домене нет необходимых разрешений для обновления Active Directory, нажмите кнопку Создать или Создать все, чтобы создать необходимый скрипт, который можно отправить администратору Active Directory для удаления повторяющихся имен субъектов-служб. После удаления SPN повторно запустите KCM, чтобы убедиться, что проблемы с SPN устранены.Примечание.
Если учетная запись домена, которая запускает KCM, не имеет привилегий для управления Именами Идентификаторов Служб в Active Directory, используйте соответствующую кнопку "Создать" или "Создать все" в столбце скриптов SPN для генерации необходимых команд. Обратитесь к администратору Active Directory, чтобы устранить проблемы, которые идентифицирует KCM.
После устранения всех проблем, которые KCM идентифицирует, повторно запустите средство. Убедитесь, что о других проблемах не сообщается, а затем повторите попытку подключения. Если средство по-прежнему сообщает о проблемах, повторите предыдущую процедуру.
Исправление ошибки без использования Kerberos Configuration Manager
Если вы не можете использовать KCM, выполните следующие шаги:
Проверка разрешения имен с помощью команды ping
Главный фактор успешной проверки подлинности Kerberos – это правильность выполнения функций DNS в сети. Чтобы проверить выполняемые функции на клиенте и сервере, используйте служебную программу командной строки Ping. На клиентском компьютере выполните следующую команду, чтобы получить IP-адрес сервера, на котором выполняется SQL Server (где имя компьютера):SQLServer1
ping sqlserver1
Чтобы выяснить, разрешает ли программа Ping полное DNS-имя SQLServer1, выполните следующую команду:
ping -a <IPAddress>
Например:
C:\>ping SQLSERVER1
Pinging SQLSERVER1 [123.123.123.123] with 32 bytes of data:
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\>ping -a 123.123.123.123
Pinging SQLSERVER1.northamerica.corp.mycompany.com [123.123.123.123] with 32 bytes of data:
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Reply from 123.123.123.123: bytes=32 time<10ms TTL=128
Ping statistics for 123.123.123.123:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
C:\>
Если команда ping -a <IPAddress> разрешает правильное полное DNS-имя компьютера, на котором запущен SQL Server, разрешение на стороне клиента также выполняется успешно.
Для получения подробной диагностики используйте командлет Test-NetConnection или Test-Connection для проверки подключения TCP в соответствии с версией PowerShell, установленной на компьютере. Дополнительные сведения о командлетах PowerShell см. в разделе "Обзор командлетов".
Примечание.
Методы разрешения имен могут включать DNS, WINS, файлы Hosts и Lmhosts. Дополнительные сведения о проблемах разрешения имен и устранении неполадок можно найти в следующих статьях:
Проверьте, существуют ли псевдонимы для целевого SQL Server в диспетчере конфигурации SQL Server и в служебной программе клиентской сети SQL Server. Если такой псевдоним существует, убедитесь, что он настроен правильно, проверяя имена серверов, сетевой протокол, номер порта и т. д. Псевдоним SQL Server может вызвать непредвиденное создание SPN. Эта проблема приводит к использованию учетных данных NTLM, если SPN не найден, или сбою SSPI, если это непреднамеренно соответствует SPN другого сервера.
Проверка связи между доменами
Убедитесь, что домен, в который вы вошли, может связываться с доменом сервера, на котором запущен SQL Server. Домен также должен иметь правильное разрешение DNS.
Убедитесь, что вы можете войти в Windows, используя ту же учетную запись домена и пароль, что и учетная запись SQL Server. Например, ошибка SSPI может возникать в одной из следующих ситуаций:
- учетная запись домена заблокирована;
- После изменения пароля не перезагрузите службу SQL Server.
Если домен входа отличается от домена сервера, на котором выполняется SQL Server, проверьте связь доверия между доменами.
Необходимо, чтобы домен сервера и учетная запись домена, которая используется для подключения, принадлежали к одному лесу. Выполнение этого шага необходимо для работы SSPI.
Проверка имен субъектов безопасности SQL Server с помощью средств SQLCHECK и Setspn
Если вы можете войти локально на компьютер SQL Server и получить доступ к администратору, используйте SQLCHECK. SQLCheck предоставляет большую часть сведений, необходимых для устранения неполадок в одном файле. Дополнительные сведения об использовании средства и собранных сведений см. на домашней странице средства. Вы также можете проверить рекомендуемые предварительные требования и страницу контрольного списка . После создания выходного файла проверьте конфигурацию имени субъекта-службы для экземпляра SQL Server в разделе Сведения об SQL Server выходного файла.
Пример результата:
Suggested SPN Exists Status
---------------------------------------------------------- ------ -------------------
MSSQLSvc/testsqlsvr.corp.com:2000 True Okay
MSSQLSvc/testsqlsvr.corp.com True Okay
MSSQLSvc/testsqlsvr:2000 False SPN does not exist.
MSSQLSvc/testsqlsvr False SPN does not exist.
Используйте эти выходные данные для определения следующих шагов (см. следующие примеры) и средства Setspn для выполнения необходимых действий по устранению проблем с SPN.
| Сценарий | Рекомендуемое действие |
|---|---|
| Имя субъекта-службы не существует | Добавьте необходимые SPN для учетной записи службы SQL Server. |
| Повторяющиеся имена субъектов-служб | Удалите имя субъекта-службы, зарегистрированное для службы SQL, в неправильной учетной записи. |
| Имя субъекта-службы в неправильной учетной записи | Удалите зарегистрированное имя субъекта-службы для службы SQL в неправильной учетной записи, а затем зарегистрируйте имя субъекта-службы в правильной учетной записи службы. |
| Неправильная регистрация имени участника-службы | Удалите неверное имя субъекта-службы и зарегистрируйте правильную имя участника-службы. |
Примечание.
Вы можете просмотреть раздел сведений SQL Server выходного файла средства SQLCHECK, чтобы найти учетную запись службы экземпляра SQL Server.
Setspn — это встроенное средство в более новых версиях Windows, которое помогает читать, добавлять, изменять или удалять имена субъектов-служб в Active Directory. Это средство можно использовать для проверки настройки имен субъектов-служб SQL Server в соответствии с регистрацией имени субъекта-службы для подключений Kerberos. Дополнительные сведения см. в статье о Setspn tool и примеры его использования.
Дополнительные сведения о сценариях, в которых SQL Server автоматически регистрирует имена субъектов-служб и где требуется регистрация имени субъекта-службы вручную, см. в разделе "Регистрация имени субъекта-службы для подключений Kerberos".
Проверка разрешений для учетной записи, используемой для запуска SQL Server, на связанном сервере.
Если вы используете олицетворения в качестве параметра проверки подлинности на странице безопасностисвязанного сервера, SQL Server должен передать входящие учетные данные удаленному СЕРВЕРУ SQL Server. Учетная запись запуска SQL Server, в которой определяется связанный сервер, должна иметь право «Учетная запись доверена для делегирования», назначенное в Active Directory. Дополнительные сведения см. в разделе Разрешение доверия к учетным записям компьютеров и пользователей при делегировании.
Примечание.
Этот шаг необходим только при устранении неполадок, связанных с запросами связанного сервера.
Часто задаваемые вопросы
Что такое SSPI?
Интерфейс поставщика поддержки безопасности (SSPI) — это набор API-интерфейсов Windows, которые разрешают делегирование и взаимную проверку подлинности с помощью транспортного уровня общих данных, такого как сокеты TCP/IP. Один или несколько программных модулей предоставляют фактические возможности проверки подлинности. Каждый модуль называется поставщиком поддержки безопасности (SSP) и реализуется как библиотека динамической компоновки (DLL).
Что такое Kerberos?
Протокол Kerberos v5 является стандартным отраслевым пакетом безопасности, а также одним из трех пакетов безопасности в операционных системах Windows. Дополнительные сведения см. в разделе Поставщики поддержки безопасности (SSP).
Что означает ошибка «Невозможно создать контекст SSPI»?
Эта ошибка означает, что SSPI пытается, но не может использовать проверку подлинности Kerberos для делегирования учетных данных клиента через TCP/IP или именованные каналы SQL Server. В большинстве случаев ошибка возникает из-за неправильно настроенного имени субъекта-службы (SPN).
Что такое SPN?
Имя субъекта-службы (SPN) — это уникальный идентификатор для экземпляра службы. Проверка подлинности Kerberos использует имена объектов службы для связывания экземпляра службы с учетной записью входа службы. Этот процесс связывания позволяет клиентским приложениям запрашивать у службы проверку подлинности учетной записи, даже если у клиента нет имени учетной записи.
Например, типичное имя субъекта-службы для сервера, на котором выполняется экземпляр SQL Server, выглядит следующим образом:
MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433
Формат имени субъекта-службы для экземпляра по умолчанию не отличается от формата имени субъекта-службы для именованного экземпляра. Привязка имени SPN к определенному экземпляру осуществляется с помощью номера порта. Дополнительные сведения о регистрации имен субъектов-служб SQL Server см. в разделе Регистрация имени субъекта-службы для подключений Kerberos.
Почему SSPI использует проверку подлинности NTLM или Kerberos?
Проверка подлинности Windows является предпочтительным методом проверки подлинности для доступа пользователей к SQL Server. Клиенты, использующие проверку подлинности Windows, выполняют проверку подлинности с помощью NTLM или Kerberos.
Если при подключении к удаленному серверу, на котором запущен SQL Server, клиент SQL Server использует интегрированную безопасность через сокеты TCP/IP, сетевая библиотека клиента SQL Server использует API-интерфейс SSPI для делегирования безопасности. Сетевой клиент SQL Server вызывает функцию AcquireCredentialsHandle и передает значение "negotiate" в параметр pszPackage. Таким образом, основной поставщик безопасности получает уведомление о начале согласованного делегирования. В этом контексте под согласованным понимается попытка выполнения проверки подлинности Kerberos или NTLM на компьютерах под управлением Windows. Другими словами, операционная система Windows использует делегирование Kerberos, если конечный компьютер, на котором запущен SQL Server, имеет связанное с ним и правильно настроенное имя субъекта-службы. В противном случае операционная система Windows использует делегирование NTLM. Если клиент SQL Server подключается локально на том же компьютере, где находится SQL Server, он всегда использует NTLM.
Почему не происходит переключение на NTLM после столкновения с проблемами Kerberos?
Когда драйвер использует проверку подлинности Windows для подключения к SQL Server, код драйвера SQL Server на клиенте использует сетевой API WinSock для разрешения полного доменного имени (DNS) сервера. Для выполнения этой операции код драйвера вызывает gethostbyname и gethostbyaddr WinSock API. Если вы используете встроенную безопасность, драйвер пытается разрешить полный DNS сервера, даже если вы передаете IP-адрес или имя узла в качестве имени сервера.
Когда драйвер SQL Server на клиенте разрешает полностью определённое DNS-имя сервера, он использует соответствующий DNS для формирования имени службы (SPN) для сервера. Таким образом, если WinSock не может разрешить IP-адрес или имя узла в полностью квалифицированное DNS-имя, драйвер SQL Server может создать недопустимое SPN для сервера.
Например, драйвер SQL Server на стороне клиента может использовать полное доменное имя (DNS) для разрешения некорректных SPN (имен главных служб) следующим образом:
MSSQLSvc/SQLSERVER1:1433MSSQLSvc/123.123.123.123:1433MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433
Если драйвер SQL Server формирует неправильное имя субъекта-службы, проверка подлинности продолжает выполняться, потому что интерфейс SSPI пытается найти имя субъекта-службы в службе Active Directory. Если интерфейс SSPI не находит имя субъекта-службы, проверка подлинности Kerberos не выполняется. На этом этапе уровень SSPI переключается на режим проверки подлинности NTLM, а вход использует проверку подлинности NTLM и обычно завершается успешно. Если драйвер SQL Server формирует допустимое имя субъекта-службы, которое не назначено соответствующему контейнеру, драйвер пытается, но не может использовать имя субъекта-службы. В этом случае может возникнуть ошибка "Не удается создать контекст SSPI". Если в качестве начальной учетной записи для запуска SQL Server используется локальная системная учетная запись, соответствующим контейнером является имя компьютера. В случае использования любой другой учетной записи соответствующим контейнером является начальная учетная запись для запуска SQL Server. При проверке подлинности используется первое найденное имя субъекта-службы, поэтому убедитесь, что имена субъектов-служб не назначены неправильным контейнерам. Это значит, что каждое имя субъекта-службы должно быть назначено только одному контейнеру.
Как проверить метод проверки подлинности подключения?
Чтобы определить метод проверки подлинности подключения, выполните следующий запрос:
SELECT net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;
Дополнительные сведения см. в разделе "Определение типа проверки подлинности" Kerberos.
Как создать SPN для SQL Server?
При запуске экземпляра СУБД SQL Server SQL Server пытается автоматически зарегистрировать SPN (имя субъекта-службы) для службы SQL Server с помощью API DsWriteAccountSpn . Этот вызов завершается успешно, учетная запись службы SQL Server имеет права на чтение servicePrincipalNameи запись servicePrincipalNameв Active Directory. В противном случае администратор Active Directory должен вручную зарегистрировать правильный SPN с помощью Microsoft Kerberos Manager для SQL Server или встроенного средства Setspn. Дополнительные сведения об управлении именами субъектов-служб для SQL Server см. в разделе "Регистрация имени субъекта-службы для подключений Kerberos".