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

Я изо всех сил пытаюсь получить соединение 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 было более наглядным и сообщало мне, с каким основным именем он пытался подключиться, я мог бы диагностировать это.

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

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

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

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

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

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

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

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

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

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

Просто чтобы добавить еще одно возможное решение этой самой неоднозначной ошибки 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-адрес, который сервер разрешает при пинге, совпадает с этим. Это исправило эту ошибку для меня.

Ошибка контекста 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/

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

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

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

ipconfig /flushdns
nbtstat -R

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

Я просто столкнулся с этим и исправил это, выполнив 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 - это номер порта, используемый экземпляром (мой не был экземпляром по умолчанию).

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

Я тестировал 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-сервере и посмотрите, есть ли какие-либо проблемы, если в статусе отображается ошибка, затем нажмите появившуюся кнопку исправления.

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

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

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

1. Подтвердите, какую учетную запись AD использует SQL Server
2. Выполните следующую команду в Powershell или CMD в режиме администратора (учетная запись службы не должна содержать домен)

setspn -L <ServiceAccountName> | Select-String <ServerName> | select line

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

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

   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>
   

4. Если вы не видите всего вышеперечисленного, выполните следующую команду в 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>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService

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

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

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

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

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

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

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

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

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

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

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

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

Этот инструмент Microsoft похож на Magic. Запустите его, подключите к серверу SQL и нажмите Исправить.

Старая версия, связанная здесь, работала на SQL Server 2017.

Диспетчер конфигурации Kerberos для SQL Server https://www.microsoft.com/en-us/download/details.aspx?id=39046

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

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

Еще одна ниша в этом вопросе - сетевые подключения. Я подключаюсь через клиент 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

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

• Пользователь смог успешно подключиться к именованному экземпляру, например, подключение к 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 к экземпляру по умолчанию.

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