Opis tożsamości w usługach IIS

Ten artykuł zawiera podstawowe informacje o tożsamościach w usługach Internet Information Services (IIS).

Oryginalna wersja produktu: Internetowe usługi informacyjne
Oryginalny numer KB: 4466942

Tożsamości puli aplikacji

Aby zrozumieć tożsamości puli aplikacji, musisz zrozumieć, czym jest tożsamość. Mówiąc prosto, tożsamość jest kontem systemu Windows. Każdy proces uruchamiany w systemie Windows jest uruchamiany w ramach tożsamości. Aplikacje są uruchamiane przez proces roboczy przy użyciu tożsamości systemu Windows. Używana tożsamość systemu Windows jest zależna od tożsamości puli aplikacji, która może być dowolnym z następujących kont:

• System lokalny: Zaufane konto, które ma wysokie uprawnienia, a także ma dostęp do zasobów sieciowych.
• Usługa sieciowa: Ograniczone lub ograniczone konto usługi używane do uruchamiania standardowych, najmniej uprzywilejowanych usług. To konto ma mniej uprawnień niż konto systemu lokalnego. To konto ma dostęp do zasobów sieciowych.
• Usługa lokalna: Ograniczone konto usługowe, które jest podobne do usługi sieci i jest przeznaczone do uruchamiania standardowych usług o najmniejszych uprawnieniach. To konto nie ma dostępu do zasobów sieciowych.
• ApplicationPoolIdentity: Po utworzeniu nowej puli aplikacji usługi IIS tworzą konto wirtualne, które ma nazwę nowej puli aplikacji i uruchamia proces roboczy puli aplikacji w ramach tego konta. Jest to również konto z najniższymi uprawnieniami.
• Konto niestandardowe: Oprócz tych wbudowanych kont można również użyć konta niestandardowego, określając nazwę użytkownika i hasło.

Różnice między tożsamościami puli aplikacji

• Scenariusz 1. Dostęp do dziennika zdarzeń

  W tym scenariuszu istnieje jedna aplikacja internetowa, która tworzy niestandardowy dziennik zdarzeń (MyWebAppZone) i źródło dziennika zdarzeń (MyWebAppZone.com) w czasie wykonywania. Aplikacje uruchamiane przy użyciu dowolnej tożsamości mogą zapisywać w dzienniku zdarzeń przy użyciu istniejących źródeł zdarzeń. Jeśli jednak są one uruchomione w ramach tożsamości innej niż system lokalny, nie mogą tworzyć nowych źródeł zdarzeń z powodu niewystarczających uprawnień rejestru.

  

  Jeśli na przykład uruchomisz aplikację w obszarze Usługa sieciowa, otrzymasz następujący wyjątek zabezpieczeń:

  

  Podczas jednoczesnego uruchamiania śledzenia ProcMon często można stwierdzić, że usługa NT AUTHORITY\NETWORK nie ma wymaganych uprawnień dostępu do odczytu i zapisu do następującego podklucza rejestru:

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\

  Jest to lokalizacja w rejestrze, w której są przechowywane wszystkie ustawienia dziennika zdarzeń.

  

• Scenariusz 2. Dostęp do rejestru

  Oprócz systemu lokalnego żadne inne tożsamości puli aplikacji nie mają dostępu do zapisu w rejestrze. W tym scenariuszu utworzono prostą aplikację internetową, która może zmienić i wyświetlić nazwę serwera czasu internetowego, z którym jest automatycznie synchronizowany system Windows. Jeśli uruchomisz tę aplikację w obszarze Usługa lokalna, otrzymasz wyjątek. Jeśli sprawdzisz ślad ProcMon, okaże się, że tożsamość puli aplikacji "NT AUTHORITY\LOCAL SERVICE" nie ma dostępu do odczytu i zapisu w następującym podkluczu rejestru:

  HKEY_LOCAL_MACHINE** **\SOFTWARE\Microsoft\Windows\CurrentVersion\DateTime\Servers

  

  Jeśli sprawdzisz dziennik zdarzeń MyWebAppZone (ze scenariusza 1), zostanie zarejestrowane następujące zdarzenie błędu. Zawiera Requested registry access is not allowed komunikat o błędzie.

  Exception Type: SecurityException  
  Message: Requested registry access is not allowed.  
  Stack Trace  
  at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable)  
  at Identities.ChangeTimeServer.Page_Load(Object sender, EventArgs e)  
  at System.Web.UI.Control.LoadRecursive()  
  at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)  
  at System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)  
  at System.Web.UI.Page.ProcessRequest()  
  at System.Web.UI.Page.ProcessRequest(HttpContext context)  
  at ASP.changetimeserver_aspx.ProcessRequest(HttpContext context) in c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\fd06117a\f8c94323\App_Web_ysqbhk00.2.cs:line 0  
  at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()  
  at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
  

