Inzicht in identiteiten in IIS

Dit artikel bevat achtergrondinformatie over identiteiten in IIS (Internet Information Services).

Oorspronkelijke productversie: Internet Information Services
Oorspronkelijk KB-nummer: 4466942

Identiteiten van groep van toepassingen

Als u de identiteiten van de groep van toepassingen wilt begrijpen, moet u begrijpen wat een identiteit is. In eenvoudige termen is een identiteit een Windows-account. Elk proces dat in Windows wordt uitgevoerd, wordt uitgevoerd onder een identiteit. De toepassingen worden uitgevoerd door het werkproces met behulp van een Windows-identiteit. De Windows-identiteit die wordt gebruikt, is afhankelijk van de identiteit van de groep van toepassingen. Dit kan een van de volgende accounts zijn:

• Lokaal systeem: vertrouwd account met hoge bevoegdheden en heeft ook toegang tot netwerkresources.
• Netwerkservice: beperkt of beperkt serviceaccount dat wordt gebruikt voor het uitvoeren van standaardservices met minimale bevoegdheden. Dit account heeft minder bevoegdheden dan een lokaal systeemaccount. Dit account heeft toegang tot netwerkbronnen.
• Lokale service: beperkt of beperkt serviceaccount dat vergelijkbaar is met netwerkservice en is bedoeld om standaardservices met minimale bevoegdheden uit te voeren. Dit account heeft geen toegang tot netwerkbronnen.
• ApplicationPoolIdentity: Wanneer een nieuwe groep van toepassingen wordt gemaakt, maakt IIS een virtueel account met de naam van de nieuwe groep van toepassingen en waarmee het werkproces van de groep van toepassingen onder dit account wordt uitgevoerd. Dit is ook een account met minimale bevoegdheden.
• Aangepast account: naast deze ingebouwde accounts kunt u ook een aangepast account gebruiken door de gebruikersnaam en het wachtwoord op te geven.

Verschillen tussen identiteiten van groep van toepassingen

• Scenario 1: Toegang tot gebeurtenislogboeken

  In dit scenario hebt u één webtoepassing waarmee tijdens runtime een aangepast gebeurtenislogboek (MyWebAppZone) en een gebeurtenislogboekbron (MyWebAppZone.com) wordt gemaakt. Toepassingen die worden uitgevoerd met behulp van een van de identiteiten, kunnen naar het gebeurtenislogboek schrijven met behulp van bestaande gebeurtenisbronnen. Als ze echter worden uitgevoerd onder een andere identiteit dan lokaal systeem, kunnen ze geen nieuwe gebeurtenisbronnen maken vanwege onvoldoende registermachtigingen.

  

  Als u bijvoorbeeld de toepassing uitvoert onder Network Service, ontvangt u de volgende beveiligingsonderzondering:

  

  Wanneer u de ProcMon-trace tegelijk uitvoert, merkt u vaak dat NT AUTHORITY\NETWORK SERVICE niet beschikt over de vereiste bevoegdheden voor lezen en schrijven voor de volgende registersubsleutel:

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\

  Dit is de locatie in het register waar alle instellingen van een gebeurtenislogboek worden opgeslagen.

  

• Scenario 2: Registertoegang

  Behalve lokaal systeem hebben geen andere identiteiten van een toepassingsgroep schrijftoegang tot het register. In dit scenario hebt u een eenvoudige webtoepassing ontwikkeld waarmee u de naam van de internettijdserver kunt wijzigen en weergeven waarmee Windows automatisch wordt gesynchroniseerd. Als u deze toepassing uitvoert onder Lokale service, krijgt u een uitzondering. Als u de ProcMon-trace controleert, ziet u dat de groep-id van de toepassingsgroep NT AUTHORITY\LOCAL SERVICE geen lees- en schrijftoegang heeft in de volgende registersubsleutel:

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

  

  Als u het gebeurtenislogboek MyWebAppZone (uit scenario 1) controleert, vindt u de volgende foutgebeurtenis die is geregistreerd. Het bevat een Requested registry access is not allowed foutbericht.

  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)
  

