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


90

Я изо всех сил пытаюсь получить соединение SQL Server с машины A на машину B, на которой работает SQL Server.

Я много гуглил, и все, что я нашел, не сработало. Они также не проводят вас шаг за шагом через процесс решения этой проблемы.

Мы не используем Kerberos, а NTLM там, где он настроен.

введите описание изображения здесь

Вовлеченные машины (xx используется, чтобы скрыть часть имени машины в целях безопасности):

  • xxPRODSVR001 - Контроллер домена Windows Server 2012
  • xxDEVSVR003 - Windows Server 2012 (этот компьютер генерирует ошибку)
  • xxDEVSVR002 - Windows Server 2012 (на этом компьютере работает SQL Server 2012)

Следующие SPN зарегистрированы на DC (xxPRODSVR001). Я скрыл домен с помощью yyy в целях безопасности:

Зарегистрированные ServicePrincipalNames для CN = xxDEVSVR002, CN = Computers, DC = yyy, DC = local:

            MSSQLSvc/xxDEVSVR002.yyy.local:49298

            MSSQLSvc/xxDEVSVR002.yyy.local:TFS

            RestrictedKrbHost/xxDEVSVR002

            RestrictedKrbHost/xxDEVSVR002.yyy.local

            Hyper-V Replica Service/xxDEVSVR002

            Hyper-V Replica Service/xxDEVSVR002.yyy.local

            Microsoft Virtual System Migration Service/xxDEVSVR002

            Microsoft Virtual System Migration Service/xxDEVSVR002.yyy.local

            Microsoft Virtual Console Service/xxDEVSVR002

            Microsoft Virtual Console Service/xxDEVSVR002.yyy.local

            SMTPSVC/xxDEVSVR002

            SMTPSVC/xxDEVSVR002.yyy.local

            WSMAN/xxDEVSVR002

            WSMAN/xxDEVSVR002.yyy.local

            Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/xxDEVSVR002.yyy.local

            TERMSRV/xxDEVSVR002

            TERMSRV/xxDEVSVR002.yyy.local

            HOST/xxDEVSVR002

            HOST/xxDEVSVR002.yyy.local

Зарегистрированные ServicePrincipalNames для CN = xxDEVSVR003, CN = Computers, DC = yyy, DC = local:

            MSSQLSvc/xxDEVSVR003.yyy.local:1433

            MSSQLSvc/xxDEVSVR003.yyy.local

            Hyper-V Replica Service/xxDEVSVR003

            Hyper-V Replica Service/xxDEVSVR003.yyy.local

            Microsoft Virtual System Migration Service/xxDEVSVR003

            Microsoft Virtual System Migration Service/xxDEVSVR003.yyy.local

            Microsoft Virtual Console Service/xxDEVSVR003

            Microsoft Virtual Console Service/xxDEVSVR003.yyy.local

            WSMAN/xxDEVSVR003

            WSMAN/xxDEVSVR003.yyy.local

            TERMSRV/xxDEVSVR003

            TERMSRV/xxDEVSVR003.yyy.local

            RestrictedKrbHost/xxDEVSVR003

            HOST/xxDEVSVR003

            RestrictedKrbHost/xxDEVSVR003.yyy.local

            HOST/xxDEVSVR003.yyy.local

Теперь, если бы только сообщение об ошибке SQL Server было более наглядным и сообщало мне, с каким основным именем он пытался подключиться, я мог бы диагностировать это.

Так может ли кто-нибудь объяснить мне, как решить эту проблему, или вы видите что-нибудь в том, что я указал, что неправильно?

Я был бы рад предоставить больше отладочной информации, просто скажите, что вам нужно.


У нас нет внутреннего DNS-сервера. Но чтобы устранить это как проблему, вы говорите, что я должен «ping -a xxxx» или есть другой способ определить, есть ли дубликаты?
TheEdge

Я не эксперт, но я думал, что SPN и SSPI относятся к Kerberos? Вы уверены, что не используете Kerberos?
Дилан Смит

