Problemas de autenticação consistentes no SQL Server

Aplica-se a: SQL Server

Observação

Os comandos fornecidos neste artigo se aplicam somente a sistemas Windows.

Problemas de autenticação consistentes que ocorrem no Microsoft SQL Server geralmente estão relacionados à autenticação e autorização de usuários ou aplicativos que tentam acessar o banco de dados do SQL Server. Esses problemas podem ser falhas de autenticação, erros de acesso negado ou outros problemas relacionados à segurança.

A chave para resolver efetivamente problemas de autenticação consistentes é entender os diferentes tipos de erro e o que cada mensagem de erro significa. Alguns erros podem aparecer em mais de um problema de autenticação. Você pode usar as informações de solução de problemas mencionadas na seção Tipos de erros para resolver o erro.

Pré-requisitos

Antes de iniciar a solução de problemas, trabalhe com a lista de verificação de pré-requisitos para ter as seguintes informações prontas:

• Instale as ferramentas WireShark e Problem Steps Recorder (PSR.exe). Para obter mais informações, consulte Métodos de coleta de dados para solucionar vários tipos de erros.

• Colete as informações do SPN (Nome do Provedor de Serviços) com base nas contas de serviço. Para fazer isso, use o SETSPN -L comando.

Tipos de erros

Esta seção descreve os tipos de erro e informações relacionadas.

• Erros de serviços de diretório: se o arquivo de log de erros do SQL Server contiver uma ou ambas as mensagens a seguir, esse erro estará relacionado aos Serviços de Domínio Active Directory (AD DS). Esse erro também poderá ocorrer se o Windows no computador baseado no SQL Server não puder entrar em contato com o DC (Controlador de Domínio) ou se o LSASS (Serviço de Subsistema de Autoridade de Segurança Local) tiver um problema.

  Error -2146893039 (0x80090311): No authority could be contacted for authentication.
  Error -2146893052 (0x80090304): The Local Security Authority cannot be contacted.
  

• Erros de falha de logon: quando você soluciona o erro "Falha de logon", o log de erros do SQL Server fornece informações adicionais sobre o código de erro 18456, incluindo um valor de estado específico que oferece mais contexto sobre o erro. Para obter mais informações, consulte o arquivo de log de erros do SQL Server no valor do estado SQL. Você pode tentar corrigir o problema de acordo com a descrição do valor do estado.

  A tabela a seguir lista algumas mensagens de erro específicas de "Falha de logon" e suas possíveis causas e soluções.

  Mensagem de erro	Mais informações
  "Ocorreu um erro no nível de transporte ao enviar a solicitação ao servidor."	Verifique se o mapeamento da conta do servidor vinculado está correto. Para obter mais informações, consulte sp_addlinkedsrvlogin.
  "Não é possível gerar contexto SSPI"	A conta SPN explícita pode estar errada, ausente ou extraviada. Verifique se o SPN está na conta errada.
  "Não é possível abrir o teste> de banco de dados <solicitado pelo logon. Houve falha no logon".	O banco de dados pode estar offline ou as permissões podem não ser suficientes. Para obter mais informações, consulte Banco de dados offline no MSSQLSERVER_18456. Além disso, verifique se o nome do banco de dados na cadeia de conexão está correto.
  "Falha no login do nome de usuário> do usuário<."	Esse erro pode ocorrer se a conta proxy não estiver autenticada corretamente.
  "Falha no logon do usuário: 'NT AUTHORITY\ANONYMOUS LOGON'"	Esse erro pode ocorrer se o SPN estiver ausente, o SPN estiver duplicado ou o SPN estiver na conta errada.
  "Falha no login do nome de usuário> do usuário<." "Falha no login do usuário '<database\username>"	Verifique se a cadeia de conexão contém um nome de servidor incorreto. Além disso, verifique se o usuário pertence a um grupo local usado para conceder acesso ao servidor. Para obter mais causas, consulte NT AUTHORITY\ANONYMOUS LOGON.
  "Falha no login do usuário '<nome de usuário>'. Motivo: a senha não correspondeu à do login fornecido."	Esse erro pode ocorrer se uma senha incorreta for usada. Para obter mais informações, consulte Falha no login do usuário '<nome de usuário>' ou falha no login do usuário 'nome de usuário> do< domínio><'.
  "O SQL Server não existe ou o acesso não foi negado."	As conexões de pipes nomeados falham porque o usuário não tem permissão para fazer logon no Windows.
  "O logon é de um domínio não confiável e não pode ser usado com a autenticação do Windows."	Esse erro pode estar relacionado aos problemas do Subsistema de Segurança Local.
  "A conta de usuário não tem permissão para o tipo de login de rede."	Talvez você não consiga fazer login na rede.

