Примечание. Диспетчер конфигурации Kerberos является инструментом, который помогает устранять проблемы с подключением к SQL Server, связанные с протоколом Kerberos. Эти проблемы могут вызывать такие ошибки, как «Не удается генерировать контекст SSPI». Данный инструмент в настоящее время находится в открытом доступе и доступен для скачивания по ссылке:

http://www.microsoft.com/downloads/ru-ru/details.aspx

Дополнительные сведения см. в следующих статьях базы знаний Майкрософт:

New tool: "Microsoft Kerberos Configuration Manager for SQL Server" is ready to resolve your Kerberos/Connectivity issues (Новый инструмент: «диспетчер конфигурации Microsoft Kerberos для SQL Server» готов помочь в устранении проблем с протоколом Kerberos / проблем подключения)

Диспетчер конфигурации Kerberos для SQL Server уже доступен

 

В данном разделе приведена справочная информация о причинах возникновения сообщения об ошибке «Не удается генерировать контекст SSPI», а также способы устранения этой ошибки. Данное сообщение об ошибке появляется при выполнении следующих условий:

  • осуществляется подключение к серверу Microsoft SQL Server;

  • используется встроенная система безопасности;

  • для делегирования маркера безопасности используется проверка подлинности Kerberos.

Понимание терминологии Kerberos и имя субъекта-службы (SPN) Драйвер SQL Server на клиентском компьютере с помощью встроенной системы безопасности использует маркер безопасности Windows, связанный с учетной записью пользователя, для успешного подключения к компьютеру, на котором запущен SQL Server. Маркер безопасности Windows делегируется клиентом компьютеру, на котором запущен SQL Server. Драйвер SQL Server выполняет делегирование, когда один компьютер делегирует маркер безопасности пользователя другому компьютеру с помощью одной из следующих конфигураций:

  • NTLM через именованные каналы (без использования интерфейса поставщика поддержки безопасности [SSPI])

  • NTLM через сокеты TCP/IP с использованием SSPI

  • Проверка подлинности Kerberos через сокеты TCP/IP с использованием SSPI

Интерфейс поставщика поддержки безопасности (SSPI) — это набор API-интерфейсов Windows, которые разрешают делегирование и взаимную проверку подлинности с помощью транспортного уровня общих данных, такого как сокеты TCP/IP. Поэтому интерфейс SSPI разрешает компьютеру под управлением операционной системы Windows безопасно делегировать маркер безопасности пользователя другому компьютеру с помощью любого транспортного уровня, поддерживающего побайтную передачу необработанных данных.

Ошибка «Не удается генерировать контекст SSPI» появляется, когда интерфейс SSPI использует проверку подлинности Kerberos для делегирования через протокол TCP/IP, а проверка подлинности Kerberos не может завершить операции, необходимые для успешного делегирования маркера безопасности пользователя конечному компьютеру, на котором запущен SQL Server.

Причины выбора проверки подлинности NTLM или Kerberos в интерфейсе поставщика поддержки безопасности Проверка подлинности Kerberos использует идентификатор с именем «Имя субъекта-службы» (SPN). Имя SPN — это уникальный идентификатор домена или леса для некоторого экземпляра в сетевых ресурсах сервера. Имя SPN может иметь веб-служба, служба SQL или служба SMTP. Можно также иметь несколько экземпляров веб-служб на одном и том же физическом компьютере, обладающем уникальным именем SPN.

Имя SPN сервера SQL Server состоит из следующих элементов:

  • Класс_службы: определяет общий класс службы. Для SQL Server всегда используется MSSQLSvc.

  • Узел: это DNS полного имени домена компьютера, на котором запущен SQL Server.

  • Порт: номер порта, который прослушивается службой.

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


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

Формат имени SPN для экземпляра по умолчанию не отличается от формата имени SPN для именованного экземпляра. Привязка имени SPN к определенному экземпляру осуществляется с помощью номера порта.

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

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

