При администрировании SQL Server мы часто сталкиваемся с необходимостью автоматизации рутинных задач, таких как резервное копирование, проверка целостности баз данных и оптимизация. Для этого используются планы обслуживания (Maintenance Plans). Однако, иногда даже при успешном завершении всех шагов плана, в журнале ошибок SQL Server может появляться тревожное сообщение об ошибке: 18456 Login failed for user 'sa'. Причина: пароль не соответствует переданному имени для входа. [КЛИЕНТ: .
Эта ситуация может вызывать недоумение: почему вход завершается неудачей, если план все равно выполняется корректно? Откуда "растут ноги" у этого события, и как его устранить, чтобы журнал ошибок оставался чистым?
Давайте проанализируем ситуацию. Ошибка 18456 Login failed for user 'sa' при выполнении планов обслуживания — это известная проблема, признанная самой Microsoft. Этот баг особенно часто проявляется в версиях SQL Server 2016, 2017 и 2019 RTM (Release To Manufacturing), когда для аутентификации в планах обслуживания используется метод SQL Server, например, с учетной записью sa.
Несмотря на то, что план обслуживания завершается успешно, сам процесс инициализации соединения или один из его внутренних шагов может пытаться установить соединение с использованием учетной записи sa с некорректными или отсутствующими учетными данными, что приводит к записи об ошибке в журнал. Затем последующие шаги плана, которые могут использовать другой контекст безопасности (например, учетную запись службы SQL Server Agent) или успешно восстанавливать соединение, выполняются как положено.
Microsoft официально признала данную проблему и выпустила исправления в следующих накопительных обновлениях (Cumulative Updates):
Применение соответствующего накопительного обновления является наиболее полным и рекомендованным способом окончательного устранения данного бага.
Если по каким-либо причинам вы не можете немедленно установить накопительные обновления, существует эффективный обходной путь. Этот метод был найден и успешно применен в нашем случае, что подтверждает его работоспособность. Он заключается в изменении типа подключения в плане обслуживания на "Использовать встроенную безопасность Windows NT" (Use Windows NT Integrated security).
Когда мы выбираем этот метод аутентификации, план обслуживания будет выполняться с использованием учетной записи службы SQL Server Agent. Это означает, что все операции в рамках плана будут происходить от имени этой учетной записи. Крайне важно убедиться, что учетная запись службы SQL Server Agent обладает всеми необходимыми разрешениями для выполнения задач плана, включая доступ к базам данных, каталогам для резервных копий и другим ресурсам.
Мы предлагаем вам выполнить следующие действия для настройки вашего плана обслуживания:
Откроем SQL Server Management Studio (SSMS): Запустите SSMS и подключитесь к экземпляру SQL Server, на котором настроены планы обслуживания.
Перейдем к планам обслуживания: В обозревателе объектов (Object Explorer) разверните узел "Управление" (Management), затем найдите и разверните "Планы обслуживания" (Maintenance Plans). Выберите план, который вызывает ошибку 18456.
Откроем свойства плана обслуживания: Щелкните правой кнопкой мыши по проблемному плану обслуживания и выберите "Изменить" (Modify) или просто дважды щелкните по нему, чтобы открыть его дизайнер.
Найдем "Управление соединениями": В верхней части панели дизайнера плана обслуживания найдите кнопку или пункт меню "Управление соединениями..." (Manage Connections...). Это очень важный шаг, так как именно здесь определяются параметры подключения, используемые планом.
Примерное расположение элемента "Управление соединениями" в SQL Server Management Studio:
Представьте, что вы видите окно дизайнера плана обслуживания. На панели инструментов этого окна (обычно сверху) вы найдете значки для различных операций. Один из них, скорее всего, будет с изображением двух соединенных звеньев цепи или другого символа, обозначающего соединение, и текстовой подписью "Manage Connections...".
Выберем "Локальное серверное соединение": В открывшемся окне "Управление соединениями" вы увидите список доступных соединений. Обычно для планов обслуживания существует одно соединение, названное "Локальное серверное соединение" (Local server connection). Выберите его.
Изменим тип аутентификации: Нажмите кнопку "Изменить..." (Edit...) для выбранного локального соединения. Откроется окно свойств соединения. Здесь мы увидим опции аутентификации.
В секции "Проверка подлинности" (Authentication) выберите опцию "Использовать встроенную безопасность Windows NT" (Use Windows NT Integrated security). Возможно, ранее там была выбрана опция "Использовать проверку подлинности SQL Server" (Use SQL Server Authentication) с учетной записью sa.
Подтвердим и сохраним изменения: Нажмите "ОК" во всех открытых окнах настроек соединения и затем обязательно сохраните сам план обслуживания (файл -> сохранить или кнопка сохранения на панели инструментов).
Проверим результат: Запустите план обслуживания вручную или дождитесь его очередного регламентного запуска. После завершения проверьте журнал ошибок SQL Server. Мы должны убедиться, что ошибка 18456 Login failed for user 'sa' больше не появляется.
Как показывает опыт, после этих изменений проблема должна уйти. Это подтверждает, что причиной был специфический механизм аутентификации в планах обслуживания, особенно когда использовалась учетная запись sa.
Для полноты картины давайте кратко рассмотрим, что вообще может вызывать ошибку 18456 ("Login failed for user"), помимо описанного бага в планах обслуживания. Эта ошибка указывает на общий сбой аутентификации и может быть вызвана рядом факторов:
Неверное имя пользователя или пароль: Это самая распространенная и очевидная причина. Мы всегда должны убеждаться в корректности вводимых учетных данных.
Несоответствие режима аутентификации: SQL Server может быть настроен только на аутентификацию Windows (например, в случае, если режим смешанной аутентификации отключен), а вы предпринимаете попытку входа с использованием аутентификации SQL Server. В таких ситуациях в журнале ошибок SQL Server может быть дополнительно указано, что "Сервер настроен только для аутентификации Windows". Мы должны проверить настройки режима аутентификации экземпляра SQL Server.
Недостаточные разрешения пользователя: Даже если учетные данные верны, учетная запись может не иметь необходимых разрешений для доступа к базе данных или ее объектам. Мы должны проверить разрешения для конкретной учетной записи на требуемые базы данных или сервер.
Отключенная учетная запись: Учетная запись пользователя, например sa, может быть отключена на уровне сервера. Мы можем проверить статус учетной записи в "Безопасность" (Security) -> "Имена для входа" (Logins) в SSMS.
Различные состояния ошибки: Код состояния (State), следующий за ошибкой 18456, может предоставить более специфическую информацию о причине сбоя. Например, State: 8, как в нашем случае, означает, что пароль не соответствует предоставленному имени входа. Другие коды состояний указывают на различные причины, такие как неверное имя пользователя, отключенная учетная запись и т.д. Мы всегда должны обращать внимание на этот код для более точной диагностики.
Исходя из лучших практик безопасности, мы не рекомендуем использовать учетную запись sa для повседневных операций в производственной среде, включая планы обслуживания. Учетная запись sa является высокопривилегированной и ее компрометация может привести к серьезным проблемам безопасности всего экземпляра SQL Server.
Мы придерживаемся принципа наименьших привилегий (Principle of Least Privilege), предоставляя учетным записям только те разрешения, которые абсолютно необходимы для выполнения их роли. Для планов обслуживания рекомендуется создавать выделенные учетные записи Windows или SQL Server с минимально необходимыми правами, либо использовать встроенную безопасность Windows NT с учетной записью службы SQL Server Agent.
При внесении изменений в планы обслуживания, мы должны учитывать некоторые нюансы, чтобы избежать потенциальных проблем:
Запуск SSMS с соответствующими учетными данными: Иногда изменение планов обслуживания, особенно связанных с безопасностью, может привести к сбою контекста подключения. Чтобы избежать этого, мы рекомендуем открывать SQL Server Management Studio (SSMS) с использованием учетных данных той сервисной учетной записи, под которой запускается SQL Server Agent. Это помогает предотвратить проблемы с разрешениями при сохранении изменений.
Проверка разрешений учетной записи службы SQL Server Agent: Мы должны убедиться, что у учетной записи службы SQL Server Agent есть соответствующие разрешения не только на базу данных, но и на все пути для резервного копирования и другие необходимые каталоги. Если Agent не имеет доступа к месту сохранения резервных копий, план обслуживания завершится с ошибкой, несмотря на корректную аутентификацию.
Двойная проверка метода аутентификации: После сохранения изменений в плане обслуживания, особенно если вы переключались между методами аутентификации, мы настоятельно рекомендуем повторно открыть настройки и убедиться, что выбранный метод аутентификации (например, "Использовать встроенную безопасность Windows NT") действительно сохранился. Иногда SSMS может "забывать" изменения при определенных сценариях.
Следуя этим рекомендациям и используя предложенное решение, мы сможем успешно устранить повторяющуюся ошибку 18456 в журнале SQL Server, обеспечив при этом стабильную и безопасную работу наших планов обслуживания.