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

Применяется к: SQL Server
Оригинальный номер базы знаний: 811889

При использовании проверки подлинности Windows для удаленного подключения к экземпляру SQL Server отображается следующее сообщение об ошибке:

Главное конечное имя неверно. Невозможно создать контекст SSPI.

Вопросы и ответы

Что такое 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?

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

Если драйвер SQL Server на клиенте разрешает полное DNS-имя сервера, соответствующее DNS-имя используется для формирования имени субъекта-службы для сервера. Поэтому любые проблемы, связанные с разрешением IP-адреса или имени узла в полное DNS-имя интерфейсом WinSock, могут привести к тому, что драйвер SQL Server создаст неправильное имя субъекта-службы для сервера.

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

• 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 формирует неправильное имя субъекта-службы, проверка подлинности продолжает выполняться, потому что интерфейс 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.

Как создать имена субъектов-служб для SQL Server?

При запуске экземпляра ядра СУБД SQL Server, SQL Server пытается автоматически зарегистрировать имя субъекта-службы для службы SQL Server с помощью API DsWriteAccountSpn. Этот вызов завершается успешно, учетная запись службы SQL Server имеет права на чтение servicePrincipalNameи запись servicePrincipalNameв Active Directory. В противном случае администратор Active Directory должен вручную зарегистрировать правильное имя субъекта-службы с помощью Microsoft Kerberos Manager для SQL Server или встроенного средства Setspn. Дополнительные сведения об управлении именами субъектов-служб для SQL Server см. в разделе "Регистрация имени субъекта-службы для подключений Kerberos".

Исправление ошибки с Configuration Manager Kerberos (рекомендуется)

Существуют различные причины сбоя подключений Kerberos, такие как неправильно настроенные имена субъектов-служб, проблемы с разрешением имен или недостаточно прав для учетных записей запуска SQL Server службы. Microsoft Kerberos Configuration Manager (KCM) — это средство, которое помогает проверить причины ошибки. KCM также предоставляет варианты для устранения всех выявленных проблем в процессе.

Для устранения ошибок с помощью KCM выполните эти действия.

1. На компьютере, на котором у вас есть проблемы с подключением, скачайте и установите Kerberos Configuration Manager.

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

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

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

   Состояние	Дополнительные сведения	Действие
   Good	Элемент, для которого установлен флажок, настроен правильно. Вы можете перейти к следующему элементу в выходных данных.	Никаких действий не требуется
   Отсутствует обязательное имя субъекта-службы	Это состояние сообщается, когда имя субъекта-службы, указанное в столбце "Обязательное имя субъекта-службы", отсутствует для учетной записи запуска SQL Server в Active Directory.	1. Выберите "Исправление", чтобы просмотреть сведения в диалоговом окне "Предупреждение". 2. Выберите "Да", чтобы добавить отсутствующее имя субъекта-службы в Active Directory. 3. Если у вашей учетной записи домена есть необходимые разрешения для обновления Active Directory, необходимое имя субъекта-службы будет добавлено в Active Directory. 4. Если у вашей учетной записи домена нет необходимых разрешений для обновления Active Directory, используйте команду Создать или Создать все , чтобы создать скрипт, который поможет администратору Active Directory добавить отсутствующие имена субъектов-служб. 5. После добавления имен субъектов-служб запустите KerberosConfiguration Manager еще раз, чтобы убедиться, что проблемы с именем субъекта-службы устранены. 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. Дополнительные сведения см. в разделе Включение или отключение сетевого протокола сервера.
   Динамический порт	Это сообщение отображается для именованных экземпляров, использующих динамические порты (конфигурация по умолчанию). В средах, где для подключения к SQL Server необходимо использовать Kerberos, следует задать для именованного экземпляра статический порт и использовать этот порт при регистрации имени субъекта-службы.	Чтобы настроить экземпляр 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-порта.
   Повторяющееся имя субъекта-службы	Вы можете столкнуться с ситуацией, когда одно и то же имя субъекта-службы регистрируется в разных учетных записях в Active Directory.	1. Нажмите кнопку Исправить, просмотрите сведения в диалоговом окне Предупреждение и нажмите Да, если вы можете добавить отсутствующее имя субъекта-службы в Active Directory. 2. Если у вашей учетной записи домена есть необходимые разрешения для обновления Active Directory, неправильное имя субъекта-службы будет удалено. 3. Если у вашей учетной записи в домене нет необходимых разрешений для обновления Active Directory, нажмите кнопку Создать или Создать все, чтобы создать необходимый скрипт, который можно отправить администратору Active Directory для удаления повторяющихся имен субъектов-служб. После удаления имен субъектов-служб повторно запустите KCM, чтобы убедиться, что проблемы с именем субъекта-службы устранены.

   Примечание.

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

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

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

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

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

Главный фактор успешной проверки подлинности 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 см. в разделе Обзор командлета.

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

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

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

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

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

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

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

Шаг 3. Проверка SQL Server имен субъектов-служб с помощью средств SQLCHECK и Setpn

Если вы можете выполнить локальный вход на компьютер 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 для выполнения необходимых действий по исправлению проблем с именами субъектов-служб.

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

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

См. также

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