Например, неправильные имена SPN, которые драйвер 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 формирует неправильное имя SPN, проверка подлинности продолжает выполняться, потому что интерфейс SSPI пытается найти имя SPN в службе каталогов Active Directory и не находит его. Если интерфейс SSPI не находит имя SPN, проверка подлинности Kerberos не выполняется. В этом случае уровень SSPI переключается на режим проверки подлинности NTLM. Проверка подлинности NTLM, которая используется при входе, обычно выполняется успешно. Если драйвер SQL Server формирует правильное имя SPN, но для него не назначен правильный контейнер, драйвер пытается использовать имя SPN, однако не может сделать этого, поэтому появляется сообщение об ошибке «Не удается генерировать контекст SSPI». Если в качестве начальной учетной записи для запуска SQL Server используется локальная системная учетная запись, соответствующим контейнером является имя компьютера. В случае использования любой другой учетной записи соответствующим контейнером является начальная учетная запись для запуска SQL Server. Поскольку при проверке подлинности используется первое найденное имя SPN, убедитесь в отсутствии имен SPN, назначенных в неправильные контейнеры. Это значит, что каждое имя SPN должно быть назначено только одному контейнеру.

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

ping sqlserver1 Чтобы выяснить, разрешает ли программа командной строки Ping полное имя DNS компьютера SQLServer1, выполните следующую команду:

ping -a IP-адрес Пример: 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 IP-адрес разрешает правильное полное DNS-имя компьютера, на котором запущен SQL Server, разрешение на стороне клиента также выполняется успешно.

Создание имени субъекта-службы SQL Server Это одна из важнейших частей проверки подлинности Kerberos и взаимодействия с SQL Server. С помощью SQL Server вы можете запустить службу SQL Server под следующими видами учетных записей: учетная запись LocalSystem, учетная запись локального пользователя или учетная запись пользователя домена. После запуска экземпляр службы SQL Server пытается зарегистрировать собственное имя SPN в службе каталогов Active Directory, вызвав API-интерфейс DsWriteAccountSpn. В случае неудачного вызова в окне «Просмотр событий» появляется следующее предупреждение. Дополнительные сведения о функции DsWriteAccountSpn см. на странице веб-сайта Майкрософт:

http://msdn2.microsoft.com/library/ms676056.aspx

Упрощенное объяснение Если вы запускаете службу SQL Server под учетной записью LocalSystem, происходит автоматическая регистрация имени SPN, а проверка подлинности Kerberos успешно взаимодействует с компьютером, на котором запущен SQL Server. Если служба SQL Server запущена с помощью учетной записи пользователя домена или с помощью локальной учетной записи, попытка создания имени SPN в большинстве случаев не будет успешной, так как учетная запись домена и локальная учетная запись не имеют права задавать собственные имена SPN. Если имя SPN создать не удалось, это означает, что компьютер, на котором запущено приложение SQL Server, не будет иметь имени SPN. Если в ходе проверки в качестве учетной записи службы SQL Server используется учетная запись администратора домена, удается создать имя SPN, так как существуют учетные данные уровня администратора домена, необходимые для создания имени SPN.