@DylanSmith Не то, чтобы я мог видеть ... Когда я запускал SP на SQL Server (забудьте имя сейчас), все получилось как NTLM. Вы знаете, как я проверяю?
TheEdge

Я знаю, что вопрос старый, поэтому сэкономьте время и запустите этот инструмент: microsoft.com/en-us/download/…
Эдуардо,

Ответы:


57

У меня была эта проблема с приложением ASP.NET MVC, над которым я работал.

Я понял, что недавно изменил свой пароль, и я смог исправить это, выйдя из системы и снова войдя в систему.


1
Это была моя проблема. пароль изменен. в моей учетной записи был запущен пул приложений.
Драгос Дурлут

когда у меня возникла эта проблема, я вышел из системы и снова зашел. Решил проблему.
shary.sharath

Похожая проблема. Это помогло мне оглянуться на свои действия. TQ
Reddy

24

Я получил эту ошибку при подключении через SQL Server Management Studio с использованием проверки подлинности Windows. Срок действия моего пароля истек, но я еще не менял его. После изменения мне пришлось выйти и снова войти в систему, чтобы машина работала с моими новыми учетными данными.


22

Попробуйте установить, Integrated Security=trueчтобы удалить этот параметр из строки подключения.


ВАЖНО: как прокомментировал пользователь @Auspex,

Удаление встроенной безопасности предотвратит эту ошибку, поскольку ошибка возникает при попытке войти в систему с вашими учетными данными Windows. К сожалению, в большинстве случаев вы хотите иметь возможность входить в систему с учетными данными Windows.


Как это удалить, если соединение через SSMS?
Джефф Доуди,

23
Ну, очевидно , удаление Integrated Security будет предотвратить эту ошибку, потому что ошибка возникает при попытке входа в систему с помощью учетных данных Windows. К сожалению, в большинстве случаев вы хотите иметь возможность входить в систему с учетными данными Windows!
Auspex

2
@GeoffDawdy, мой ответ ниже может помочь? Это произошло из-за просроченного пароля, который потребовал от меня изменить свой пароль, выйти из системы и снова войти, а затем все работало как обычно.
Мэтт Шеперд

3
Сэкономьте время и запустите этот инструмент: microsoft.com/en-us/download/…
Эдуардо,

15

Я получал ту же ошибку при попытке проверки подлинности Windows. Звучит нелепо, но на всякий случай это поможет кому-то другому: это произошло из-за того, что моя учетная запись домена каким-то образом была заблокирована, пока я все еще был в системе (!). Разблокировка учетной записи исправила это.


12

Я входил в Windows 10 с помощью PIN-кода вместо пароля. Вместо этого я вышел из системы и снова вошел в систему, используя свой пароль, и смог войти в SQL Server через Management Studio.


Это нелепо. И это сработало. Я потратил на это столько времени. Спасибо!
mcb2k3

2
Ой, это было не совсем так. SSMS переключился на меня, когда я не смотрел, и вернулся к своей учетной записи SQL Server. Но я наконец попытался переключиться с использования учетной записи Microsoft для локального входа в систему с использованием локальной учетной записи локально. Это помогло, и, похоже, теперь это работает, даже если я вхожу в систему с помощью своего ПИН-кода.
mcb2k3

Да, использование пароля вместо пин-кода также помогло мне. +1 для Microsoft.
BrunoMartinsPro

О, МОЙ БОГ! Я не могу поверить, что это действительно имело значение!
arni

8

Просто чтобы добавить еще одно возможное решение этой самой неоднозначной ошибки The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider):

Убедитесь, что IP-адрес, разрешенный при проверке связи с SQL Server, совпадает с IP-адресом в Configuration Manager. Чтобы проверить, откройте диспетчер конфигурации SQL Server, а затем перейдите в раздел «Сетевая конфигурация SQL Server»> «Протоколы для MSSQLServer»> «TCP / IP».

