Falha no login do usuário 'DOMAIN \ MACHINENAME $'

Eu sei que isso é quase uma duplicata de: O erro "Falha de login para o usuário 'NT AUTHORITY \ IUSR'" no ASP.NET e SQL Server 2008 e o login falhou para o usuário 'nome de usuário' - System.Data.SqlClient.SqlException com LINQ em projeto externo / biblioteca de classe, mas algumas coisas não somam em comparação com outros aplicativos no meu servidor e não tenho certeza por quê.

Caixas em uso:

Web Box
SQL Box
SQL Test Box

Minha aplicação:

Eu tenho um aplicativo da Web ASP.NET, que faz referência a uma biblioteca de classes que usa LINQ-to-SQL. Cadeia de conexão configurada corretamente na biblioteca de classes. De acordo com o Login falhou para o usuário 'username' - System.Data.SqlClient.SqlException com LINQ no projeto externo / biblioteca de classes , também adicionei esta string de conexão ao aplicativo da web.

A string de conexão usa credenciais SQL como tal (no aplicativo da web e na biblioteca de classes):

 <add name="Namespace.My.MySettings.ConnectionStringProduction"
        connectionString="Data Source=(SQL Test Box);Initial Catalog=(db name);Persist Security Info=True;User ID=ID;Password=Password"
        providerName="System.Data.SqlClient" />

Esta conexão foi confirmada como funcionando, adicionando-a ao Server Explorer. Esta é a string de conexão que meu arquivo .dbml está usando.

O problema:

Estou tendo o erro a seguir:

System.Data.SqlClient.SqlException: Login failed for user 'DOMAIN\MACHINENAME$'.

Agora referenciando isso O erro "Falha no login do usuário 'NT AUTHORITY \ IUSR'" no ASP.NET e no SQL Server 2008 diz que esse é realmente o serviço de rede local e o uso de qualquer outro nome que não seja de domínio não funcionará.

Mas estou confuso porque marquei SQL Box e SQL Test Box SQL Management Studio e ambos têm NT AUTHORITY/NETWORK SERVICEem Segurança -> Logins, no nível do banco de dados, que não está listado em Segurança -> Usuários, mas no nível do banco de dados Segurança -> Usuários Tenho o usuário exibido na string de conexão.

No nível NTFS no servidor web, as permissões têm o SERVIÇO DE REDE tem controle total.

A razão pela qual estou confuso é porque tenho muitos outros aplicativos da Web em meu servidor Web, que fazem referência a bancos de dados no SQL Box e no SQL Test Box, e todos funcionam. Mas não consigo encontrar uma diferença entre eles e meu aplicativo atual, a não ser que estou usando uma biblioteca de classes. Isso vai importar? A verificação de permissões NTFS, a configuração de logins de segurança nos níveis de servidor e bancos de dados, cadeia de caracteres de conexão e método de conexão (credenciais do SQL Server) e pool de aplicativos IIS e outras opções de pasta são todos iguais.

Por que esses aplicativos funcionam sem adicionar o machinename $ às permissões de nenhuma das minhas caixas SQL? Mas é isso que o link está me dizendo para fazer para corrigir esse problema.

O SERVIÇO DE REDE e o LocalSystem se autenticarão sempre como a conta correspondente localmente (serviço de rede embutido e sistema interno), mas ambos serão autenticados como conta da máquina remotamente.

Se você vir uma falha como Login failed for user 'DOMAIN\MACHINENAME$'isso, significa que um processo em execução como SERVIÇO DE REDE ou como LocalSystem acessou um recurso remoto, autenticou-se como a conta da máquina e teve a autorização negada.

Um exemplo típico seria um aplicativo ASP em execução em um pool de aplicativos definido para usar a credencial NETWORK SERVICE e se conectar a um SQL Server remoto: o pool de aplicativos será autenticado como a máquina que executa o pool de aplicativos e é esta conta de máquina que precisa ter acesso .

Quando o acesso é negado a uma conta da máquina, o acesso deve ser concedido à conta da máquina. Se o servidor se recusar a acessar 'DOMÍNIO \ MÁQUINA $', você deve conceder direitos de login a 'DOMÍNIO \ MÁQUINA $' e não ao SERVIÇO DE REDE. Conceder acesso ao NETWORK SERVICE permitiria que um processo local rodando como NETWORK SERVICE se conectasse, não um remoto, já que o remoto irá autenticar como, você adivinhou, DOMAIN \ MACHINE $.

