Problemas de autenticação consistentes no SQL Server

Esta secção lista os problemas relacionados com as definições de configuração que são utilizadas pelas aplicações para ligar a uma base de dados.

• SPN explícito em falta – este problema ocorre se o SPN não estiver configurado ou registado corretamente.

  Solução: Para resolver este problema, veja o erro "Não é possível gerar o contexto de SSPI" ao utilizar a autenticação do Windows para ligar o SQL Server.

• SPN explícito no local incorreto – refere-se a um SPN que foi incorretamente associado a um determinado serviço ou conta.

  Solução: Para resolver este problema, veja Explicit misplaced SPN (SPN explícito no local incorrido).

• O SPN explícito está duplicado – este problema ocorre se um SPN estiver duplicado porque está registado mais do que uma vez.

  Solução: Para resolver este problema, veja o erro "Não é possível gerar o contexto de SSPI" ao utilizar a autenticação do Windows para ligar o SQL Server.

• Nome de servidor incorreto na cadeia de ligação – este problema ocorre se o nome do servidor especificado estiver incorreto ou não for encontrado.

  Solução: Para resolver este problema, veja MSSQLSERVER_18456.

• Nome da base de dados incorreto na cadeia de ligação – este problema ocorre se o nome da base de dados fornecido para autenticação estiver incorreto.

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

• Conta SPN explícita errada – este problema pode ocorrer se o SPN estiver associado à conta errada no AD DS.

  Solução: Para resolver este problema, veja Não é possível gerar o erro de contexto da SSPI.

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

• A base de dados está offline – refere-se a um cenário em que uma base de dados do SQL Server tenta restabelecer ligação 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 da base de dados – refere-se à ativação ou restrição do acesso a uma base de dados do SQL Server.

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

• Erros de conectividade do servidor ligado no SQL Server – ocorre um problema no processo de autenticação que afeta os servidores ligados no contexto do SQL Server.

  Solução: Para resolver este problema, veja Erros de conectividade do servidor ligado no SQL Server.

• Os metadados do servidor ligado são inconsistentes – refere-se a um problema em que os metadados do servidor ligado são inconsistentes ou não correspondem aos metadados esperados.

  Uma vista ou procedimento armazenado consulta as tabelas ou vistas no servidor ligado, mas recebe falhas de início de sessão, mesmo que uma instrução distribuída SELECT copiada do procedimento não o faça.

  Este problema pode ocorrer se a vista tiver sido criada e, em seguida, o servidor ligado tiver sido recriado ou se uma tabela remota tiver sido modificada sem reconstruir a Vista.

  Solução: atualize os metadados do servidor ligado ao executar o sp_refreshview procedimento armazenado.

• A conta proxy não tem permissões – uma tarefa do SQL Server Integration Service (SSIS) executada pelo SQL Agent pode necessitar de permissões diferentes das que a conta de serviço do SQL Agent pode fornecer.

  Solução: Para resolver este problema, veja O pacote do SSIS não é executado quando é chamado a partir de um passo de trabalho do SQL Server Agent.

• Não é possível iniciar sessão na base de dados do SQL Server – a incapacidade de iniciar sessão pode causar falhas na autenticação.

  Solução: Para resolver este problema, veja MSSQLSERVER_18456.

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

• Uma conta está desativada – poderá deparar-se com este cenário se a conta de utilizador tiver sido desativada por um administrador ou por um utilizador. Neste caso, não pode iniciar sessão com esta conta ou não pode utilizar esta conta para iniciar um serviço. Isto pode causar problemas de autenticação consistentes porque pode impedir que aceda a recursos ou realize ações que exijam autenticação.

  Solução: Um administrador de domínio pode corrigir esta situação ao reativar a conta. Quando uma conta é desativada, normalmente é porque um utilizador tentou iniciar sessão com a palavra-passe errada demasiadas vezes ou porque uma aplicação ou serviço está a tentar utilizar uma palavra-passe antiga.

• Uma conta não está no grupo – este problema pode ocorrer se um utilizador estiver a tentar aceder a um recurso restrito a um grupo específico.

  Solução: Verifique os inícios de sessão do SQL para enumerar os grupos permitidos e certifique-se de que o utilizador pertence a um dos grupos.

