dotNETportal.cz

Při provozování ASP.NET webových aplikací řešíme vždy současně s jejím nasazením i její konfiguraci z hlediska práv pro přístup k lokálním nebo sítových zdrojům. Přitom se může jednat o přístup k souborům nebo například připojení k SQL Server databázi. Podíváme se podrobněji pod jakými identitami a Windows účty aplikace k těmto zdrojům přistupuje a jaké jsou možnosti nastavení IIS.

V článku se budu věnovat pouze IIS 7/7.5 a také budu uvažovat doménové prostředí.

Kód aplikace, tedy i kód přistupující k danému zdroji, běží pod nějakou konkrétní identitou. V případě ASP.NET aplikace se jedná buď o identitu IIS Worker procesu (w3wp) – Process Identity nebo přímo o identitu uživatele přistupujícího k aplikaci. Pod identitou uživatele běží pouze kód odpovídající obsluze jeho požadavku (HTTP requestu) a pouze v případě povolení impersonace (zosobnění) - kód běží v tzv. impersonovaném kontextu.

IIS Worker process identity

Identita, pod kterou běží IIS Worker proces, je dána nastavením na úrovní aplikačního poolu v IIS. Konkrétně jde o volbu identity v Advanced Settings poolu.

Tabulka níže uvádí pod jakými Windows účty přistupuje aplikace k lokálním a síťovým zdrojům na základě nastavení IIS v případě, že kód běží pod identitou IIS Worker procesu.

1) IIS Worker process běžící pod účtem NETWORK SERVICE přistupuje k síti pod účtem počítače (machine account) - <domainname>\<machinename>$ (například CONTOSO\WEBSVR$). Účet počítače je vytvořen, když je počítač přidán do domény.

2) Pokud v IIS zvolíme v nastavení Pool itentity volbu ApplicationPoolIdentity, běží IIS Worker process pod účtem IIS APPPOOL\<poolname> (tedy například IIS APPPOOL\DefaultAppPool). Jedná se o virtuální účet (Virtual Account), který IIS sám vytvoří jedinečně pro každý takto nastavený pool. Přístup k síti probíhá stejně jako u NETWORK SERVICE tj. pod účtem počítače.

Pokud IIS APPPOOL účet nastavujeme například pro přístup k souborům, můžeme ve Windows 7 nebo Windows Server 2008 R2 použít dialog Select Users or Group, ale účet zde musíme přímo napsat (ve tvaru “IIS APPPOOL\<poolname>”). Pokud provedeme vyhledání přes Avanced, Find Now, tak v seznamu účtů nebude. (V systémech Vista nebo Windows Server 2008 tento účet musíme nastavit scriptem).

V IIS 7.5 je na rozdíl od IIS 7 volba ApplicationPoolIdentity pro DefaultAppPool nastavena po instalaci jako výchozí.

Ještě upozorním, že někdy je potřeba změnit nastavení volby Load User Profile poolu, protože ApplicationPoolIdentity nemá vytvořen souborový profil a tak nemusí mít například přístup k Temp adresáři apod.

Více o ApplicationPoolIdentity a User Profile je popsáno zde.

Identita v impersonovaném kontextu

Při zapnuté impersonaci (nastavením <identity impersonate="true" /> v konfiguračním souboru web.config) aplikace používá pro přistup ke zdrojům security context přihlášeného nebo anonymního uživatele. Pro kód běžící v impersonovaném kontextu na nastavené identitě poolu z pohledu přístupu ke zdrojům nezáleží. Více o Impersonaci je popsáno zde.

Tabulka níže uvádí pod jakými Windows účty přistupuje aplikace k lokálním a síťovým zdrojům na základě nastavení způsobu autentizace v IIS v případě použití impersonace.

Pokud pod IIS provozujeme jiné než ASP.NET aplikace tj. například Classic ASP nebo PHP, je pool nastaven na No Managed Code a Classic pipeline mode (pokud ho nechceme mixovat s ASP.NET). V takovém případě je také používán impersonovaný kontext a přístup, ke zdrojům je stejný jako v předcházející tabulce.

3) Účet NT AUTHORITY\IUSR slouží jako výchozí účet pro anonymní přihlášení (anonymous authentication). Tento účet je v IIS od verze 7 a nahrazuje dřívější účet IUSR_MachineName. Na rozdíl od něj se jedná o built-in account, což má značné výhody, více zde.

4) Pro přístup k síťovému zdroji je nutné předat identitu volajícího (impersonation token) až na vzdálený server. K tomu je nutné použít delegaci (delegation). Delegace je funkce autentizačního protokolu Kerberos, která umožní serveru získat tiket jménem koncového uživatele aniž by server měl přístup k heslu tohoto uživatele. Tento způsob, kdy je umožněno, aby credentials uživatele “protekly“ přes více úrovní (v našem případě client –> web server –> remote server), se také nazývá "double-hop".

Při integrované Windows autentizaci se použije buď NTLM nebo Kerberos. V doménovém prostředí má přednost Kerberos, ale v případě webového serveru se pro přihlášení z klienta použije NTLM (protože klient nemá přistup k doménovému controléru na získání Kerberos tiketu). NTLM ale delegaci nepodporuje, a tak se pro přístup k síťovému zdroji pomoci protocol transition přepne na Kerberos autentizaci (viz. také rozšíření Protocol Transition and Constrained Delegation).

Standardně je delegace potlačena (Kerberos defaultně povolí pouze one hop), a tak aby delegace fungovala, je potřeba provést řadu nastavení v Active Directory a nastavení SPN (Service Principal Name) pro web site. V případě, že delegace není povolena nebo v daném scénáři podporována, k síťovému zdroji se přistupuje pod anonymní identitou NT AUTHORITY\ANONYMOUS LOGON. Více o Kerberos protokolu a nastavení delegace je popsáno zde, zde, zde , zde nebo zde. (Také vám může pomoci utilita DelegConfig.)

Dále pozor, že pokud na web přistupujete lokálně, přistupujeme na něj nejčastěji pod identitou, pod kterou jsme zároveň přímo přihlášeni na webovém serveru (nejčastěji se tak děje při vývoji). V takovém případě se nejedná o případ Kerberos double-hop, delegace tedy není potřeba a přístup k síťovému zdroji je umožněn i pokud není delegace povolena.

5) U Basic autentizace je zadané heslo posíláno jako čistý text (pouze enkodované do Base64), a tak má IIS přístup k heslu uživatele. Tím může uživatele lokálně přihlásit (přes Win32 API LogonUser) a přistupovat tak jako tento uživatel k síťovým zdrojům (je zde vždy pouze single hop).

Basic autentizace může kromě Windows doménových účtů používat i lokálním účty, pokud jsou na obou počítačích (webový server, remote server) založeny identicky.