Ошибка "Не удается создать контекст SSPI" при использовании проверки подлинности Windows для подключения к SQL Server

Применяется к: 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.

1. На компьютере, на котором возникают проблемы с подключением, скачайте и установите Диспетчер конфигурации Kerberos.

2. Начните KerberosConfigMgr.exe из папки %SystemDrive%:\Program Files\Microsoft\Kerberos Configuration Manager. Затем используйте учетную запись домена с разрешениями для подключения к компьютеру SQL Server, к которому не удается подключиться.

3. Выберите Connect, оставив имя сервера и другие сведения пустыми при запуске KCM на компьютере SQL Server. Выберите "Подключиться ", чтобы выполнить анализ. После того как KCM завершит получение необходимой информации, он автоматически переключится на вкладку SPN и по умолчанию отобразит сведения о SQL Server, SQL Server Reporting Services, Analysis Services и прослушивателях групп доступности. Чтобы устранить эту ошибку, снимите все параметры, кроме SQL Server.

4. Просмотрите результаты диагностики из средства с помощью столбца Status и выполните соответствующие действия, чтобы устранить проблему.

   Состояние	Дополнительная информация	Действие
   Хорошо	Элемент, для которого установлен флажок, настроен правильно. Вы можете перейти к следующему элементу в выходных данных.	Никаких действий не требуется
   Отсутствует обязательный SPN	KCM сообщает о таком состоянии, когда SPN, указанный в столбце Required SPN, отсутствует в Active Directory у учетной записи, под которой запускается SQL Server.	1. Выберите "Исправление", чтобы просмотреть сведения в диалоговом окне "Предупреждение". 2. Выберите Да, чтобы добавить отсутствующий SPN в Active Directory. 3. Если у учетной записи домена есть необходимые разрешения для обновления Active Directory, необходимый SPN добавляется в Active Directory. 4. Если у учетной записи домена нет необходимых разрешений для обновления Active Directory, используйте Создать или Создать все, чтобы сгенерировать скрипт, который позволит администратору Active Directory добавить отсутствующие SPNs. 5. После добавления SPN, запустите Диспетчер конфигурации Kerberos еще раз, чтобы убедиться, что проблемы с SPN устранены. 6. Кроме того, можно использовать следующие команды: - Используйте SETSPN -Q spnName, чтобы найти SPN и его текущие учетные записи. — Используйте SETSPN -D, чтобы удалить SPN из неверной учетной записи.
   Для использования конфигурации Kerberos необходимо включить протокол TCP	Эта ошибка возникает, если tcp не включен на клиентском компьютере.	Чтобы включить протокол TCP/IP для экземпляра SQL Server, выполните следующие действия. 1. В диспетчере конфигурации SQL Server, в области консоли, разверните Конфигурация сети SQL Server. 2. В панели консоли выберите Protocols для <имени экземпляра>. 3. В области сведений щелкните правой кнопкой мыши параметр TCP/IP и выберите пункт "Включить". 4. В области консоли выберите SQL Server Services. 5. В области сведений щелкните правой кнопкой мыши SQL Server (<имя экземпляра>), а затем выберите Перезапустить, чтобы остановить и перезапустить службу SQL Server. Дополнительные сведения см. в разделе Включение или отключение сетевого протокола сервера.
   Динамический порт	Это сообщение отображается для именованных экземпляров, использующих динамические порты (конфигурация по умолчанию). В средах, где необходимо использовать Kerberos для подключения к SQL Server, задайте именованный экземпляр на статический порт и используйте этот порт при регистрации SPN.	Чтобы настроить экземпляр SQL Server для использования статического порта выполните следующие шаги: 1. В диспетчере конфигурации SQL Server в области консоли разверните Конфигурация сети SQL Server, разверните Протоколы для <имя экземпляра>, а затем дважды щелкните TCP/IP. 2. В диалоговом окне Свойства TCP/IP проверьте параметр Прослушивать все на вкладке Протокол. 3. Если для параметра Прослушивать все задано значение Да, перейдите на вкладку IP-адреса и прокрутите страницу до нижней части окна программы Windows, чтобы найти параметр IPAll. Удалите текущее значение, содержащееся в поле Динамические TCP-порты, и задайте нужное значение в поле TCP-порт. Нажмите кнопку ОК и перезапустите экземпляр SQL Server, чтобы изменение этих параметров вступило в силу. 4. Если для параметра Прослушивать все задано значение Нет, перейдите на вкладку IP-адреса и проверьте каждый из IP-адресов, отображаемых в IP1, IP2. Для включенных IP-адресов удалите текущее значение, содержащееся в поле Динамические TCP-порты, и задайте нужное значение в поле TCP-порт. Нажмите кнопку ОК и перезапустите экземпляр SQL Server, чтобы изменение этих параметров вступило в силу. Дополнительные сведения см. в разделе Настройка сервера для прослушивания определенного TCP-порта.
   Дублирующийся SPN	Эта ситуация возникает, когда один и тот же SPN регистрируется в разных учетных записях в Active Directory.	1. Выберите кнопку Исправить, ознакомьтесь со сведениями в диалоговом окне Предупреждение и выберите Да, если вы можете добавить отсутствующий SPN в Active Directory. 2. Если у вашей учетной записи домена есть необходимые разрешения для обновления Active Directory, то неправильный SPN удаляется. 3. Если у вашей доменной учетной записи нет необходимых разрешений для внесения изменений в Active Directory, используйте кнопку Создать или Создать все, чтобы сгенерировать нужный скрипт, который можно передать администратору Active Directory для удаления дубликатов SPN. После удаления SPN повторно запустите KCM, чтобы убедиться, что проблемы с SPN устранены.

   Примечание.

   Если учетная запись домена, которая запускает KCM, не имеет привилегий для управления Именами Идентификаторов Служб в Active Directory, используйте соответствующую кнопку "Создать" или "Создать все" в столбце скриптов SPN для генерации необходимых команд. Обратитесь к администратору Active Directory, чтобы устранить проблемы, которые идентифицирует KCM.