Tipos de problemas de autenticação consistentes

Esta seção descreve as causas típicas de problemas de autenticação consistentes, juntamente com suas respectivas soluções. Selecione o tipo de problema para ver os problemas, as causas e as soluções relevantes.

Cadeia de conexão

Esta seção lista os problemas relacionados às definições de configuração usadas pelos aplicativos para se conectar a um banco de dados.

• O SPN explícito está ausente – esse problema ocorrerá se o SPN não estiver configurado ou registrado corretamente.

  Solução: para resolver esse problema, consulte o erro "Não é possível gerar contexto SSPI" ao usar a autenticação do Windows para conectar o SQL Server.

• SPN explícito mal colocado - Refere-se a um SPN que foi associado incorretamente a um determinado serviço ou conta.

  Solução: para resolver esse problema, consulte SPN explícito mal colocado.

• O SPN explícito é duplicado – esse problema ocorre se um SPN for duplicado porque foi registrado mais de uma vez.

  Solução: para resolver esse problema, consulte o erro "Não é possível gerar contexto SSPI" ao usar a autenticação do Windows para conectar o SQL Server.

• Nome de servidor incorreto na cadeia de conexão – esse problema ocorrerá se o nome do servidor especificado estiver incorreto ou não puder ser encontrado.

  Solução: para resolver esse problema, consulte MSSQLSERVER_18456.

• Nome de banco de dados incorreto na cadeia de conexão – esse problema ocorrerá se o nome do banco de dados fornecido para autenticação estiver incorreto.

  Solução: Verifique se o nome está escrito corretamente. Para obter mais informações, consulte MSSQLSERVER_4064.

• Conta SPN explícita incorreta – esse problema poderá ocorrer se o SPN estiver associado à conta errada no AD DS.

  Solução: para resolver esse problema, consulte Não é possível gerar erro de contexto SSPI.

Backup de banco de dados

Esta seção lista os problemas específicos de vários aspectos do SQL Server:

• O banco de dados está offline – refere-se a um cenário no qual um banco de dados do SQL Server tenta se reconectar a uma instância do SQL Server configurada para o modo de Autenticação do Windows.

  Solução: Para obter mais informações, consulte MSSQLSERVER_18456.

• Permissões de banco de dados – refere-se à habilitação ou restrição do acesso a um banco de dados do SQL Server.

  Solução: Para obter mais informações, consulte MSSQLSERVER_18456.

• Erros de conectividade do servidor vinculado no SQL Server – você enfrenta um problema no processo de autenticação que afeta os servidores vinculados no contexto do SQL Server.

  Solução: para resolver esse problema, consulte Erros de conectividade do servidor vinculado no SQL Server.

• Os metadados do servidor vinculado são inconsistentes – refere-se a um problema no qual os metadados do servidor vinculado são inconsistentes ou não correspondem aos metadados esperados.

  Uma exibição ou procedimento armazenado consulta as tabelas ou exibições no servidor vinculado, mas recebe falhas de logon, mesmo que uma instrução distribuída SELECT copiada do procedimento não o faça.

  Esse problema pode ocorrer se a exibição tiver sido criada e, em seguida, o servidor vinculado tiver sido recriado ou uma tabela remota tiver sido modificada sem reconstruir a exibição.

  Solução: atualize os metadados do servidor vinculado executando o sp_refreshview procedimento armazenado.

• A conta proxy não tem permissões – um trabalho do SQL Server Integration Service (SSIS) executado pelo SQL Agent pode exigir permissões diferentes daquelas que a conta de serviço do SQL Agent pode fornecer.

  Solução: para resolver esse problema, consulte O pacote SSIS não é executado quando chamado de uma etapa de trabalho do SQL Server Agent.

• Não é possível fazer logon no banco de dados do SQL Server – a incapacidade de fazer logon pode causar falhas na autenticação.

  Solução: para resolver esse problema, consulte MSSQLSERVER_18456.

Serviços de diretório