• Scenario 3: Aangepast account in Kerberos-verificatie en omgeving met gelijke taakverdeling

  U hebt in scenario's 1 en 2 al enkele van de verschillen tussen de ingebouwde accounts gezien. Laten we nu bespreken wat een aangepast account is en hoe het voordelen heeft ten opzichte van ingebouwde accounts wanneer u met Kerberos-verificatie in een omgeving met gelijke taakverdeling werkt.

  Met deze methode voert u uw toepassing uit in een groep toepassingen die is geconfigureerd voor uitvoering met behulp van een specifieke Windows-identiteit. Bekijk het volgende diagram, waarin een toepassing wordt gehost in een omgeving met gelijke taakverdeling die twee servers bevat en Kerberos-verificatie gebruikt om de client te identificeren.

  

  Kerberos-verificatie werkt alleen als u SPN voor beide servers instelt met behulp van hun computeraccount. Als de groep van toepassingen wordt uitgevoerd onder een ingebouwd account, worden de computerreferenties in het netwerk weergegeven. Als de computernaam bijvoorbeeld Server1 is, wordt deze weergegeven als 'Server1$'. Dit computeraccount wordt automatisch gemaakt wanneer een computer lid wordt van een domein. Als er N-servers zijn, moet u daarom een N aantal SPN's instellen dat overeenkomt met het respectieve computeraccount.

  Een SPN registreren bij een computeraccount:

  setspn -a HTTP/HOSTNAME MachineAccount$
  

  Voorbeeld:

  setspn -a HTTP/MyWebAppZone.com Server1$
  

  Om dit nadeel te verhelpen, kunt u de toepassing uitvoeren onder een aangepaste Windows-identiteit (domein) en vervolgens de SPN instellen op alleen dat specifieke domeinaccount in de domeincontroller.

  Een SPN registreren bij een domeinaccount:

  setspn -a HTTP/HOSTNAME domain\account
  

  Voorbeeld:

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

Standaardmachtigingen en gebruikersrechten in wwwroot

IIS 7.0 en nieuwere versies maken het ook eenvoudiger om een identiteit van een groep van toepassingen te configureren en alle benodigde wijzigingen aan te brengen. Wanneer IIS een werkproces start, moet er een token worden gemaakt dat door het proces wordt gebruikt. Wanneer dit token wordt gemaakt, voegt IIS automatisch het IIS_IUSRS-lidmaatschap toe aan het token van werkprocessen tijdens de uitvoertijd. De accounts die worden uitgevoerd als identiteiten van de groep van toepassingen hoeven niet langer een expliciet deel van de IIS_IUSRS groep te zijn. Als u een website maakt en vervolgens de fysieke locatie aanwijst C:\inetpub\wwwroot, worden de volgende gebruikers en groepen automatisch toegevoegd aan de toegangsbeheerlijsten van de site.

Gebruikers/groepen	Toegestane machtigingen
MAKER / EIGENAAR	Speciale machtigingen
SYSTEEM	Volledige controle
Beheerders	Volledige controle
Gebruikers	Lezen en uitvoeren, Inhoud van lijstmap, Lezen
IIS_USRS	Lezen en uitvoeren
TrustedInstaller	Volledige controle

Als u deze functie wilt uitschakelen en handmatig accounts aan de IIS_IUSRS groep wilt toevoegen, stelt u de waarde manualGroupMembership in op true in het bestand ApplicationHost.config. In het volgende voorbeeld ziet u hoe dit kan worden gedaan voor de standaardtoepassingsgroep:

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

Begrip van configuratie-isolatie

IIS-werkprocessen hebben geen leestoegang tot het ApplicationHost.config-bestand . U vraagt zich dus misschien af hoe ze een van de configuratiesets in dit bestand kunnen lezen.

Het antwoord is met behulp van de functie voor configuratieisolatie in IIS 7.0 en nieuwere versies. In plaats van de IIS-werkprocessen in te schakelen om ApplicationHost.config rechtstreeks te lezen wanneer ze de hiërarchie van het configuratiebestand lezen, genereert de Windows Process Activation Service (WAS) gefilterde kopieën van dit bestand. Elk IIS-werkproces gebruikt deze kopieën als vervanging van ApplicationHost.config wanneer de configuratie wordt gelezen in het IIS-werkproces. Deze bestanden worden standaard gegenereerd in de %SystemDrive%\inetpub\Temp\appPools map en hebben de naam {AppPoolName}.config. Deze bestanden zijn geconfigureerd om alleen toegang te verlenen tot de IIS-werkprocessen in de bijbehorende groep van toepassingen met behulp van de beveiligings-id (SID) van de IIS APPPOOL\AppPoolName toepassingsgroep.

Notitie

Zie Beveiligings-id's voor meer informatie over SID.

Dit wordt gedaan om te voorkomen dat IIS-werkprocessen van toepassingsgroep A configuratiegegevens kunnen lezen in het ApplicationHost.config-bestand dat is bedoeld voor groep B van toepassingen.

ApplicationHost.config kan gevoelige persoonlijke gegevens bevatten, zoals de gebruikersnaam en het wachtwoord voor aangepaste identiteiten van de groep van toepassingen, of de gebruikersnaam en het wachtwoord voor virtuele mappen. Als u alle toepassingsgroepen toegang geeft tot ApplicationHost.config , wordt de isolatie van de groep van toepassingen verbroken. Als elke groep van toepassingen directe toegang heeft gekregen tot het ApplicationHost.config-bestand , kunnen deze pools eenvoudig gevoelige informatie uit andere toepassingsgroepen hacken door de volgende opdracht uit te voeren:

appcmd list APPPOOL "DefaultAppPool" /text:*

IUSR - anonieme authenticatie

