Po wdrożeniu mojej strony internetowej do IIS7.5 znalazłem dziwne zachowanie: gdy pozostała tożsamość puli aplikacjiApplicationPoolIdentity domyślnie (zgodnie z zaleceniami wTożsamości pul aplikacji IIS),Ninject wydaje się być ignorowany, ponieważ pojawia się następujący błąd podczas tworzenia pierwszego kontrolera:

System.InvalidOperationException: Wystąpił błąd podczas próby utworzenia kontrolera typu „..MainController”. Upewnij się, że kontroler ma publiczny konstruktor bez parametrów. ---> System.DirectoryServices.DirectoryServicesCOMException: Wystąpił błąd operacji.

Próbowałem udzielićFullAccess doIIS AppPool\<MySiteAppPool> do folderu zawierającego witrynę (w tym wszystkie podfoldery i pliki), ale nic to nie zmieniło.

Jednak gdy ustawię tożsamość puli aplikacji na dowolnym koncie domeny (nawet prostym, bez uprawnień administracyjnych, a także bez dostępu do folderu z witryną), działa normalnie.

Ninject jest zainstalowany zgodnie zKonfigurowanie aplikacji MVC3 samouczek w pakiecie NuGet.

Nie jestem pewien, czy strona ma działać w intranecie domeny z uwierzytelnianiem systemu Windows.

Tak więc jedynym problemem wydaje się być tożsamość puli aplikacji. O ile chętnie korzystam z zalecanego sposobu, chciałbym miećApplicationPoolIdentity, nie konto domeny.

Z czym można to połączyć? Czy jest możliwe połączenie wszystkich tych elementów?

Oto wątek SO z podobnym problemem:ASP.NET MVC 4 + Ninject MVC 3 = Dla tego obiektu nie zdefiniowano żadnego konstruktora bez parametrów. Nie ma jednak żadnej odpowiedniej odpowiedzi.

Jak sugerował usunięty komentarz, próbowałem użyćNetworkSerive jako tożsamość. I działało poprawnie. Sądzę jednak, że nie jest to dużo lepsze niż konto domeny nieuprzywilejowane.

EDYTOWAĆ

Nagle znaleziono inną zależność: tożsamość puli aplikacji jest używana do uwierzytelniania systemu Windows na serwerze sql, chociaż oczekiwałem, że będą tam używane poświadczenia użytkownika po stronie klienta.

Na podstawie komentarzy

Zgadzam się, że dostęp do zdalnego serwera sql można uzyskać za pomocą uwierzytelnionych poświadczeń za pośrednictwem personifikacji.

Jednak nadal nie jest jasne, na czym polega problem z ApplicationPoolIdentity i Ninject.

Artykuł wspomniany na samym szczycie tego pytania skłonił mnie do przypuszczenia, że ​​może to być spowodowane faktem, że to wirtualne kontonie ma profilu użytkownika. Ten aspekt pozostaje dla mnie niejasny, ponieważ nadal można włączyć IIS, aby załadować profil użytkownika za pomocąLoadUserProfile atrybut. Nie mogę uzyskać, co załaduje IIS, jeśli nie ma profilu dla konta wirtualnego?

Mówi się tam:

Usługi IIS nie ładują profilu użytkownika systemu Windows, ale niektóre aplikacje i tak mogą je wykorzystać do przechowywania danych tymczasowych. SQL Express jest przykładem aplikacji, która to robi. Jednak profil użytkownika musi zostać utworzony w celu przechowywania danych tymczasowych w katalogu profilu lub w gałęzi rejestru. Profil użytkownika dla konta NETWORKSERVICE został utworzony przez system i był zawsze dostępny. Jednak z przełączeniem na unikalne tożsamości pul aplikacji, system nie tworzy profilu użytkownika. Tylko standardowe pule aplikacji (DefaultAppPool i Classic .NET AppPool) mają profile użytkowników na dysku. Nie tworzy się profilu użytkownika, jeśli administrator utworzy nową pulę aplikacji.

Jeśli jednak chcesz, możesz skonfigurować pule aplikacji IIS, aby ładowały profil użytkownika, ustawiając atrybut „LoadUserProfile” na „true”.

Znalazłem następujący wątek na serverfault.com:

Jak przypisać uprawnienie do aktywnego katalogu do domyślnej tożsamości puli aplikacji

Stwierdzono również, że tożsamość puli aplikacji nie może działać jako usługa sieciowa, w szczególności odpytać AD.