Esta seção lista os problemas relacionados a serviços de diretório e servidores.

• Uma conta está desabilitada – você pode enfrentar esse cenário se a conta de usuário tiver sido desabilitada por um administrador ou por um usuário. Nesse caso, você não pode fazer login usando essa conta ou não pode usar essa conta para iniciar um serviço. Isso pode causar problemas de autenticação consistentes porque pode impedir que você acesse recursos ou execute ações que exijam autenticação.

  Solução: um administrador de domínio pode corrigir isso reativando a conta. Quando uma conta é desativada, geralmente é porque um usuário tentou fazer login com a senha errada muitas vezes ou porque um aplicativo ou serviço está tentando usar uma senha antiga.

• Uma conta não está no grupo – esse problema pode ocorrer se um usuário estiver tentando acessar um recurso restrito a um grupo específico.

  Solução: verifique os logons do SQL para enumerar os grupos permitidos e verifique se o usuário pertence a um dos grupos.

• Falha na migração de conta – se as contas de usuário antigas não puderem se conectar ao servidor, mas as contas recém-criadas puderem, a migração de conta poderá não estar correta. Esse problema está relacionado ao AD DS.

  Solução: para obter mais informações, consulte Transferir logons e senhas entre instâncias do SQL Server.

• O controlador de domínio está offline – refere-se a um problema em que o controlador de domínio não está acessível.

  Solução: use o nltest comando para forçar o computador a alternar para outro controlador de domínio. Para obter mais informações, consulte ID do evento de replicação do Active Directory 2087: falha na pesquisa de DNS causou falha na replicação.

• O firewall bloqueia o controlador de domínio - Você pode ter problemas ao gerenciar o acesso do usuário aos recursos.

  Solução: verifique se o controlador de domínio pode ser acessado no cliente ou no servidor. Para fazer isso, use o nltest /SC_QUERY:CONTOSO comando.

• O login é de um domínio não confiável - Esse problema está relacionado ao nível de confiança entre domínios. Você pode ver a seguinte mensagem de erro: "Falha no login. O logon é de um domínio não confiável e não pode ser usado com a autenticação do Windows. (18452)."

  O erro 18452 indica que o logon usa a autenticação do Windows, mas o logon é uma entidade de segurança do Windows não reconhecida. Uma entidade de segurança do Windows não reconhecida indica que o logon não pode ser verificado pelo Windows. Isso pode ocorrer porque o logon do Windows é de um domínio não confiável. O nível de confiança entre domínios pode causar falhas na autenticação da conta ou na visibilidade do SPN (Nome do Provedor de Serviços).

  Solução: para resolver esse problema, consulte MSSQLSERVER_18452.

• Sem permissões para grupos entre domínios – os usuários do domínio remoto devem pertencer a um grupo no domínio do SQL Server. Pode haver um problema se você tentar usar um grupo local de domínio para se conectar a uma instância do SQL Server de outro domínio.

  Solução: se os domínios não tiverem a confiança adequada, adicionar os usuários em um grupo no domínio remoto poderá impedir que o servidor enumere a associação do grupo.

• A autenticação seletiva está desabilitada – refere-se a um recurso de relações de confiança de domínio que permite ao administrador de domínio limitar quais usuários têm acesso aos recursos no domínio remoto. Se a autenticação seletiva não estiver habilitada, todos os usuários no domínio confiável poderão obter acesso ao domínio remoto.

  Solução: para resolver esse problema, habilite a autenticação seletiva para garantir que os usuários não tenham permissão para se autenticar no domínio remoto.

Autenticação Kerberos

Esta seção lista os problemas relacionados à autenticação Kerberos:

• Um sufixo DNS incorreto é acrescentado ao nome NetBIOS – esse problema pode ocorrer se você usar apenas o nome NetBIOS (por exemplo, SQLPROD01) em vez do FQDN (nome de domínio totalmente qualificado) (por exemplo, SQLPROD01.CONTOSO.COM). Quando isso ocorre, o sufixo DNS incorreto pode ser anexado.

  Solução: verifique as configurações de rede para os sufixos padrão para garantir que estejam corretos ou use o FQDN para evitar problemas.

• A distorção do relógio é muito alta – esse problema pode ocorrer se vários dispositivos em uma rede não estiverem sincronizados. Para que a autenticação Kerberos funcione, os relógios entre os dispositivos não podem ser desligados por mais de cinco minutos ou podem ocorrer falhas de autenticação consistentes.

  Solução: Configure os computadores para sincronizar regularmente seus relógios com um serviço de horário central.

