Jak poprawnie skonfigurować tożsamość puli aplikacji IIS 7?

Question

Po wdrożeniu moją stronę do IIS7.5 znalazłem jedno dziwne zachowanie: gdy tożsamość puli aplikacji jest pozostawiony być ApplicationPoolIdentity domyślnie (jak zaleca IIS Application Pool Identities) Ninject wydaje się być ignorowane, ponieważ pojawia się następujący błąd, gdy tworzenia pierwszego kontrolera:

System.InvalidOperationException: wystąpił błąd podczas próby utworzyć kontroler 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 do IIS AppPool\<MySiteAppPool> do folderu, zawierający miejsce (w tym wszystkich podfolderów i plików), ale to niczego nie zmienia.

Jednak po ustawieniu tożsamości puli aplikacji na dowolnym koncie domeny (nawet prostym, bez przywilejów administracyjnych, a także bez dostępu do folderu z witryną) działa normalnie.

Ninject jest instalowany zgodnie z tutorialem Setting up an MVC3 application poprzez pakiet NuGet.

Nie jestem pewien, czy jest to istotne, witryna powinna działać w intranecie domeny z uwierzytelnianiem Windows.

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

Z czym to może być powiązane? Czy jest możliwe połączenie tych wszystkich elementów razem?

---

Oto wątek SO z podobnym problemem: ASP.NET MVC 4 + Ninject MVC 3 = No parameterless constructor defined for this object. Nie ma jednak żadnej odpowiedniej odpowiedzi.

---

Zgodnie z sugestią usuniętą, próbowałem użyć tożsamości NetworkSerive. I działało poprawnie. Jednak myślę, że to nie jest dużo lepsze, niż nieuprawnione konto domeny.

---

EDIT

Nagle znalazł inną zależność: tożsamość puli aplikacji służy do uwierzytelniania systemu Windows na serwerze SQL, choć spodziewałem poświadczenia użytkownika po stronie klienta, aby być tam wykorzystywane.

podstawie wypowiedzi

Zgadzam się, że zdalny serwer SQL można uzyskać z uwierzytelnionych poświadczeń za pomocą personifikacji.

---

Jednak nadal nie jest jasne, jaki jest problem z ApplicationPoolIdentity i Ninject.

Artykuł wspomniany na samym początku tego pytania spowodował, że przypuszczam, że może to być spowodowane faktem, że konto wirtualne nie ma profilu użytkownika. Ten aspekt pozostaje niejasny, ponieważ nadal można włączyć usługi IIS, aby załadować profil użytkownika z atrybutem LoadUserProfile. Nie mogę uzyskać, co IIS zamierza załadować, jeśli nie ma profilu dla konta wirtualnego?

Mówi się tam:

IIS nie załadować profilu użytkownika systemu Windows, ale niektóre aplikacje może skorzystać z niej w każdym razie do przechowywania danych tymczasowych. SQL Express to przykład aplikacji, która to robi. Profil użytkownika musi jednak zostać utworzony w celu przechowywania tymczasowych danych w katalogu profilu lub w gałęzi rejestru. Profil użytkownika konta NETWORKSERVICE został utworzony przez system i zawsze był dostępny . Jednak dzięki zmianie na unikatowe tożsamości puli aplikacji żaden profil użytkownika nie jest tworzony przez system. Tylko standardowe pule aplikacji (DefaultAppPool i Classic .NET AppPool) mają profile użytkowników na dysku. Żaden profil użytkownika nie zostanie utworzony, jeśli administrator utworzy nową pulę aplikacji.

Jednakże, jeśli chcesz, możesz skonfigurować Pule aplikacji IIS, aby załadować profil użytkownika, ustawiając atrybut "LoadUserProfile" na "true".

---

znalazłem wątku na serverfault.com:

How can I assign active directory permission to the default app pool identity

Nie jest również powiedziane, że tożsamość puli aplikacji nie jest w stanie pracować jako usługa sieciowa, w szczególności zapytań AD.

Answer 1