Так как для запуска службы SQL Server учетная запись администратора домена может не использоваться (в целях предотвращения угрозы безопасности), компьютер, на котором запущен SQL Server, не может создать собственное имя SPN. Если при подключении к компьютеру, на котором запущен SQL Server, требуется использовать проверку подлинности Kerberos, необходимо создать имя SPN вручную. Необходимо сделать это и в том случае, если SQL Server запущен с помощью учетной записи администратора домена или локальной учетной записи. Создаваемое имя SPN должно быть назначено учетной записи службы SQL Server на этом компьютере. Имя SPN нельзя назначить контейнеру компьютера, если для запуска компьютера с SQL Server используется локальная системная учетная запись. Имя SPN должно быть единственным и должно быть назначено соответствующему контейнеру. Как правило, в такой ситуации будут использоваться текущая учетная запись службы SQL Server и контейнер учетной записи компьютера с локальной системной учетной записью.
 

 

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

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

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

    • учетная запись домена заблокирована;

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

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

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

  4. При запуске SQL Server используйте параметр Учетная запись доверена для делегирования компонента «Пользователи и компьютеры Active Directory».


    Примечание. Разрешение «Учетная запись доверена для делегирования» необходимо только в случае делегирования учетных данных от целевого SQL Server к удаленному SQL Server, например, в сценариях с двойным прыжком, таких как распределенные запросы (запросы от связанного сервера), которые используют проверку подлинности Windows.

  5. Используйте служебную программу Manipulate Service Principal Names for Accounts (SetSPN.exe), входящую в состав набора ресурсов Windows 2000 Resource Kit. Учетные записи администраторов домена Windows 2000 или учетные записи администраторов домена Windows 2003 могут использовать эту служебную программу для управления именами SPN, которые назначаются службе и учетной записи. SQL Server может иметь только одно имя SPN. Имя SPN должно быть присвоено соответствующему контейнеру. Таким контейнером в большинстве случаев является текущая учетная запись службы SQL Server и учетная запись компьютера, если приложение SQL Server запускается с помощью локальной системной учетной записи. Если при запуске SQL Server пользователь уже вошел в систему с помощью учетной записи LocalSystem, выполняется автоматическая настройка имени SPN. Если для запуска SQL Server используется учетная запись домена или учетная запись, используемая для запуска SQL Server, была изменена, необходимо запустить служебную программу SetSPN.exe, чтобы удалить просроченные имена SPN. Затем нужно добавить действительное имя SPN. Дополнительные сведения см. в теме "Security Account Delegation" (делегирование учетной записи безопасности) электронной документации на SQL Server 2000. Для этого посетите следующий веб-сайт корпорации Майкрософт:

    http://msdn2.microsoft.com/ru-ru/library/aa905162(SQL.80).aspx Дополнительные сведения о наборах ресурсов Windows 2000 Resource Kit см. на следующем веб-сайте корпорации Майкрософт:

    http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/default.mspx?mfr=true

  6. Проверьте правильность разрешения имен. В разрешении имен могут участвовать службы DNS и WINS, файлы HOSTS и LMHOSTS. Дополнительные сведения о неполадках при разрешении имен и их устранении см. в следующей статье базы знаний Майкрософт:

    169790 Как устранить основные неполадки, возникающие при использовании протокола TCP/IP
     

  7. Дополнительные сведения об устранении проблем доступности и брандмауэра в Active Directory см. в следующих статьях базы знаний Майкрософт:

    291382 Вопросы и ответы о службе DNS в Windows 2000 и Windows Server 2003
     

    224196 Ограничение трафика репликации Active Directory и клиентского трафика RPC на определенный порт

Настройка службы SQL Server для динамического создания имен SPN для экземпляров SQL Server Чтобы настроить службу SQL Server для динамического создания имен SPN, необходимо изменить для учетной записи параметры управления доступом в службе каталогов Active Directory. Предоставьте учетной записи службы SQL Server разрешения "Read servicePrincipalName" и "Write servicePrincipalName".

Внимание! Неправильное изменение атрибутов объектов Active Directory с помощью оснастки «Редактирование интерфейсов ADSI», служебной программы LDP или любого другого клиента LDAP версии 3 может привести к возникновению серьезных неполадок. В некоторых случаях для их устранения потребуется переустановить Windows 2000 Server, Windows Server 2003, Exchange 2000 Server, Exchange Server 2003 или операционную систему Windows одновременно с сервером Exchange. Корпорация Майкрософт не гарантирует решения проблем, возникающих по причине неправильного изменения объектов Active Directory. Ответственность за результаты выполненных действий несет пользователь.

Примечание. Для предоставления соответствующих разрешений и прав пользователя учетной записи SQL Server необходимо войти в систему с учетной записью администратора домена или попросить администратора домена выполнить эту задачу.

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

  1. Нажмите кнопку Пуск, выберите пункт Выполнить, введите запрос Adsiedit.msc и нажмите кнопку ОК.

  2. В оснастке «Редактирование интерфейсов ADSI» разверните раздел Домен [имя_домена], DC= имя_корневого_домена и CN=Users, щелкните правой кнопкой мыши запись CN= имя_учетной_записи, а затем щелкните пункт Свойства.

    Примечания

    • имя_домена — это заполнитель для имени вашего домена.

    • имя_корневого_домена — это заполнитель для имени вашего корневого домена.

    • имя_учетной_записи — заполнитель для учетной записи, выбранной для службы SQL Server.

    • Если для запуска службы SQL Server выбрана учетная запись Local System, то имя_учетной_записи — это заполнитель для учетной записи, которая использовалась для входа в Microsoft Windows.

    • Если для запуска службы SQL Server выбрана учетная запись пользователя домена, то имя_учетной_записи — это заполнитель для учетной записи пользователя домена.

  3. В диалоговом окне CN= имя_учетной_записи_свойства щелкните вкладку Безопасность.

  4. На вкладке Безопасность нажмите кнопку Дополнительно.

  5. Убедитесь, что в диалоговом окне Дополнительные параметры безопасности в списке Элементы разрешений присутствует параметр SELF.

    Если параметр SELF отсутствует, нажмите кнопку Добавить для добавления SELF.

  6. В списке Элементы разрешений щелкните запись SELF, а затем – кнопку Изменить.

  7. В диалоговом окне Элемент разрешения откройте вкладку Свойства.

  8. На вкладке Свойства установите флажок Только для этого объекта в списке Применить к, и удостоверьтесь, что установлены флажки для следующих разрешений в списке Разрешения:

    • чтение servicePrincipalName

    • запись servicePrincipalName

  9. Нажмите кнопку ОК три раза и закройте оснастку редактирования интерфейсов ADSI.

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


