Logowanie nie powiodło się dla użytkownika „IIS APPPOOL \ ASP.NET v4.0”

Mam projekt internetowy (C # Asp.Net, EF 4, MS SQL 2008 i IIS 7) i muszę go migrować lokalnie do IIS 7 (w tej chwili działa dobrze z CASSINI).

Lokalnie w IIS mam Default Web Siteswoje wdrożenie. Zarówno moje wdrożenie i Default Web Sitesą w puli ASP.NET v4.0 (poszukaj obrazu ustawień) puli docelowej Framework 4 jako mojego projektu internetowego. Podczas odwiedzania witryny przeglądarka nie wyświetla strony i zezwala przeglądarce na pobranie strony.

Mam inne projekty działające lokalnie na IIS i działają bezproblemowo (ale nie używają Entity Framework).

Za pomocą rejestratora zdarzeń widzę błędy jak poniżej:

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)

Powiązane pytanie

AKTUALIZACJA: Możesz przeczytać w zasobach tego pytania, że ​​uprawnienia muszą być przyznane na MS SQL 2008 ręcznie, jak wyjaśniono w jego odpowiedzi. Przy użyciu IIS 7.5 i MS SQL 2008 R2 ręczne ustawienie uprawnień nie powinno być konieczne.

Wygląda na to, że próba otwarcia połączenia z programem SQL Server kończy się niepowodzeniem.

Musisz dodać login do SQL Server IIS APPPOOL\ASP.NET v4.0i przyznać uprawnienia do bazy danych.

W SSMS pod serwerem rozwiń Zabezpieczenia, następnie kliknij Loginy prawym przyciskiem myszy i wybierz „Nowe logowanie ...”.

W oknie dialogowym Nowe logowanie wprowadź pulę aplikacji jako nazwę logowania i kliknij „OK”.

Następnie możesz kliknąć prawym przyciskiem myszy login dla puli aplikacji, wybrać Właściwości i wybrać „Mapowanie użytkowników”. Sprawdź odpowiednią bazę danych i odpowiednie role. Myślę, że możesz po prostu wybrać db_datareaderi db_datawriter, ale myślę, że nadal będziesz musiał przyznać uprawnienia do wykonywania procedur przechowywanych, jeśli zrobisz to za pośrednictwem EF. Można sprawdzić szczegóły ról tutaj .

Możesz zmienić ApplicationPoolIdentity z IIS7 -> Pule aplikacji -> Ustawienia zaawansowane.

W ApplicationPoolIdentity znajdziesz system lokalny. Spowoduje to uruchomienie aplikacji NT AUTHORITY\SYSTEM, która jest domyślnie istniejącym loginem do bazy danych.

Edycja: Przed zastosowaniem tej sugestii powinieneś zanotować i zrozumieć konsekwencje dla bezpieczeństwa.

upewnij się, że masz ...

Trusted_Connection=false;

w twoim połączeniu String

Rozwiązałem ten problem, używając narzędzia SQL jako następującego obrazu.

Kliknij prawym przyciskiem myszy db-> właściwości -> pozwolenie -> Wyświetl uprawnienie serwera ->, a następnie wybierz IIS APPPOOL\ASP.NET v4.0i udziel uprawnienia.

Uruchom ten skrypt 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

Jeśli w ciągu połączenia podałeś:

User ID=xxx;Password=yyy

ale w ciągu połączenia znajduje się:

Trusted_Connection=true;

SQL Server będzie korzystał z uwierzytelniania systemu Windows, więc wartości połączenia zostaną zignorowane i zastąpione (IIS użyje konta Windows określonego w profilu użytkownika Tożsamość). więcej informacji tutaj

To samo dotyczy sytuacji, gdy w ciągu połączenia znajduje się:

 Integrated Security = true;

lub

 Integrated Security = SSPI;

ponieważ do połączenia z serwerem bazy danych zostanie użyte uwierzytelnianie systemu Windows. więcej informacji tutaj

przejdź do iis -> pule aplikacji -> znajdź pulę aplikacji używaną w aplikacji

wybierz pulę aplikacji używaną dla aplikacji kliknij prawym przyciskiem myszy wybierz ustawienia zaawansowane

Wybierz tożsamość puli aplikacji

wybierz wbudowany jako system lokalny i kliknij OK

Nienawidzę ApplicationPoolIdentity. Zawsze ustawiam konto użytkownika Windows jako konto w AppPools.

Jak mówi adrift, brzmi to jak problem bezpieczeństwa bazy danych. Stwórz więc konto użytkownika NT, przypisz je do ASP.NET v4.0 AppPool, a następnie przyznaj mu uprawnienia w folderze witryny i odpowiednich tabelach w SQL.