Se você espera que o aplicativo asp se conecte ao SQL Server remoto como um login do SQL e obtenha exceções sobre DOMAIN \ MACHINE $, isso significa que você usa Segurança Integrada na cadeia de conexão. Se isso for inesperado, significa que você estragou as cadeias de conexão que usa.

Este erro ocorre quando você configura seu aplicativo com o IIS, e o IIS vai para o SQL Server e tenta fazer o login com credenciais que não têm as permissões adequadas. Esse erro também pode ocorrer quando a replicação ou o espelhamento é configurado. Vou repassar uma solução que sempre funciona e é muito simples. Vá para SQL Server >> Segurança >> Logins e clique com o botão direito em NT AUTHORITY \ NETWORK SERVICE e selecione Propriedades

Na tela recém-aberta de Propriedades de Login, vá para a guia “Mapeamento de Usuário”. Em seguida, na guia “Mapeamento de usuário”, selecione o banco de dados desejado - especialmente o banco de dados para o qual esta mensagem de erro é exibida. Na tela inferior, verifique a função db_owner. Clique OK.

No meu caso, eu tinha o Identity="ApplicationPoolIdentity"meu pool de aplicativos IIS.

Depois de adicionar o IIS APPPOOL\ApplicationNameusuário ao SQL Server, ele funciona.

Basicamente, para resolver isso, precisamos ter algumas configurações como

• Aplicativo da Web em execução em ApplicationPoolIdentity
• Aplicativo da Web conectando-se a bancos de dados por meio do ADO.Net usando a autenticação do Windows na string de conexão

A string de conexão usada com a autenticação do Windows inclui o Trusted_Connection=Yesatributo ou o atributo equivalente Integrated Security=SSPIno Web.configarquivo

Minha conexão de banco de dados está no modo de autenticação do Windows. Resolvi isso simplesmente alterando a identidade dos pools de aplicativos de ApplicationPoolIdentity para minhas credenciais de login de domínio DomainName \ MyloginId

Degrau:

1. Clique em Pools de aplicativos

2. Selecione o nome do seu aplicativo

3. Vá para a configuração avançada

4. Expanda Modelo de Processo e clique em Identidade . Clique em três pontos na extremidade direita.
5. Clique no botão Definir ... e forneça suas credenciais de login de domínio

Para mim foi resolvido.

Nota: No ambiente de produção ou TI, você pode ter uma conta de serviço no mesmo domínio para a identidade do pool de aplicativos. Em caso afirmativo, use a conta de serviço em vez do seu login.

O truque que funcionou para mim foi remover Integrated Securityda minha string de conexão e adicionar uma User ID=userName; Password=passwordstring de conexão regular no App.configdo seu bibliotecário. Pode não estar usando segurança integrada, mas a criada em Web.configestá!

Um colega teve o mesmo erro e foi devido a um pequeno erro de configuração no IIS.
O pool de aplicativos incorreto foi atribuído ao aplicativo da web.

Na verdade, usamos um pool de aplicativos personalizado com uma identidade específica para atender às nossas necessidades.

Em seu gerenciador do IIS local -> Sites -> Site padrão -> Nome do nosso aplicativo da Web -> Configurações básicas ... O pool de aplicativos era "DefaultAppPool" em vez de nosso pool de aplicativos personalizado.

Definir o pool de aplicativos correto resolveu o problema.

Eu adicionei <identity impersonate="true" />ao meu web.config e funcionou bem.

Para mim, o problema foi resolvido quando substituí a conta interna padrão 'ApplicationPoolIdentity' por uma conta de rede que permitia o acesso ao banco de dados.

As configurações podem ser feitas no Internet Information Server (IIS 7+)> Application Pools> Advanded Settings> Process Model> Identity

Para mim, o problema com 'DOMAIN \ MACHINENAME $' foi corrigido ao definir a DefaultApplicationPoolidentidade como NetworkService.

Recebíamos mensagens de erro semelhantes durante o processamento de um banco de dados do Analysis Services. Descobriu-se que o nome de usuário, usado para executar a instância do Analysis Services, não foi adicionado aos Logins de Segurança do SQL Server.

No SQL Server 2012, os serviços SQL Server e Analysis são configurados para serem executados como usuários diferentes por padrão. Se você optou pelos padrões, sempre certifique-se de que o usuário AS tenha acesso à sua fonte de dados!