Важно! Корпорация Майкрософт не рекомендует наделять учетную запись службы SQL правом WriteServicePrincipalName при выполнении следующих условий:

  • присутствует несколько контроллеров доменов;

  • SQL Server кластеризован.

В таком сценарии имя SPN для SQL Server может быть удалено из-за задержек в репликации Active Directory. Это может вызывать проблемы подключения к экземпляру SQL Server.

Предположим, что у вас есть:

  • виртуальный экземпляр SQL с именем Sqlcluster и двумя узлами: узел A и узел B;

  • проверка подлинности узла A выполняется контроллером домена A, а проверка подлинности узла B выполняется контроллером домена B.



Происходит следующее:

  1. Экземпляр Sqlcluster активен в узле A и зарегистрировал имя SQL SPN в контроллере домена A во время запуска.

  2. При нормальном отключении узла А экземпляр Sqlcluster выполняет резервное переключение на узел B.

  3. В ходе процесса выключения узла А экземпляр Sqlcluster отменяет регистрацию своего SPN в контроллере домена A.

  4. Имя SPN удаляется из контроллера домена A, однако репликация изменений в контроллер домена B еще не была выполнена.

  5. При запуске на узле B экземпляр Sqlcluster пытается зарегистрировать свой SQL SPN в контроллере домена B. Однако поскольку SPN по-прежнему существует, узел B не регистрирует его.

  6. Через некоторое время контроллер домена A выполняет репликацию удаления имени SPN (из шага 3) в контроллер домена B в рамках процесса репликации Active Directory. Конечным результатом будет отсутствие допустимого имени SPN для экземпляра SQL, и именно поэтому вы наблюдаете проблемы с подключением к экземпляру Sqlcluster.


Примечание. Эта проблема исправлена в SQL Server 2012.

Проверка среды сервера Проверьте основные параметры компьютера, на котором установлен SQL Server.

  1. Проверка подлинности Kerberos не поддерживается на компьютерах под управлением Windows 2000 с запущенной кластеризацией Windows, кроме случаев, когда установлен пакет обновлений 3 (или более поздняя версия) для Windows 2000. Поэтому любая попытка использовать проверку подлинности SSPI в кластерном экземпляре SQL Server может оказаться неудачной. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:

    235529 Поддержка проверки подлинности Kerberos в кластерах серверов под управлением Windows 2000
     

  2. Убедитесь, что сервер работает под управлением Windows 2000 с пакетом обновления 1 (SP1). Дополнительные сведения о поддержке проверки подлинности Kerberos на серверах под управлением Windows 2000 см. в следующей статье базы знаний Майкрософт:

    267588 Сообщение об ошибке «Не удается генерировать контекст SSPI» появляется при подключении к SQL Server 2000
     

  3. Если на кластере изменилась учетная запись, использовавшаяся для запуска SQL Server, агента SQL Server или служб полнотекстового поиска (например, изменился пароль), выполните действия, описанные в следующей статье базы знаний Майкрософт:

    239885 Как изменить учетные записи служб для кластеризованного компьютера с работающим SQL Server
     

  4. Убедитесь, что используемая учетная запись для запуска SQL Server обладает соответствующими разрешениями. Если используемая учетная запись не является членом группы «Локальные администраторы», подробный список разрешений, которыми должна обладать учетная запись, см. в теме «Setting up Windows Services Accounts» (настройка учетных записей служб Windows) в электронной документации на SQL Server:

    http://msdn2.microsoft.com/ru-ru/library/aa176564(SQL.80).aspx