5. После устранения всех проблем, которые KCM идентифицирует, повторно запустите средство. Убедитесь, что о других проблемах не сообщается, а затем повторите попытку подключения. Если средство по-прежнему сообщает о проблемах, повторите предыдущую процедуру.

Исправление ошибки без использования Kerberos Configuration Manager

Если вы не можете использовать KCM, выполните следующие шаги:

Проверка разрешения имен с помощью команды ping

Ключевой фактор, который делает проверку подлинности Kerberos успешной, является допустимой функциональностью DNS в сети. Эту функциональность можно проверить как на клиенте, так и на сервере с помощью служебной программы командной строки Ping. На клиентском компьютере выполните следующую команду, чтобы получить IP-адрес сервера, работающего SQL Server (где имя компьютера SQLServer1):

ping sqlserver1

Чтобы проверить, определяет ли утилита Ping полное доменное имя (FQDN) для 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> преобразуется в правильное полное доменное имя (FQDN) компьютера, на котором работает SQL Server, то разрешение имени на стороне клиента также выполняется успешно.

Для получения подробной диагностики используйте командлет Test-NetConnection или Test-Connection для проверки подключения TCP в зависимости от версии PowerShell, установленной на компьютере.

Проверьте, существуют ли псевдонимы для целевого SQL Server в диспетчере конфигурации SQL Server и в служебной программе клиентской сети SQL Server. Если такой псевдоним существует, убедитесь, что он настроен правильно, проверяя имена серверов, сетевой протокол, номер порта и т. д. Псевдоним SQL Server может вызвать непредвиденное создание SPN. Эта проблема приводит к использованию учетных данных NTLM, если SPN не найден, или сбою SSPI, если это непреднамеренно соответствует SPN другого сервера.

Проверка связи между доменами

Убедитесь, что домен, в который вы входите, может взаимодействовать с доменом сервера, на котором выполняется SQL Server. Домен также должен иметь правильное разрешение DNS.

1. Убедитесь, что вы можете войти в Windows с помощью той же учетной записи домена и пароля, что и учетная запись запуска службы SQL Server. Например, ошибка SSPI может возникать в одной из следующих ситуаций:

   • учетная запись домена заблокирована;
   • После изменения пароля не перезагрузите службу SQL Server.

2. Если домен входа отличается от домена сервера, на котором выполняется SQL Server, проверьте связь доверия между доменами.

3. Проверьте, находятся ли домен, к которому относится сервер, и учетная запись домена, которую вы используете для подключения, в одном лесу. Выполнение этого шага необходимо для работы SSPI.

Проверка SPN SQL Server с помощью средств SQLCHECK и Setspn

Если вы можете войти локально на компьютер SQL Server и получить доступ к администратору, используйте SQLCHECK. SQLCheck предоставляет большую часть сведений, необходимых для устранения неполадок в одном файле. Дополнительные сведения об использовании средства и собранных сведений см. на домашней странице средства. Кроме того, можно проверить рекомендуемые предварительные требования и контрольный список. После того как вы создадите выходной файл, проверьте конфигурацию SPN для вашего экземпляра SQL Server в разделе SQL Server Information выходного файла.

Пример результата:

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.

Проверка разрешений для учетной записи, используемой для запуска SQL Server, на связанном сервере.

Если вы используете олицетворения в качестве параметра проверки подлинности на странице безопасностисвязанного сервера, SQL Server должен передать входящие учетные данные удаленному СЕРВЕРУ SQL Server. Учетная запись запуска SQL Server, в которой определяется связанный сервер, должна иметь право «Учетная запись доверена для делегирования», назначенное в Active Directory. Дополнительные сведения см. в разделе Настройка доверия учетных записей компьютеров и пользователей для делегирования.

Часто задаваемые вопросы

Что такое SSPI?

Security Support Provider Interface (SSPI) — это набор API Windows, который позволяет выполнять делегирование и взаимную проверку подлинности по любому универсальному уровню транспорта данных, например сокетам TCP/IP. Один или несколько программных модулей предоставляют фактические возможности проверки подлинности. Каждый модуль называется поставщиком поддержки безопасности (SSP) и реализуется как библиотека динамической компоновки (DLL).

