Pergunta

Eu sei que isso é quase uma duplicata de: O erro "Login falhou para o usuário 'NT Authority iusr'" em Asp.net e SQL Server 2008 e O login falhou para o usuário 'Nome de usuário' - System.data.sqlclient.sqlexception com LINQ na biblioteca externa do projeto / classe Mas algumas coisas não se somam em comparação com outras aplicações no meu servidor e não sei por que.

Caixas sendo usadas:

Web Box
Caixa SQL
Caixa de teste SQL

Minha aplicação:

Eu tenho um aplicativo Web ASP.NET, que faz referência a uma biblioteca de classes que usa o LINQ para SQL. String de conexão configurada corretamente na biblioteca da classe. Conforme O login falhou para o usuário 'Nome de usuário' - System.data.sqlclient.sqlexception com LINQ na biblioteca externa do projeto / classe Eu também adicionei esta string de conexão ao aplicativo da Web.

A string de conexão usa credenciais SQL como assim (tanto na Web aplicativo quanto 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" />

Essa conexão 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 "Login falhou para o usuário 'NT Authority iusr'" em Asp.net e SQL Server 2008 Ele diz que esse é realmente o serviço de rede local e o uso de qualquer outro nome de não domínio não funcionará.

Mas estou confuso porque verifiquei o SQL Box e o SQL Test Box Studio de gerenciamento SQL e ambos têm NT AUTHORITY/NETWORK SERVICE Em Segurança -> Logins, no nível do banco de dados, que não estão listados em segurança -> usuários, mas no nível do banco de dados Segurança -> Usuários eu tenho o usuário exibido na string de conexão.

No nível NTFS no servidor da Web, as permissões possuem serviço de rede tem controle total.

O motivo pelo qual estou confuso é porque tenho muitos outros aplicativos da Web no meu servidor da Web, que referenciam bancos de dados na caixa SQL e na caixa de teste SQL e todos funcionam. Mas não consigo encontrar a diferença entre eles e meu aplicativo atual, além de estar usando uma biblioteca de classes. Isso vai importa? Verificando as permissões NTFs, a configuração dos logins de segurança nos níveis de servidor e bancos de dados, string de conexão e método de conexão (credenciais do SQL Server) e pool de aplicativos do IIS e outras opções de pasta, são todas as mesmas.

Por que esses aplicativos funcionam sem adicionar o nome do maquiné $ às permissões de qualquer uma das minhas caixas SQL? Mas é isso que o link está me dizendo para resolver esse problema.

Foi útil?

Solução

O serviço de rede e o sistema local se autenticarão sempre como a conta Correpsonding localmente (serviço de rede e sistema incorporado), mas ambos se autenticarão como a conta da máquina remotamente.

Se você vir um fracasso como Login failed for user 'DOMAIN\MACHINENAME$' Isso significa que um processo em execução como serviço de rede ou como o local do local acessou um recurso remoto, se autenticou como conta da máquina e foi negado a autorização.

Exemplo típico seria um aplicativo ASP em execução em um conjunto de pool de aplicativos para usar a credencial de serviço de rede e conectar -se a um servidor SQL remoto: o pool de aplicativos se autenticará como o máquina Executando o pool de aplicativos e é essa conta da 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 fazer login 'Domain Machine $', você deverá conceder direitos de login ao 'domain máquina $' ao serviço de rede. Conceder acesso ao serviço de rede permitiria um local Processo em execução como serviço de rede para se conectar, não um remoto, pois o controle remoto se autenticará como, você adivinhou, o domínio máquina $.

Se você espera que o aplicativo ASP se conecte ao remoto SQL Server como um login SQL e você obtém exceções sobre o domínio máquina $, significa que você usa segurança integrada na string de conexão. Se isso for inesperado, significa que você estragou as seqüências de strings de conexão que você usa.

Outras dicas

Esse erro ocorre quando você configurou seu aplicativo com o IIS, e o IIS vai para o SQL Server e tenta fazer login com credenciais que não têm permissões adequadas. Esse erro também pode ocorrer quando a replicação ou o espelho é configurado. Eu estarei analisando uma solução que funciona sempre e é muito simples. Vá para o SQL Server >> Segurança >> Logins e clique com o botão direito do mouse no serviço NT Authority Network e selecione Propriedades

Na tela recém -aberta das propriedades de login, vá para a guia "Mapeamento do usuário". Em seguida, na guia "Mapeamento do usuário", selecione o banco de dados desejado - especialmente o banco de dados para o qual essa mensagem de erro é exibida. Na tela inferior, verifique a função db_owner. Clique OK.

No meu caso, eu tive Identity="ApplicationPoolIdentity" Para o meu pool de aplicativos do IIS.

Depois que eu adicionei IIS APPPOOL\ApplicationName Usuário para SQL Server, ele funciona.

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

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

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

Definir o pool de aplicativos correto resolveu o problema.

O truque que funcionou para mim foi remover Integrated Security da minha string de conexão e adicione um regular User ID=userName; Password=password Sua string de conexão no App.config da sua biblioteca pode não estar usando segurança integrada, mas a criada em Web.config é!

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

Basicamente para resolver isso, precisamos ter alguns

  • Aplicativo da web em execução em ApplicationPoolIdentity
  • Aplicativo da Web conectando aos bancos de dados através do ADO.net usando a autenticação do Windows na string de conexão

A sequência de conexão usada com a autenticação do Windows inclui Trusted_Connection=Yesatributo ou o atributo equivalente Integrated Security=SSPI dentro Web.config Arquivo

Minha conexão com o banco de dados está no modo de autenticação do Windows. Então eu resolvi isso simplesmente mudando o Pools de aplicativos Identidade de ApplicationPoolIdentity para o meu domínio de login de credenciais DomainName MyLoginid

Etapa:

  1. Clique em Pools de aplicativos
  2. Selecione o nome do seu aplicativo

  3. Vamos para Configuração avançada

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

Para mim, foi resolvido.

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

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

Configurações podem ser feitas no Internet Information Server (IIS 7+)> Pools de aplicativos> Configurações de Advanded> Modelo de Processo> Identidade

Para mim, problema com 'domínio machineName $' corrigido por configuração DefaultApplicationPool Identidade para NetworkService.

enter image description here

Estávamos recebendo mensagens de erro semelhantes ao processar um banco de dados de serviços de análise. Aconteceu que o nome de usuário, usado para executar a instância dos Serviços de Análise, não havia sido adicionado aos logins de segurança do SQL Server.

No SQL Server 2012, o SQL Server e os serviços de análise são configurados para executar como diferentes usuários por padrão. Se você foi com os padrões, sempre verifique se o usuário do AS tem acesso ao seu DataSource!

Verifique se você tem

User Instance=true

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

Eu também tive esse erro com um usuário autenticado pelo SQL Server

Eu tentei algumas das correções, mas elas não funcionaram.

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

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

Passei algumas horas tentando corrigir o problema e finalmente o comprei - o navegador do SQL Server foi "parado". A correção é alterá -lo para o modo "automático":

Se estiver desativado, vá para o painel de controle-> Ferramentas administrativas-> Serviços e procure o agente do SQL Server. Clique com o botão direito do mouse e selecione "Propriedades". Do suspensão "Tipo de inicialização", altere de "desativado" para "automático".

Citação daqui

Eu tive o mesmo problema anteriormente, removendo Persist Security Info=True A partir da conexão, funcionou para mim.

Eu encontrei esse problema quando um cliente renomeou um servidor SQL. O serviço de relatório SQL foi configurado para conectar -se ao nome antigo do servidor, que eles também haviam criado um alias para o redirecionado para o IP do novo nome do servidor.

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

"O serviço não está disponível. Continue o administrador do seu sistema para resolver o problema. Administradores do sistema: o servidor de relatório não pode se conectar ao seu 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 se conectava porque estava usando o alias para o nome do servidor antigo. Configurando o SSRS para usar o novo nome do servidor em vez do antigo/alias o corrigiu.

  1. Altere a identidade do pool de aplicativos para o sistema local
  2. No SQL MGMT> Security> Logins
    1. Encontre NT Autoridade Sistema Clique duas vezes
    2. Mapeamentos de usuário> Verifique seu banco de dados e dê uma função abaixo.
    3. Lembre -se também de criar o Base de Dados do Usuário o Logins de Segurança com uma senha correta.

Recebi este erro tentando 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 sob outra conta, porque a conta que eu estava usando para abrir não era minha conta de administrador.

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

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

No meu caso, tudo estava funcionando bem, depois parou sem motivo aparente com o erro declarado na pergunta.

O IIS estava em execução como serviço de rede e o serviço de rede havia sido configurado no SQL Server anteriormente (consulte outras respostas para esta postagem). As funções de servidor e os mapeamentos de usuários pareciam corretos.

A questão 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 do mouse em 'NT Authority Network Service' e clique em Propriedades.
  3. Vá para a guia 'Status' e defina Permission to Connect To Database Engine Conceder'.

Network Service Allowed

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top