MSSQLSERVER_18456
Aplica-se: 
SQL Server
Detalhes
| Atributo | Valor |
|---|---|
| Nome do produto | SQL Server |
| ID do evento | 18456 |
| Origem do Evento | MSSQLSERVER |
| Componente | SQLEngine |
| Nome simbólico | LOGON_FAILED |
| Texto da mensagem | Falha no logon do usuário '%.*ls'.%.*ls |
Explicação
Você recebe essa mensagem de erro quando uma tentativa de conexão é rejeitada devido a uma falha de autenticação. Os logins de usuário podem falhar por vários motivos, como credenciais inválidas, expiração de senha e ativação do modo de autenticação incorreto. Em muitos casos, os códigos de erro incluem descrições.
Ação do usuário
Os exemplos a seguir são algumas das falhas comuns de logon. Selecione o erro exato que você está enfrentando para solucionar o problema:
Falha no login do usuário '<nome de usuário>' ou falha no login do usuário '<domínio>\<nome de usuário>'
Se o nome de domínio não for especificado, o problema será uma tentativa de logon do SQL Server com falha. Se o nome de domínio for especificado, o problema é uma falha no login da conta de usuário do Windows. Para possíveis causas e resoluções sugeridas, consulte:
| Possível causa | Solução sugerida |
|---|---|
| Você está tentando usar a Autenticação do SQL Server, mas a instância do SQL Server está configurada para o modo de Autenticação do Windows. | Verifique se o SQL Server está configurado para usar o modo de autenticação do SQL Server e do Windows. Você pode examinar e alterar o modo de autenticação da instância do SQL Server na página Segurança em Propriedades da instância correspondente no SQL Server Management Studio (SSMS). Para obter mais informações, consulte Alterar Modo de Autenticação do Servidor. Como alternativa, você pode alterar seu aplicativo para usar o modo de Autenticação do Windows para se conectar ao SQL Server. Observação: você pode ver uma mensagem como a seguinte no log de erros do SQL Server para este cenário: Login failed for user '<UserName>'. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only. |
| Você está tentando acessar o SQL Server por meio de um grupo e vê uma mensagem de erro. | Se você não tiver as permissões necessárias para acessar o servidor, o provedor mostrará a mensagem de erro "Falha no logon para o usuário 'contoso/user1'". Use o recurso "Acesso via grupo" que ajuda você a acessar um servidor com base em sua associação ao grupo. Quando você executa o xp_logininfo 'contoso/user1' procedimento armazenado, pode ocorrer o seguinte:- Se você vir um erro, o SQL Server não poderá resolver o nome de usuário. É provável que um nome não esteja presente no Active Directory (AD) ou que possa haver problemas de conexão com o controlador de domínio (DC). Tente com outro nome para verificar se o problema é específico de uma conta específica. - Se você estiver se conectando a um servidor entre domínios, o grupo deverá estar no domínio do SQL Server, e não no domínio do usuário, para que sua associação possa ser resolvida. - Quando uma consulta de banco de dados não retorna linhas, isso significa que não há nenhum grupo que forneça acesso ao servidor. Quando uma consulta retorna uma ou mais linhas, significa que o usuário pertence a um grupo que fornece acesso. O DBA pode verificar novamente as permissões verificando a pasta Security\Logins no SQL Server Management Studio (SSMS). Segurança \Logons exibe uma lista de logons criados. Se for um banco de dados independente, o DBA poderá verificar Security \Logins sob o nome do banco de dados para verificar e gerenciar os logons. Para obter mais informações, consulte Configurar o controle de acesso e as permissões do usuário. |
| Os logons do SQL não estão habilitados | O sistema de gerenciamento de banco de dados (DBMS) pode mostrar alguma variação da Login failed for user '<username>' mensagem. Para resolver esse erro, siga estas etapas:1. Verifique se o log de erros do SQL Server contém a mensagem de erro "Falha no login para o usuário '<username>'. Motivo: Falha na tentativa de fazer logon usando a autenticação SQL. O servidor está configurado apenas para autenticação do Windows." 2. Use um dos seguintes métodos para resolver o erro: - Use um login integrado. Por exemplo, para provedores OLE DB, adicione INTEGRATED SECURITY=SSPI à cadeia de conexão e, para drivers ODBC, adicione TRUSTED_CONNECTION=YES. O provedor .NET aceita qualquer sintaxe.Observação: isso pode levar a outros problemas se eles não estiverem configurados corretamente para permitir a autenticação integrada e precisarem ser investigados como um problema separado. - Habilite logins SQL no servidor: a. No SQL Server Management Studio, clique com o botão direito do mouse no nome do SQL Server no Pesquisador de Objetos e selecione Propriedades. b. No painel Segurança, selecione o modo de autenticação do SQL Server e do Windows. c. Selecione OK. d. Reinicie o SQL Server para que a alteração ocorra. Observação: isso pode levar a outros problemas, como definir um logon SQL. - Tente especificar uma conta local do Windows ou uma conta de domínio para o nome de usuário. Somente logons SQL são permitidos. O aplicativo deve estar usando segurança integrada. |
| O logon não existe na instância do SQL Server à qual você está tentando se conectar. | Verifique se o logon do SQL Server existe e se você o digitou corretamente. Se o logon não existir, crie-o. Se estiver presente, mas estiver escrito incorretamente, corrija na cadeia de conexão do aplicativo. O log de erros do SQL Server terá uma das seguintes mensagens: - 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.Pode ser um problema comum se você implantar um aplicativo que usa um servidor DEV ou QA em produção e não conseguir atualizar a cadeia de conexão. Para resolver esse problema, verifique se você está se conectando ao servidor apropriado. Caso contrário, corrija a cadeia de conexão. Se estiver, conceda o acesso de logon ao SQL Server. Ou, se for um logon do Windows, conceda acesso diretamente ou adicione-o a um grupo local ou de domínio que tenha permissão para se conectar ao servidor de banco de dados. Para obter mais informações, consulte Crie um logon. |
| Você está usando a Autenticação do SQL Server, mas a senha especificada para o logon do SQL Server está incorreta. | Verifique o log de erros do SQL em busca de mensagens como "Motivo: a senha não correspondeu à do logon fornecido" para confirmar a causa. Para corrigir o problema, use a senha correta em seu aplicativo ou use uma conta diferente se você não conseguir lembrar a senha. Como alternativa, trabalhe com o administrador do SQL Server para redefinir a senha da conta. Se o aplicativo for o SQL Server Integration Services (SSIS), poderá haver vários níveis de um arquivo de configuração para o trabalho, o que poderá substituir as configurações do Gerenciador de Conexões para o pacote. Se o aplicativo foi escrito por sua empresa e a cadeia de conexão é gerada programaticamente, entre em contato com a equipe de desenvolvimento para resolver o problema. Como solução temporária, codifique a cadeia de conexão e teste. Use um arquivo UDL ou um script para provar que uma conexão é possível com uma cadeia de conexão embutida em código. |
| A cadeia de conexão tem sintaxe, nome do servidor ou credenciais de usuário incorretas. | Para resolver isso, siga estas etapas:
|
| Sem login | Verifique se o SQL Server mostra as seguintes mensagens: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: ]Alguns dos erros pertencem à conta de Logon Anônimo. Isso está relacionado ao problema do Kerberos. Houve uma entrada manual incorreta no arquivo HOSTS, ou seja, o nome do servidor errado foi fornecido. As questões restantes podem se enquadrar nas seguintes categorias:
|
| Você está tentando se conectar usando a autenticação do Windows, mas está conectado a um domínio incorreto. | Verifique se você está conectado corretamente ao domínio correto. A mensagem de erro geralmente exibe o nome de domínio. |
| Verificar permissões de banco de dados | O banco de dados não aparece offline no SQL Server Management Studio. Outros usuários, por exemplo, o DBA, podem se conectar a ele. A conta de usuário em questão deve receber acesso explícito ao banco de dados ou ser adicionada a uma função do SQL Server ou a um grupo local do Windows ou grupo de domínio que tenha acesso ao banco de dados. Para obter mais informações, consulte CREATE USER, ALTER ROLE e ALTER SERVER ROLE |
| Você não está executando seu aplicativo (por exemplo, SSMS) como administrador. | Se você estiver tentando se conectar usando suas credenciais de administrador, inicie seu aplicativo usando a opção Executar como Administrador . Quando conectado, adicione seu usuário do Windows como um logon individual. |
| O logon é excluído após uma migração para um usuário de banco de dados independente. | Se o Mecanismo de Banco de Dados der suporte a bancos de dados independentes, confirme se o logon não foi excluído após a migração para um usuário de banco de dados independente. Para obter mais informações, consulte Autenticação de banco de dados independente: introdução. |
| O banco de dados padrão do logon está offline ou não está disponível. | Verifique com o administrador do SQL Server e resolva problemas relacionados à disponibilidade do banco de dados. Se o logon tiver permissões para outros bancos de dados no servidor e você não precisar acessar o banco de dados padrão configurado no momento em seu aplicativo, use uma das seguintes opções: - Solicite ao administrador que altere o banco de dados padrão para o logon usando a instrução ALTER LOGIN ou o SSMS. - Especifique explicitamente um banco de dados diferente na cadeia de conexão do aplicativo. Ou, se você estiver usando o SSMS, alterne para a guia Propriedades da Conexão para especificar um banco de dados que está disponível no momento.Aplicativos como o SSMS podem mostrar uma mensagem de erro como a seguinte: Cannot open user default database. Login failed.Login failed for user <user name>. (Microsoft SQL Server, Error: 4064)O log de erros do SQL Server terá uma mensagem de erro como a seguinte: Login failed for user '<user name>'. Reason: Failed to open the database '<dbname>' specified in the login properties [CLIENT: <ip address>]Para obter mais informações, consulte MSSQLSERVER_4064. |
| O banco de dados especificado explicitamente na cadeia de conexão ou no SSMS está escrito incorretamente, offline ou não está disponível. | - Corrija o nome do banco de dados na cadeia de conexão. Preste atenção à diferenciação de maiúsculas e minúsculas se estiver usando uma ordenação que diferencia maiúsculas de minúsculas no servidor. - Se o nome do banco de dados estiver correto, verifique com o administrador do SQL Server e resolva problemas relacionados à disponibilidade do banco de dados. Verifique se o banco de dados está offline, não recuperado e assim por diante. - Se o logon tiver sido mapeado para usuários com permissões para outros bancos de dados no servidor e você não precisar acessar o banco de dados configurado no momento em seu aplicativo, especifique um banco de dados diferente em sua cadeia de conexão. Ou, se você estiver se conectando ao SSMS, use a guia Propriedades da Conexão para especificar um banco de dados que esteja disponível no momento. O log de erros do SQL Server terá uma mensagem de erro como a seguinte: Login failed for user <UserName>. Reason: Failed to open the explicitly specified database 'dbname'. [CLIENT: <ip address>]Observação: se o banco de dados padrão do logon estiver disponível, o SQL Server permitirá que a conexão seja bem-sucedida. Para obter mais informações, consulte MSSQLSERVER_4064. |
| O usuário não tem permissões para o banco de dados solicitado. | - Tente se conectar como outro usuário que tenha direitos de administrador de sistema para ver se a conectividade pode ser estabelecida. - Conceda ao login acesso ao banco de dados criando o usuário correspondente (por exemplo, CREATE USER [<UserName>] FOR LOGIN [UserName]) |
Além disso, verifique a extensa lista de códigos de erro em Solução de problemas do erro 18456.
Para obter mais ajuda para solução de problemas, consulte Solucionando problemas de conectividade do SQL Client/Server.
Falha no logon do usuário NT AUTHORITY\LOGON ANÔNIMO
Há pelo menos quatro cenários para esse problema. Na tabela a seguir, examine cada causa potencial aplicável e use a resolução apropriada: Consulte a observação abaixo da tabela para obter uma explicação do termo salto duplo.
| Causas potenciais | Resoluções sugeridas |
|---|---|
| Você está tentando passar credenciais NTLM (NTLM (Gerenciador de LAN NT) de um serviço para outro serviço no mesmo computador (por exemplo: do IIS para o SQL Server), mas ocorre uma falha no processo. | Adicione as entradas do Registro DisableLoopbackCheck ou BackConnectionHostNames . |
| Há cenários de salto duplo (delegação de restrição) em vários computadores. O erro pode ocorrer se a conexão Kerberos falhar devido a problemas de SPN (Nomes de Entidade de Serviço). | Execute SQLCheck em cada SQL Server e no servidor Web. Use os guias de solução de problemas: Problema de Delegação de Credencial 0600 e Problemas de Delegação de Servidor Vinculado do SQL Server 0650. |
| Se nenhum salto duplo (delegação de restrição) estiver envolvido, provavelmente existirão SPNs duplicados e o cliente estará em execução como um LocalSystem ou outra conta de computador que obtém credenciais NTLM em vez de credenciais Kerberos. | Use SQLCheck ou Setspn.exe para diagnosticar e corrigir quaisquer problemas relacionados ao SPN. Examine também Visão geral do Kerberos Configuration Manager para SQL Server. |
| A política de Segurança Local do Windows pode ter sido configurada para impedir o uso da conta do computador para solicitações de autenticação remota. | Navegue até Política>de Segurança Local Políticas Locais>Opções>de Segurança Segurança de rede: Permitir que o Sistema Local use a identidade do computador para NTLM, selecione a opção Habilitado se a configuração estiver desabilitada e selecione OK. Observação: conforme detalhado na guia Explicar , essa política está habilitada no Windows 7 e versões posteriores por padrão. |
| A ocorrência intermitente desse problema ao usar a delegação restrita pode indicar a presença de um tíquete expirado que não pode ser renovado pela camada intermediária. Esse é um comportamento esperado com o cenário de servidor vinculado ou qualquer aplicativo que esteja mantendo uma sessão de logon por mais de 10 horas. | Alterar as configurações de delegação no servidor de camada intermediária de Confiar neste computador para delegação somente para serviços especificados - Usar somente Kerberos para confiar neste computador para delegação somente para serviços especificados - Usar qualquer protocolo. Para obter mais informações, consulte LOGON ANSCRINO intermitente do salto duplo do servidor vinculado do SQL Server. |
| NTLM Peer Login | Esse erro está relacionado ao protocolo de autenticação NTLM usado pelo sistema operacional Microsoft Windows. Ao se comunicar entre computadores que estão em estações de trabalho ou em domínios que não confiam uns nos outros, você pode configurar contas idênticas em ambos os computadores e usar a autenticação de mesmo nível NTLM Login de mesmo nível NTLM. Os logons só funcionam se a conta de usuário e a senha corresponderem em ambas as máquinas. |
| Proteção de loopback | A proteção de loopback foi projetada para proibir que os aplicativos chamem outros serviços no mesmo computador. Você pode definir as DisableLoopbackCheck chaves do Registro ou BackConnectionHostNames (preferenciais) para permitir isso. Para obter mais informações, consulte Mensagem de erro ao tentar acessar um servidor localmente usando seu FQDN ou seu alias CNAME após a instalação do Windows Server 2003 Service Pack 1: Acesso negado ou Nenhum provedor de rede aceitou o caminho de rede fornecido. |
| Proteção de loopback de ouvinte sempre ativa | Ao se conectar ao Ouvinte Always-On do nó primário, a conexão será NTLM. Isso ativará a verificação de loopback e resultará em um erro "Falha no login" informando que o usuário é de um domínio não confiável. Para resolver esse erro, digite o nome do NETBIOS do ouvinte e o nome totalmente qualificado na BackConnectionHostNames chave do Registro em todos os computadores do Grupo de Disponibilidade. Para obter mais informações, consulte Mensagem de erro ao tentar acessar um servidor localmente usando seu FQDN ou seu alias CNAME após a instalação do Windows Server 2003 Service Pack 1: Acesso negado ou Nenhum provedor de rede aceitou o caminho de rede fornecido. |
| Nível de compatibilidade LANMAN | Isso geralmente acontece entre computadores mais antigos (anteriores ao Windows 2008) e computadores mais novos. Defina o nível de compatibilidade LANMAN como 5 em todos os computadores. Isso também não permite o NTLM v1. Você também pode alternar para o Kerberos para evitar esse problema. |
| Conta confidencial | Algumas contas podem ser marcadas como confidenciais no Active Directory. Essas contas não podem ser delegadas a outro serviço em um cenário de salto duplo. |
| Não é um alvo restrito | Se a delegação restrita estiver habilitada para uma conta de serviço específica, o Kerberos falhará se o SPN do servidor de destino não estiver na lista de destinos de delegação restrita. |
| SID por serviço | Esse recurso limita as conexões locais a usar NTLM e não Kerberos como método de autenticação. O serviço pode fazer um único salto para outro servidor usando credenciais NTLM, mas não pode ser delegado ainda mais sem o uso de delegação restrita. |
| NTLM e delegação restrita | Se o destino for um compartilhamento de arquivos, o tipo de delegação da conta de serviço de camada intermediária deverá ser Constrained-Any e não Constrained-Kerberos. |
Observação
Um salto duplo normalmente envolve a delegação de credenciais de usuário em vários computadores remotos. Por exemplo, suponha que você tenha uma instância do SQL Server chamada SQL1 em que criou um servidor vinculado para um SQL Server remoto chamado SQL2. Na configuração de segurança do servidor vinculado, você selecionou a opção Ser feito usando o contexto de segurança atual do login. Ao usar essa configuração, se você executar uma consulta de servidor vinculado no SQL1 de um computador cliente remoto chamado Client1, as credenciais do Windows primeiro terão que pular do Client1 para o SQL1 e, em seguida, do SQL1 para o SQL2 (portanto, é chamado de salto duplo). Para obter mais informações, consulte Noções básicas sobre Kerberos Double Hop e Kerberos Constrained Delegation Overview
Falha no login do usuário (vazio)
Esse erro ocorre quando um usuário tenta fazer login sem sucesso. Esse erro pode ocorrer se o computador não estiver conectado à rede. Por exemplo, você pode receber uma mensagem de erro semelhante à seguinte:
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.
Uma cadeia de caracteres vazia significa que o SQL Server tentou entregar as credenciais ao LSASS (Serviço de Subsistema de Autoridade de Segurança Local), mas não conseguiu devido a algum problema. O LSASS não estava disponível ou o controlador de domínio não pôde ser contatado.
Você também pode ver os seguintes códigos de erro SSPI correspondentes:
O handshake SSPI falhou com o código de erro 0x80090311 ao estabelecer uma conexão com segurança integrada; A conexão foi fechada.
O handshake SSPI falhou com o código de erro 0x80090304 ao estabelecer uma conexão com segurança integrada; A conexão foi fechada.
Esses códigos de erro são traduzidos da seguinte forma:
Erro -2146893039 (0x80090311): Nenhuma autoridade pôde ser contatada para autenticação. Erro -2146893052 (0x80090304): A Autoridade de Segurança Local não pode ser contatada.
Para resolver esses erros, você pode colocar o controlador de domínio ofensivo offline ou usá NLTEST.EXE para alternar os controladores de domínio.
- Para consultar o DC, execute o NLTEST /SC_QUERY:CONTOSO comando.
- Para alterar o DC, execute o NLTEST /SC_RESET:CONTOSO\DC03 comando.
Se precisar de mais assistência, entre em contato com a equipe do Microsoft Active Directory.
Verifique os logs de eventos no cliente e no servidor em busca de mensagens relacionadas à rede ou ao Active Directory que foram registradas no momento da falha. Se você encontrar algum, trabalhe com o administrador do domínio para corrigir os problemas.
Falha no logon do usuário "(null)"
Uma indicação de "nulo" pode significar que o LSASS não pode descriptografar o token de segurança usando as credenciais da conta de serviço do SQL Server. O principal motivo para essa condição é que o SPN está associado à conta errada.
Para corrigir o problema, siga estas etapas:
Use o SQLCheck ou Setspn.exe para diagnosticar e corrigir problemas relacionados ao SPN.
Use SQLCheck para verificar se a conta de serviço SQL é confiável para delegação. Se a saída indicar que a conta não é confiável para delegação, trabalhe com o administrador do Active Directory para habilitar a delegação para a conta.
Observação
Os SETSPN -X comandos e -Q são úteis para verificar se há SPNs duplicados ou mal colocados.
Diagnostique e corrija problemas de resolução de nomes do Sistema de Nomes de Domínio (DNS). Por exemplo:
Faça ping no endereço IP usando scripts do PowerShell:
ping -a <your_target_machine>(use-4especificamente para IPv4 e-6IPv6)ping -a <your_remote_IPAddress>
Use NSLookup para inserir o nome do computador local e remoto e o endereço IP várias vezes.
Procure discrepâncias e incompatibilidades nos resultados retornados. A precisão da configuração de DNS na rede é importante para uma conexão bem-sucedida do SQL Server. Uma entrada DNS incorreta pode causar vários problemas de conectividade posteriormente.
Verifique se os firewalls ou outros dispositivos de rede não impedem que um cliente se conecte ao controlador de domínio. Os SPNs são armazenados no Active Directory. Se os clientes não puderem se comunicar com o diretório, a conexão não poderá ser bem-sucedida.
Informações adicionais sobre erros
Para aumentar a segurança, a mensagem de erro que é retornada ao cliente oculta deliberadamente a natureza do erro de autenticação. No entanto, no log de erros do SQL Server, um erro correspondente contém um estado de erro que é mapeado para uma condição de falha de autenticação. Compare o estado de erro com a lista a seguir para determinar a razão da falha no logon.
| Estadual | descrição |
|---|---|
| 1 | As informações de erro não estão disponíveis. Esse estado geralmente significa que você não tem permissão para receber os detalhes do erro. Entre em contato com o administrador do SQL Server para obter mais informações. |
| 2 | O ID do usuário não é válido. |
| 5 | O ID do usuário não é válido. |
| 6 | Uma tentativa foi feita para usar um logon do Windows com Autenticação do SQL Server. |
| 7 | O logon está desabilitado e a senha está incorreta. |
| 8 | A senha está incorreta. |
| 9 | A senha não é válida. |
| 11 | O logon é válido, mas houve falha no acesso ao servidor. Uma possível causa desse erro é quando o usuário do Windows tem acesso ao SQL Server como membro do grupo de administradores locais, mas o Windows não está fornecendo credenciais de administrador. Para se conectar, inicie o programa de conexão usando a opção Executar como administrador e adicione o usuário do Windows ao SQL Server como um logon específico. |
| 12 | O logon é válido, mas houve falha no acesso ao servidor. |
| 18 | A senha deve ser alterada. |
| 38, 46 | Não foi possível encontrar o banco de dados solicitado pelo usuário. |
| 58 | Quando o SQL Server é definido para usar somente a autenticação do Windows e um cliente tenta fazer logon usando a autenticação do SQL. Outra causa é quando os SIDs não correspondem. |
| 102 – 111 | Falha do Azure AD. |
| 122 – 124 | Falha devido a nome de usuário ou senha vazios. |
| 126 | O banco de dados solicitado pelo usuário não existe. |
| 132 – 133 | Falha do Azure AD. |
Outros estados de erro existem e significam um erro de processamento interno inesperado.
Causa possível mais rara
O motivo do erro Falha na tentativa de fazer logon usando a autenticação SQL. O servidor está configurado apenas para autenticação do Windows. pode ser retornado nas seguintes situações.
Quando o servidor é configurado para autenticação de modo misto e uma conexão ODBC usa o protocolo TCP e a conexão não especifica explicitamente que a conexão deve usar uma conexão confiável.
Quando o SQL Server é configurado para autenticação de modo misto e uma conexão ODBC usa pipes nomeados e as credenciais que o cliente usou para abrir o pipe nomeado são usadas para representar automaticamente o usuário e a cadeia de conexão não especifica explicitamente o uso de uma autenticação confiável.
Para resolver esse problema, inclua TRUSTED_CONNECTION = TRUE na cadeia de conexão.
Exemplos
Neste exemplo, o estado do erro de autenticação é 8. Isso indica que a senha está incorreta.
| Data | Origem | Mensagem |
|---|---|---|
| 2007-12-05 20:12:56.34 | Logon | Erro: 18456, Severidade: 14, Estado: 8. |
| 2007-12-05 20:12:56.34 | Logon | Falha no login do usuário '<user_name>'. [CLIENTE: <endereço> ip] |
Observação
Quando o SQL Server é instalado usando o modo de Autenticação do Windows e posteriormente alterado para o modo de Autenticação do SQL Server e do Windows, o logon sa é inicialmente desabilitado. Isso causa o erro de estado 7: "Falha no login para o usuário 'sa'". Para habilitar o logon sa, consulte Alterar o modo de autenticação do servidor.