Falha no logon para o usuário 'IIS APPPOOL \ ASP.NET v4.0'

Eu tenho um projeto da web (C # Asp.Net, EF 4, MS SQL 2008 e IIS 7) e preciso migrá-lo para o IIS 7 localmente (no momento funciona bem com o CASSINI).

Localmente no IIS, eu tenho o meu Default Web Sitecom minha implantação. Tanto a minha implantação quanto o Default Web SiteASP.NET v4.0 (veja a imagem nas configurações) estão no pool de destino do Framework 4 como meu projeto da web. Ao visitar o site, o navegador não mostra a página e permite que o navegador faça o download da página.

Eu tenho outros projetos em execução no IIS localmente e eles funcionam sem problemas (mas eles não usam o Entity Framework).

Usando o Event Logger, vejo os erros abaixo:

Exception information: 
    Exception type: EntityException 
    Exception message: The underlying provider failed on Open.
   at System.Data.EntityClient.EntityConnection.OpenStoreConnectionIf(Boolean openCondition, DbConnection storeConnectionToOpen, DbConnection originalConnection, String exceptionCode, String attemptedOperation, Boolean& closeStoreConnectionOnFailure)


    Login failed for user 'IIS APPPOOL\ASP.NET v4.0'.
       at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject)
       at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
       at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
       at System.Data.SqlClient.SqlConnection.Open()
       at System.Data.EntityClient.EntityConnection.OpenStoreConnectionIf(Boolean openCondition, DbConnection storeConnectionToOpen, DbConnection originalConnection, String exceptionCode, String attemptedOperation, Boolean& closeStoreConnectionOnFailure)

Pergunta relacionada

ATUALIZAÇÃO: Você pode ler nos recursos desta pergunta que as permissões devem ser concedidas no MS SQL 2008 manualmente, conforme explicado em sua resposta. Usando o IIS 7.5 e o MS SQL 2008 R2, a configuração manual de permissão não deve ser necessária.

Parece que está falhando ao tentar abrir uma conexão com o SQL Server.

Você precisa adicionar um logon ao SQL Server IIS APPPOOL\ASP.NET v4.0e conceder permissões ao banco de dados.

No SSMS, no servidor, expanda Segurança, clique com o botão direito do mouse em Logins e selecione "Novo Login ...".

Na caixa de diálogo Novo logon, insira o pool de aplicativos como o nome de logon e clique em "OK".

Você pode clicar com o botão direito do mouse no login do pool de aplicativos, selecionar Propriedades e selecionar "Mapeamento do Usuário". Verifique o banco de dados apropriado e as funções apropriadas. Acho que você pode simplesmente selecionar db_datareadere db_datawriter, mas acho que ainda precisaria conceder permissões para executar procedimentos armazenados se fizer isso através do EF. Você pode verificar os detalhes das funções aqui .

Você pode alterar o ApplicationPoolIdentity do IIS7 -> Pools de aplicativos -> Configurações avançadas.

Em ApplicationPoolIdentity, você encontrará o sistema local. Isso fará com que seu aplicativo seja executado emNT AUTHORITY\SYSTEM , que é um login existente para o banco de dados por padrão.

Editar: Antes de aplicar esta sugestão, observe e entenda as implicações de segurança.

garantir que você tenha ...

Trusted_Connection=false;

na sua conexão String

Resolvi esse problema usando o sql da seguinte imagem.

Clique com o botão direito do mouse em db-> propriedades -> permissão -> Exibir permissão do servidor -> e selecione IIS APPPOOL\ASP.NET v4.0e conceda a permissão.

Execute este script sql

IF NOT EXISTS (SELECT name FROM sys.server_principals WHERE name = 'IIS APPPOOL\DefaultAppPool')
BEGIN
    CREATE LOGIN [IIS APPPOOL\DefaultAppPool] 
      FROM WINDOWS WITH DEFAULT_DATABASE=[master], 
      DEFAULT_LANGUAGE=[us_english]
END
GO
CREATE USER [WebDatabaseUser] 
  FOR LOGIN [IIS APPPOOL\DefaultAppPool]
GO
EXEC sp_addrolemember 'db_owner', 'WebDatabaseUser'
GO

Se na cadeia de conexão que você especificou:

User ID=xxx;Password=yyy

mas na cadeia de conexão existe:

Trusted_Connection=true;

O SQL Server usará a autenticação do Windows, portanto, seus valores de conexão serão ignorados e substituídos (o IIS usará a conta do Windows especificada no perfil de usuário de identidade). mais informações aqui