• Falha na migração da conta – se as contas de utilizador antigas não conseguirem ligar ao servidor, mas as contas criadas recentemente o conseguirem, a migração da conta poderá não estar correta. Este problema está relacionado com o AD DS.

  Solução: Para obter mais informações, veja Transferir inícios de sessão e palavras-passe 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: Utilize o nltest comando para forçar o computador a mudar para outro controlador de domínio. Para obter mais informações, veja Active Directory replication Event ID 2087: DNS lookup failure caused replication to fail.

• Firewall bloqueia o Controlador de Domínio – poderá ter problemas ao gerir o acesso do utilizador aos recursos.

  Solução: Certifique-se de que o controlador de domínio está acessível a partir do cliente ou do servidor. Para tal, utilize o nltest /SC_QUERY:CONTOSO comando .

• O início de sessão é de um domínio não fidedigno – este problema está relacionado com o nível de confiança entre domínios. Poderá ver a seguinte mensagem de erro: "O início de sessão falhou. O início de sessão é de um domínio não fidedigno e não pode ser utilizado com a autenticação do Windows. (18452)."

  O erro 18452 indica que o início de sessão utiliza a Autenticação do Windows, mas o início de sessão é um principal do Windows não reconhecido. Um principal do Windows não reconhecido indica que o início de sessão não pode ser verificado pelo Windows. Isto pode ocorrer porque o início de sessão do Windows é de um domínio não fidedigno. O nível de confiança entre domínios pode causar falhas na autenticação da conta ou na visibilidade do Nome do Fornecedor de Serviços (SPN).

  Solução: Para resolver este problema, veja MSSQLSERVER_18452.

• Sem permissões para grupos entre domínios – os utilizadores do domínio remoto devem pertencer a um grupo no domínio do SQL Server. Poderá existir um problema se tentar utilizar um grupo local de domínio para ligar a uma instância do SQL Server a partir de outro domínio.

  Solução: Se não houver confiança adequada nos domínios, adicionar os utilizadores num grupo no domínio remoto poderá impedir o servidor de enumerar a associação do grupo.

• A autenticação seletiva está desativada – refere-se a uma funcionalidade de fidedignidades de domínio que permite ao administrador de domínio limitar os utilizadores que têm acesso aos recursos no domínio remoto. Se a autenticação seletiva não estiver ativada, todos os utilizadores no domínio fidedigno podem obter acesso ao domínio remoto.

  Solução: Para resolver este problema, ative a autenticação seletiva para garantir que os utilizadores não têm permissão para se autenticarem no domínio remoto.

Esta secção lista os problemas relacionados com a autenticação Kerberos:

• Um sufixo DNS incorreto é anexado ao nome NetBIOS – este problema pode ocorrer se utilizar apenas o nome NetBIOS (por exemplo, SQLPROD01) em vez do nome de domínio completamente qualificado (FQDN) (por exemplo, SQLPROD01.CONTOSO.COM). Quando isto ocorre, o sufixo DNS errado pode ser anexado.

  Solução: Verifique as definições de rede dos sufixos predefinidos para se certificar de que estão corretos ou utilize o FQDN para evitar problemas.

• A distorção do relógio é demasiado elevada – este problema pode ocorrer se vários dispositivos numa rede não estiverem sincronizados. Para que a autenticação Kerberos funcione, os relógios entre dispositivos não podem ser desativados durante mais de cinco minutos ou podem ocorrer falhas de autenticação consistentes.

  Solução: Configure os computadores para sincronizar regularmente os respetivos relógios com um serviço de hora central.

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

  Solução: Para resolver este problema, veja Falha no início de sessão do utilizador NT AUTHORITY\ANONYMOUS LOGON.

• Delegar a uma partilha de ficheiros – refere-se a uma situação em que um utilizador ou aplicação delega as respetivas credenciais para aceder a uma partilha de ficheiros. Sem restrições adequadas, delegar credenciais a uma partilha de ficheiros pode criar riscos de segurança.

  Solução: Para resolver este tipo de problema, certifique-se de que utiliza a delegação restrita.

• Espaço de nomes 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. Poderá deparar-se com problemas de autenticação se utilizar um espaço de nomes não contíguo. Se a hierarquia organizacional no AD DS e no DNS não corresponder, o SPN errado poderá ser gerado se utilizar o nome NETBIOS na cadeia de ligação da aplicação de base de dados. Nesta situação, o SPN não é encontrado e as credenciais do New Technology LAN Manager (NTLM) são utilizadas em vez de credenciais Kerberos.

  Solução: Para mitigar o problema, utilize o FQDN do servidor ou especifique o nome SPN na cadeia de ligação. Para obter informações sobre o FQDN, veja Nomenclatura do Computador.

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

  Solução: Para resolver este problema, veja Corrigir o erro com o Kerberos Configuration Manager (Recomendado).

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

  Solução: Para resolver este problema, pode ativá-lo com a política nos clientes. Em seguida, o http/web01.contoso.com:88 SPN teria de estar no formato para permitir que o Kerberos funcionasse corretamente. Caso contrário, são utilizadas credenciais NTLM.

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