Убедитесь, что TCP / IP включен, и на вкладке IP-адреса убедитесь, что IP-адрес, который сервер разрешает при пинге, совпадает с этим. Это исправило эту ошибку для меня.


8

Ошибка контекста SSPI определенно указывает на попытку аутентификации с использованием Kerberos .

Поскольку проверка подлинности Kerberos Проверка подлинности Windows SQL Server зависит от Active Directory , что требует наличия взаимосвязи между вашим компьютером и контроллером сетевого домена, вам следует начать с проверки этой взаимосвязи.

Вы можете быстро проверить эту взаимосвязь с помощью следующей команды Powershell Test-ComputerSecureChannel .

Test-ComputerSecureChannel -verbose

введите описание изображения здесь

Если он возвращает False , вы должны восстановить на своем компьютере безопасный канал Active Directory, так как без него проверка учетных данных домена за пределами вашего компьютера невозможна.

Вы можете восстановить свой Computer Secure Channel с помощью следующей команды Powershell :

Test-ComputerSecureChannel -Repair

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

Проверка подлинности NTLM может дать сбой, поэтому предпринимается попытка проверки подлинности Kerberos. Вы также можете увидеть сбой попытки входа NTLM в журнал событий безопасности?

Вы можете включить регистрацию событий kerberos в dev, чтобы попытаться отладить, почему происходит сбой kerberos, хотя это очень подробное сообщение.

Диспетчер конфигурации Microsoft Kerberos для SQL Server может помочь вам быстро диагностировать и исправить эту проблему.

Вот хорошая история для чтения: http://houseofbrick.com/microsoft-made-an-easy-button-for-spn-and-double-hop-issues/


Это устранило проблему для меня. SPN были зарегистрированы не для того объекта пользователя в Active Directory. Диспетчер конфигурации Kerberos для SQL Server исправил это двумя щелчками мыши!
Крейг - MSFT

6

Проблема, похоже, связана с учетными данными Windows. Я получал ту же ошибку на своем рабочем ноутбуке с VPN. Я предположительно вошел в систему как мой домен / имя пользователя, что я успешно использую при прямом подключении, но как только я перехожу на VPN с другим подключением, я получаю эту ошибку. Я думал, что это проблема с DNS, поскольку я мог проверить связь с сервером, но оказалось, что мне нужно было запустить SMSS явно как мой пользователь из командной строки.

например, runas / netonly / user: YourDoman \ YourUsername "C: \ Program Files (x86) \ Microsoft SQL Server Management Studio 18 \ Common7 \ IDE \ Ssms.exe"


У меня была аналогичная проблема (iMac vpn с виртуальной машиной Windows). Я решил это, добавив DNS-серверы моей работы в настройки сети Wi-Fi моего Mac. Я предполагаю, что есть способ получше, но он помог мне.
Эрик Пирсон,

5

Войдите как в свой SQL Box, так и в свой клиент, и введите:

ipconfig /flushdns
nbtstat -R

Если это не сработает, обновите DHCP на вашем клиентском компьютере ... Это работает для 2 ПК в нашем офисе.