• Scenariusz 3: Konto niestandardowe w uwierzytelnianiu Kerberos i środowisku z równoważeniem obciążenia

  Znasz już scenariusze 1 i 2 niektóre różnice między wbudowanymi kontami. Teraz omówimy, czym jest konto niestandardowe i jak ma on zalety w przypadku kont wbudowanych podczas pracy z uwierzytelnianiem Kerberos w środowisku ze zrównoważonym obciążeniem.

  Korzystając z tego podejścia, uruchamiasz aplikację w puli aplikacji skonfigurowanej do uruchamiania przy użyciu określonej tożsamości systemu Windows. Rozważmy poniższy diagram, na którym aplikacja jest hostowana w środowisku o zrównoważonym obciążeniu obejmującym dwa serwery i używa uwierzytelniania Kerberos do identyfikowania klienta.

  

  Aby uwierzytelnianie Kerberos działało, należy skonfigurować nazwę SPN dla obu serwerów przy użyciu konta komputera. Jeśli pula aplikacji jest uruchomiona na wbudowanym koncie, przedstawia poświadczenia komputera w sieci. Jeśli na przykład nazwa komputera to Server1, jest ona wyświetlana jako "Server1$". To konto komputera jest tworzone automatycznie po dołączeniu komputera do domeny. W związku z tym, jeśli istnieją N serwerów, należy ustawić N liczby nazw SPN odpowiadających odpowiedniemu kontu komputera.

  Rejestrowanie głównej nazwy usługi na koncie komputera:

  setspn -a HTTP/HOSTNAME MachineAccount$
  

  Przykład:

  setspn -a HTTP/MyWebAppZone.com Server1$
  

  Aby przezwyciężyć tę wadę, można uruchomić aplikację w ramach niestandardowej tożsamości systemu Windows (domeny), a następnie ustawić nazwę SPN tylko na to określone konto domeny na kontrolerze domeny.

  Rejestrowanie głównej nazwy usługi na koncie domeny:

  setspn -a HTTP/HOSTNAME domain\account
  

  Przykład:

  setspn -a HTTP/MyWebAppZone.com contoso.com\account_alias
  

Domyślne uprawnienia i prawa użytkownika w witrynie wwwroot

Usługi IIS 7.0 i nowsze również ułatwiają konfigurowanie tożsamości puli aplikacji i wprowadzanie wszystkich niezbędnych zmian. Gdy usługi IIS uruchamiają proces roboczy, musi utworzyć token, który będzie używany przez proces. Po utworzeniu tego tokenu usługi IIS automatycznie dodają IIS_IUSRS członkostwo do tokenu procesów roboczych w czasie wykonywania. Konta uruchamiane jako tożsamości puli aplikacji nie muszą już być jawną częścią IIS_IUSRS grupy. Jeśli tworzysz witrynę internetową, a następnie wskażesz lokalizację fizyczną , C:\inetpub\wwwrootnastępujących użytkowników i grupy zostaną automatycznie dodane do list kontroli dostępu witryny.

Użytkownicy/grupy	Dozwolone uprawnienia
WŁAŚCICIEL TWÓRCY	Uprawnienia specjalne
SYSTEM	Pełna kontrola
Administratorzy	Pełna kontrola
Użytkownicy	Odczytywanie i wykonywanie, zawartość folderu listy, odczyt
IIS_USRS	Odczytywanie i wykonywanie
TrustedInstaller	Pełna kontrola