Проверка среды клиента Проверьте на стороне клиента следующее:

  1. Убедитесь, что на стороне клиента правильно установлен и запущен поставщик поддержки безопасности NTLM. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:

    269541 Сообщение об ошибке «Не удается генерировать контекст SSPI» при подключении к SQL Server, если отсутствует раздел реестра, связанный с поставщиком поддержки безопасности NT LM Windows
     

  2. Определите, используются ли кэшированные учетные данные. Если для входа в клиентский компьютер используются кэшированные учетные данные, выйдите из системы, а затем снова войдите в нее, если есть возможность подключиться к контроллеру домена и предотвратить использование кэшированных учетных данных. Дополнительные сведения об определении возможного использования кэшированных учетных данных см. в следующей статье базы знаний Майкрософт:

    242536 Отсутствует оповещение, когда для входа в домен используются кэшированные учетные данные
     

  3. Проверьте правильность дат на клиентском компьютере и на сервере. Если даты существенно различаются, сертификаты могут считаться недействительными.

  4. Интерфейс SSPI использует файл Security.dll. Если какое-либо другое приложение установит файл с таким именем, вместо исходного файла SSPI может использовать другой файл. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:

    253577 Ошибка: 80004005 – драйвер MS ODBC SQL Server не может инициализировать пакет SSPI
     

  5. Если на клиентском компьютере установлена операционная система Microsoft Windows 98, на этом компьютере необходимо установить компонент «Клиент для сетей Microsoft».

    Дополнительные сведения см. в следующей статье базы знаний Майкрософт:

    267550 ОШИБКА: «Ошибка утверждения» при использовании протокола TCP/IP для подключения к SQL Server
     

Проверка программы Client Network Utility Программа CNU (Client Network Utility) поставляется вместе с компонентами MDAC и используется для настройки подключения к компьютерам, на которых запущен SQL Server. Используйте программу CNU Cliconfg.exe, входящую в состав MDAC, для настройки подключения.

  1. Способ определения протоколов на вкладке General (общее) зависит от версии MDAC. При использовании более ранних версий MDAC можно выбрать протокол «по умолчанию». Если используется одна из последних версий MDAC, при подключении к SQL Server можно включить один или несколько протоколов с помощью одного, находящегося в верхней части списка. Так как интерфейс SSPI связан только с протоколом TCP/IP, во избежание ошибки можно использовать другой протокол, например именованные каналы.

  2. В программе CNU перейдите на вкладку Псевдоним, чтобы проверить, определен ли псевдоним для сервера, к которому выполняется подключение. Если псевдоним сервера определен, проверьте параметры подключения этого компьютера к SQL Server. С целью проверки удалите псевдоним сервера и выясните, изменилось ли поведение.

  3. Если псевдоним сервера, к которому выполняется подключение, в программе CNU не определен, добавьте его. При этом можно также явно задать протокол и дополнительно определить IP-адрес и порт.

Настройка имени субъекта-службы SQL Server вручную Дополнительные сведения о настройке имени субъекта-службы SQL Server см. в следующей статье базы знаний Майкрософт:

319723 Как использовать проверку подлинности Kerberos в SQL Server
  Интерфейс поставщика поддержки безопасности (SSPI) – это интерфейс безопасности Microsoft Windows NT, который используется проверкой подлинности Kerberos и поддерживает схему проверки поставщика поддержки безопасности NTLM. Проверка подлинности выполняется в операционной системе при входе в домен Windows. Проверка подлинности Kerberos доступна только на компьютерах под управлением Windows 2000, на которых включена проверка подлинности Kerberos и используется служба Active Directory.

Интерфейс SSPI используется только для подключений по протоколу TCP/IP. Для создания подключений требуется проверка подлинности Windows. Проверка подлинности Windows также называется доверительными соединениями или встроенной системой безопасности. Интерфейс SSPI не используется именованными каналами или если соединения поддерживают несколько протоколов. Поэтому во избежание неполадок можно настроить клиентские компьютеры таким образом, чтобы при подключении использовался протокол, отличный от TCP/IP.

