(jest to pytanie o niejasny problem. Staram się przedstawić wszystkie istotne dane, w nadziei, że ktoś ma pomocne informacje; przepraszam za długi opis.)

Nasza aplikacja internetowa

Mamy aplikację internetową. NET 4 działającą w IIS 7.5 z dostępem do Active Directory i bazy danych SQL Server.

Ta aplikacja internetowa działa w ramach wirtualnej "tożsamości puli aplikacji", ustawiając tożsamość puli aplikacji na ApplicationPoolIdentity. Zwięzły opis tożsamości wirtualnych można znaleźć w odpowiedzi StackOverflow, a także w wpisie na blogu, do którego się odnosi: tożsamość puli aplikacji jest tylko dodatkową grupą, która jest dodawana do procesów roboczych aplikacji sieciowej, która działa jako "usługa sieciowa". Jednak Jedno źródło mgliście sugeruje, że " Usługa sieciowa i zastosowanie mają różnice, które IIS.net dokumenty witryny nie są publikowane."Więc wirtualny tożsamość może być czymś więcej niż tylko dodatkową grupą.

Zdecydowaliśmy się użyć ApplicationPoolIdentity, w przeciwieństwie do Usług Sieciowych, ponieważ stało się to domyślne w IIS 7.5 (patrz np. tutaj) i zgodnie z zaleceniem Microsoftu: "ta tożsamość pozwala administratorom określać uprawnienia, które odnoszą się tylko do tożsamości, pod którą uruchomiona jest pula aplikacji, zwiększając tym samym bezpieczeństwo serwera."(from element processModel for add for applicationPools [IIS 7 Settings Schema] ) "tożsamości puli aplikacji są nową, potężną funkcją izolacji", która " sprawia, że uruchomione aplikacje IIS są jeszcze bardziej bezpieczne i niezawodne. "(z IIS.net artykuł "tożsamość puli aplikacji")

Aplikacja wykorzystuje zintegrowane uwierzytelnianie Windows, ale z <identity impersonate="false"/>, tak, że nie tożsamość użytkownika końcowego, ale tożsamość wirtualnej puli aplikacji jest używana do uruchomienia naszego kodu.

Ta aplikacja zapytuje Active Directory za pomocą System.DirectoryServices klasy, czyli API ADSI. W większości przypadków odbywa się to bez podawania dodatkowej nazwy użytkownika/hasła lub innych danych uwierzytelniających.

Ta aplikacja łączy się również z bazą danych SQL Server za pomocą Integrated Security=true w łańcuchu połączenia. Jeśli baza danych jest lokalna, wtedy widzimy, że IIS APPPOOL\OurAppPoolName jest używana do łączenia się z bazą danych; jeśli baza danych jest zdalna, wtedy używane jest konto maszyny OURDOMAIN\ourwebserver$.

Nasze problemy

Regularnie mamy problemy gdy działająca instalacja zaczyna zawodzić w jeden z następujących sposobów.

• Gdy baza danych znajduje się w zdalnym systemie, połączenie z bazą danych zaczyna nie działać: "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Powód: weryfikacja dostępu do serwera opartego na tokenach nie powiodła się z błędem infrastruktury. Sprawdź poprzednie błędy."The previous error is" Error: 18456, Severity: 14, State: 11."Wydaje się więc, że teraz OURDOMAIN\ourwebserver$ nie jest już używany, ale zamiast tego Dostęp anonimowy jest próba. (Mamy niepotwierdzone anegdoty, że ten problem wystąpił, gdy UAC został wyłączony, i że zniknął po włączeniu UAC. Należy jednak pamiętać, że zmiana UAC wymaga ponownego uruchomienia...) Podobny problem występuje w IIS.net wątek "use ApplicationPoolIdentity to connect to SQL" , konkretnie w one reply.

• Operacje Active Directory poprzez ADSI (System.DirectoryServices) zaczynają się nie powieść z błędem 0x8000500C ("Nieznany błąd"), 0x80072020 ("Wystąpił błąd operacji.") lub 0x200B ("określony atrybut usługi katalogowej lub wartość nie istnieje").

• Logowanie do aplikacji z przeglądarki Internet Explorer kończy się niepowodzeniem z błędami HTTP 401. Ale jeśli w IIS umieścimy NTLM przed negocjacją, to działa ponownie. (Należy pamiętać, że dostęp do AD jest potrzebny dla Kerberos, ale nie dla NTLM.) Podobny problem występuje w IIS.net wątek " Windows Authentication failed with AppPool Tożsamość " .

Nasza hipoteza i obejście

Przynajmniej problemy z reklamą i logowaniem zawsze wydają się znikać podczas przełączania puli aplikacji z ApplicationPoolIdentity na NetworkService. (Znaleźliśmy jeden raport potwierdzający to.)

Page "Troubleshooting Authentication Problems on ASP Pages" ma kilka sugestii dotyczących tokenów podstawowych i drugorzędnych, a to, co uważam za zachęcające, to to, że łączy dwa pierwsze z naszych błędy: wymienia NT AUTHORITY\ANONYMOUS LOGON access, oraz błędy AD 0x8000500C i "określony atrybut usługi katalogowej lub wartość nie istnieje".

(ta sama strona wspomina również o problemach z pamięcią podręczną schematu ADSI, ale wszystko, co możemy znaleźć na ten temat, jest stare. Na razie uważamy to za niezwiązane.)

W oparciu o powyższe, nasza obecna działająca hipoteza czy tylko wtedy, gdy działa pod wirtualną tożsamością puli aplikacji, nasza aplikacja internetowa (IIS? proces pracowniczy?) nagle traci swoje główny token , tak że IIS ma tylko dodatkowy token, dzięki czemu cały dostęp do Active Directory i SQL Server odbywa się anonimowo, co prowadzi do wszystkich powyższych błędów.

Na razie zamierzamy przełączyć się z ApplicationPoolIdentity na NetworkService. Mam nadzieję, że to sprawi, że wszystkie powyższe problemy znikną. Ale nie jesteśmy pewni; i chcielibyśmy zmienić się z powrotem, jeśli to możliwe.

Nasze pytanie

Czy powyższa hipoteza jest poprawna, a jeśli tak, to czy jest to błąd w IIS / Windows/. NET? w jakich okolicznościach dochodzi do utraty tokena głównego?