• Permissões expiradas – refere-se aos bilhetes Kerberos. A utilização de permissões Kerberos expiradas pode causar problemas de autenticação.

  Solução: Para resolver este problema, veja Permissões expiradas.

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

  Solução: Reveja o ficheiro HOSTS e remova as entradas do servidor. As entradas de ficheiro HOSTS são apresentadas no relatório SQLCHECK.

• Problema com as permissões do identificador de segurança por serviço (SID) – o SID por serviço é uma funcionalidade de segurança do SQL Server que limita as ligações locais para utilizar o NTLM e não o Kerberos como método de autenticação. O serviço pode fazer um único salto para outro servidor com credenciais NTLM, mas não pode ser delegado sem utilizar a delegação restrita. Para obter mais informações, veja Falha no início de sessão do utilizador NT AUTHORITY\ANONYMOUS LOGON.

  Solução: Para resolver este problema, o administrador de domínio tem de configurar a delegação restrita.

• Autenticação no modo kernel – o SPN na conta do Conjunto de Aplicações é normalmente necessário para servidores Web. No entanto, quando a autenticação no modo kernel é utilizada, o SPN ANFITRIÃO do computador é utilizado para autenticação. Esta ação ocorre no kernel. Esta definição poderá ser utilizada se o servidor aloja vários sites diferentes que utilizam o mesmo URL de cabeçalho de anfitrião, diferentes contas do Conjunto de Aplicações e Autenticação do Windows.

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

• Limitar os direitos de delegação ao Access ou ao Excel – os fornecedores de Tecnologia de Motor Conjunto (JET) e Motor de Conectividade de Acesso (ACE) são semelhantes a qualquer um dos sistemas de ficheiros. Tem de utilizar a delegação restrita para permitir que o SQL Server leia ficheiros localizados noutro computador. Em geral, o fornecedor ACE não deve ser utilizado num servidor ligado porque não é explicitamente suportado. O fornecedor JET foi preterido e está disponível apenas em computadores de 32 bits.

  Observação

  Quando o SQL Server 2014, a última versão para suportar instalações de 32 bits, ficar sem suporte, o cenário JET deixará de ser suportado.

• SPN em falta – este problema pode ocorrer se um SPN relacionado com uma instância do SQL Sever estiver ausente.

  Solução: Para obter mais informações, veja Corrigir o erro com o Kerberos Configuration Manager (Recomendado).

• Não é um destino restrito – se a delegação restrita estiver ativada 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 este problema, um administrador de domínio tem de adicionar o SPN do servidor de destino aos SPNs de destino da conta de serviço de escalão médio.

• NTLM e delegação restrita – se o destino for uma partilha de ficheiros, o tipo de delegação da conta de serviço de escalão médio tem de ser Constrained-Any e não Constrained-Kerberos. Se o tipo de delegação estiver definido como Constrained-Kerberos, a conta de escalão médio pode alocar apenas a serviços específicos, mas Constrained-Any permite que a conta de serviço delegue a qualquer serviço.

  Solução: Para resolver este problema, veja Falha no início de sessão do utilizador NT AUTHORITY\ANONYMOUS LOGON.

• Não é possível confiar na conta de serviço para delegação no AD – num cenário de duplo salto, a conta de serviço do serviço de escalão médio tem de ser fidedigna para delegação no AD DS. Se a conta de serviço não for fidedigna para delegação, a autenticação Kerberos pode falhar.

  Solução: Se for um administrador, ative a opção Fidedigno para delegação .

• Alguns fornecedores legados não suportam Kerberos através de Pipes Nomeados – o fornecedor OLE DB legado (SQLOLEDB) e o fornecedor ODBC (SQL Server) que estão agrupados com o Windows não oferecem suporte para autenticação Kerberos através de Pipes Nomeados. Em vez disso, suportam apenas a autenticação NTLM.

  Solução: Utilize uma ligação TCP para permitir a autenticação Kerberos. Também pode utilizar um controlador mais recente, por exemplo, MSOLEDBSQL ou Controlador ODBC 17. No entanto, o TCP continua a ser preferido em relação aos Pipes Nomeados, independentemente da versão do controlador.

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

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

  Solução: Para resolver o erro, siga estes passos:

  1. Utilize SETSPN -Q spnName para localizar o SPN e a respetiva conta atual.
  2. Utilize SETSPN -D para eliminar os SPNs existentes.
  3. Utilize o SETSPN -S para migrar o SPN para a conta correta.