Nie używaj zintegrowanych zabezpieczeń. Posługiwać sięUser Id=yourUser; pwd=yourPwd;

To rozwiązuje problem.

Miałem ten problem i był on spowodowany przez coś innego - miałem w swojej bazie danych użytkownika „IIS APPPOOL \ ASP.NET v4.0”, ale nadal nie działał.

Niedawno zaktualizowałem moją instalację programu SQL Server i podczas tego procesu użytkownik został odłączony od logowania - więc w bazie danych istniała aplikacja IIS APPPOOL \ ASP.NET v4.0 - Baza danych -> Bezpieczeństwo -> Użytkownicy, ALE żaden użytkownik nie jest zabezpieczony -> Loginy.

Dodano Login „IIS APPPOOL \ ASP.NET v4.0” do Zabezpieczeń -> Loginy, SQL Server automatycznie zamapował go na użytkownika w bazie danych (wcześniej trzeba było to robić ręcznie) i problem został naprawiony.

Najpierw musisz wyczyścić, jeśli korzystasz z uwierzytelniania systemu Windows i nie podajesz hasła nazwy użytkownika w ciągu połączenia, a następnie:

Co się stanie, gdy uruchomisz kod przez localhost: kiedy uruchomisz klienta testowego wcf z localhost, będzie on mógł komunikować się z bazą danych, ponieważ lokalny tryb debugowania wywołuje bazę danych przez usługę twojego konta. Ma więc dostęp do bazy danych, ponieważ devenv.exe działa na Twoim koncie użytkownika.

Ale po wdrożeniu usługi sieci Web w usługach IIS. Teraz zrozum, że ta usługa działa w ramach IIS, a nie na Twoim koncie. Musisz więc przypisać prawa dostępu do usługi IIS, aby uzyskać dostęp do serwera SQL w celu uwierzytelnienia systemu Windows. W tym przypadku twoja usługa internetowa nie będzie mogła komunikować się z serwerem SQL z powodu problemu z prawami dostępu i logowania nie powiodło się dla użytkownika_______ (tutaj przyjedzie użytkownik)

Jeśli więc używasz uwierzytelniania systemu Windows do połączenia z bazą danych, musisz tylko zmienić ustawienia puli aplikacji IIS. Musisz zmienić tożsamość puli aplikacji IIS na system lokalny.

Poniżej znajdują się kroki do uwierzytelniania systemu Windows WCF:

1) Otwórz IIS (Windows + R (uruchom), następnie wpisz inetmgr, a następnie kliknij OK)

2) dwukrotnie kliknij nazwę swojego komputera w obszarze Połączenia

3) Kliknij Pule aplikacji

4) Wybierz pulę aplikacji (DefaultAppPool)

5) Następnie pod działaniami po prawej kliknij Ustawienia zaawansowane:

6) Przejdź do sekcji Model procesu i

7) kliknij Tożsamość.

8) Teraz wybierz LocalSystem.

Teraz otwórz studio zarządzania serwerem SQL: otwórz run-> następnie wpisz ssms -> następnie naciśnij ok W ssms zaloguj się przy użyciu konta uwierzytelniania systemu Windows. Otwórz kartę bezpieczeństwa rozwiń kartę logowania, wtedy będziesz mógł zobaczyć swoje konto.

Teraz otwórz właściwości swojego konta idź do UserMapping, następnie wybierz bazę danych, z którą chcesz się połączyć, a następnie sprawdź rolę usług członkostwa, których chcesz użyć dla wybranej bazy danych. Kliknij OK.

(W przypadku usług sieciowych, tj. Użytkowników intranetu, należy również skonfigurować powyższe ustawienia dla użytkownika NT AUTHORITY \ SYSTEM)

dodaj Trusted_Connection = True; właściwość w ciągu połączenia. Zapisz i wdróż usługę internetową. Uruchom ponownie pulę aplikacji.

będziesz mógł teraz połączyć się z bazą danych.

Miałem tę wiadomość i korzystam z uwierzytelniania systemu Windows na serwerze WWW.

Chciałem, aby aktualnie uwierzytelniony użytkownik sieciowy był uwierzytelniany względem bazy danych, zamiast używać użytkownika IIS APPPOOL \ ASP.NET v4 określonego w puli aplikacji.

Znalazłem, wpisując następujące polecenie w pliku web.config, naprawiłem to:

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

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

Widzę inne odpowiedzi dotyczące tworzenia nazwy użytkownika AppPool w SQL DB lub po prostu używania SQL Auth. Oba byłyby poprawne, jeśli nie chcesz przechwytywać ani zabezpieczyć poszczególnych użytkowników systemu Windows w SQL.