O mesmo se aplica se na cadeia de conexão houver:

 Integrated Security = true;

ou

 Integrated Security = SSPI;

porque a autenticação do Windows será usada para conectar-se ao servidor de banco de dados. mais informações aqui

vá para iis -> pools de aplicativos -> encontre seu pool de aplicativos usado no aplicativo

selecione o pool de aplicativos usado para o aplicativo, clique com o botão direito do mouse e selecione configurações avançadas

Selecionar identidade do pool de aplicativos

selecione incorporado como sistema local e clique em ok

Eu odeio o ApplicationPoolIdentity. Eu sempre defino uma conta de usuário do Windows como a conta no AppPools.

Como diz o derrift, parece um problema de segurança do banco de dados. Portanto, crie uma conta de usuário do NT, atribua-a ao ASP.NET v4.0 AppPool e conceda permissão na pasta do site e nas tabelas relevantes no SQL.

Não use segurança integrada. UsarUser Id=yourUser; pwd=yourPwd;

Isso resolve o problema.

Eu tive esse problema e foi realmente causado por algo diferente - eu tinha o usuário 'IIS APPPOOL \ ASP.NET v4.0' no meu banco de dados, mas ele ainda não estava funcionando.

Eu havia atualizado recentemente minha Instalação do SQL Server e, no processo, o Usuário se desconectou do Logon - portanto, havia um 'IIS APPPOOL \ ASP.NET v4.0' em Banco de Dados -> Segurança -> Usuários, mas nenhum usuário não estava em Segurança -> Logins.

Adicionado o logon 'IIS APPPOOL \ ASP.NET v4.0' a Segurança -> Logins, o SQL Server o mapeou automaticamente para o usuário no banco de dados (isso costumava ser feito manualmente) e o problema foi corrigido.

A primeira coisa que você precisa limpar se você estiver usando a autenticação do Windows e não mencionar nenhuma senha de nome de usuário na cadeia de conexão:

O que acontece quando você executa seu código através do host local: quando você executa o cliente de teste wcf a partir do host local, ele pode se comunicar com o banco de dados, pois o aplicativo do modo de depuração local está chamando o banco de dados pelo serviço da sua conta. Portanto, ele tem acesso ao banco de dados porque o devenv.exe está sendo executado na sua conta de usuário.

Mas quando você implanta seu serviço web no IIS. Agora entenda que este serviço é executado no IIS e não na sua conta. Portanto, você precisa atribuir direitos de acesso ao serviço IIS para acessar o servidor sql para autenticação do Windows. Aqui, seu serviço da web não poderá se comunicar com o servidor SQL devido a problemas de direitos de acesso e falha de login para o usuário_______ (aqui o usuário chegará)

Portanto, se você estiver usando a autenticação do Windows para conectar seu banco de dados, basta alterar as configurações do pool de aplicativos do IIS. Você precisa alterar a identidade do pool de aplicativos IIS para o sistema local.

Abaixo estão as etapas para autenticação do Windows WCF:

1) Abra o IIS (windows + R (run), digite inetmgr e clique em ok)

2) clique duas vezes no nome do seu PC em Conexões

3) Clique em Pools de aplicativos

4) Selecione seu pool de aplicativos (DefaultAppPool)

5) Em ações à direita, clique em Configurações avançadas:

6) Vá para a seção Modelo de Processo e

7) clique em Identidade.

8) Agora selecione LocalSystem.

Agora abra seu estúdio de gerenciamento de servidor sql: abra run-> digite ssms -> pressione ok No ssms, faça o login usando sua conta de autenticação do windows. Abra a guia Segurança, expanda a guia Logins e poderá visualizar sua conta.

Agora abra as propriedades da sua conta, vá para userMapping, selecione o banco de dados que você deseja conectar e verifique os serviços de associação de função que deseja usar para o banco de dados selecionado. Clique OK.

(Para serviços de rede, ou seja, usuários da intranet, é necessário definir as configurações acima também para o usuário NT AUTHORITY \ SYSTEM)

adicione Trusted_Connection = True; propriedade na sua cadeia de conexão. Salve e implante o serviço da web. Reinicie o pool de aplicativos.

você poderá conectar o banco de dados agora.

Eu recebi essa mensagem e uso a autenticação do Windows no servidor da web.

Queria que o usuário da web autenticado atualmente fosse autenticado no banco de dados, em vez de usar o Usuário do IIS APPPOOL \ ASP.NET v4 especificado no Pool de Aplicativos.