Jeśli chcesz wyłączyć tę funkcję i ręcznie dodać konta do IIS_IUSRS grupy, ustaw wartość manualGroupMembership na true w pliku ApplicationHost.config . W poniższym przykładzie pokazano, jak można to zrobić w domyślnej puli aplikacji:

<applicationPools> 
    <add name="DefaultAppPool"> 
        <processModel manualGroupMembership="true" />
    </add>
</applicationPools>

Opis izolacji konfiguracji

Procesy robocze usług IIS nie mają dostępu do odczytu do pliku ApplicationHost.config . Dlatego możesz się zastanawiać, jak można odczytać dowolny zestaw konfiguracji w tym pliku.

Odpowiedzią jest użycie funkcji izolacji konfiguracji w usługach IIS 7.0 i nowszych wersjach. Zamiast umożliwiać procesom roboczym usług IIS odczytywanie ApplicationHost.config bezpośrednio podczas odczytywania hierarchii plików konfiguracji, usługa aktywacji procesów systemu Windows (WAS) generuje odfiltrowane kopie tego pliku. Każdy proces roboczy IIS używa tych kopii jako zamiennika ApplicationHost.config, gdy konfiguracja jest odczytywana wewnątrz procesu roboczego IIS. Te pliki są domyślnie generowane w %SystemDrive%\inetpub\Temp\appPools katalogu i mają nazwę {AppPoolName}.config. Te pliki są skonfigurowane tak, aby zezwalały na dostęp tylko do procesów roboczych usług IIS w odpowiedniej puli aplikacji przy użyciu identyfikatora IIS APPPOOL\AppPoolName zabezpieczeń puli aplikacji (SID).

Uwaga 16.

Aby dowiedzieć się więcej na temat identyfikatorów SID, zobacz Identyfikatory zabezpieczeń.

Dzieje się tak, aby uniemożliwić procesom roboczym usług IIS z puli aplikacji A odczytywanie informacji o konfiguracji w pliku ApplicationHost.config przeznaczonym dla puli aplikacji B.

ApplicationHost.config może zawierać poufne dane osobowe, takie jak nazwa użytkownika i hasło dla niestandardowych tożsamości puli aplikacji lub nazwa użytkownika i hasło dla katalogów wirtualnych. W związku z tym zezwolenie wszystkim pulam aplikacji na dostęp do ApplicationHost.config spowoduje przerwanie izolacji puli aplikacji. Jeśli każda pula aplikacji otrzymała bezpośredni dostęp do pliku ApplicationHost.config , te pule mogą łatwo włamać poufne informacje z innych pul aplikacji, uruchamiając następujące polecenie:

appcmd list APPPOOL "DefaultAppPool" /text:*

IUSR — uwierzytelnianie anonimowe

Uwierzytelnianie anonimowe umożliwia użytkownikom dostęp do publicznych obszarów witryny internetowej bez monitowania o podanie nazwy użytkownika lub hasła. W usługach IIS w wersji 7.0 lub nowszej wbudowane konto IUSRjest używane do zapewniania dostępu anonimowego. To wbudowane konto nie wymaga hasła. Będzie to domyślna tożsamość używana podczas włączania uwierzytelniania anonimowego. W pliku ApplicationHost.config można zobaczyć następującą definicję:

<authentication>
     <anonymousAuthentication enabled="true" userName="IUSR" />
 </authentication>

Spowoduje to, że usługi IIS będą używać nowego wbudowanego konta dla wszystkich żądań uwierzytelniania anonimowego. Największe zalety w tym celu są następujące:

• Nie musisz już martwić się o wygasanie haseł dla tego konta.
• Za pomocą narzędzia xcopy /o można bezproblemowo kopiować pliki wraz z ich własnością i listą ACL do różnych komputerów.

Możesz również podać uwierzytelnianie anonimowe w witrynie internetowej przy użyciu określonego konta systemu Windows lub tożsamości puli aplikacji zamiast IUSR konta.