Tomek

1_in SqlServer Security => Login => NT AUTHORITY \ SYSTEM => RightClick => Property => UserMaping => Select YourDatabse => Public && Owner Select => OK 2_In IIs Pule aplikacji DefaultAppPool => Advance Setting => Identity => LocalSystem => Ok

Ustawienie tożsamości powoduje, że działa to tylko na moich stronach.

Cassini uruchamia witrynę jako własną tożsamość użytkownika podczas uruchamiania aplikacji Visual Studio. IIS obsługuje Twoją witrynę jako tożsamość puli aplikacji. O ile tożsamość puli aplikacji nie uzyska dostępu do bazy danych, pojawią się błędy.

Usługi IIS wprowadziły tożsamość puli aplikacji w celu zwiększenia bezpieczeństwa. Możesz uruchamiać witryny internetowe pod domyślną tożsamością puli aplikacji lub utworzyć nową pulę aplikacji z własną nazwą lub utworzyć nową pulę aplikacji z własną nazwą, która będzie działać pod kontem użytkownika (zazwyczaj konto domeny).

W sytuacjach sieciowych (które nie są na platformie Azure) możesz uruchomić nową pulę aplikacji na koncie użytkownika domeny Active Directory; Wolę to niż konto komputera. Takie postępowanie zapewnia szczegółowe bezpieczeństwo i szczegółowy dostęp do zasobów sieciowych, w tym baz danych. Każda witryna działa na innej puli aplikacji (każda z nich działa na własnym koncie użytkownika domeny).

Nadal używaj zintegrowanych zabezpieczeń systemu Windows we wszystkich ciągach połączeń. W SQL Server dodaj użytkowników domeny jako loginy i udzielaj uprawnień do baz danych, tabel, SP itp. Dla poszczególnych witryn. Np. DB1 używany przez Website1 ma login dla User1, ponieważ Website1 działa w puli aplikacji jako User1.

Jedno wyzwanie związane z wdrażaniem z wbudowanej bazy danych Visual Studio (np. LocalDB) i wbudowanego serwera WWW do środowiska produkcyjnego wynika z faktu, że identyfikatora SID użytkownika i jego list ACL dewelopera nie należy używać w bezpiecznym środowisku produkcyjnym. Microsoft zapewnia narzędzia do wdrażania. Ale szkoda biednego programisty, który jest przyzwyczajony do wszystkiego, co działa po wyjęciu z pudełka w nowym łatwym VS IDE z localDB i localWebServer, ponieważ te narzędzia będą trudne w użyciu dla tego programisty, szczególnie dla takiego programisty, który nie obsługuje SysAdmin i DBAdmin lub ich specjalistyczna wiedza. Niemniej jednak wdrożenie na platformie Azure jest łatwiejsze niż sytuacja sieci korporacyjnej wspomniana powyżej.

Jeśli dodano ciąg połączenia w pliku web.config, upewnij się, że „Integrated Security = false;” więc użyłby identyfikatora i hasła określonych w pliku 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>

Jak wskazano, nie używaj uwierzytelniania systemu Windows, używaj uwierzytelniania programu SQL Server

Również jeśli utworzono połączenie za pomocą okna dialogowego „Połączenie z serwerem”, sprawdź połączenia w pliku web.config. Prawdopodobnie utworzono / zmodyfikowano połączenie i zostało ono zapisane jako zaufane połączenie w pliku web.config. Po prostu użyj tego uwierzytelnienia

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

co powinno naprawić błąd.

Innym sposobem przyznania użytkownikowi uprawnień do bazy danych IIS APPPOOL\ASP.NET v4.0jest:

1. Dodaj nowego użytkownika o nazwie użytkownika i nazwie logowania, tak jak IIS APPPOOL\ASP.NET v4.0w schemacie domyślnym.
2. Przejdź do schematu właściciela i członkostwa, sprawdź db_datareader, db_datawriter

Pomyślałem, że opublikuję to jako odpowiedź, ponieważ jest to związane z pytaniem i może odpowiedzieć w niektórych przypadkach.

Ten sam komunikat pojawia się również, jeśli baza danych nie istnieje!

Upewnij się, że ciąg połączenia nie zawiera błędów ortograficznych, wskazuje odpowiednią instancję serwera itp.

Mam ten sam problem, który rozwiązałem, zmieniając Integrated Security=Truena false teraz działa

przydarzyło mi się coś podobnego, co działało dla mnie: zmiana właściwości Integrated Security = True to Integrated Security = false w pliku web.config witryny

