Помилка входу в систему для Windows SQL Server 2008: Помилка входу з домену, який не довіряється

При спробі підключення до екземпляра SQL Server 2008 за допомогою студії управління я отримую таку помилку:

Помилка логіну. Логін здійснюється з ненадійного домену і не може використовуватися для автентифікації Windows. (Microsoft SQL Server, помилка: 18452)

Я можу без проблем увійти за допомогою аутентифікації SQL. Я несподівано отримував цю помилку. Увімкнено автентифікацію змішаного режиму.

Хтось має з цим досвід?

Додаткова інформація: 64-розрядна версія SQL Enterprise Edition на Windows 2003 Server

Ще одна причина цього може статися (щойно трапилося зі мною) ... - це термін дії пароля користувача. Я не усвідомлював цього, поки не спробував зайнятись на фактичному сервері, і мені не запропонували змінити пароль.

Для мене це сталося, коли я редагував порожній drivers/etc/hostsфайл і додав запис для локального веб-сайту, але його нехтувати127.0.0.1 localhost

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

Для всіх, хто стикається з цим, я мав це у своєму файлі хостів:

127.0.0.1   localhost
127.0.0.1   customname

і мені це було потрібно, щоб це було:

127.0.0.1   localhost
127.0.0.1   localhost   customname

"Проблема була викликана сервером Active Directory, який не працює, і, звичайно, не вдалося підтвердити автентифікацію облікового запису Windows"

Звичайно, це не так, оскільки якщо AD недоступний, тоді автентифікація Kerberos повертається до NTLM (дані облікового запису домену кешуються локально, можна ввійти в нього, навіть якщо AD / Kerberos недоступний). Я думаю, що у вас можливо 2 одночасні умови цього невдачі:

• SQL Server не є локальним (на іншій машині)
• Траст налаштований "лише Kerberos"

або іншої конкретної конфігурації мережі / сервера / AD / машини

У мене виникла ця проблема для екземпляра сервера на моїй локальній машині, і я виявив, що це було тому, що я вказував на 127.0.0.1 з чимось іншим, ніж "localhost" у моєму файлі хостів. Є два способи вирішити цю проблему в моєму випадку:

1. Очистіть кривдний запис, який вказує на 127.0.0.1 у файлі хостів
2. використовуйте "localhost" замість іншої назви у файлі хостів, що вказує на 127.0.0.1

* Це працювало для мене лише тоді, коли я запускав екземпляр сервера sql у своєму локальному вікні та намагався отримати доступ до нього з тієї ж машини.

Переконайтеся, що ви не підключені до VPN для іншого домену \ користувача . Або, навпаки, переконайтеся , що ви будете підключені, якщо це те , що потрібно.

Я вирішив цю проблему на відключенні налаштування перевірки петлі:

1. Відредагуйте реєстр Windows: Пуск -> Запуск> Regedit
2. Перейдіть до: HKLM \ System \ CurrentControlSet \ Control \ LSA
3. Додайте значення DWORD під назвою "DisableLoopbackCheck"
4. Встановіть це значення на 1

спробуйте використовувати інший дійсний логін, використовуючи команду RUNAS

runas /user:domain\user “C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\ssmsee.exe” 

runas /user:domain\user “C:\WINDOWS\system32\mmc.exe /s \”C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC\”" 

runas /user:domain\user isqlw 

Для мене це було тому, що я не додав обліковий запис, щоб мати ролі, які я хотів використовувати в самій базі даних SQL. А також через неправильні спроби пароля через копіювання вставки проблеми блокування вставки.

Гаразд, цілком там відповідь від мене. Я отримував цю помилку із середовища розробки, розміщеного на VM VirtualBox. Три сервери; SharePoint, SQL DB та контролер домену. Сервер SharePoint не зміг підключитися до бази даних конфігурації. Я все ще можу підключитися через ODBC для аутентифікації Sql, використовуючи обліковий запис SA, але не автентифікацію Windows. Але цей користувач із задоволенням увійде в SSMS на сервері sql. Я отримав і краще повідомлення про помилку від ODBC, а також перевіривши невдалі повідомлення для входу на сервері sql:

select text from sys.messages where message_id = '18452' and language_id = 1033

Не можу взяти на це кредит, тому що я попросив одного з наших адміністраторів корпоративних систем про допомогу, і він поставив діагноз через 5 хвилин перегляду декількох знімків екрана, які я йому надіслав. Проблема полягала в тому, що годинник контролера домену встановлено неправильно! Не міг повірити. Сервери налаштовані лише на мережу Host Only, тому не має Інтернету, щоб синхронізувати годинник. Це також пояснює, чому відкат до попереднього знімка, коли я знаю, що система працювала, не вирішив проблему.

Редагувати: Встановлення додатків для гостей на сервер синхронізує гостьовий годинник з хостом.

На драйвері jTDS під назвою USENTLMV2 встановлено налаштування, яке за замовчуванням встановлено на значення false. Встановивши це значення "true" в моєму програмному забезпеченні (DBVisualizer), це вирішило.

Інший сценарій, коли ви можете це бачити, - це коли ви намагаєтеся підключитися до іншого SQL-сервера з сеансу SSMS, який вже був увійшов у систему під час зміни пароля. Послідовність подій може мати щось на зразок:

