IUSR e IWAM datam dos primeiros dias do IIS quando você o instalou separadamente (não como um componente do sistema operacional). Por padrão, se um site permitir autenticação anônima, a conta IUSR será usada com relação às permissões no sistema operacional. Isso pode ser alterado do padrão. Existem algumas recomendações de segurança para pelo menos renomear a conta, portanto, não é uma conta "conhecida", assim como há uma recomendação para renomear a conta de administrador em um servidor. Você pode saber mais sobre IUSR e autenticação no MSDN .
O IWAM foi projetado para qualquer aplicativo fora de processo e é usado apenas no IIS 6.0 quando você está no modo de isolamento do IIS 5.0. Você costumava vê-lo com objetos COM / DCOM.
Com relação às identidades do pool de aplicativos, o padrão é executar como o Serviço de Rede. Você não deve executar como Sistema Local porque essa conta possui direitos maiores que o de um administrador. Isso basicamente deixa você no serviço de rede, no serviço local ou em uma conta local / de domínio diferente dessas duas.
Quanto ao que fazer, isso depende. Uma vantagem de deixá-lo como Serviço de Rede é que esta é uma conta de privilégio limitado no servidor. No entanto, quando acessa recursos pela rede, aparece como Domain \ ComputerName $, o que significa que você pode atribuir permissões que permitem que a conta do Serviço de Rede acesse recursos como o SQL Server em execução em uma caixa diferente. Além disso, uma vez que aparece como a conta do computador, se você habilitar a autenticação do Kerberos, o SPN já estará em vigor se você estiver acessando o site pelo nome do servidor.
Um caso em que você consideraria alterar o pool de aplicativos para uma determinada conta de domínio do Windows se desejar que uma determinada conta acesse recursos em rede, como uma conta de serviço que acesse o SQL Server para um aplicativo baseado na Web. Existem outras opções dentro do ASP.NET para fazer isso sem alterar a identidade do pool de aplicativos, portanto isso não é estritamente necessário por mais tempo. Outro motivo que você consideraria usar uma conta de usuário de domínio é que você estava fazendo a autenticação do Kerberos e tinha vários servidores da Web atendendo a um aplicativo da Web. Um bom exemplo é se você tivesse dois ou mais servidores da Web servindo o SQL Server Reporting Services. O front end provavelmente seria um URL genérico, como reports.mydomain.com ou reporting.mydomain.com. Nesse caso, o SPN só pode ser aplicado a uma conta no AD. Se você tiver os pools de aplicativos em execução no Serviço de Rede em cada servidor, isso não funcionará, porque, quando eles saem dos servidores, eles aparecem como Domain \ ComputerName $, o que significa que você teria tantas contas quanto os servidores que estavam atendendo o servidor. aplicativo. A solução é criar uma conta de domínio, definir a identidade do pool de aplicativos em todos os servidores para a mesma conta de usuário do domínio e criar um SPN, permitindo a autenticação Kerberos. No caso de um aplicativo como o SSRS, no qual você pode passar as credenciais do usuário para o servidor de banco de dados de back-end, a autenticação do Kerberos é uma obrigação, porque você precisará configurar a delegação do Kerberos.
Eu sei que é muito para receber, mas a resposta curta é, exceto para o Sistema Local, isso depende.