MSSQLSERVER_18456
Область применения: 
SQL Server
Сведения
| Атрибут | Значение |
|---|---|
| Название продукта | SQL Server |
| ИД события | 18456 |
| Источник событий | MSSQLSERVER |
| Компонент | SQLEngine |
| Символическое имя | LOGON_FAILED |
| Текст сообщения | Сбой входа для пользователя "%.*ls".%.*ls |
Описание
Это сообщение об ошибке возникает при отклонении попытки подключения из-за сбоя проверки подлинности. Имена входа пользователей могут завершиться сбоем по многим причинам, например недопустимые учетные данные, срок действия пароля и включение неправильного режима проверки подлинности. Во многих случаях коды ошибок включают описания.
Действие пользователя
Ниже приведены некоторые распространенные сбои входа. Выберите точное сообщение об ошибке, с которой вы столкнулись, чтобы устранить эту проблему:
Сбой входа для пользователя "<имя пользователя>" или имя входа для пользователя "<domain>\<username>"
Если доменное имя не указано, проблема возникает сбоем попытки входа в SQL Server. Если указано доменное имя, проблема заключается в сбое входа учетной записи пользователя Windows. Сведения о потенциальных причинах и предлагаемых решениях см. в следующем разделе:
| Возможная причина | Рекомендуемое решение |
|---|---|
| Вы пытаетесь использовать проверку подлинности SQL Server, но экземпляр SQL Server настроен для режима проверки подлинности Windows. | Убедитесь, что SQL Server настроен для использования режима проверки подлинности SQL Server и Windows. Вы можете просмотреть и изменить режим проверки подлинности для экземпляра SQL Server на странице "Безопасность " в разделе "Свойства " соответствующего экземпляра в SQL Server Management Studio (SSMS). Дополнительные сведения см. в разделе "Изменение режима проверки подлинности сервера". Кроме того, вы можете изменить приложение, чтобы использовать режим проверки подлинности Windows для подключения к SQL Server. Примечание. В этом сценарии в журнале ошибок SQL Server можно увидеть следующее сообщение: Login failed for user '<UserName>'. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only. |
| Вы пытаетесь получить доступ к SQL Server через группу, и появится сообщение об ошибке. | Если у вас нет необходимых разрешений для доступа к серверу, поставщик отображает сообщение об ошибке "Ошибка входа для пользователя contoso/user1". Используйте функцию Access через группу, которая помогает получить доступ к серверу на основе членства в группе. При запуске хранимой xp_logininfo 'contoso/user1' процедуры может возникнуть следующее:— Если вы видите ошибку, SQL Server не может разрешить имя пользователя вообще. Скорее всего, имя отсутствует в Active Directory (AD) или может возникнуть проблема с подключением к контроллеру домена (DC). Попробуйте использовать другое имя, чтобы проверить, связана ли проблема с определенной учетной записью. — Если вы подключаетесь к серверу между доменами, группа должна находиться в домене SQL Server, а не в домене пользователя, чтобы ее членство можно было разрешить. — Если запрос базы данных не возвращает строк, это означает, что нет группы, которая предоставляет доступ к серверу. Когда запрос возвращает одну или несколько строк, это означает, что пользователь принадлежит группе, предоставляющей доступ. DBA может дважды проверить разрешения, проверив папку Security\Logins в SQL Server Management Studio (SSMS). В файле Security\Login отображается список созданных имен входа. Если это содержащаяся база данных, DBA может проверить имена безопасности\Logins под именем базы данных, чтобы проверить имена входа и управлять ими. Дополнительные сведения см. в разделе "Настройка пользовательских контроль доступа и разрешений". |
| Имена входа SQL не включены | Система управления базами данных (СУБД) может показать некоторые Login failed for user '<username>' варианты сообщения. Для устранения этой ошибки выполните следующие действия.1. Проверьте, содержит ли журнал ошибок SQL Server сообщение об ошибке "Ошибка входа для пользователя "<имя пользователя>". Причина. Попытка входа с использованием проверки подлинности SQL завершилась ошибкой. Сервер настроен только для проверка подлинности Windows". 2. Чтобы устранить ошибку, используйте один из следующих методов: — Используйте встроенное имя входа. Например, для поставщиков OLE DB добавьте INTEGRATED SECURITY=SSPI в строка подключения и драйверы ODBC.TRUSTED_CONNECTION=YES Поставщик .NET принимает любой синтаксис.Примечание. Это может привести к другим проблемам, если они не настроены правильно, чтобы разрешить встроенную проверку подлинности, и требуется исследовать как отдельную проблему. — включение имен входа SQL на сервере: a. В SQL Server Management Studio щелкните правой кнопкой мыши имя SQL Server в обозреватель объектов и выберите "Свойства". b. В области "Безопасность" выберите режим проверки подлинности SQL Server и Windows. c. Нажмите ОК. d. Перезапустите SQL Server, чтобы произошло изменение. Примечание. Это может привести к другим проблемам, таким как определение имени входа SQL. — Попробуйте указать локальную учетную запись Windows или учетную запись домена для имени пользователя. Разрешены только имена входа SQL. Приложение должно использовать встроенную безопасность. |
| Имя входа не существует в экземпляре SQL Server, к которому вы пытаетесь подключиться. | Убедитесь, что имя входа SQL Server существует и правильно написано. Если такой вход не существует, создайте его. Если он присутствует, но имя написано неправильно, исправьте это в приложении строка подключения. В журнале ошибок SQL Server будет одно из следующих сообщений: - Login failed for user 'username'. Reason: Could not find a login matching the name provided.- Login failed for user 'Domain\username'. Reason: Could not find a login matching the name provided.Это может быть распространенной проблемой при развертывании приложения, использующего сервер DEV или QA в рабочей среде, и вы не сможете обновить строку подключения. Чтобы устранить эту проблему, убедитесь, что вы подключаетесь к соответствующему серверу. Если это не так, правильно укажите стоку подключения. Если это так, предоставьте пользователю доступ к SQL Server. Или если это доступ для входа Windows напрямую или его добавление в локальную либо доменную группу, которая разрешена для подключения к серверу базы данных. Дополнительные сведения см. в разделе Создание имени входа. |
| Вы используете проверку подлинности SQL Server, но пароль, указанный для входа в SQL Server, неверный. | Проверьте журнал ошибок SQL для сообщений, таких как "Причина: пароль не совпадал с указанным именем входа", чтобы подтвердить причину. Чтобы устранить проблему, используйте правильный пароль в приложении или используйте другую учетную запись, если пароль не запомнить. Кроме того, обратитесь к администратору SQL Server, чтобы сбросить пароль для учетной записи. Если приложением является SQL Server Integration Services (SSIS), для задания может быть несколько уровней файла конфигурации, который может переопределить параметры диспетчер подключений пакета. Если приложение было написано вашей компанией и строка подключения создается программным способом, обратитесь к группе разработчиков для решения этой проблемы. В качестве временного обходного решения жестко закодируйте строка подключения и тест. Используйте UDL-файл или скрипт для подтверждения подключения с жестко закодированным строка подключения. |
| Строка подключения имеет неправильный синтаксис, имя сервера или учетные данные пользователя. | Чтобы устранить эту проблему, выполните следующие действия.
|
| Нет имени входа | Проверьте, отображает ли SQL Server следующие сообщения:Logon Error: 18456, Severity: 14, State: 11.Logon Login failed for user 'CONTOSO\JohnDoe'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: ]Некоторые ошибки относятся к учетной записи анонимного входа. Это связано с проблемой Kerberos. Была плохая запись вручную в файле HOSTS, то есть неправильное имя сервера. Остальные проблемы могут стать следующими категориями:
|
| Вы пытаетесь подключиться с помощью проверка подлинности Windows, но вошли в неправильный домен. | Убедитесь, что вы правильно вошли в правильный домен. Сообщение об ошибке обычно отображает доменное имя. |
| Проверка разрешений базы данных | База данных не отображается в автономном режиме в СРЕДЕ SQL Server Management Studio. Другие пользователи, например DBA, могут подключиться к нему. Учетная запись пользователя должна быть предоставлена явный доступ к базе данных или добавляться в роль SQL Server или локальную группу Windows или группу домена, доступ к базе данных. Дополнительные сведения см. в разделе CREATE USER, ALTER ROLE и ALTER SERVER ROLE |
| Вы не запускаете приложение (например, SSMS) в качестве администратора. | Если вы пытаетесь подключиться с помощью учетных данных администратора, запустите приложение с помощью параметра "Запуск от имени администратора ". После подключения добавьте пользователя Windows в качестве отдельного имени входа. |
| Имя входа удаляется после миграции на пользователя автономной базы данных. | Если ядро СУБД поддерживает содержащиеся базы данных, убедитесь, что имя входа не было удалено после миграции на пользователя автономной базы данных. Дополнительные сведения см. в статье "Проверка подлинности в автономной базе данных: введение". |
| База данных входа по умолчанию отключена или недоступна. | Обратитесь к администратору SQL Server и устраните проблемы, связанные с доступностью базы данных. Если у входа есть разрешения на другие базы данных на сервере, и вам не нужно получить доступ к текущей настроенной базе данных по умолчанию в приложении, используйте один из следующих вариантов: — попросите администратора изменить базу данных по умолчанию для входа с помощью инструкции ALTER LOGIN или SSMS. — явно укажите другую базу данных в приложении строка подключения. Или если вы используете SSMS, перейдите на вкладку "Свойства подключения", чтобы указать базу данных, доступную в настоящее время.Такие приложения, как SSMS, могут отображать сообщение об ошибке, например следующее: Cannot open user default database. Login failed.Login failed for user <user name>. (Microsoft SQL Server, Error: 4064)В журнале ошибок SQL Server появится сообщение об ошибке, например следующее: Login failed for user '<user name>'. Reason: Failed to open the database '<dbname>' specified in the login properties [CLIENT: <ip address>]Дополнительные сведения см. в MSSQLSERVER_4064. |
| База данных, явно указанная в строка подключения или в SSMS, неправильно написана, отключена или недоступна. | — Исправление имени базы данных в строка подключения. Обратите внимание на конфиденциальность регистра при использовании параметров сортировки с учетом регистра на сервере. — Если имя базы данных правильно, обратитесь к администратору SQL Server и устраните проблемы, связанные с доступностью базы данных. Проверьте, находится ли база данных в автономном режиме, не восстановлена и т. д. — Если имя входа сопоставлено с пользователями с разрешениями на другие базы данных на сервере и вам не нужно получить доступ к текущей настроенной базе данных в приложении, а затем укажите другую базу данных в строка подключения. Или если вы подключаетесь к SSMS, используйте вкладку "Свойства подключения", чтобы указать базу данных, доступную в настоящее время. В журнале ошибок SQL Server появится сообщение об ошибке, например следующее: Login failed for user <UserName>. Reason: Failed to open the explicitly specified database 'dbname'. [CLIENT: <ip address>]Примечание. Если база данных по умолчанию для входа доступна, SQL Server разрешает подключение успешно. Дополнительные сведения см. в MSSQLSERVER_4064. |
| У пользователя нет разрешений на запрошенную базу данных. | — Попробуйте подключиться от имени другого пользователя, имеющего права sysadmin, чтобы узнать, можно ли установить подключение. — предоставьте пользователю доступ к базе данных для входа, создав соответствующего пользователя (например, CREATE USER [<UserName>] FOR LOGIN [UserName]) |
Кроме того, ознакомьтесь с обширным списком кодов ошибок при устранении ошибки 18456.
Дополнительные сведения об устранении неполадок см. в разделе "Устранение неполадок с подключением клиента SQL/ Сервера".
Сбой входа для пользователя NT AUTHORITY\ANONYMOUS LOGON
Для этой проблемы существует по крайней мере четыре сценария. В следующей таблице изучите каждую применимую потенциальную причину и используйте соответствующее разрешение: см. примечание ниже таблицы для объяснения термина двойного прыжка.
| Возможные причины | Предлагаемые разрешения |
|---|---|
| Вы пытаетесь передать учетные данные NT LAN Manager (NTLM) из одной службы в другую службу на том же компьютере (например, из IIS в SQL Server), но в процессе возникает сбой. | Добавьте записи реестра DisableLoopbackCheck или BackConnectionHostNames. |
| Существуют сценарии двойного прыжка (делегирование ограничений) на нескольких компьютерах. Ошибка может возникнуть, если подключение Kerberos завершается ошибкой из-за проблем с именами субъектов-служб (SPN). | Запустите SQLCheck на каждом сервере SQL Server и веб-сервере. Используйте руководства по устранению неполадок: проблема с делегированием учетных данных 0600 и проблема с делегированием связанных серверов SQL Server 0650. |
| Если не используется двойной прыжк (делегирование ограничений), скорее всего, существуют дублирующиеся имена субъектов-служб, и клиент работает в качестве локальной системы или другой учетной записи компьютера, которая получает учетные данные NTLM вместо учетных данных Kerberos. | Используйте SQLCheck или Setspn.exe для диагностики и устранения проблем, связанных с spN. Также ознакомьтесь с обзором Диспетчера конфигурации Kerberos для SQL Server. |
| Возможно, политика локальной безопасности Windows настроена для предотвращения использования учетной записи компьютера для запросов удаленной проверки подлинности. | Перейдите в раздел "Параметры безопасности локальной политики>>>безопасности": разрешить локальной системе использовать удостоверение компьютера для NTLM, выберите параметр "Включен", если параметр отключен, а затем нажмите кнопку "ОК". Примечание. Как описано на вкладке "Объяснение", эта политика включена в Windows 7 и более поздних версиях по умолчанию. |
| Периодические вхождения этой проблемы при использовании ограниченного делегирования могут указывать на наличие просроченного билета, который не может быть продлен средним уровнем. Это ожидаемое поведение с сценарием связанного сервера или любым приложением, которое проводит сеанс входа в систему более 10 часов. | Измените параметры делегирования на сервере среднего уровня на сервере доверия на этом компьютере только для делегирования указанным службам. Используйте Kerberos Only для доверия этому компьютеру только для делегирования указанным службам. Используйте любой протокол. Дополнительные сведения см. в разделе "Временный анонимный вход" связанного сервера SQL Server с двойным прыжком. |
| Вход однорангового узла NTLM | Эта ошибка связана с протоколом проверки подлинности NTLM, используемым ОС Microsoft Windows. При взаимодействии между компьютерами, которые находятся на рабочих станциях или в доменах, которые не доверяют друг другу, можно настроить одинаковые учетные записи на обоих компьютерах и использовать одноранговую проверку подлинности NTLM. Имена входа работают только в том случае, если учетная запись пользователя и пароль совпадают на обоих компьютерах. |
| Защита от циклов | Защита от циклов предназначена для запрета приложений вызывать другие службы на том же компьютере. Чтобы разрешить это, можно задать DisableLoopbackCheck BackConnectionHostNames или (предпочтительный) раздел реестра. Дополнительные сведения см. в статье об ошибке при попытке доступа к серверу локально с помощью полного доменного имени или псевдонима CNAME после установки Windows Server 2003 с пакетом обновления 1 (SP1): доступ запрещен или поставщик сети не принял указанный сетевой путь. |
| Защита от обратного цикла прослушивателя Always-On | При подключении к прослушивателю Always-On с первичного узла соединение будет NTLM. Это приведет к возникновению ошибки "Сбой входа" с сообщением о том, что пользователь находится из недоверенного домена. Чтобы устранить эту ошибку, введите имя прослушивателя NETBIOS и полное имя BackConnectionHostNames в раздел реестра на всех компьютерах в группе доступности. Дополнительные сведения см. в статье об ошибке при попытке доступа к серверу локально с помощью полного доменного имени или псевдонима CNAME после установки Windows Server 2003 с пакетом обновления 1 (SP1): доступ запрещен или поставщик сети не принял указанный сетевой путь. |
| Уровень совместимости LANMAN | Обычно это происходит между старыми компьютерами (до Windows 2008) и более новыми компьютерами. Задайте для уровня совместимости LANMAN значение 5 на всех компьютерах. Это также запрещает NTLM версии 1. Вы также можете переключиться на Kerberos, чтобы избежать этой проблемы. |
| Конфиденциальная учетная запись | Некоторые учетные записи могут быть помечены как конфиденциальные в Active Directory. Эти учетные записи нельзя делегировать другой службе в сценарии двойного прыжка. |
| Не ограниченный целевой объект | Если ограниченное делегирование включено для определенной учетной записи службы, Kerberos завершится ошибкой, если имя субъекта-службы целевого сервера не находится в списке целевых объектов ограниченного делегирования. |
| Per-Service-SID | Эта функция ограничивает локальные подключения для использования NTLM, а не Kerberos в качестве метода проверки подлинности. Служба может сделать один прыжок на другой сервер с помощью учетных данных NTLM, но его нельзя делегировать дальше без использования ограниченного делегирования. |
| NTLM и ограниченное делегирование | Если целевой ресурс является общей папкой, то тип делегирования учетной записи службы среднего уровня должен быть ограничен и не ограничен kerberos. |
Примечание.
Двойной переход обычно включает делегирование учетных данных пользователя на нескольких удаленных компьютерах. Например, предположим, что у вас есть экземпляр SQL Server с именем SQL1, на котором вы создали связанный сервер для удаленного SQL Server с именем SQL2. В конфигурации безопасности связанного сервера выбран параметр Be made using the login's current security context. При использовании этой конфигурации при выполнении запроса связанного сервера в SQL1 с удаленного клиентского компьютера с именем Client1 учетные данные Windows сначала должны переходить от Client1 до SQL1, а затем с SQL1 до SQL2 (следовательно, это называется двойным прыжком). Дополнительные сведения см. в разделе "Общие сведения о двойном прыжке Kerberos" и "Ограниченное делегирование Kerberos"
Сбой входа для пользователя (пустой)
Эта ошибка возникает при неудачном входе пользователя. Эта ошибка может возникнуть, если компьютер не подключен к сети. Например, может появиться сообщение об ошибке, похожее на следующее:
Source: NETLOGON
Date: 8/12/2012 8:22:16 PM
Event ID: 5719
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: <computer name>
Description: This computer was not able to set up a secure session with a domain controller in domain due to the following: The remote procedure call was cancelled.
This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.
Пустая строка означает, что SQL Server пытался передать учетные данные службе подсистемы локального центра безопасности (LSASS), но не удалось из-за какой-то проблемы. Либо LSASS недоступен, либо контроллер домена не удалось связаться.
Кроме того, могут появиться следующие коды ошибок SSPI:
Сбой подтверждения SSPI с кодом ошибки 0x80090311 при установке подключения с интегрированной безопасностью; подключение закрыто.
Сбой подтверждения SSPI с кодом ошибки 0x80090304 при установке подключения с интегрированной безопасностью; подключение закрыто.
Эти коды ошибок преобразуют следующим образом:
Ошибка -2146893039 (0x80090311): для проверки подлинности невозможно связаться с центром. Ошибка -2146893052 (0x80090304): не удается связаться с локальным центром безопасности.
Чтобы устранить эти ошибки, можно отключить контроллер домена в автономном режиме или использовать NLTEST.EXE для переключения контроллеров домена.
— Чтобы запросить контроллер домена, выполните NLTEST /SC_QUERY:CONTOSO команду.
— Чтобы изменить контроллер домена, выполните NLTEST /SC_RESET:CONTOSO\DC03 команду.
Если вам нужна дополнительная помощь, обратитесь в группу Microsoft Active Directory.
Проверьте журналы событий на клиенте и сервере для любых сообщений, связанных с сетью, или сообщений, связанных с Active Directory, которые регистрировались во время сбоя. Если вы найдете их, обратитесь к администратору домена, чтобы устранить проблемы.
Ошибка входа для пользователя "(null)"
Указание значения NULL может означать, что LSASS не может расшифровать маркер безопасности с помощью учетных данных учетной записи службы SQL Server. Основной причиной этого условия является то, что имя участника-службы связано с неправильной учетной записью.
Чтобы устранить проблему, сделайте следующее:
Используйте SQLCheck или Setspn.exe для диагностики и устранения проблем, связанных с spN.
Используйте SQLCheck , чтобы проверить, является ли учетная запись службы SQL доверенной для делегирования. Если выходные данные указывают, что учетная запись не является доверенной для делегирования, обратитесь к администратору Active Directory, чтобы включить делегирование для учетной записи.
Примечание.
-Q И SETSPN -X это полезные команды для проверки повторяющихся или неуместных имен субъектов-служб.
Диагностика и устранение проблем с разрешением доменных имен (DNS). Например:
Ping IP-адрес с помощью скриптов PowerShell:
ping -a <your_target_machine>(в частности, используется-4для IPv4 и-6IPv6)ping -a <your_remote_IPAddress>
Используйте NSLookup , чтобы ввести имя локального и удаленного компьютера и IP-адрес несколько раз.
Найдите несоответствия и несоответствия в возвращаемых результатах. Точность конфигурации DNS в сети важна для успешного подключения к SQL Server. Неправильная запись DNS может вызвать многочисленные проблемы с подключением позже.
Убедитесь, что брандмауэры или другие сетевые устройства не блокируют подключение клиента к контроллеру домена. Имена субъектов-служб хранятся в Active Directory. Если клиенты не могут взаимодействовать с каталогом, подключение не может завершиться успешно.
Дополнительные сведения об ошибке
В целях повышения безопасности сообщение об ошибке, возвращаемое клиенту, намеренно скрывает природу ошибки проверки подлинности. Однако в журнале ошибок SQL Server соответствующая ошибка содержит состояние ошибки, которое сопоставляется с условием сбоя проверки подлинности. Сравните состояние ошибки со следующим списком, чтобы определить причину ошибки имени входа.
| State | описание |
|---|---|
| 1 | Сведения об ошибке недоступны. Обычно это состояние означает, что у вас нет разрешения на получение сведений об ошибке. Чтобы получить дополнительные сведения, обратитесь к администратору SQL Server. |
| 2 | Недопустимый идентификатор пользователя. |
| 5 | Недопустимый идентификатор пользователя. |
| 6 | Предпринята попытка использовать имя входа Windows при использовании проверки подлинности SQL Server. |
| 7 | Имя входа отключено, и пароль неверный. |
| 8 | Пароль неверный. |
| 9 | Недопустимый пароль. |
| 11 | Допустимое имя входа, но доступ к серверу не удался. Одна из возможных причин этой ошибки заключается в том, что пользователь Windows имеет доступ к SQL Server в качестве члена группы локальных администраторов, но Windows не предоставляет учетные данные администратора. Чтобы подключиться, запустите программу подключения с помощью параметра "Запуск от имени администратора ", а затем добавьте пользователя Windows в SQL Server в качестве определенного имени входа. |
| 12 | Допустимое имя входа, но доступ к серверу не удался. |
| 18 | Пароль должен быть изменен. |
| 38, 46 | Не удалось найти базу данных, запрошенную пользователем. |
| 58 | Если SQL Server настроен на использование только проверки подлинности Windows, а клиент пытается выполнить вход с использованием проверки подлинности SQL. Еще одна причина заключается в том, что идентификаторы SID не совпадают. |
| 102–111 | Сбой Azure AD. |
| 122–124 | Сбой из-за пустого имени пользователя или пароля. |
| 126 | База данных, запрошенная пользователем, не существует. |
| 132–133 | Сбой Azure AD. |
Есть другие коды ошибок, которые означают непредвиденные внутренние ошибки обработки.
Более редкие возможные причины
Ошибка, из-за которой попытка входа с помощью проверки подлинности SQL завершилась ошибкой. Сервер настроен только для проверка подлинности Windows. Его можно вернуть в следующих ситуациях.
Если сервер настроен для проверки подлинности в смешанном режиме, а подключение ODBC использует протокол TCP, а подключение явно не указывает, что подключение должно использовать доверенное соединение.
Если SQL Server настроен для проверки подлинности в смешанном режиме, а подключение ODBC использует именованные каналы, а учетные данные, используемые для открытия именованного канала, используются для автоматического олицетворения пользователя, а строка подключения не явно указывает использование доверенной проверки подлинности.
Чтобы решить эту проблему, включите в строку подключения параметр TRUSTED_CONNECTION = TRUE.
Примеры
В этом примере состояние ошибки проверки подлинности равно 8. Это означает, что пароль неверный.
| Дата | Исходный код | Сообщение |
|---|---|---|
| 2007-12-05 20:12:56.34 | Вход в систему | Ошибка: 18456, серьезность: 14, состояние: 8. |
| 2007-12-05 20:12:56.34 | Вход в систему | Ошибка входа для пользователя "<user_name>". [КЛИЕНТ: <IP-адрес>] |
Примечание.
При установке SQL Server с помощью режима проверки подлинности Windows и последующего изменения в режиме проверки подлинности SQL Server и Windows имя входа sa изначально отключено. Это приводит к ошибке 7 состояния: "Ошибка входа для пользователя sa". Чтобы включить вход sa , см. раздел "Изменить режим проверки подлинности сервера".