1. RDP на сервер A (ваш SQL сервер), відкрийте SSMS та увійдіть
2. RDP на сервер-B у тому самому домені та змініть пароль
3. Поверніться до сеансу RDP на сервері A-сервер та через SSMS спробуйте додати ще один БД до існуючої групи доступності AlwaysOn. Під час підключення до реплік ви отримуєте "недовірений домен" -login-помилку

Щоб вирішити проблему, просто вийдіть із системи та увійдіть назад

Вас можуть ввести в оману щодо того, яке ім’я користувача ви використовуєте локально. Це був мій випадок у Windows 10 Home. Коли я дивлюся на користувачів на панелі управління, я бачу ім'я usrpc01 . Однак коли я набираюnet config workstation , виявляється, що ім'я користувача - spc01 . Здається, хтось перейменував користувача, але внутрішня назва залишилася незмінною.

Не знаючи, як виправити ім'я користувача Windows (і ім'я папки під C:\Users, яке також посилається на оригінальне внутрішнє ім’я), я додав новий акаунт користувача на своєму db-сервері.

Я намагався увійти в SQL Server 2008 з облікового запису домену. SQL Server 2008 розміщений на іншому комп'ютері робочої групи, який не входить у домен. Як не дивно це звучить, мені на сервері робочих груп, де працює SQL Server 2008, довелося перейти до System Properties | Назва комп'ютера (вкладка) | Зміна (кнопка) | Зміна імені комп'ютера | Більше ... (кнопка) та введіть "Первинний суфікс DNS цього комп'ютера" (він був порожнім, тому введіть потрібний суфікс для вашої мережі) та встановіть прапорець "Змінити первинний суфікс DNS при зміні членства в домені". Це дозволило завершити процес автентифікації Windows під час входу в систему SQL Server 2008.

Мені довелося скористатися netonly, щоб це працювало на сучасних Windows:

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

Ще одна причина> хтось змінив пароль для користувача SQL за замовчуванням

це сталося зі мною пару хвилин тому, перейшовши на новий контролер домену ...

Не вдалося записати файл хостів під C:\Windows\System32\drivers\etc

[Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

Переконайтеся, що у вас є запис, як показано нижче

127.0.0.1   localhost
127.0.0.1   localhost   servername

Я використовував псевдонім для екземпляра SQL Server, який вказував на "127.0.0.1". Змінивши його на "localhost", замість цього зробила трюк.

Якщо ваш сервер Sql працює на сервері, який не є частиною домену, і в рядку підключення ви використовуєте повністю кваліфіковане ім'я домену (наприклад, xyz.mypc.com) з інтегрованою безпекою = True, можливо, вам доведеться перейти на використання будь-якого IP-адресу, ім’я машини (SERVER01) або крапку (.) у випадку, якщо він розміщений на локальному рівні.

Це працювало для мене, використання fqdn призвело до вищевказаної помилки.

щоб увімкнути автентифікацію Windows, обидва комп'ютери повинні бути в одному домені. щоб студії управління могли передавати поточні облікові дані та аутентифікуватись у вікні sql

Для мене я повинен відключити (змінити робочу групу / домен) від Домену та знову підключитися.

І ще одна можлива причина: у новому створеному локальному обліковому записі на сервері DB було встановлено: "Користувач повинен змінити пароль при наступному вході".

Ось що для мене виправлено: Властивості мережевого з'єднання Клацніть на "Internet Protocol Version 4 (TCT / IPv4)". Натисніть кнопку "Властивості". Натисніть кнопку "Додатково". Виберіть вкладку "DNS". Видаліть текст у "Суфіксі DNS для цього з'єднання".

Я не зміг віддалено підключитися до сервера SQL. І SQL-сервер, і віддалений сервер, де в одному домені. І мене просили змінити пароль кілька днів тому. Перезапуск і SQL-сервера, і віддаленого сервера, з якого я намагався отримати доступ до SQL-сервера, зробив для мене трюк.

У нашому випадку справа в тому, що розробник запускав пул додатків під власним обліковим записом і скинув свій пароль, але забув змінити його в пулі додатків. Да ...

У моєму випадку сервер був відключений у контролері домену. Я зайшов у каталог COMPUTERS OU в Active, правою кнопкою миші натиснув на сервер, включив його, а потім зробив gpupdate / force з SQL-сервера. Минув мить, але нарешті спрацювало.

У моєму випадку у файлі хоста ім'я машини жорстко кодується із старими IP-адресами. Я замінюю старіший IP на новий, питання вирішено.

Розташування файлу хоста

WindowsDrive: \ Windows \ System32 \ драйвери \ тощо \ хости

Зміни зробили 159.xx.xx.xxx MachineName

Ніщо з перерахованого вище не працювало для мене. Що мені потрібно було зробити: у студії управління SQL Server на екрані входу виберіть Опції >> У розділі Мережа змініть протокол мережі на Іменовані труби.

Крім того, що мені довелося зробити, щоб він працював із <default>налаштуванням, це відключити бездротову мережу (машина також була підключена до провідного ланцюга).

Моє виправлення полягало в тому, щоб змінити файл web.config, щоб він відповідав моєму новому імені сервера для підключення SQL (IT Security щойно зробила перейменування netdom у вікні моєї розробки.