• O Alias do SQL pode não funcionar corretamente – um alias do SQL Server pode fazer com que seja gerado um SPN inesperado. Isto 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 apresentados no relatório SQLCHECK. Para resolver o problema, identifique e corrija quaisquer aliases de SQL incorretas ou configuradas incorretamente para que apontem para o SQL Server correto.

• O utilizador pertence a muitos grupos – se um utilizador pertencer a vários grupos, poderão ocorrer problemas de autenticação no Kerberos. Se utilizar o Kerberos através de UDP, todo o token de segurança tem de caber num único pacote. Os utilizadores que pertencem a muitos grupos têm um token de segurança maior do que os utilizadores que pertencem a menos grupos.

  Solução: Se utilizar o Kerberos através de TCP, pode aumentar a definição [MaxTokenSize]. Para obter mais informações, veja MaxTokenSize e Kerberos Token Bloat.

• Utilizar o cabeçalho do anfitrião do site – o cabeçalho do Anfitrião HTTP desempenha uma função muito importante no protocolo HTTP para aceder a páginas Web.

  Solução: Se o site tiver um nome de cabeçalho de anfitrião, o SPN ANFITRIÕES não pode ser utilizado. Tem de ser utilizado um SPN HTTP explícito. Se o site não tiver um nome de cabeçalho de anfitrião, será utilizado NTLM. O NTLM não pode ser delegado a uma instância do SQL Server de back-end ou a outro serviço.

Esta secção lista problemas específicos do NTLM (NT LAN Manager):

• Acesso negado para inícios de sessão do elemento da rede NTLM – refere-se a um problema relacionado com inícios de sessão do elemento da rede NTLM.

  Solução: Ao comunicar entre computadores que estão em estações de trabalho ou domínios que não confiam uns nos outros, pode configurar contas idênticas em ambos os computadores e utilizar a autenticação ponto a ponto NTLM.

  Os inícios de sessão só funcionam se a conta de utilizador e a palavra-passe corresponderem em ambos os computadores. A autenticação NTLM pode ser desativada ou não suportada no lado do cliente ou do servidor. Esta 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 duplo salto falhará se forem utilizadas credenciais NTLM. São necessárias credenciais kerberos.

  Solução: Para resolver este problema, veja Falha no início de sessão do utilizador NT AUTHORITY\ANONYMOUS LOGON.

• A proteção contra loopback não está definida corretamente – a proteção do Loopback foi concebida para proibir que as aplicações chamem outros serviços no mesmo computador. Se a proteção contra loopback não estiver configurada corretamente ou se ocorrer alguma avaria, esta situação pode causar indiretamente problemas de autenticação.

  Solução: Para resolver este problema, veja MSSQLSERVER_18456.

• A proteção contra loopback falha quando se liga ao serviço de escuta Always-on – este problema está relacionado com a proteção de loopback. Quando se liga ao serviço de escuta do Always-On a partir do nó primário, a ligação utiliza a autenticação NTLM.

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

• Problema que afeta o nível de compatibilidade LANMAN – normalmente, o problema de autenticação lan manager (LANMAN) ocorre se existir um erro de correspondência nos protocolos de autenticação utilizados pelos computadores mais antigos (anteriores ao Windows Server 2008) e mais recentes. Quando define o nível de compatibilidade como 5, o NTLMv2 não é permitido.

  Solução: Mudar para Kerberos evita este problema porque o Kerberos é mais seguro. Para obter mais informações, veja Falha no início de sessão do utilizador NT AUTHORITY\ANONYMOUS LOGON.

Esta secção lista os problemas relacionados com as credenciais de autenticação:

• Palavra-passe incorreta – refere-se a um problema relacionado com o início de sessão.

  Solução: Para resolver este problema, veja MSSQLSERVER_18456.

• Nome de utilizador inválido – refere-se a um problema relacionado com o início de sessão.

  Solução: Para resolver este problema, veja MSSQLSERVER_18456.