• Delegando contas confidenciais a outros serviços – algumas contas podem ser marcadas como Sensitive no AD DS. Essas contas não podem ser delegadas a outro serviço em um cenário de salto duplo. Contas confidenciais são essenciais para fornecer segurança, mas podem afetar a autenticação.

  Solução: para resolver esse problema, consulte Falha no logon do usuário NT AUTHORITY\ANONYMOUS LOGON.

• Delegar a um compartilhamento de arquivos – refere-se a uma situação em que um usuário ou aplicativo delega suas credenciais para acessar um compartilhamento de arquivos. Sem restrições apropriadas, delegar credenciais a um compartilhamento de arquivos pode criar riscos de segurança.

  Solução: para resolver esse tipo de problema, use a delegação restrita.

• Namespace DNS não contíguo – refere-se a um problema de autenticação consistente que pode ocorrer se o sufixo DNS não corresponder entre o membro do domínio e o DNS. Você pode ter problemas de autenticação se usar um namespace não contíguo. Se a hierarquia organizacional no AD DS e no DNS não corresponder, o SPN incorreto poderá ser gerado se você usar o nome NETBIOS na cadeia de conexão do aplicativo de banco de dados. Nessa situação, o SPN não é encontrado e as credenciais do NTLM (New Technology LAN Manager) são usadas em vez das credenciais Kerberos.

  Solução: para atenuar o problema, use o FQDN do servidor ou especifique o nome do SPN na cadeia de conexão. Para obter informações sobre FQDN, consulte Nomenclatura de Computador.

• SPN duplicado - Refere-se a uma situação em que dois ou mais SPNs são idênticos em um domínio. Os SPNs são usados para identificar exclusivamente os serviços que estão sendo executados em servidores em um domínio do Windows. SPNs duplicados podem causar problemas de autenticação.

  Solução: para resolver esse problema, consulte Corrigir o erro com o Kerberos Configuration Manager (recomendado).

• Habilitar portas HTTP em SPNs – normalmente, os SPNs HTTP não usam números de porta (por exemplo, http/web01.contoso.com).

  Solução: para resolver esse problema, você pode habilitar isso usando a política nos clientes. O SPN teria que estar no formato para permitir que o http/web01.contoso.com:88 Kerberos funcionasse corretamente. Caso contrário, as credenciais NTLM serão usadas.

  As credenciais NTLM não são recomendadas porque podem dificultar o diagnóstico do problema. Além disso, essa situação pode gerar sobrecarga administrativa excessiva.

• Tíquetes expirados - Refere-se a tíquetes Kerberos. O uso de tíquetes Kerberos expirados pode causar problemas de autenticação.

  Solução: para resolver esse problema, consulte Tickets expirados.

• O arquivo HOSTS está incorreto – o arquivo HOSTS pode interromper as pesquisas de DNS e gerar um nome SPN inesperado. Essa situação faz com que as credenciais NTLM sejam usadas. Se um endereço IP inesperado estiver no arquivo HOSTS, o SPN gerado poderá não corresponder ao servidor back-end apontado.

  Solução: revise o arquivo HOSTS e remova as entradas do servidor. As entradas do arquivo HOSTS são mostradas no relatório SQLCHECK.

• Problema com permissões SID (identificador de segurança) por serviço – o SID por serviço é um recurso de segurança do SQL Server que 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 usar a delegação restrita. Para obter mais informações, consulte Falha no logon do usuário NT AUTHORITY\ANONYMOUS LOGON.

  Solução: para resolver esse problema, o administrador do domínio precisa configurar a delegação restrita.

• Autenticação no modo kernel – o SPN na conta do Pool de Aplicativos normalmente é necessário para servidores Web. No entanto, quando a autenticação no modo kernel é usada, o SPN HOST do computador é usado para autenticação. Essa ação ocorre no kernel. Essa configuração poderá ser usada se o servidor hospedar muitos sites diferentes que usam a mesma URL de cabeçalho de host, contas diferentes do Pool de Aplicativos e Autenticação do Windows.

  Solução: remova os SPNs HTTP se a autenticação no modo kernel estiver habilitada.

