Подробный гайд: Ошибка (2) login failed for user admin: диагностика и пошаговое решение

Ошибка (2) login failed for user admin возникает при подключении к MS SQL Server. Разобраны причины, коды состояния 18456, настройка драйверов,устранение сбоя.

2026.05.21                  

Подробный гайд: Ошибка (2) login failed for user admin: диагностика и пошаговое решениеПодробный гайд: Ошибка (2) login failed for user admin: диагностика и пошаговое решение Ошибка (2) login failed for user admin — классический сбой аутентификации при подключении к базе данных. Чаще всего она возникает при работе с MS SQL Server через клиентские библиотеки, использующие протокол TDS: FreeTDS, pymssql (Python), PDO_DBLIB (PHP), unixODBC или старые версии pyodbc. Внутренний код ошибки SQL Server при этом обычно 18456, а клиентская библиотека транслирует его в (2).

Ниже приведён подробный гайд по диагностике и устранению.

1. Быстрая карта возможных причин

Причина Как проверить Частота
Неверный логин/пароль Подключиться через SSMS / sqlcmd Очень высокая
SQL Server настроен только на Windows Auth Свойства сервера -> Security Высокая
Пользователь отключён/заблокирован/пароль истёк Запрос к sys.sql_logins Средняя
Ошибка в строке подключения или драйвере Логи клиента, tds_dump / ODBC trace Средняя
IP не разрешён в firewall БД (Azure/облако) Настройки сети сервера Низкая
Проблемы с кодировкой/регистром/пробелами Внимательный парсинг строки подключения Низкая

2. Пошаговая диагностика и решение

Шаг 1. Убедитесь, что учётные данные корректны

1. Попробуйте подключиться к тому же серверу через SSMS или sqlcmd:
   sqlcmd -S <host> -U admin -P <пароль> -d <база>
  1. Если подключение не проходит -> проблема в учётной записи или настройках сервера.
  2. Если проходит -> проблема в клиенте, драйвере или строке подключения вашего приложения.

Шаг 2. Проверьте режим аутентификации SQL Server

По умолчанию SQL Server может разрешать только Windows Authentication. Для логинов вида admin нужен Mixed Mode. 1. В SSMS: ПКМ по серверу -> Properties -> Security
2. Убедитесь, что выбрано: SQL Server and Windows Authentication mode

3. После изменения обязательно перезапустите службу SQL Server:
   Restart-Service MSSQLSERVER  # или MSSQL$<INSTANCE>

Шаг 3. Проверьте статус пользователя в БД

Выполните от имени sa или администратора:

SELECT 
    name, 
    is_disabled, 
    LOGINPROPERTY(name, 'IsLocked') AS IsLocked,
    LOGINPROPERTY(name, 'PasswordLastSetTime') AS PwdLastSet,
    LOGINPROPERTY(name, 'BadPasswordCount') AS BadPwdCount
FROM sys.sql_logins 
WHERE name = 'admin';
  • is_disabled = 1 -> включите: ALTER LOGIN admin ENABLE;
  • Пароль истёк/заблокирован -> сбросьте: ALTER LOGIN admin WITH PASSWORD = 'NewStrongPass123!';

Шаг 4. Разберитесь с кодами состояния (State) в логах SQL Server

Ошибка входа всегда записывается с кодом 18456. Откройте SQL Server Logs (SSMS -> Management -> SQL Server Logs) и найдите последнюю запись для admin.

Обратите внимание на State:

State Причина
5 Пользователь не существует
6 Попытка входа с логином Windows в SQL-режиме (или наоборот)
7 Логин отключён
8 Неверный пароль
9 Пароль недействителен (истёк/требует смены)
11 Логин валиден, но нет доступа к БД
18 Пароль нужно сменить при следующем входе

Примечание:

Если видите State 1 -> это заглушка безопасности. Включите аудит или проверьте расширенные логи, чтобы увидеть реальный State.

Шаг 5. Проверьте конфигурацию клиента и драйвера

