Логин принадлежит ненадежному домену и не может использоваться для проверки подлинности Windows

Обновлено: 05.07.2024

Сообщение об ошибке:

TITLE: Connect to Server
-----------------
Не удается подключиться к SQL .
-----------------------------
ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ:
Не удалось войти в систему. Логин относится к ненадежному домену и не может использоваться с проверкой подлинности Windows. (Microsoft SQL Server, ошибка: 18452)

что я пытаюсь сделать.

Установка Windows 2012 R2 Standard Server со Skype для бизнеса 2015 и SQL 2014 на нем.

SQL следует использовать только в SfB 2015.

Windows Server находится в домене. (домен.lab)

Добавлено статическое DNS-имя SQL для того же IP-адреса сервера SKYPE. (пробовал статический и псевдоним CNAME)

Подключение SQL через skype.domain.lab работает отлично.

При подключении SQL через SQL.domain.lab появляется сообщение об ошибке.

Мы будем признательны за любую помощь.

Второй DNS необходим из-за корпоративной установки SfB 2015.

Все ответы

Если у доменов нет доверия и у пользователей/групп AD из этого домена нет входа в экземпляр SQL, к которому вы пытаетесь подключиться, это не сработает.

Джои Эндрю "С 1982 года"

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

извините, но я немного новичок в этом. Что именно вы имеете в виду?

Мне удалось войти в базу данных с помощью Management Studio с локального хоста, используя проверку подлинности Windows с именем сервера skype.domain.lab.

Но я не могу войти в систему с именем сервера sql.domain.lab.

Многодоменных доменов нет.

Я использую учетную запись администратора домена для входа через Management Studio.
У локального администратора такой же пароль. Или я вас неправильно понял?

Можете ли вы проверить, добавлена ​​ли учетная запись SQL в политику «Доступ к этому компьютеру из сети» в разделе «Локальная политика безопасности» -> «Локальные политики» -> «Назначение прав пользователя» -> «Доступ к этому компьютеру из сети».

runas /netonly /user:domain\user "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe"

проверьте и подтвердите.

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

у вас есть два субдомена skype.domain.lab и sql.domain.lab. Предположим, у вас есть учетная запись test в skype.domain.lab с паролем password. Создайте идентичную учетную запись в домене sql.domain.lab под названием test с паролем password. Когда вы пытаетесь войти в свой сервер SQL с помощью Skype.domain.lab\test, он сначала попытается выполнить test, а затем sql.domain.lab\test. Вы также можете создать идентичную учетную запись на локальном компьютере с SQL.

  • Предложено в качестве ответа Uri Dimant MVP, 5 февраля 2017 г., воскресенье, 13:43.

runas /netonly /user:domain\user "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe"

проверьте и подтвердите.

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

C:\Windows\system32>runas /netonly /user:domain.lab\administrator "C:\Program File
s (x86)\Microsoft SQL Server\120\Tools\Binn\ManagementStudio\ssms. exe"
Введите пароль для домена.lab\administrator:
Попытка запуска C:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\M
anagementStudio\ssms .exe от имени пользователя «domain.lab\administrator».

-> SQL запускается до входа в систему Management Studio. Имя сервера sql01.domain.lab по-прежнему выдает ту же ошибку.

у вас есть два поддомена skype.domain.lab и sql.domain.lab. Предположим, у вас есть учетная запись test в skype.domain.lab с паролем password. Создайте идентичную учетную запись в домене sql.domain.lab под названием test с паролем password. Когда вы пытаетесь войти в свой сервер SQL с помощью Skype.domain.lab\test, он сначала попытается выполнить test, а затем sql.domain.lab\test. Вы также можете создать идентичную учетную запись на локальном компьютере с SQL.

Я считаю, что описал это неправильно. Skype — это имя хоста сервера в domain.lab, а sql — псевдоним DNS для того же сервера.

Чтобы войти в систему с проверкой подлинности Windows, вам потребуется создать SPN (имя субъекта-службы) для вашего SQL-сервера. Это работает, если SQL Server работает как встроенная учетная запись сетевой службы (но не в том случае, если вы используете учетную запись, созданную при установке SQL)

Дополнение Microsoft SQL Server 2019 Big Data Clusters будет прекращено. Поддержка кластеров больших данных SQL Server 2019 прекратится 28 февраля 2025 года. Дополнительные сведения см. в разделе Параметры больших данных на платформе Microsoft SQL Server.

В кластере больших данных SQL Server в режиме Active Directory попытка подключения может завершиться неудачно, и попытка подключения возвращает следующую ошибку:

Не удалось войти. Логин относится к ненадежному домену и не может использоваться со встроенной проверкой подлинности.

Это может произойти, если вы настроили записи DNS как CNAME, указывающие на псевдоним обратного прокси-сервера, который распределяет трафик на узлы Kubernetes.

Основная причина