• Limitar os direitos de delegação ao Access ou Excel – os provedores Joint Engine Technology (JET) e Access Connectivity Engine (ACE) são semelhantes a qualquer um dos sistemas de arquivos. Você deve usar a delegação restrita para permitir que o SQL Server leia arquivos localizados em outro computador. Em geral, o provedor ACE não deve ser usado em um servidor vinculado porque isso não é explicitamente suportado. O provedor JET foi preterido e está disponível somente em computadores de 32 bits.

  Observação

  Quando o SQL Server 2014, a última versão a dar suporte a instalações de 32 bits, ficar sem suporte, o cenário JET não terá mais suporte.

• SPN ausente – esse problema poderá ocorrer se um SPN relacionado a uma instância do SQL Server estiver ausente.

  Solução: para obter mais informações, consulte Corrigir o erro com o Kerberos Configuration Manager (recomendado).

• Não é um destino 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.

  Solução: para resolver esse problema, um administrador de domínio deve adicionar o SPN do servidor de destino aos SPNs de destino da conta de serviço de camada intermediária.

• 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. Se o tipo de delegação estiver definido como Constrained-Kerberos, a conta de camada intermediária poderá alocar apenas para serviços específicos, mas Constrained-Any permite que a conta de serviço delegue a qualquer serviço.

  Solução: para resolver esse problema, consulte Falha no logon do usuário NT AUTHORITY\ANONYMOUS LOGON.

• A conta de serviço não pode ser confiável para delegação no AD – em um cenário de salto duplo, a conta de serviço do serviço de camada intermediária deve ser confiável para delegação no AD DS. Se a conta de serviço não for confiável para delegação, a autenticação Kerberos poderá falhar.

  Solução: se você for um administrador, habilite a opção Confiável para delegação .

• Alguns provedores herdados não dão suporte a Kerberos em pipes nomeados – o provedor OLE DB herdado (SQLOLEDB) e o provedor ODBC (SQL Server) que são empacotados com Windows não oferecem suporte para autenticação Kerberos em pipes nomeados. Em vez disso, eles dão suporte apenas à autenticação NTLM.

  Solução: use uma conexão TCP para permitir a autenticação Kerberos. Você também pode usar um driver mais recente, por exemplo, MSOLEDBSQL ou ODBC Driver 17. Mas o TCP ainda é preferido em relação aos pipes nomeados, independentemente da versão do driver.

• O SPN está associado a uma conta errada – esse problema pode ocorrer se um SPN estiver associado à conta errada no AD DS. Para obter mais informações, consulte Corrigir o erro com o Kerberos Configuration Manager (recomendado).

  Você poderá receber uma mensagem de erro se o SPN estiver configurado na conta errada no AD DS.

  Solução: Para resolver o erro, siga estas etapas:

  1. Use SETSPN -Q spnName para localizar o SPN e sua conta atual.
  2. Use SETSPN -D para excluir os SPNs existentes.
  3. Use o SETSPN -S para migrar o SPN para a conta correta.

• Alias do SQL pode não funcionar corretamente – um alias do SQL Server pode fazer com que um SPN inesperado seja gerado. Isso faz com que as credenciais NTLM falhem se o SPN não for encontrado ou uma falha de SSPI se corresponder inadvertidamente ao SPN de outro servidor.

  Solução: os aliases SQL são mostrados no relatório SQLCHECK. Para resolver o problema, identifique e corrija quaisquer aliases SQL incorretos ou mal configurados para que eles apontem para o SQL Server correto.

• O usuário pertence a muitos grupos - Se um usuário pertencer a vários grupos, poderão ocorrer problemas de autenticação no Kerberos. Se você usar Kerberos sobre UDP, todo o token de segurança deverá caber em um único pacote. Os usuários que pertencem a muitos grupos têm um token de segurança maior do que os usuários que pertencem a menos grupos.

  Solução: se você usar Kerberos sobre TCP, poderá aumentar a configuração [MaxTokenSize]. Para obter mais informações, consulte MaxTokenSize e Inchaço de token Kerberos.

• Usar cabeçalho de host de site - O cabeçalho HTTP Host desempenha um papel muito importante no protocolo HTTP para acessar páginas da web.

  Solução: se o site tiver um nome de cabeçalho de host, o SPN HOSTS não poderá ser usado. Um SPN HTTP explícito deve ser usado. Se o site não tiver um nome de cabeçalho de host, o NTLM será usado. O NTLM não pode ser delegado a uma instância de back-end do SQL Server ou a outro serviço.

Gerenciador de LAN NT (NTLM)

Esta seção lista os problemas específicos do NTLM (NTL LAN Manager):

• O acesso é negado para logons de mesmo nível NTLM - Refere-se a um problema relacionado a logons de mesmo nível NTLM.

  Solução: ao se comunicar entre computadores que estão em estações de trabalho ou 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.

  Os logons funcionam somente se a conta de usuário e a senha corresponderem em ambos os computadores. A autenticação NTLM pode estar desabilitada ou não ter suporte no lado do cliente ou do servidor. Essa situação pode causar falhas de autenticação. Para obter mais informações, consulte MSSQLSERVER_18456.

• Cenários de salto duplo em vários computadores – um processo de salto duplo falhará se as credenciais NTLM forem usadas. As credenciais Kerberos são necessárias.

  Solução: para resolver esse problema, consulte Falha no logon do usuário NT AUTHORITY\ANONYMOUS LOGON.

• A proteção de loopback não está definida corretamente – a proteção de loopback foi projetada para proibir que os aplicativos chamem outros serviços no mesmo computador. Se a proteção contra loopback não estiver configurada corretamente ou se houver algum mau funcionamento, essa situação poderá causar indiretamente problemas de autenticação.

  Solução: para resolver esse problema, consulte MSSQLSERVER_18456.

• A proteção de loopback falha quando você se conecta ao ouvinte Always-on – esse problema está relacionado à proteção de loopback. Quando você se conecta ao Ouvinte Always-On do nó primário, a conexão usa a autenticação NTLM.

  Solução: Para obter mais informações, consulte MSSQLSERVER_18456.

• Problema que afeta o nível de compatibilidade do LANMAN - O problema de autenticação do LAN Manager (LANMAN) geralmente ocorre se houver uma incompatibilidade nos protocolos de autenticação usados por computadores mais antigos (anteriores ao Windows Server 2008) e mais recentes. Quando você define o nível de compatibilidade como 5, o NTLMv2 não é permitido.

  Solução: alternar para o Kerberos evita esse problema porque o Kerberos é mais seguro. Para obter mais informações, consulte Falha no logon do usuário NT AUTHORITY\ANONYMOUS LOGON.

Logon do SQL

Esta seção lista os problemas relacionados às credenciais de autenticação:

• Senha incorreta - Refere-se a um problema relacionado ao login.

  Solução: para resolver esse problema, consulte MSSQLSERVER_18456.

• Nome de usuário inválido - Refere-se a um problema relacionado ao login.

  Solução: para resolver esse problema, consulte MSSQLSERVER_18456.

• Os logons do SQL Server não estão habilitados – refere-se a um cenário no qual você tenta se conectar a uma instância do Microsoft SQL Server usando a autenticação do SQL Server, mas o logon associado à conta está desabilitado.

  Solução: para resolver esse problema, consulte MSSQLSERVER_18456.

• As conexões de pipes nomeados falham porque o usuário não tem permissão para fazer logon no Windows - Refere-se a um problema de permissões no Windows.

  Solução: para resolver esse problema, consulte Problema de conexões de pipes nomeados no SQL Server.

Permissões do Windows

Esta seção lista problemas específicos das permissões ou configurações de política do Windows:

• O acesso é concedido por meio de grupos locais – se o usuário não pertencer a um grupo local usado para conceder acesso ao servidor, o provedor exibirá a mensagem de erro "Falha no logon para o usuário 'contoso/user1'".

  Solução: o administrador do banco de dados pode verificar essa situação examinando a pasta Logons de Segurança>no SQL Server Management Studio (SSMS). Se o banco de dados for um banco de dados independente, verifique em databasename. Para obter mais informações, consulte Falha no logon do usuário '<username>' ou logon failed for user '<domain>\<username>'.

• O Credential Guard está habilitado – esse cenário indica que o recurso Credential Guard está habilitado em um sistema Windows e é usado para criar um ambiente seguro para armazenar informações confidenciais. No entanto, em determinadas situações, esse recurso pode causar problemas de autenticação.

  Solução: para resolver esse problema, peça a um administrador de domínio para configurar a delegação restrita. Para obter mais informações, consulte Considerações e problemas conhecidos ao usar o Credential Guard.

