IUSR e IWAM risalgono ai primissimi giorni di IIS quando lo si installava separatamente (non come componente del sistema operativo). Per impostazione predefinita, se un sito Web consente l'autenticazione anonima, l'account IUSR viene utilizzato in relazione alle autorizzazioni sul sistema operativo. Questo può essere modificato dal valore predefinito. Esistono alcuni consigli di sicurezza per rinominare almeno l'account, quindi non è un account "noto", proprio come esiste un consiglio per rinominare l'account amministratore su un server. Puoi saperne di più su IUSR e l'autenticazione su MSDN .
IWAM è stato progettato per qualsiasi applicazione fuori processo e viene utilizzato in IIS 6.0 solo in modalità di isolamento IIS 5.0. Di solito lo vedevi con oggetti COM / DCOM.
Per quanto riguarda le identità del pool di applicazioni, l'impostazione predefinita è l'esecuzione come servizio di rete. Non si dovrebbe eseguire come sistema locale perché quell'account ha diritti superiori a quelli di un amministratore. In modo che sostanzialmente ti lascia al servizio di rete, servizio locale o un account locale / dominio diverso da quei due.
Quanto a cosa fare, dipende. Un vantaggio di lasciarlo come servizio di rete è che questo è un account con privilegi limitati sul server. Tuttavia, quando accede alle risorse attraverso la rete, viene visualizzato come Domain \ ComputerName $, il che significa che è possibile assegnare autorizzazioni che consentono all'account del servizio di rete di accedere a risorse come SQL Server in esecuzione su una casella diversa. Inoltre, poiché viene visualizzato come account del computer, se si abilita l'autenticazione Kerberos, l'SPN è già in atto se si accede al sito Web con il nome del server.
Un caso in cui potresti prendere in considerazione la modifica del pool di applicazioni in un determinato account di dominio Windows se desideri che un determinato account acceda a risorse di rete come un account di servizio che accede a SQL Server per un'applicazione basata sul Web. Ci sono altre opzioni in ASP.NET per farlo senza cambiare l'identità del pool di applicazioni, quindi non è più strettamente necessario. Un altro motivo che potresti considerare di utilizzare un account utente di dominio è che stavi eseguendo l'autenticazione Kerberos e disponevi di più server Web che eseguivano la manutenzione di un'applicazione Web. Un buon esempio è se due o più server Web offrivano SQL Server Reporting Services. Il front-end probabilmente verrebbe indirizzato a un URL generico come reports.mydomain.com o reporting.mydomain.com. In tal caso, l'SPN può essere applicato a un solo account in AD. Se i pool di app sono in esecuzione in Servizio di rete su ciascun server, ciò non funzionerà, perché quando escono dai server, vengono visualizzati come Domain \ ComputerName $, il che significa che avresti tutti gli account quanti ne hai i server che servono il app. La soluzione è creare un account di dominio, impostare l'identità del pool di app su tutti i server sullo stesso account utente di dominio e creare un unico SPN, consentendo così l'autenticazione Kerberos. Nel caso di un'app come SSRS, dove potresti voler trasferire le credenziali dell'utente al server di database back-end, l'autenticazione Kerberos è d'obbligo perché dovrai configurare la delega Kerberos. d ha tanti account quanti erano i server che servono l'app. La soluzione è creare un account di dominio, impostare l'identità del pool di app su tutti i server sullo stesso account utente di dominio e creare un unico SPN, consentendo così l'autenticazione Kerberos. Nel caso di un'app come SSRS, dove potresti voler trasferire le credenziali dell'utente al server di database back-end, l'autenticazione Kerberos è d'obbligo perché dovrai configurare la delega Kerberos. d ha tanti account quanti erano i server che servono l'app. La soluzione è creare un account di dominio, impostare l'identità del pool di app su tutti i server sullo stesso account utente di dominio e creare un unico SPN, consentendo così l'autenticazione Kerberos. Nel caso di un'app come SSRS, dove potresti voler trasferire le credenziali dell'utente al server di database back-end, l'autenticazione Kerberos è d'obbligo perché dovrai configurare la delega Kerberos.
So che c'è molto da accettare, ma la risposta breve è, ad eccezione del sistema locale, dipende.