Met anonieme verificatie hebben gebruikers toegang tot openbare gebieden van de website zonder dat ze om een gebruikersnaam of wachtwoord hoeven te worden gevraagd. In IIS 7.0 en hoger wordt een ingebouwd account gebruikt IUSRom anonieme toegang te bieden. Voor dit ingebouwde account is geen wachtwoord vereist. Dit is de standaardidentiteit die wordt gebruikt wanneer anonieme verificatie is ingeschakeld. In het bestand ApplicationHost.config ziet u de volgende definitie:

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

Dit vertelt IIS om het nieuwe ingebouwde account te gebruiken voor alle anonieme verificatieaanvragen. De grootste voordelen hiervan zijn:

• U hoeft zich geen zorgen meer te maken over wachtwoorden die verlopen voor dit account.
• U kunt xcopy /o gebruiken om bestanden naadloos te kopiëren met hun eigendom en ACL-gegevens naar verschillende computers.

U kunt uw website ook anoniem verifiëren met behulp van een specifiek Windows-account of groepsidentiteit voor toepassingen in plaats van een IUSR account.

IUSR versus Verbind als

Maak verbinding zoals een optie in IIS waarmee u kunt bepalen welke referenties u wilt gebruiken voor toegang tot de website. U kunt de geverifieerde gebruikersreferenties of specifieke gebruikersreferenties gebruiken. Als u het verschil wilt begrijpen, moet u rekening houden met het volgende scenario:

U hebt een standaardwebsite die is geconfigureerd voor het gebruik van anonieme verificatie. De inhoud van uw website bevindt zich echter op een andere server en u gebruikt de sectie Verbinding maken als voor toegang tot die resource via een Test domeingebruiker. Wanneer de gebruiker zich aanmeldt, wordt hij geverifieerd met behulp van een IUSR-account. De inhoud van de website wordt echter geopend via de gebruikersreferenties die worden vermeld in de sectie Verbinding maken.

Om het simpeler te maken, is anonieme verificatie het mechanisme dat door de website wordt gebruikt om een gebruiker te identificeren. Maar wanneer u deze functie gebruikt, hoeft de gebruiker geen referenties op te geven. Er kan echter een vergelijkbaar scenario zijn waarin de inhoud zich op een netwerkshare bevindt. In dergelijke gevallen kunt u geen ingebouwde accounts gebruiken om toegang te krijgen tot de netwerkshare. In plaats daarvan moet u een specifiek account (domein) gebruiken om dit te doen.

ASP.NET-imitatie

Letterlijk betekent imitatie de handeling van doen alsof het een andere persoon is. In technische termen is het een ASP.NET beveiligingsfunctie die de mogelijkheid biedt om de identiteit te beheren waaronder toepassingscode wordt uitgevoerd. Imitatie vindt plaats wanneer ASP.NET code uitvoert in de context van een geverifieerde en geautoriseerde client. IIS biedt anonieme toegang tot resources met behulp van een IUSR account. Nadat de aanvraag is doorgegeven aan ASP.NET, wordt de toepassingscode uitgevoerd met behulp van de identiteit van de groep van toepassingen.

Imitatie kan worden ingeschakeld via IIS en ASP.NET code als de toepassing anonieme verificatie gebruikt en als aan een van de volgende voorwaarden wordt voldaan:

• Als IMPERSONATION deze optie is uitgeschakeld, wordt de identiteit van de groep van toepassingen gebruikt om de toepassingscode uit te voeren.
• Als IMPERSONATION deze optie is ingeschakeld, NT AUTHORITY\IUSR wordt deze gebruikt om de toepassingscode uit te voeren.

Wanneer impersonation is ingeschakeld via IIS, wordt de volgende tag toegevoegd aan het Web.config-bestand van de toepassing om het geauthenticeerde IIS-account of de gebruiker te imiteren: <identiteit imitatie="true" />

Als u een specifieke gebruiker wilt imiteren voor alle aanvragen op alle pagina's van een ASP.NET toepassing, kunt u de gebruikersnaam en wachtwoordkenmerken opgeven in de <identity> tag van het Web.config-bestand voor die toepassing.

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

Zie Imitatie implementeren in een ASP.NET toepassing om imitatie te implementeren via ASP.NET code

Open het IIS-werkproces van een testwebsite die een Test lokale gebruiker imiteert en controleer of u het imitatieaccount kunt vinden waaronder de toepassingscode wordt uitgevoerd.

De identiteit van de toepassingsgroep van de toepassing is ingesteld op ApplicationPoolIdentity en anonieme verificatie wordt geleverd met behulp van een IUSR account. U kunt eenvoudig de imitatie-identiteit traceren met ProcMon. Als u bijvoorbeeld een van de CreateFile-gebeurtenissen bekijkt die overeenkomt met het w3wp.exe proces dat u onderzoekt, kunt u het imitatieaccount vinden, zoals wordt weergegeven in de volgende schermopname.