• Erros do subsistema de segurança local - Quando você experimenta erros do subsistema de segurança local, particularmente aqueles que estão vinculados ao LSASS que não responde, isso pode indicar problemas subjacentes que afetam a autenticação.

  Solução: para resolver esses erros, consulte Erros do subsistema de segurança local no SQL Server.

• Logon de rede não permitido – esse cenário ocorre quando você tenta fazer logon em uma rede, mas sua solicitação de logon é negada por determinados motivos.

  Solução: para resolver esse problema, consulte O usuário não tem permissões para fazer logon na rede.

• Somente administradores podem fazer logon – esse problema ocorre se o log de segurança em um computador estiver cheio e não tiver espaço suficiente para preencher eventos. O recurso de segurança, CrashOnAuditFail, é usado pelos administradores do sistema para verificar todos os eventos de segurança. Os valores válidos para CrashOnAuditFail são 0, 1 e 2. Se a chave for CrashOnAuditFail definida como 2, isso significa que o log de segurança está cheio e a mensagem de erro "Somente administradores podem fazer login" é exibida.

  Solução: para resolver o problema, siga estas etapas:

  1. Inicie o editor do Registro.
  2. Localize e verifique a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa!crashonauditfail subchave para ver se o valor está definido como 2. Esse valor indica que o log de segurança requer limpeza manual.
  3. Defina o valor como 0 e reinicie o servidor. Você também pode querer alterar o log de segurança para permitir que os eventos sejam substituídos. Para obter mais informações sobre como a configuração afeta todos os serviços, como SQL, IIS, compartilhamento de arquivos e logon, consulte Os usuários não podem acessar sites quando o log de eventos de segurança está cheio.

  Observação

  Esse problema afeta apenas logins integrados. Uma conexão de Pipes Nomeados também será afetada em um logon do SQL Server porque os Pipes Nomeados primeiro fazem logon no Pipe de Administração do Windows antes de se conectar ao SQL Server.

• A conta de serviço não é confiável para delegação – esse tipo de problema geralmente ocorre se uma conta de serviço não tiver permissão para atribuir credenciais a outros servidores. Esse problema pode afetar os serviços que exigem delegação.

  Solução: se um cenário de delegação não estiver habilitado, verifique o SQL Server secpol.msc para determinar se a conta de serviço do SQL Server está listada nas configurações de política de segurança Atribuição de Direitos de > Usuário de Diretivas > Locais Representar um cliente após a autenticação. Para obter mais informações, consulte Habilitar contas de computador e de usuário para serem confiáveis para delegação.

• O perfil de usuário do Windows não pode ser carregado no SQL Server – refere-se ao problema do perfil de usuário do Windows.

  Solução: para obter mais informações sobre como solucionar problemas de perfis de usuário corrompidos, consulte O perfil de usuário do Windows não pode ser carregado no SQL Server.

Outros aspectos

Esta seção lista os problemas relacionados à autenticação e ao controle de acesso em um ambiente da Web:

• A autenticação integrada não está habilitada – refere-se a um problema de configuração no qual a IWA (Autenticação Integrada do Windows) não está configurada corretamente.

  Solução: para resolver esse problema, verifique se a opção Autenticação Integrada do Windows está habilitada nas configurações de Opções da Internet.

• A autenticação do IIS não é permitida – esse problema ocorre devido a configurações incorretas no IIS. As configurações de autenticação definidas no arquivo Web.config do aplicativo Web podem entrar em conflito com as configurações definidas no IIS. Essa situação pode causar problemas de autenticação.

  Solução: para resolver esse problema, configure o site para habilitar a Autenticação do Windows e defina o <identity impersonate="true"/> valor no arquivo Web.config.

• Zona de Internet errada - Esse problema pode ocorrer se você tentar acessar um site que não esteja na zona de Internet correta no Internet Explorer. As credenciais não funcionarão se o site estiver na zona da Intranet local.

  Solução: adicione o servidor Web à zona de intranet local do IE.

Aviso de isenção de responsabilidade para informações de terceiros

Os produtos de terceiros mencionados neste artigo são produzidos por empresas independentes da Microsoft. A Microsoft não oferece nenhuma garantia, implícita ou não, do desempenho ou da confiabilidade desses produtos.

Mais informações

Coletar dados para solucionar problemas de conectividade do SQL Server