Encontrei inserindo o seguinte no web.config corrigido isso para mim:

<system.web>
  <identity impersonate="true" />
</system.web>

https://msdn.microsoft.com/en-us/library/bsz5788z.aspx

Vejo outras respostas sobre a criação do nome de usuário do AppPool no SQL DB ou apenas para usar o SQL Auth. Ambos estariam corretos se você não quisesse capturar ou proteger usuários individuais do Windows dentro do SQL.

Tom

1_in SqlServer Security => Login => NT AUTHORITY \ SYSTEM => RightClick => Property => UserMaping => Selecione YourDatabse => Público && Proprietário Selecione => OK 2_In IIs Pools de aplicativos DefaultAppPool => Configuração avançada => Identidade => LocalSystem => Ok

Definir a identidade apenas faz com que isso funcione em minhas páginas.

A Cassini executa seu site como sua própria identidade de usuário quando você inicia o aplicativo Visual Studio. O IIS executa seu site como uma identidade do pool de aplicativos. A menos que a identidade do pool de aplicativos tenha acesso ao banco de dados, você receberá erros.

O IIS introduziu a identidade do pool de aplicativos para melhorar a segurança. Você pode executar sites com a identidade padrão do pool de aplicativos ou criar um novo pool de aplicativos com seu próprio nome ou criar um novo pool de aplicativos com seu próprio nome que seja executado em uma conta de usuário (geralmente conta de domínio).

Em situações de rede (que não estão no Azure), você pode executar um novo pool de aplicativos em uma conta de usuário de domínio do Active Directory; Eu prefiro isso sobre a conta da máquina. Isso fornece segurança granular e acesso granular aos recursos da rede, incluindo bancos de dados. Cada site é executado em um pool de aplicativos diferente (e cada um deles é executado em sua própria conta de usuário de domínio).

Continue usando o Windows Integrated Security em todas as seqüências de conexão. No SQL Server, adicione os usuários do domínio como logons e conceda permissões a bancos de dados, tabelas, SP etc., por site. Por exemplo, o DB1 usado pelo Site1 tem um logon para o Usuário1 porque o Site1 é executado em um pool de aplicativos como Usuário1.

Um desafio com a implantação do banco de dados interno do Visual Studio (por exemplo, LocalDB) e do servidor Web interno para um ambiente de produção deriva do fato de que o SID do usuário do desenvolvedor e suas ACLs não devem ser usados ​​em um ambiente de produção seguro. A Microsoft fornece ferramentas para implantação. Mas tenha pena do desenvolvedor pobre que está acostumado a tudo pronto para funcionar no novo VS IDE fácil com localDB e localWebServer, porque essas ferramentas serão difíceis de usar para esse desenvolvedor, especialmente para um desenvolvedor sem suporte ao SysAdmin e DBAdmin ou seu conhecimento especializado. No entanto, a implantação no Azure é mais fácil do que a situação da rede corporativa mencionada acima.

Se você adicionou sua cadeia de conexão no seu web.config, verifique se "Segurança Integrada = false;" portanto, usaria o ID e a senha especificados no web.config.

<connectionStrings>
    <add providerName="System.Data.SqlClient" name="MyDbContext" connectionString="Data Source=localhost,1433;Initial Catalog=MyDatabase;user id=MyUserName;Password=MyPassword;Trusted_Connection=true;Integrated Security=false;" />
</connectionStrings>

Conforme indicado, não use a autenticação do Windows, use a autenticação do SQL Server

Além disso, se você criou a conexão usando a caixa de diálogo "Conexão do servidor", verifique as conexões no web.config. É provável que você tenha criado / modificado a conexão e ela tenha sido armazenada como conexão confiável no web.config. Basta usar esta autenticação

<add name="MyDBConnectionString" connectionString="Data Source=localhost;Initial Catalog=Finantial;User ID=xxx;Password=xxx" providerName="System.Data.SqlClient"/>

o que deve corrigir o erro.

Outra maneira de conceder permissão ao banco de dados para o usuário IIS APPPOOL\ASP.NET v4.0é a seguinte.

1. Adicione novo usuário com nome de usuário e nome de logon, como IIS APPPOOL\ASP.NET v4.0no esquema padrão.
2. Vá para esquema e associação do proprietário, verifique db_datareader, db_datawriter

Pensei em postar isso como uma resposta, pois é relevante para a pergunta e, em alguns casos, posso respondê-la.

Essa mesma mensagem aparece também se o banco de dados não existir!

Verifique se a string de conexão não possui erros de ortografia, está apontando para a instância correta do servidor etc.

Eu tenho o mesmo problema que eu resolvi, alterando Integrated Security=Truepara false agora está funcionando

algo semelhante aconteceu comigo, o que funcionou para mim foi alterar a propriedade Segurança Integrada = Verdadeira para Segurança Integrada = false no web.config do site

Você já fez o que é @Teddyrecomendado e você AINDA obtém o mesmo erro?

Verifique se você está alterando as configurações do pool de aplicativos que corresponde ao diretório virtual e não ao servidor pai. Cada diretório virtual possui seu próprio AppPool e não herda.

No DefaultAppPool, defina NetworkService na propriedade Identity e, no Sql Server, adicione o User Network Service e conceda as permissões apropriadas ao seu banco de dados. outro computador na rede. quando você define LocalSystem na identidade no IIS, isso funciona bem e não é necessário criar nenhum outro usuário no Sql Server, mas acho que isso não funcionará em um ambiente de rede.

Encontrei o mesmo problema ao testar a API da Web do ASP.NET

Web.Host desenvolvido no Visual Studio 2013 Express Banco de dados criado no SQL Server 2012 Express Teste executado usando o IIS Express interno (funcionando) Modificado para usar o IIS Local (da página de propriedades - opção da web) Executei o teste com o Fiddler Erro recebido - não foi possível abrir o banco de dados para o provedor .... citando 'APPPOOL \ DefaultAppPool'

Solução que funcionou.

No IIS

Clique no pool de aplicativos 'DefaultAppPool' Set Identify = 'ApplicationPoolIdentity' Set .NET framework = v4.0 (mesmo que meu aplicativo seja 4.5)

No SQL Server Management Studio

Clique com o botão direito do mouse na pasta Segurança (no mecanismo do SQL Server, aplicável a todas as tabelas). Clique com o botão direito do mouse em Usuário e adicione 'IIS APPPOOL \ DefaultAppPool'. Em protegíveis na coluna 'Conceder', marque as opções que você deseja fornecer. Com relação ao exposto acima, se você é um DBA, provavelmente conhece e deseja controlar quais são essas opções. Se você é como eu, um desenvolvedor só queria testar seu serviço de API da WEB, que também acessa o SQL Server através do EF 6 no estilo MVC, basta marcar tudo. :) Sim, eu sei, mas funcionou.

Caso você adicione um novo logon, verifique se, em propriedades do servidor (clique com o botão direito do mouse -> propriedades) / segurança, o modo de autenticação está definido como sqlserver e windows, não apenas janelas.

Adicione "Todos" em segurança. Se você adicionou o servidor e os usuários que efetuam login no banco de dados, isso está faltando. Espero que isto ajude.

Para o registro, se você encontrar esse erro após alternar de LocalDBpara SQLEXPRESS, verifique se o banco de dados já existe emSQLEXPRESS . Você pode verificar isso no Management Studio.

Eu tive o mesmo problema ao usar Entity Frameworkdepois de mudar para SQLEXPRESS from LocalDB. Eu tive que executar o Update-Databasecomando. Consegui conectar com sucesso depois disso.

Fiz exatamente como o @JeffOgata disse, mas recebi o erro:

Windows NT user or group 'IIS APPPOOL\ASP.NET v4.0' not found. Check the name again. (Microsoft SQL Server, Error: 15401)

Olhei para minha mensagem de erro novamente e ela dizia Login failed for user 'IIS APPPOOL\DefaultAppPool'.

Depois de adicionar um usuário chamado IIS APPPOOL\DefaultAppPooltudo funcionou.

Eu usei o SQL Server Profiler (disponível no SSMS => menu Ferramentas) e vi lá (quando o IIS tentou se conectar ao banco de dados) que meu usuário do IIS era por algum motivo NT AUTHORITY \ IUSR, independentemente de todas as etapas recomendadas nas respostas desta pergunta . Então eu adicionei esse usuário ao SQL Server e funcionou ...

No formulário da web Asp.net,

este erro foi corrigido ao instalar o asp.net de:

O Gerenciador de servidores> Gerenciar> Adicionar função e recurso> Funções de servidor> Servidor Web (IIS)> Servidor Web> Desenvolvimento de aplicativos> ASP.NET 3.5 / 4.6 está instalado.

meu problema foi corrigido.