Czy zrobiłeś to, co @Teddyzalecałeś i WCIĄŻ masz ten sam błąd?

Upewnij się, że zmieniasz ustawienia puli aplikacji, które odpowiadają katalogowi wirtualnemu, a nie serwerowi nadrzędnemu. Każdy katalog wirtualny ma swój własny AppPool i nie dziedziczy.

W DefaultAppPool ustaw NetworkService we właściwości Tożsamość, aw Sql Server dodaj usługę sieciową użytkownika i nadaj jej odpowiednie uprawnienia do bazy danych, to działa dla mnie bardzo dobrze, przetestowałem lokalnie, ale myślę, że jest to najlepsza konfiguracja do połączenia z dowolnego inny komputer w sieci. kiedy ustawisz LocalSystem w Tożsamości w IIS, to działa dobrze i nie jest konieczne tworzenie żadnego innego użytkownika w Sql Server, ale myślę, że to nie będzie działać w środowisku sieciowym.

Natknąłem się na ten sam problem podczas testowania interfejsu API sieci Web ASP.NET

Opracowany Web.Host w Visual Studio 2013 Express Baza danych utworzona w SQL Server 2012 Express Wykonany test przy użyciu wbudowanego IIS Express (działający) Zmodyfikowany do używania IIS Lokalny (ze strony właściwości - opcja sieci Web) Ran test z Fiddler Błąd odebrany - nie można otworzyć bazy danych dla dostawcy .... powołując się na „APPPOOL \ DefaultAppPool”

Rozwiązanie, które zadziałało.

W IIS

Kliknij pulę aplikacji „DefaultAppPool” Set Identify = „ApplicationPoolIdentity” Ustaw .NET Framework = v4.0 (nawet jeśli moja aplikacja miała 4.5)

W SQL Server Management Studio

Kliknij prawym przyciskiem myszy folder Security (w silniku SQL Server, więc dotyczy to wszystkich tabel) Kliknij prawym przyciskiem myszy Użytkownik i dodaj „IIS APPPOOL \ DefaultAppPool” W sekcjach bezpieczeństwa w kolumnie „Grant” zaznacz opcje, które chcesz podać. Jeśli chodzi o powyższe, jeśli jesteś DBA, prawdopodobnie wiesz i chcesz kontrolować, jakie są te opcje. Jeśli jesteś podobny do mnie, programista chciał po prostu przetestować twoją usługę API WEB, która zdarza się również uzyskiwać dostęp do SQL Server poprzez EF 6 w stylu MVC, a następnie po prostu zaznacz wszystko. :) Tak, wiem, ale zadziałało.

W przypadku dodania nowego loginu upewnij się, że w obszarze właściwości serwera (prawy przycisk myszy -> właściwości) / bezpieczeństwo tryb uwierzytelniania jest ustawiony zarówno na serwer sqlserver, jak i system Windows, nie tylko Windows.

Dodaj „Wszyscy” pod ochroną. Jeśli dodałeś serwer i użytkowników logujących się do bazy danych, to czegoś brakuje. Mam nadzieję że to pomoże.

Dla przypomnienia, w przypadku wystąpienia tego błędu po przełączeniu z LocalDBdo SQLEXPRESSupewnij się, że baza danych już w esistsSQLEXPRESS . Możesz to sprawdzić w Management Studio.

Miałem ten sam problem podczas korzystania Entity Frameworkpo przełączeniu na SQLEXPRESS from LocalDB. Musiałem uruchomić Update-Databasepolecenie. Po tym udało mi się pomyślnie połączyć.

Zrobiłem dokładnie tak, jak powiedział @JeffOgata, ale dostałem błąd:

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

Ponownie spojrzałem na komunikat o błędzie i powiedział Login failed for user 'IIS APPPOOL\DefaultAppPool'.

Po dodaniu użytkownika o nazwie IIS APPPOOL\DefaultAppPoolwszystko działało.

Użyłem SQL Server Profiler (dostępny w SSMS => menu Narzędzia) i zobaczyłem tam (kiedy IIS próbowało połączyć się z bazą danych), że mój użytkownik IIS był z jakiegoś powodu NT AUTHORITY \ IUSR, bez względu na wszystkie kroki zalecane w odpowiedziach na to pytanie . Dodałem więc tego użytkownika do SQL Server i działało ...

W formularzu internetowym Asp.net

ten błąd naprawiono podczas instalacji asp.net z:

Menedżer serwera> Zarządzaj> Dodaj rolę i funkcję> Role serwera> Serwer sieci Web (IIS)> Serwer sieci Web> Tworzenie aplikacji> ASP.NET 3.5 / 4.6 jest zainstalowany.

mój problem naprawiony.