• Os inícios de sessão do SQL Server não estão ativados – refere-se a um cenário em que tenta ligar-se a uma instância do Microsoft SQL Server através da autenticação do SQL Server, mas o início de sessão associado à conta está desativado.

  Solução: Para resolver este problema, veja MSSQLSERVER_18456.

• As ligações pipes nomeadas falham porque o utilizador não tem permissão para iniciar sessão no Windows – Refere-se a um problema de permissões no Windows.

  Solução: Para resolver este problema, veja Problema de ligações de Pipes Nomeados no SQL Server.

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

• O acesso é concedido através de grupos locais – se o utilizador não pertencer a um grupo local que é utilizado para conceder acesso ao servidor, o fornecedor apresenta a mensagem de erro "O início de sessão falhou para o utilizador "contoso/utilizador1".

  Solução: O administrador da base de dados pode verificar esta situação ao examinar a pastaInícios de Sessão de Segurança> no SQL Server Management Studio (SSMS). Se a base de dados for uma base de dados contida, verifique em databasename. Para obter mais informações, veja Falha no início de sessão do utilizador "<nome> de utilizador" ou o início de sessão falhou para o utilizador "<domain>\<username>".

• A proteção de credenciais está ativada – este cenário indica que a funcionalidade Credential Guard está ativada num sistema Windows e é utilizada para criar um ambiente seguro para armazenar informações confidenciais. No entanto, em determinadas situações, esta funcionalidade pode causar problemas de autenticação.

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

• Erros do subsistema de segurança local – quando ocorrem erros do subsistema de segurança local, especialmente aqueles que estão ligados ao LSASS que não respondem, podem indicar problemas subjacentes que afetam a autenticação.

  Solução: Para resolver estes erros, veja Erros do subsistema de segurança local no SQL Server.

• Início de sessão de rede não permitido – este cenário ocorre quando tenta iniciar sessão numa rede, mas o pedido de início de sessão é negado por determinados motivos.

  Solução: Para resolver este problema, veja O utilizador não tem permissões para iniciar sessão na rede.

• Apenas os administradores podem iniciar sessão – este problema ocorre se o registo de segurança num computador estiver cheio e não tiver espaço suficiente para preencher eventos. A funcionalidade de segurança CrashOnAuditFail é utilizada 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 para estiver definida como CrashOnAuditFail2, significa que o registo de segurança está cheio e é apresentada a mensagem de erro "Apenas os Administradores podem iniciar sessão".

  Solução: Para resolver este problema, siga estes passos:

  1. Inicie o Editor de registo.
  2. Localize e verifique a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa!crashonauditfail subchave para ver se o valor está definido como 2. Este valor indica que o registo de segurança requer limpeza manual.
  3. Defina o valor como 0 e, em seguida, reinicie o servidor. Também poderá querer alterar o registo de segurança para permitir que os eventos sejam revertidas. Para obter mais informações sobre como a definição afeta todos os serviços, como SQL, IIS, partilha de ficheiros e início de sessão, veja Os utilizadores não conseguem aceder a Web sites quando o registo de eventos de segurança está cheio.

  Observação

  Este problema afeta apenas os inícios de sessão integrados. Uma ligação Pipes Nomeados também será afetada num início de sessão do SQL Server porque os Pipes Nomeados iniciam sessão primeiro no Windows Admin Pipe antes de se ligar ao SQL Server.

• A conta de serviço não é fidedigna para delegação – normalmente, este tipo de problema ocorre se uma conta de serviço não tiver permissão para atribuir credenciais a outros servidores. Este problema pode afetar os serviços que necessitam de delegação.

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

• Não é possível carregar o perfil de utilizador do Windows no SQL Server – refere-se ao problema do perfil de utilizador do Windows.

  Solução: Para obter mais informações sobre como resolver problemas de perfis de utilizador danificados, veja Não é possível carregar o perfil de utilizador do Windows no SQL Server.

Esta secção lista problemas relacionados com a autenticação e o controlo de acesso num ambiente Web:

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

  Solução: Para resolver este problema, certifique-se de que a opção Autenticação Integrada do Windows está ativada nas definições de Opções da Internet .

• A Autenticação do IIS não é permitida – este problema ocorre devido a configurações incorretas no IIS. As definições de autenticação definidas no ficheiro Web.config da aplicação Web podem entrar em conflito com as definições configuradas no IIS. Esta situação pode causar problemas de autenticação.

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

• Zona de Internet errada – este problema poderá ocorrer se tentar aceder a 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 intranet local.

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