Если конечные точки настроены с записями DNS с CNAME, указывающим на псевдоним обратного прокси-сервера, который распределяет трафик на узлы Kubernetes:

  • Процесс проверки подлинности Kerberos ищет имя субъекта-службы (SPN), которое соответствует записи для CNAME; неправильный SPN, зарегистрированный BDC в активном каталоге
  • Аутентификация не удалась

Подтвердите основную причину

После сбоя аутентификации проверьте кеш билетов Kerberos.

Чтобы проверить кэш билетов, используйте команду klist.

Найдите билет с SPN, соответствующим конечной точке, к которой вы пытались подключиться.

Ожидаемый билет отсутствует.

В этом примере главная конечная точка, DNS-запись bdc-sql, имеет CNAME для обратного прокси-сервера с именем ServerReverseProxy

В следующем разделе показаны результаты предыдущей команды.

В следующем разделе упоминается tshark . tshark — это утилита командной строки, устанавливаемая как часть утилиты трассировки сети Wireshark).

Чтобы увидеть имя участника-службы, запрошенное из Active Directory, используйте tshark . Следующая команда ограничивает запись сетевой трассировки обменом данными по протоколу Kerberos и отображает только сообщения krb-error (30). Эти сообщения должны содержать сообщения о неудачных запросах SPN.

Из другой командной оболочки попробуйте подключиться к главному модулю:

См. следующий пример вывода.

Проверьте вывод tshark.

Ошибка 25 означает KDC_ERR_PREAUTH_REQUIRED — требуется дополнительная предварительная аутентификация. Его можно смело игнорировать. KDC_ERR_PREAUTH_REQUIRED возвращается в исходном запросе Kerberos AD. По умолчанию клиент Windows Kerberos не включает данные предварительной проверки подлинности в этот первый запрос.

Чтобы просмотреть список имен участников-служб, зарегистрированных BDC для главной конечной точки, запустите setspn -L mssql-master .

См. следующий пример вывода:

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

Решение

В этом разделе показаны два способа решения проблемы. После внесения соответствующих изменений запустите ipconfig -flushdns и klist purge в своем клиенте. Затем повторите попытку подключения.

Вариант 1

Удалите запись CNAME для каждой конечной точки BDC в DNS и замените несколькими записями A, которые указывают на каждый узел Kubernetes или на каждый мастер Kubernetes, если у вас несколько мастеров.

Описанный ниже сценарий использует PowerShell. Дополнительную информацию см. в разделе Установка PowerShell в Linux.

Для обновления записей конечных точек DNS можно использовать следующий сценарий PowerShell. Запустите скрипт с любого компьютера, подключенного к тому же домену:

Вариант 2

Кроме того, эту проблему можно обойти, изменив CNAME так, чтобы он указывал на IP-адрес обратного прокси-сервера, а не на имя обратного прокси-сервера.

Подтвердить решение

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

В SQL Server появляется несколько сообщений об ошибках, которые могут быть вызваны несколькими причинами. Одним из известных примеров является сообщение об ошибке «Ошибка входа в систему для пользователя». Если вы видели это раньше, вы бы знали, что это сообщение может появиться из-за неправильного имени пользователя, неправильного пароля, неправильной базы данных и многих других причин. Всякий раз, когда я вижу ошибку входа в систему, я смотрю на SQL Server ERRORLOG, чтобы увидеть точную причину.

Вот одна из ошибок, причина которой мне не ясна.

SQL SERVER - Ошибка входа в систему. Вход осуществляется из ненадежного домена и не может использоваться с проверкой подлинности Windows
<p>Вот были сообщения в ERRORLOG.</p>
<p>Не удалось войти. Логин относится к ненадежному домену и не может использоваться с проверкой подлинности Windows. [КЛИЕНТ: 169.111.227.120] Сбой рукопожатия SSPI с кодом ошибки 0x8009030c, состояние 14 при установлении соединения со встроенной защитой; соединение было закрыто. Причина: ошибка AcceptSecurityContext. Код ошибки Windows указывает на причину сбоя. Попытка входа не удалась [КЛИЕНТ: 169.111.227.120]</p>
<p>Это исходило от сервера приложений, который находился в том же домене. Основываясь на моем поиске в Интернете, существует какая-то петля, проверка происходит, что приводит к сбою доверенных соединений через адаптер обратной петли.</p>
<h3>ВРЕМЕННОЕ РЕШЕНИЕ/РЕШЕНИЕ</h3>
<p>Проверку замыкания на себя можно удалить, добавив запись реестра следующим образом:</p>
<ul>
  <li>Внесите изменения в реестр с помощью regedit. (Пуск -> Выполнить > Regedit )</li>
  <li>Перейдите к: HKLM\System\CurrentControlSet\Control\LSA</li>
  <li>Добавьте параметр DWORD под названием «DisableLoopbackCheck».</li>
  <li>Установите для этого значения значение 1.</li>