Что такое Kerberos?

Протокол Kerberos v5 является стандартным отраслевым пакетом безопасности, а также одним из трех пакетов безопасности в операционных системах Windows. Дополнительные сведения см. в разделе Поставщики поддержки безопасности (SSP).

Что означает ошибка «Невозможно создать контекст SSPI»?

Эта ошибка означает, что SSPI пытается, но не может использовать проверку подлинности Kerberos для делегирования учетных данных клиента в SQL Server через TCP/IP или именованные каналы. В большинстве случаев ошибка возникает из-за неправильно настроенного имени субъекта-службы (SPN).

Что такое SPN?

Имя субъекта-службы (SPN) — это уникальный идентификатор для экземпляра службы. Проверка подлинности Kerberos использует имена объектов службы для связывания экземпляра службы с учетной записью входа службы. Этот процесс сопоставления позволяет клиентскому приложению запрашивать службу для проверки подлинности учетной записи, даже если у клиента нет имени учетной записи.

Например, типичное имя субъекта-службы для сервера, на котором запущен экземпляр SQL Server, выглядит следующим образом:

MSSQLSvc/SQLSERVER1.northamerica.corp.mycompany.com:1433

Формат SPN для экземпляра по умолчанию совпадает с форматом SPN для именованного экземпляра. Именно номер порта связывает SPN с конкретным экземпляром. Дополнительные сведения о регистрации SPN служб SQL Server см. в разделе Регистрация SPN для подключений 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. Этот процесс уведомляет базового поставщика безопасности о необходимости согласовать делегирование. В этом контексте «negotiate» означает попытку использовать проверку подлинности Kerberos или NTLM на компьютерах с Windows. Другими словами, Windows использует делегирование Kerberos, если целевой компьютер, на котором работает SQL Server, имеет связанный с ним и правильно настроенный SPN (имя субъекта-службы). В противном случае операционная система Windows использует делегирование NTLM. Если клиент SQL Server подключается локально на том же компьютере, где находится SQL Server, он всегда использует NTLM.

Почему не происходит переключение на NTLM после столкновения с проблемами Kerberos?

Когда драйвер использует проверку подлинности Windows для подключения к SQL Server, код драйвера SQL Server на клиенте использует сетевой API WinSock для разрешения полного доменного имени (DNS) сервера. Чтобы выполнить эту операцию, код драйвера вызывает API WinSock gethostbyname и gethostbyaddr. Если вы используете встроенную безопасность, драйвер пытается разрешить полный DNS сервера, даже если вы передаете IP-адрес или имя узла в качестве имени сервера.

Когда драйвер SQL Server на клиенте разрешает полностью определённое DNS-имя сервера, он использует соответствующий DNS для формирования имени службы (SPN) для сервера. Таким образом, если WinSock не может разрешить IP-адрес или имя узла в полностью квалифицированное DNS-имя, драйвер SQL Server может создать недопустимое SPN для сервера.

Например, драйвер SQL Server на стороне клиента может использовать полное доменное имя (DNS) для разрешения некорректных SPN (имен главных служб) следующим образом:

• MSSQLSvc/SQLSERVER1:1433
• MSSQLSvc/123.123.123.123:1433
• MSSQLSvc/SQLSERVER1.antartica.corp.mycompany.com:1433
• MSSQLSvc/SQLSERVER1.dns.northamerica.corp.mycompany.com:1433

Если драйвер SQL Server формирует недопустимый SPN, аутентификация всё равно выполняется, поскольку интерфейс SSPI пытается найти SPN в службе Active Directory. Если интерфейс SSPI не находит SPN, аутентификация Kerberos не выполняется. На этом этапе уровень SSPI переключается на режим проверки подлинности NTLM, а вход использует проверку подлинности NTLM и обычно завершается успешно. Если драйвер SQL Server формирует допустимый SPN (имя субъекта-службы), который не назначен соответствующему контейнеру, драйвер пытается использовать этот SPN, но не может. В этом случае может возникнуть ошибка "Не удается создать контекст SSPI". Если в качестве начальной учетной записи для запуска SQL Server используется локальная системная учетная запись, соответствующим контейнером является имя компьютера. В случае использования любой другой учетной записи соответствующим контейнером является начальная учетная запись для запуска SQL Server. При аутентификации используется первый найденный SPN, поэтому убедитесь, что SPN не назначены неправильным контейнерам. Иными словами, каждое SPN должно быть назначено только одному контейнеру.

Как проверить метод проверки подлинности подключения?

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

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 Configuration Manager для SQL Server или встроенного средства Setspn. Дополнительные сведения об управлении именами участников-служб (SPN) для SQL Server см. в разделе Зарегистрируйте имя участника-службы для подключений Kerberos.

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

• Устранение проблем с подключением в SQL Server
• Устранение постоянных проблем с аутентификацией
• Клиентское средство SSPI
• Включение ведения журнала событий Kerberos
• Как заставить Kerberos использовать TCP вместо UDP в Windows