Неправильне ім’я головного цільового користувача. Не вдається створити контекст 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 зареєстровані на постійному струмі (xxPRODSVR001). З міркувань безпеки я затулив домен yyy:

Зареєстрована службаPrincipalNames для CN = xxDEVSVR002, CN = Комп’ютери, DC = ррр, DC = локальна:

            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

Зареєстрована службаPrincipalNames для CN = xxDEVSVR003, CN = Комп’ютери, DC = ррр, DC = локальна:

            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.

Помилка контексту SSPI однозначно вказує на спробу автентифікації за допомогою Kerberos .

Оскільки автентифікація Kerberos для аутентифікації Windows Server SQL покладається на Active Directory , яка вимагає надійного взаємозв’язку між вашим комп’ютером та контролером мережевого домену, вам слід розпочати перевірку цього зв’язку.

Ви можете швидко перевірити ці стосунки за допомогою наведеної нижче команди Powershell Test-ComputerSecureChannel .

Test-ComputerSecureChannel -verbose

Якщо повертається False , ви повинні відновити захищений канал вашого комп'ютера Active Directory, оскільки без нього жодна перевірка облікових записів домену неможлива поза вашим комп'ютером.

Ви можете відновити захищений канал свого комп’ютера за допомогою наступної команди Powershell :

Test-ComputerSecureChannel -Repair

Перевірте журнали подій безпеки, якщо ви використовуєте kerberos, ви повинні побачити спроби входу з пакетом автентифікації: Kerberos.

Можливо, помилка автентифікації NTLM є, і тому робиться спроба автентифікації kerberos. Ви також можете побачити помилку спроби входу в NTLM у своєму журналі подій безпеки?

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

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

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

Просто для того, щоб додати ще одне потенційне рішення цієї найбільш неоднозначної помилки The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider):

Переконайтеся, що IP-адреса, яка вирішується при пінгуванні SQL Server, така ж, як і в диспетчері конфігурацій. Щоб перевірити, відкрийте диспетчер конфігурації SQL Server, а потім перейдіть до Конфігурація мережі SQL Server> Протоколи для MSSQLServer> TCP / IP.

Переконайтеся, що TCP / IP увімкнено, а на вкладці IP-адреси переконайтеся, що IP-адреса, на яку сервер розпізнає при пінгуванні, тут однаковий. Це виправило цю помилку для мене.

Видається, що це проблема з обліковими даними 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. Переконайтесь, що повернутий вивід містить SPN, який є повністю кваліфікованим, не повністю кваліфікованим, з портом і без порту.

   Очікуваний результат:

   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 потрібно кілька хвилин

Крім того, якщо ви отримаєте повідомлення про знайдені дублікати імен-носіїв, ви можете видалити їх і відтворити

У мене була ця проблема під час доступу до веб-програми. Можливо, це пов’язано з тим, що я нещодавно змінив пароль Windows.

Ця проблема вирішилася, коли я оновив пароль для пулу програм, де я розміщував веб-програму.

Перевірте відповідність годинника між клієнтом та сервером.

Коли ця помилка періодично виникала, жодна з наведених відповідей не спрацювала, то ми виявили, що час змінився на деяких наших серверах, як тільки вони знову синхронізувались, помилка зникла. Шукайте w32tm або NTP, щоб побачити, як автоматично синхронізувати час у Windows.

Оскільки я приземлився тут, шукаючи рішення власної проблеми, я поділюсь своїм рішенням тут, на випадок, якщо тут також приземляться інші.

Я добре підключався до SQL Server, поки мою машину не перенесли в інший офіс в іншому домені . Потім, після перемикання, я отримував цю помилку щодо цільового імені головного. Що було виправлено, це було підключення за допомогою повноцінного імені, такого як: server.domain.com . І насправді, як тільки я підключився до першого сервера таким чином, я міг підключатися до інших серверів, використовуючи лише ім'я сервера (без повної кваліфікації), але ваш пробіг може відрізнятися.

Я зіткнувся з цим сьогодні і хотів поділитися своїм виправленням, оскільки це просто не помічається і легко виправляється.

Ми управляємо власним rDNS і нещодавно переробили схему іменування серверів. Як частину цього, нам слід було оновити наш rDNS і забути це зробити.

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

Простота виправлення: змініть rDNS, виконайте ipconfig / flushdns, зачекайте 30 секунд (просто те, що я роблю), виконайте ще один пінг -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-сервері. Потім я встановивpn -D mssqlsvc \ Hostname.domainname Ім'я хосту зупинив і запустив службу SQL-сервера.

Я думаю, що просто зупинившись і запустивши службу sql, це було б зроблено.

У мене була та сама проблема, але блокування та розблокування машини працювали у мене. Іноді проблеми з брандмауером дають помилки.

Я не впевнений, що це спрацює у вас чи ні, просто поділившись своїм досвідом.

Я спробував усі рішення тут, і жодне з них ще не працювало. Обхідним шляхом, яке працює, є натискання кнопки « Підключитися» , введення імені сервера, вибір «Параметри», вкладка «Властивості підключення». Встановіть для «Мережевого протоколу» значення «Іменовані канали». Це дозволяє користувачам віддалено підключатися за допомогою своїх облікових даних мережі. Я опублікую оновлення, коли отримаю виправлення.

У моєму випадку проблема полягала в налаштуванні DNS на wi-fi. Я видалив налаштування, залишив їх порожніми і працював.

Переконайтеся, що "Іменовані труби" увімкнено з "Диспетчера конфігурацій SQL Server". Це спрацювало для мене.

1. Відкрийте "Диспетчер конфігурації SQL Server".
2. Розгорніть "Налаштування мережі SQL Server" зі списку ліворуч.
3. Виберіть "Протоколи для [Вашого імені екземпляра]".
4. Клацніть правою кнопкою миші на "Іменовані труби" зі списку праворуч.
5. Виберіть "Увімкнути"
6. Перезапустіть службу Instance.

Цей інструмент Microsoft схожий на Magic. Запустіть його, підключіть до SQL-сервера та натисніть Виправити

Стара посилання тут працювала на SQL Server 2017.

Kerberos Configuration Manager для SQL Server https://www.microsoft.com/en-us/download/details.aspx?id=39046

У моїй ситуації я намагався використовувати інтегровану безпеку для підключення з ПК на 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. Додайте запис до файлу хостів, що знаходиться в C:\Windows\System32\drivers\etc\hosts(запустіть Блокнот від імені адміністратора, щоб змінити цей файл). Запис, який ми додали, був
   Server.domain.com Server

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

У мене теж була ця проблема на SQL Server 2014 під час входу з автентифікацією Windows, щоб вирішити проблему, я перезапустив сервер один раз, а потім спробував увійти, це спрацювало для мене.