Z tego szczegółu brzmi to jak problem z uprawnieniami powodujący wyrzucenie COMException, co uniemożliwia firmie Ninject utworzenie wystąpienia MainController. Wyjątek jest związany z System.DirectoryServices, które są klasami używanymi do wysyłania zapytań do Active Directory.

Gdy usługi IIS działają na zwykłych kontach puli aplikacji, konta te nie mają uprawnień do wysyłania zapytań do usługi Active Directory i można wygenerować COMException. Myślę, że faktyczny komunikat w wyjątku (nie można znaleźć konstruktora bez parametrów) jest trochę czerwony śledzia i jest Ninject próbuje wrócić do innego konstruktora, ponieważ normalny nie działa.

To by wyjaśniało, dlaczego po zmianie puli aplikacji IIS na konto domeny nagle zadziała, ponieważ to konto ma uprawnienia do wysyłania zapytań do domeny.

Nie można jednoznacznie stwierdzić, czy użytkownik sam korzysta z usługi System.DirectoryServices, czy też używa jej program Ninject/IIS/ASP. Jeśli jednak korzystasz z nich samodzielnie, upewnij się, że żaden z konstruktorów w twoich zajęciach AD nie może wyrzucać wyjątków (przechwytywać ich i logować je lub coś w tym stylu), które zapobiegną awariom aplikacji podczas uruchamiania. Prawdopodobnie dowiesz się, co powiedziałem powyżej o uprawnieniach.

Jeśli potrzebujesz usług IIS do działania jako normalne konto puli aplikacji (co jest dobrym pomysłem), ale wciąż wysyłaj zapytanie do AD jako użytkownik domeny, możesz określić poświadczenia na DirectoryEntry i użyć wyszukiwania DirectorySearcher, aby wykonać wyszukiwanie AD. Jeśli korzystasz z .Net 4 lub nowszego, polecam zamiast tego używać nowych klas System.DirectoryServices.AccountManagement (które również umożliwiają określenie poświadczeń).

Ta metoda nie wymaga personifikacji dla zapytań AD, a pula aplikacji może nadal działać jako normalne konta puli aplikacji.

Answer 2

Konta iispool \ appPoolName nazywane są kontami wirtualnymi & zostały dodane do systemu Windows 2008. Chodzi o to, że nie są to naprawdę konta w prawdziwym znaczeniu. Pozwalają one na zwiększenie bezpieczeństwa między procesami wykorzystującymi konto podstawowe.

Wiele usług na twoim komputerze używa networkService, wbudowanego konta z dostępem do sieci. Z tego powodu, jeśli atakujący miałby skorzystać z jednej z tych usług, każdy inny proces działający pod tym samym kontem byłby dostępny. Konta wirtualne, takie jak te używane przez IIS, zapobiegają temu, wyświetlając się jako różne konta, pozostając jednocześnie tym samym kontem - twoja aplikacja asp.net jest nadal technicznie uruchomiona jako usługa sieciowa & przyznając temu kontu dostęp do rzeczy, które wciąż działają. Oznacza to również, że jeśli potrzebujesz dostępu do zasobów sieciowych, konta iispool zrobiłyby to, ponieważ usługa sieciowa ma & używać konta domeny maszyn.

Jeśli uzyskujesz dostęp do zdalnego serwera sql, jest to konto, które należy dodać, aby umożliwić dostęp z serwera WWW. Nie radzę używać personifikacji, chyba że naprawdę musisz zobaczyć, kto jest użytkownikiem serwera SQL. Bezpieczeństwo Twojej aplikacji jest prostsze, jeśli ją opuścisz.

co do tego, dlaczego twoje zastrzyki nie działają, może to być jedna z twoich zależności. jeśli kontroler A jest wstrzykiwany w ClassB, który z kolei jest wstrzykiwany w ClassC &, klasa nie wstrzykuje ClassD, wtedy cały łańcuch zawodzi. Tak się stało & zajęło mi trochę czasu, aby uświadomić sobie, że było to coś, co zostało usunięte z tego, na co patrzyłem.