IUSR a Connect jako

Połącz jako to opcja w IIS, która umożliwia określenie, które poświadczenia chcesz użyć do uzyskania dostępu do witryny internetowej. Możesz użyć uwierzytelnionych poświadczeń użytkownika lub określonych poświadczeń użytkownika. Aby zrozumieć różnicę, rozważ następujący scenariusz:

Masz domyślną witrynę internetową skonfigurowaną do korzystania z uwierzytelniania anonimowego. Jednak zawartość witryny internetowej jest na innym serwerze i używasz sekcji Połącz jako , aby uzyskać dostęp do tego zasobu za pośrednictwem Test użytkownika domeny. Po zalogowaniu się użytkownik jest uwierzytelniany przy użyciu konta IUSR. Jednak dostęp do zawartości witryny internetowej jest uzyskiwany za pośrednictwem poświadczeń użytkownika wymienionych w sekcji Połącz jako .

Mówiąc bardziej prosto, uwierzytelnianie anonimowe to mechanizm używany przez witrynę internetową do identyfikowania użytkownika. Jednak w przypadku korzystania z tej funkcji użytkownik nie musi podawać żadnych poświadczeń. Może jednak wystąpić podobny scenariusz, w którym zawartość znajduje się w udziale sieciowym. W takich przypadkach nie można używać kont wbudowanych do uzyskiwania dostępu do udziału sieciowego. Zamiast tego należy użyć określonego konta (domeny), aby to zrobić.

personifikacja w programie ASP.NET

Dosłownie personifikacja oznacza akt udawania innej osoby. W kategoriach technicznych jest to funkcja zabezpieczeń ASP.NET, która zapewnia możliwość kontrolowania tożsamości, w ramach której jest uruchamiany kod aplikacji. Personifikacja występuje, gdy ASP.NET uruchamia kod w kontekście uwierzytelnionego i autoryzowanego klienta. Usługi IIS zapewniają anonimowy dostęp do zasobów przy użyciu IUSR konta. Po przekazaniu żądania do ASP.NET kod aplikacji jest uruchamiany przy użyciu tożsamości puli aplikacji.

Personifikację można włączyć zarówno za pośrednictwem usług IIS, jak i kodu ASP.NET, jeśli aplikacja używa uwierzytelniania anonimowego, a jeśli jeden z następujących warunków jest spełniony:

• Jeśli IMPERSONATION jest wyłączona, tożsamość puli aplikacji jest używana do uruchamiania kodu aplikacji.
• Jeśli IMPERSONATION to ustawienie jest włączone, NT AUTHORITY\IUSR służy do uruchamiania kodu aplikacji.

Po impersonation włączeniu za pośrednictwem usług IIS dodaje następujący tag w pliku Web.config aplikacji w celu personifikacji uwierzytelnionego konta usług IIS lub użytkownika: <tożsamość personifikat="true" />

Aby personifikować określonego użytkownika dla wszystkich żądań na wszystkich stronach aplikacji ASP.NET, możesz określić nazwę użytkownika i atrybuty hasła w <identity> tagu pliku Web.config dla tej aplikacji.

<identity impersonate="true" userName="accountname" password="password" />

Aby zaimplementować personifikację za pomocą kodu ASP.NET, zobacz Implementowanie personifikacji w aplikacji ASP.NET

Otwórz proces roboczy usług IIS testowej witryny internetowej, która personifikuje użytkownika lokalnego Test , i sprawdź, czy możesz znaleźć konto personifikacji, w ramach którego jest uruchamiany kod aplikacji.

Tożsamość puli aplikacji jest ustawiona na ApplicationPoolIdentity, a uwierzytelnianie anonimowe jest realizowane przy użyciu konta IUSR. Możesz łatwo śledzić personifikację tożsamości przy użyciu narzędzia ProcMon. Jeśli na przykład zbadasz jedno ze zdarzeń CreateFile, które odpowiada badanemu procesowi w3wp.exe, możesz znaleźć konto personifikujące, jak pokazano na poniższym zrzucie ekranu.