FreeTDS (/etc/freetds.conf или ~/.freetds.conf)

[mssql_server]
    host = 192.168.1.10
    port = 1433
    tds version = 7.4
    client charset = UTF-8
    encryption = require

Важно:

Версии 7.1 и ниже не поддерживают современные механизмы аутентификации. Используйте 7.4 или 8.0.

Python (pymssql / pyodbc)

# pymssql (устаревает, но ещё используется)
import pymssql
conn = pymssql.connect(
    server='192.168.1.10',
    user='admin',
    password='YourPassword',
    database='YourDB',
    login_timeout=10
)

# pyodbc (рекомендуется)
import pyodbc
conn = pyodbc.connect(
    'DRIVER={ODBC Driver 18 for SQL Server};'
    'SERVER=192.168.1.10;'
    'DATABASE=YourDB;'
    'UID=admin;'
    'PWD=YourPassword;'
    'TrustServerCertificate=yes;'
)

PHP (PDO_DBLIB)

$dsn = "dblib:host=192.168.1.10;dbname=YourDB;charset=UTF-8;tds_version=7.4";
$pdo = new PDO($dsn, 'admin', 'YourPassword', [
    PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION
]);

Шаг 6. Сетевые и облачные ограничения

  • Убедитесь, что порт 1433 (или кастомный) доступен: telnet <host> 1433 или nc -zv <host> 1433
- В Azure SQL / AWS RDS / GCP Cloud SQL проверьте:
  • Firewall rules (разрешён ли IP клиента)
  • Разрешение доступа для служб платформы (если применимо)
  • Не включён ли Enforce SSL без поддержки в драйвере
    • Фаерволы могут обрывать или модифицировать пакеты TDS. Временно отключите их для теста.

3. Рекомендации по миграции на современные драйверы

Старый стек Современная замена Почему
FreeTDS + PDO_DBLIB ODBC Driver 18 for SQL Server + pdo_sqlsrv Поддержка TLS 1.2/1.3, Kerberos, Always Encrypted, стабильные коды ошибок
pymssql pyodbc или SQLAlchemy + pyodbc Активная поддержка Microsoft, совместимость с Azure, корректная обработка State 18456
Самописные обёртки microsoft/tedious (Node.js), go-mssqldb (Go) Нативная поддержка TDS 8.0+, MFA, Azure AD

Установить ODBC Driver 18 на Linux:

curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add -
apt-add-repository "deb https://packages.microsoft.com/ubuntu/22.04/prod jammy main"
apt-get update
apt-get install msodbcsql18

4. Профилактика и лучшие практики

  1. Не используйте admin/sa/root в приложениях. Создавайте специализированные логины с минимальными правами (db_datareader, db_datawriter или кастомные роли).
  2. Храните креды вне кода: .env, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault.
3. Включите аудит входов:
   CREATE SERVER AUDIT LoginAudit TO FILE (FILEPATH = '/var/log/sql/');
   CREATE SERVER AUDIT SPECIFICATION LoginAuditSpec
   FOR SERVER AUDIT LoginAudit
   ADD (FAILED_LOGIN_GROUP);
   ALTER SERVER AUDIT LoginAudit WITH (STATE = ON);
  1. Регулярно ротируйте пароли и отключайте неиспользуемые логины.
  2. Логгируйте State из 18456 в приложениях, а не только текст ошибки. Это экономит часы отладки.

Когда обращаться к вендору

  • Вы не имеете прав на изменение настроек сервера
  • В логах появляются State 6 или State 11 при корректных креденшелсах
  • Подозрение на компрометацию учётной записи
  • Ошибка возникает только в определённых пулах соединений (возможна проблема с connection pooling или таймаутами Kerberos)

Мы делимся этой технической информацией, чтобы помочь вам в решении задач — используйте её с пониманием. Статья носит рекомендательный характер, поэтому, пожалуйста, применяйте описанные методы осмотрительно и на свой страх и риск.

×

Полный размер Слайдшоу Предыдущий Следующий