Если при подключении к удаленному компьютеру, на котором запущен SQL Server, клиент SQL Server пытается использовать интегрированную безопасность через сокеты TCP/IP, сетевая библиотека клиента SQL Server использует API-интерфейс SSPI для делегирования безопасности. Сетевой клиент SQL Server (Dbnetlib.dll) вызывает функцию AcquireCredentialsHandle и передает значение "negotiate" в параметр pszPackage. Таким образом, основной поставщик безопасности получает уведомление о начале согласованного делегирования. В этом контексте под согласованием понимается попытка выполнения проверки подлинности Kerberos или NTLM на компьютерах под управлением Windows. Другими словами, операционная система Windows использует делегирование Kerberos, если конечный компьютер, на котором запущен SQL Server, имеет связанное с ним и правильно настроенное имя SPN. В противном случае операционная система Windows использует делегирование NTLM.

Примечание. Убедитесь, что для запуска служб SQL Server (MSSQLServer, SQLServerAgent, MSSearch) не используется учетная запись SYSTEM. Ключевое слово SYSTEM может вызвать конфликт с центром распространения ключей (KDC).
 

 

Если причину неполадки не удалось устранить даже с помощью способов, приведенных в этой статье, соберите следующие сведения и обратитесь в службу поддержки пользователей Майкрософт (CSS).

Полный список телефонов службы поддержки пользователей Майкрософт, а также сведения об условиях обслуживания см. на следующем сайте Майкрософт:

http://support.microsoft.com/ru-ru/contactus/?ws=support

  1. С помощью SQL Server создайте отчет sqldiag. Дополнительные сведения см. в теме "sqldiag Utility" (служебная программа sqldiag) электронной документации на SQL Server.

  2. Сделайте снимок экрана ошибки на клиентском компьютере.

  3. Откройте командную строку на узле, который не может подключиться к SQL Server, и введите следующую команду:

    net start > started.txt Эта команда создает файл с названием Started.txt в том каталоге, в котором вы выполняете команду.

  4. Сохраните значения раздела реестра в следующем разделе реестра на клиентском компьютере:

    HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\MSSQLSERVER\CLIENT\CONNECTTO

  5. В среде кластера для каждого узла получите значение следующего раздела реестра:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\LMCompatibilityLevel

  6. В среде кластера выясните, существует ли на каждом узле следующий раздел реестра:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTLMSsp

  7. Запишите результаты подключения клиентского компьютера к SQL Server при использовании имени в формате UNC (или имени SQL Network Name на кластере).

  8. Запишите результаты выполнения команды ping для имени компьютера (или имени SQL Network Name на кластере).

  9. Сохраните имена учетных записей пользователей, используемых для запуска каждой службы SQL Server (MSSQLServer, SQLServerAgent, MSSearch).

  10. Специалист службы поддержки должен знать, какой тип проверки подлинности настроен в SQL Server — смешанная проверка подлинности или проверка подлинности Windows.

  11. Выясните, может ли клиентский компьютер подключиться к компьютеру, на котором запущен SQL Server, используя проверку подлинности SQL Server.

  12. Выясните, можно ли подключиться с помощью протокола именованных каналов.

Ссылки Дополнительные сведения о работе проверки подлинности Kerberos и безопасности SSPI см. в следующих статьях базы знаний Майкрософт:

266080 Вопросы и ответы о проверке подлинности Kerberos
 

231789 Локальный вход в систему Windows 2000
 

304161 Взаимная проверка подлинности SSPI указывается на стороне клиента, но не указывается на стороне сервера
 

232179 Администрирование Kerberos в Windows 2000
 

230476 Описание стандартных ошибок, имеющих отношение к Kerberos, в Windows 2000
 

262177 Как включить ведение журнала событий Kerberos
 

277658 Не удается использовать служебную программу Setspn, если имя домена отличается от имени NetBIOS, которое использовалось для регистрации имени SPN для SQL Server

244474 Как принудить Kerberos работать с протоколом TCP вместо UDP в Windows Server 2003, Windows XP и Windows 2000
  Для просмотра документа «Безопасность Microsoft SQL Server 2000» посетите следующий веб-сайт корпорации Майкрософт:

http://technet.microsoft.com/cc984178.aspx

Нужна дополнительная помощь?

Совершенствование навыков
Перейти к обучению
Первоочередный доступ к новым возможностям
Присоединение к программе предварительной оценки Майкрософт

Были ли сведения полезными?

Насколько вы удовлетворены качеством перевода?
Что повлияло на вашу оценку?

Спасибо за ваш отзыв!

×