IUSR et IWAM remontent aux tout premiers jours d’IIS lorsqu’il était installé séparément (pas en tant que composant du système d’exploitation). Par défaut, si un site web autorise l’authentification anonyme, le compte IUSR est utilisé en ce qui concerne les permissions du système d’exploitation. Cela peut être modifié par rapport à la valeur par défaut. Il existe des recommandations de sécurité pour au moins renommer le compte, afin qu’il ne soit pas un compte « connu », tout comme il est recommandé de renommer le compte administrateur sur un serveur. Vous pouvez en savoir plus sur IUSR et l’authentification sur MSDN.
IWAM a été conçu pour toutes les applications hors processus et n’est utilisé dans IIS 6.0 que lorsque vous êtes en mode d’isolation IIS 5.0. Vous le voyiez généralement avec les objets COM/DCOM.
Concernant les identités des pools d’applications, la valeur par défaut est d’exécuter en tant que Network Service. Vous ne devriez pas exécuter en tant que Local System car ce compte a des droits supérieurs à ceux d’un administrateur. Il vous reste donc Network Service, Local Service ou un compte local/de domaine autre que ces deux-là.
Quant à ce qu’il faut faire, cela dépend. Un avantage de le laisser en tant que Network Service est qu’il s’agit d’un compte à privilèges limités sur le serveur. Cependant, lorsqu’il accède à des ressources sur le réseau, il apparaît comme Domaine\NomOrdinateur$, ce qui signifie que vous pouvez attribuer des permissions qui permettent au compte Network Service d’accéder à des ressources telles que SQL Server sur une autre machine. De plus, comme il apparaît comme le compte de l’ordinateur, si vous activez l’authentification Kerberos, le SPN est déjà en place si vous accédez au site web par le nom du serveur.
Un cas où vous envisageriez de changer l’identité du pool d’applications pour un compte de domaine Windows particulier est lorsque vous voulez qu’un compte spécifique accède à des ressources réseau, comme un compte de service accédant à SQL Server pour une application web. Il existe d’autres options au sein d’ASP.NET pour le faire sans changer l’identité du pool d’applications, donc ce n’est plus strictement nécessaire. Une autre raison serait si vous faisiez de l’authentification Kerberos et aviez plusieurs serveurs web desservant une application web. Un bon exemple est si vous aviez deux serveurs web ou plus servant SQL Server Reporting Services. Le frontal utiliserait probablement une URL générique comme reports.mondomaine.com. Dans ce cas, le SPN ne peut être appliqué qu’à un seul compte dans AD. Si les pools d’applications s’exécutent sous Network Service sur chaque serveur, cela ne fonctionnera pas, car quand ils quittent les serveurs, ils apparaissent comme Domaine\NomOrdinateur$. La solution est de créer un compte de domaine, définir l’identité du pool d’applications sur tous les serveurs sur le même compte utilisateur de domaine et créer l’unique SPN, permettant ainsi l’authentification Kerberos. Dans le cas d’une application comme SSRS, où vous pourriez vouloir faire passer les identifiants utilisateur au serveur de base de données backend, l’authentification Kerberos est indispensable car vous devrez configurer la délégation Kerberos.
Je sais que c’est beaucoup à assimiler, mais la réponse courte est : à l’exception de Local System, cela dépend.