сделал ли ваш ответ на моей клиентской машине и SQL Box plus, ipconfig/releaseа также ipconfig/renewна моей клиентской машине, и это не сработало для меня; (
AlbatrossCafe

4

Я просто столкнулся с этим и исправил это, выполнив 2 вещи:

  1. Предоставление разрешений на чтение и запись servicePrincipalName учетной записи службы с помощью ADSI Edit, как описано в https://support.microsoft.com/en-us/kb/811889
  2. Удаление SPN, которые ранее существовали в учетной записи компьютера SQL Server (в отличие от учетной записи службы) с помощью

    setspn -D MSSQLSvc/HOSTNAME.domain.name.com:1234 HOSTNAME
    

    где 1234 - это номер порта, используемый экземпляром (мой не был экземпляром по умолчанию).


Я переключил экземпляр MS SQL Server с работы на использование NT Service\MSSQLSSERVERв качестве управляемой учетной записи службы. После этого SSMS может подключаться к базе данных локально на сервере, но не удаленно с моего ноутбука. Исправление имен SPN решило проблему.
Hydrargyrum

4

В моем случае перезапуск SQL Server 2014 (на моем сервере разработки) устранил проблему.


То же
самое с

4

Я тестировал IPv6 на кластере ПК в изолированной сети и столкнулся с этой проблемой, когда вернулся к IPv4. Я играл в активном каталоге, DNS и DHCP, поэтому понятия не имею, что я толкнул, чтобы нарушить настройку Kerberos.

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

https://blogs.msdn.microsoft.com/steverac/2010/12/13/test-remote-sql-connectivity-easily/

затем после краткого поиска нашел это на веб-сайте Microsoft https://support.microsoft.com/en-gb/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context-error-message .

запустите инструмент на SQL-сервере и посмотрите, есть ли какие-либо проблемы, если в статусе отображается ошибка, затем нажмите появившуюся кнопку исправления.

Это решило проблему для меня.


3

Обычно это происходит из-за отсутствия, неправильного или повторяющегося имени принципа службы (SPN).

Шаги по разрешению:

  1. Подтвердите, какую учетную запись AD использует SQL Server
  2. Выполните следующую команду в Powershell или CMD в режиме администратора (учетная запись службы не должна содержать домен)
setspn -L <ServiceAccountName> | Select-String <ServerName> | select line
  1. Убедитесь, что возвращенные выходные данные содержат полное имя участника-службы, не полностью квалифицированное, с портом и без порта.

    Ожидаемый результат:

    Registered ServicePrincipalNames for CN=<ServiceAccountName>,OU=CSN Service Accounts,DC=<Domain>,DC=com: 
    MSSQLSvc/<ServerName>.<domain>.com:1433
    MSSQLSvc/<ServerName>:1433                                           
    MSSQLSvc/<ServerName>.<domain>.com
    MSSQLSvc/<ServerName>
    
  2. Если вы не видите всего вышеперечисленного, выполните следующую команду в PowerShell или CMD в режиме администратора (обязательно измените порт, если вы не используете по умолчанию 1433)

SETSPN -S  MSSQLSvc/<ServerName> <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>.<Domain> <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>:1433 <Domain>\<ServiceAccountName> 
SETSPN -S  MSSQLSvc/<ServerName>.<Domain>:1433 <Domain>\<ServiceAccountName>
  1. После завершения вышеуказанного обычно для распространения DNS требуется несколько минут.

Кроме того, если вы получаете сообщение об обнаружении повторяющихся имен SPN, вы можете удалить их и создать заново.


2

У меня возникла эта проблема при доступе к веб-приложению. Возможно, это связано с тем, что я недавно изменил пароль Windows.

Эта проблема была решена, когда я обновил пароль для пула приложений, в котором я разместил веб-приложение.


2

Проверьте совпадение часов между клиентом и сервером.

Когда у меня периодически возникала эта ошибка, ни один из вышеперечисленных ответов не работал, тогда мы обнаружили, что время на некоторых из наших серверов сдвинулось, после того как они снова синхронизировались, ошибка исчезла. Найдите w32tm или NTP, чтобы узнать, как автоматически синхронизировать время в Windows.


1

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

Я нормально подключался к SQL Server, пока моя машина не была перемещена в другой офис в другом домене . Затем, после переключения, я получал эту ошибку относительно целевого основного имени. Что исправлено, это подключение с использованием полного имени, например: server.domain.com . И на самом деле, как только я подключился к первому серверу таким образом, я мог подключиться к другим серверам, используя только имя сервера (без полной квалификации), но ваш опыт может отличаться.


Эта проблема возникла у меня только тогда, когда я добавил сертификат в соединение SQL. Сертификат был выдан на полное доменное имя, поэтому, когда я подключаюсь к полному доменному имени \ экземпляру, он работал.
Slogmeister Extraordinaire

1

Я столкнулся с этим сегодня и хотел поделиться своим исправлением, так как это просто игнорируется и его легко исправить.

Мы управляем нашим собственным rDNS и недавно переделали схему именования серверов. В рамках этого мы должны были обновить наш rDNS и забыть об этом.

Пинг вернул правильное имя хоста, но пинг -a вернул неправильное имя хоста.

Простое исправление: измените rDNS, выполните ipconfig / flushdns, подождите 30 секунд (как раз то, что я делаю), сделайте еще один ping -a, посмотрите, как он разрешает правильное имя хоста, подключитесь ... прибыль.


1

Я столкнулся с новым для этого: SQL 2012, размещенным на сервере 2012. Было поручено создать кластер для SQL AlwaysOn.
Кластер создан, все получили сообщение SSPI.

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

setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService

DomainNamerunningSQLService== учетная запись домена, которую я установил для SQL. Мне нужен администратор домена для выполнения команды. Только один сервер в кластере имел проблемы.

Затем перезапустил SQL. К моему удивлению, мне удалось подключиться.


У меня была такая же проблема, но не в кластере. Я изменил вход для службы SQL Engine в учетную запись домена. Мне пришлось удалить MSSQLSvc/SERVER_FQNName:*SPN из учетной записи компьютера, а затем добавить их в учетную запись пользователя, на котором запущена служба.
Slogmeister Extraordinaire

1

Я пытался подключиться к виртуальной машине с SQL Server 2015 со своего ноутбука в консольном приложении Visual Studio 2015. Я запускаю свое приложение накануне вечером, и все в порядке. Утром пытаюсь отладить приложение и получаю эту ошибку. Пробовал ipconfig/flushи release+ renewи еще куча другой фигни, но в итоге ...

Перезагрузите виртуальную машину и перезапустите клиент. Это исправило это для меня. Я должен был знать, перезагрузка работает каждый раз.


Аналогичный опыт SQLServer 2016 на ВМ. Не знаю, почему начали разрывать соединения. Перезагрузка виртуальной машины исправила это, не перезагружая клиента.
youcantryreachingme

1

У меня была эта проблема на моем сервере sql. Я установил spn -D mssqlsvc \ Hostname.domainname Hostname, затем остановил и запустил мою службу SQL-сервера.

Я думаю, что просто остановка и запуск моей службы sql сделали бы это.


Это то, что я сделал после сравнения setspn -L <Hostname>с работающим сервером. Оказалось, что все работающие экземпляры не имеют зарегистрированного SPN. Я действительно не знаю, что делаю, но очевидно, что без регистрации этих SPN можно использовать NTLM. Благодарность!
BenderBoy

Имейте в виду, что на самом деле это не решение, если вы хотите использовать Kerberos вместо NTLM, как вам, очевидно, следует: serverfault.com/a/384721 . Фактически, это решение в основном отключает аутентификацию Kerberos.
BenderBoy

1

У меня была такая же проблема, но блокировка и разблокировка машины помогли мне. Иногда проблемы с брандмауэром приводят к ошибкам.

Я не уверен, что это сработает для вас или нет, просто поделитесь своим опытом.


1

Я пробовал все решения здесь, и ни одно из них еще не сработало. Обходной путь, который работает: нажмите « Подключить» , введите имя сервера, выберите «Параметры», вкладку «Свойства подключения». Установите «Сетевой протокол» на «Именованные каналы». Это позволяет пользователям удаленно подключаться, используя свои сетевые учетные данные. Я выложу обновление, когда получу исправление.


Я фактически установил свой "TCP / IP". Я не знаю,
устранил

1

В моем случае проблема заключалась в настройке DNS на Wi-Fi. Я удалил настройки, оставил их пустыми и работал.

Como ficou minha configuração do DNS


1

Убедитесь, что «Именованные каналы» включены в «Диспетчере конфигурации SQL Server». Это сработало для меня.

  1. Откройте «Диспетчер конфигурации SQL Server».
  2. В списке слева разверните «Конфигурация сети SQL Server».
  3. Выберите «Протоколы для [Имя вашего экземпляра]».
  4. Щелкните правой кнопкой мыши «Именованные каналы» в списке справа.
  5. Выберите "Включить"
  6. Перезапустите службу экземпляров.

1
У меня было такое же сообщение. Я пытался подключиться по IP, поэтому сделал это как stackoverflow.com/users/8568873/s3minaki , т.е. шаги 1-6, но я включил TCP / IP вместо именованных каналов. Также в IPALL я очистил динамический порт TCP и вместо этого установил порт TCP. Убедитесь, что этот порт не работает на других экземплярах, иначе экземпляр не перезапустится. Мне также нужен пользователь SQL, проверка подлинности Windows не работает. В SQL Manager вы подключаетесь с помощью xxxx \ instancename, portnr. т.е. 127.0.0.1 \ SQLEXPRESS, 1433
Tomas Hesse


1

В моей ситуации я пытался использовать Integrated Security для подключения с ПК к SQL Server на другом ПК в сети без домена. На обоих компьютерах я входил в Windows с одной и той же учетной записью Microsoft . Я переключился на локальную учетную запись на обоих ПК, и теперь SQL Server успешно подключается.


1

В моем случае, поскольку я работал в своей среде разработки, кто-то отключил контроллер домена, и учетные данные Windows не могли быть аутентифицированы. После включения контроллера домена ошибка исчезла, и все заработало нормально.


1

Еще одна ниша в этом вопросе - сетевые подключения. Я подключаюсь через клиент Windows VPN, и эта проблема возникла, когда я переключился с Wi-Fi на проводное соединение. Исправление для моей ситуации заключалось в том, чтобы вручную настроить метрику адаптера.

В PowerShell используйте Get-NetIPInterface, чтобы просмотреть все значения метрик. Меньшие числа имеют меньшую стоимость, поэтому им отдают предпочтение окна. Я переключил Ethernet и VPN, и учетные данные оказались там, где они должны были быть для SSMS, чтобы быть счастливым.

Чтобы настроить функцию автоматической метрики: На панели управления дважды щелкните «Сетевые подключения». Щелкните правой кнопкой мыши сетевой интерфейс и выберите «Свойства». Щелкните Протокол Интернета (TCP / IP), а затем выберите Свойства. На вкладке Общие выберите Дополнительно. Чтобы указать метрику, на вкладке «Параметры IP» снимите флажок «Автоматическая метрика», а затем введите нужную метрику в поле «Метрика интерфейса».

Источник: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/automatic-metric-for-ipv4-routes


0

Я столкнулся с вариантом этой проблемы, вот характеристики:

  • Пользователь смог успешно подключиться к именованному экземпляру, например, подключение к Server\Instanceбыло успешным
  • Пользователь не смог подключиться к экземпляру по умолчанию, например, Serverне удалось подключиться со снимком экрана OP относительно SSPI.
  • Пользователь не смог подключить экземпляр по умолчанию с полным именем, например, соединение Server.domain.comне удалось (тайм-аут)
  • Пользователь не смог подключиться к IP-адресу без именованного экземпляра, например, 192.168.1.134не удалось подключиться к
  • Другие пользователи, не входящие в домен (например, пользователи, подключенные к сети через VPN), но использующие учетные данные домена, смогли успешно подключиться к экземпляру по умолчанию и IP-адресу.

Итак, после многих головных болей в попытках выяснить, почему этот единственный пользователь не может подключиться, вот шаги, которые мы предприняли, чтобы исправить ситуацию:

  1. Взгляните на сервер в списке SPN, используя расширение
    setspn -l Server
    . В нашем случае было сказаноServer.domain.com
  2. Добавьте запись в файл hosts, расположенный в C:\Windows\System32\drivers\etc\hosts(запустите Блокнот от имени администратора, чтобы изменить этот файл). Добавленная нами запись была
    Server.domain.com Server

После этого мы смогли успешно подключиться через SSMS к экземпляру по умолчанию.


0

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.