Verifique se você tem

User Instance=true

na string de conexão. Tente removê-lo, o que resolverá seu problema.

Também tive este erro com um usuário autenticado do SQL Server

Tentei algumas das correções, mas não funcionaram.

A solução no meu caso foi configurar o seu "Modo de Autenticação do Servidor" para permitir a autenticação do SQL Server, em Management Studio: Propriedades / Segurança.

O único ponto que todos parecem ter esquecido é que você pode querer segurança integrada = verdadeira. Você pode ter o site funcionando sob uma conta de pool. Está tudo bem e ainda é possível acessar o servidor SQL com a credencial de usuário original e não a do pool. É chamado de delegação restrita. Se você habilitá-lo e configurar um SPN, o windows irá traduzir as credenciais do pool com as solicitações do usuário indo para o serviço final (SQL é apenas um desses serviços). Você deve registrar o ÚNICO servidor SQL que atende solicitações SQL no servidor web. Configurar tudo isso é demais para eu tentar descrever com precisão aqui. Levei um bom tempo para resolver isso sozinho.

Passei algumas horas tentando consertar o problema e finalmente consegui - o navegador do SQL Server estava "Parado". A solução é alterá-lo para o modo "Automático":

Se estiver desabilitado, vá para Painel de Controle-> Ferramentas Administrativas-> Serviços e procure o SQL Server Agent. Clique com o botão direito e selecione “Propriedades”. Na lista suspensa "Tipo de inicialização", altere de "Desativado" para "Automático".

citar daqui

Eu tive o mesmo problema anteriormente, remover Persist Security Info=Truedo connectionstring funcionou para mim.

Eu me deparei com esse problema quando um cliente renomeou um SQL Server. O SQL Reporting Service foi configurado para se conectar ao antigo nome do servidor, para o qual também foi criado um alias para redirecionar para o IP do novo nome do servidor.

Todos os aplicativos IIS antigos estavam funcionando, redirecionando para o novo nome do servidor por meio do alias. Em um palpite, verifiquei se eles estavam executando o SSRS. A tentativa de se conectar ao site SSRS gerou o erro:

"O serviço não está disponível. Entre em contato com o administrador do sistema para resolver o problema. Administradores do sistema: O servidor de relatório não pode se conectar ao banco de dados. Verifique se o banco de dados está em execução e acessível. Você também pode verificar o log de rastreamento do servidor de relatório para obter detalhes . "

Ele estava em execução no servidor, mas não conseguiu se conectar porque estava usando o alias do nome do servidor antigo. A reconfiguração do SSRS para usar o novo nome do servidor em vez do antigo / alias corrigiu o problema.

1. Alterar a identidade do pool de aplicativos para sistema local
2. Em SQL Mgmt> Security> Logins
   1. Encontre NT AUTHORITY \ SYSTEM clique duplo
   2. Mapeamentos de usuários> Verifique seu banco de dados e atribua uma função a ele abaixo.
   3. Lembre-se também de criar a base de dados do usuário ou logins de segurança com a senha correta.

Recebi este erro ao tentar testar uma solução usando o seguinte

string cn = "Data Source=[servername];Integrated Security=true;Initial Catalog=[dbname];";

A maneira como resolvi foi: tive que abrir o Visual Studio e executá-lo em outra conta, porque a conta que estava usando para abrir não era minha conta de administrador.

Portanto, se o seu problema for semelhante ao meu: fixe o VS na barra de tarefas, use Shift e clique com o botão direito para abrir o menu para que você possa abrir o VS como outro usuário.

Agradeço que haja algumas boas respostas aqui, mas como acabei de perder tempo tentando resolver isso, espero que isso possa ajudar alguém.

No meu caso tudo estava funcionando bem, então parou sem motivo aparente com o erro citado na pergunta.

O IIS estava funcionando como serviço de rede e o serviço de rede foi configurado no SQL Server anteriormente (veja outras respostas a esta postagem). Funções de servidor e mapeamentos de usuário pareciam corretos.

O problema era; por absolutamente nenhuma razão aparente; O serviço de rede mudou para 'Negar' direitos de login no banco de dados.

Consertar:

1. Abra SSMS> Segurança> Logins.
2. Clique com o botão direito em 'NT AUTHORITY \ NETWORK SERVICE' e clique em Propriedades.
3. Vá para a guia 'Status' e defina como Permission to Connect To Database Engine'Conceder'.