</ul>
<p>Лучшее в этом инструменте то, что он может помочь в поиске отсутствующего имени участника-службы и предоставить сценарий для его непосредственного запуска или исправления, если у вас есть разрешение. В принципе, можно</p>
<p>Я создал базу данных на нашем сервере SQL для Eplan. Когда я пытаюсь войти в SQL с использованием проверки подлинности Windows, я получаю сообщение об ошибке «Ошибка входа. Вход осуществляется из ненадежного домена и не может использоваться с проверкой подлинности Windows».</p>
<p>Когда я использую свой логин SQL-сервера, он возвращает

Итак, я убедился, что использую правильный логин/пароль. TCP/IP включен, а SQL-сервер использует SQL-сервер и аутентификацию Windows.

Я действительно не знаю, что делать дальше. Вчера я начал изучать SQL, так что, возможно, я упускаю что-то простое.

Максимальное использование гиперконвергентной инфраструктуры

2022-03-22 18:00:00 Веб-семинар UTC Веб-семинар: Dell — максимально эффективное использование гиперконвергентной инфраструктуры Подробнее о событии Просмотреть все события

12 ответов

Род-ИТ

Являются ли SQL-сервер и клиент, с которого вы подключаетесь, доменом/рабочей группой? Если домен, они показывают домен в профиле брандмауэра Windows?

Fessor

  • отметить 36 лучших ответов
  • thumb_up – 103 благодарных голоса

Дано ли логину SQL Server разрешение на доступ к базе данных?

Принадлежат ли учетная запись домена и SQL Server к одному и тому же домену для входа в Windows?

molan

Этот человек является проверенным специалистом

Молан

разрешен ли порт 1433 сервера SQL для входящего трафика в брандмауэре Windows?

Alec6638

Этот человек является проверенным специалистом

Алек6638

  • отметить 124 лучших ответа
  • thumb_up: 287 благодарных отзывов

Rod-IT ​ и Fessor ​ уже упоминали о возможных проблемах с доменом.

В каком домене расположен сервер SQL и к какому домену принадлежит ваша учетная запись для входа в Windows?

Если между этими двумя доменами нет доверительных отношений, вы не сможете использовать свою учетную запись Windows для подключения к этому SQL-серверу.
В этом случае вам, возможно, придется создать учетную запись SQL для входа. использовать вместо учетной записи входа в Windows. Я вижу, вы, возможно, уже пробовали войти в систему SQL — используете ли вы для этого правильный пароль?

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

Alec6638

Этот человек является проверенным специалистом

Алек6638

  • отметить 124 лучших ответа
  • thumb_up: 287 благодарных отзывов

AmandaR35 написал:

Алек,

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

Спасибо!

Можно ли войти на сервер SQL с помощью SSMS, работающей непосредственно на этом сервере?

Alec6638

Этот человек является проверенным специалистом

Алек6638

  • отметить 124 лучших ответа
  • thumb_up: 287 благодарных отзывов

К вашему сведению, вы не ответили на вопрос Молана о настройке брандмауэра для входящего порта 1433?

Поэтому я бы хотел, чтобы вы подключились к SQL напрямую через SSMS (поскольку вы сказали, что это работает) и просмотрели журнал SQL Server (в разделе «Управление» -> «Журналы SQL Server»), чтобы узнать, не появляются ли при попытке войти в систему неудачные записи. подключиться к SQL через SSMS в удаленной системе. Можете ли вы сделать это и сообщить нам, что происходит? К вашему сведению, в разделе «Безопасность» обычно по умолчанию для аудита используется «Ошибка входа».

Rod-IT Fessor Они находятся в одном домене. У нас есть только один на данный момент. Я предоставил им разрешения. У нас есть еще одна база данных на сервере, которая правильно подключается.

molan ​ Мои извинения! У меня есть порт SQL Server 1433, разрешенный для входящего трафика в брандмауэре Windows.

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

После неудачной попытки входа в систему я просмотрел журналы. Пишет: "Ошибка входа в систему для пользователя "Администратор". Причина: пароль не соответствует указанному для входа в систему". Далее следует IP-адрес клиента.

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

Alec6638

Этот человек является проверенным специалистом

Алек6638

  • отметить 124 лучших ответа
  • thumb_up: 287 благодарных отзывов

AmandaR35 написал:

Alec6638 ​

После неудачной попытки войти в систему я просмотрел журналы. Пишет: "Ошибка входа в систему для пользователя "Администратор". Причина: пароль не соответствует указанному для входа в систему". За ним следует IP-адрес клиента.

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

После сброса пароля для учетной записи SQL с помощью SSMS -> Безопасность -> Логины, этот пароль сразу же вступает в силу.
Поэтому я думаю, что либо вы используете неправильную учетную запись для входа в SSMS, либо сбрасываете неправильный логин. аккаунт.

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

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

Или, возможно, попробуйте создать новую учетную запись SQL "Admin2" (временную, затем удалите ее) и используйте ее вместо "Admin".

Читайте также: