SQLException: Logowanie nie powiodło się dla użytkownika „NT AUTHORITY \ NETWORK SERVICE

Question

Kiedy uruchomić aplikację internetową za pośrednictwem VS 2008, aplikacja jest w stanie zalogować się na serwerze SQL i sprawdzić poświadczenia (nazwa użytkownika i hasło) wprowadzonych przez użytkownika, ale kiedy przejść do tej aplikacji za pośrednictwem IIS 7 i spróbuj ogłaszanie nazwę użytkownika i hasło, aplikacja zgłasza wyjątek:

System.Data.SqlClient.SqlException: Logowanie nie powiodło się dla użytkownika „SERVICE NT \ NETWORK "

• W przypadku IIS 7 każdy proces jest uruchamiany pod kontem Network Service ... więc jakie prawa muszę przypisać do tego konta dla aplikacji, aby móc "skontaktować się" z serwerem Sql?

thanx

EDIT:

Witam,

Działa teraz, chociaż nie rozumiem, dlaczego konto komputera potrzebuje tych uprawnień. Rozumiem, że konto urządzenia wymaga pewnych uprawnień, aby móc "rozmawiać" z określonym programem (serwerem Sql), ale dlaczego potrzebuje uprawnień dostępu do bazy danych i jej tabel? Czy to nie do konta określonego w ciągu połączenia

<add name="MyConnection" connectionString="data source=localhost; integrated security=sspi; initial catalog=aspnetdb;" /> 

mieć odpowiednie prawa dostępu do bazy danych i jej tabel?

Answer 1

Będziesz musiał utworzyć konto w SQL Server dla konta usługi sieciowej. Następnie przyznasz mu dostęp do bazy danych, a konkretne uprawnienia, którym udzielane jest konto, zależą od charakteru zadań, które musi wykonać twoja baza danych.

Możesz to zrobić w SSMS poprzez sekcję "Bezpieczeństwo", kliknij prawym przyciskiem myszy "Logowania" i wybierz Dodaj. Będziesz dodawać konto Windows, możesz następnie wyszukać i potwierdzić nazwę "NETWORK SERVICE". Następnie przejdź do sekcji "Mapowanie użytkownika" i zezwól na przeglądanie bazy danych. Uprawnienia, jak już powiedziałem, zależą od Ciebie lub możesz przypisać im uprawnienia dbowner do pełnej kontroli.

Po wykonaniu tej czynności wszystko będzie dobrze. Ostrzegam przed przyznaniem aplikacji więcej uprawnień niż potrzeba!

Answer 2

Zalecam utworzenie konta usługi i przeprowadzenie procesu IIS 7 jako tego konta. Upewnij się, że konto ma prawidłowy dostęp do DB (jeśli tylko czyta, to DB-Reader) (jeśli czyta i aktualizuje to DB-Reader i DB-Writer).

Answer 3

Osobiście uruchomiłbym aplikację internetową pod niestandardowym kontem usługi. Jeśli naprawdę chcesz go uruchomić w ramach usługi sieciowej - see this MSDN document.

Answer 4

Podczas określania "integrated security = sspi" w ciągu połączenia, niż myślę, że spodziewasz się podszywania się. Ale do tego należy: 1. Włącz zintegrowane uwierzytelnianie w IIS 2.włączyć okien uwierzytelniania w ASP.NET: 3. Włącz imerposation w ASP.NET:

również pod uwagę, że to nie wystarczy, jeśli serwer WWW i maszyna SQL Server są różne maszyny. W takim przypadku konto użytkownika będzie wymagało zaufania do delegowania. Jest to specjalna opcja w AD.

Powiedziano Ci już, że lepiej jest mieć oddzielne konto dla połączeń SQLSRV. Mam nadzieję, że to pomoże.

Answer 5

Napotkano ten sam błąd w nowej konfiguracji IIS. Użyłem "integrated security = false, User Id = sa, Password = yourpassword" i wszystko działało dobrze.

Answer 6

Ten błąd występuje po skonfigurowaniu aplikacji z usługami IIS, a serwer IIS przechodzi do programu SQL Server i próbuje zalogować się za pomocą poświadczeń, które nie mają odpowiednich uprawnień. Ten błąd może również wystąpić podczas konfigurowania replikacji lub tworzenia kopii lustrzanej.

Będę omawiać rozwiązanie, które działa zawsze i jest bardzo proste.

idź do SQL Server >> Zabezpieczenia >> logowania i kliknij prawym przyciskiem myszy na NT \ Network Service i wybierz Właściwości

W nowo otwartym ekranie logowania Właściwości, przejdź do zakładki „User Mapping”. Następnie na karcie "Mapowanie użytkownika" wybierz żądaną bazę danych - szczególnie bazę danych, dla której wyświetlany jest ten komunikat o błędzie. Na dolnym ekranie sprawdź rolę db_owner. Kliknij OK.

Answer 7

Napotkano ten problem w projekcie SharePoint. Zintegrowane zabezpieczenia były włączone, a baza danych została już skonfigurowana, aby umożliwić dostęp użytkownikowi aplikacji.

Problem polegał na tym, że podszywanie się pod numer zostało zmienione na, kiedy trzeba było wyłączyć. This answer doprowadziły mnie we właściwym kierunku:

WindowsImpersonationContext noImpersonateContext = null; 

try 
{ 
    noImpersonateContext = WindowsIdentity.Impersonate(IntPtr.Zero); 
    using (SqlConnection conn = CreateConnection()) 
    { 
     // database calls... 
    } 
} 
finally 
{ 
    if (noImpersonateContext != null) noImpersonateContext.Undo(); 
}