Quels sont les comptes IUSR et IWAM dans IIS?
Je cherche une bonne explication des comptes IUSR et IWAM utilisés par IIS pour m'aider à mieux configurer notre environnement d'hébergement:
- Pourquoi sont-ils là?
- Quelle est la différence entre eux?
- Les noms représentent-ils quelque chose de significatif?
- Y a-t-il des changements de bonnes pratiques que je devrais apporter?
- IIS me donne également des options pour exécuter des pools d'applications en tant que service réseau, service local ou système local. Devrais-je?
- Mon serveur Web fait partie d'un domaine, comment cela change-t-il les choses?
Il semble courant de créer vos propres versions de ces comptes lors du déploiement de plusieurs sites sur un serveur, ce qui soulève des questions supplémentaires:
- Quand pourrais-je vouloir créer mes propres comptes IUSR et IWAM?
- Comment dois-je créer ces comptes supplémentaires pour qu'ils disposent des autorisations appropriées?
J'utilise à la fois IIS 6 et et IIS 7 avec principalement des configurations par défaut).
IUSR et IWAM remontent aux tout premiers jours de IIS lorsque vous l'avez 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 autorisations sur le système d'exploitation. Cela peut être modifié par rapport à la valeur par défaut. Il existe certaines recommandations de sécurité pour renommer au moins le compte, donc ce n'est pas un compte "connu", tout comme il est recommandé de renommer le compte administrateur sur un Vous pouvez en savoir plus sur IUSR et authentification sur MSDN .
IWAM a été conçu pour toutes les applications hors processus et n'est utilisé qu'en IIS 6.0 lorsque vous êtes en IIS 5.0 mode d'isolation. Vous l'avez généralement vu avec COM/Objets DCOM.
En ce qui concerne les identités de pool d'applications, la valeur par défaut est de s'exécuter en tant que service réseau. Vous ne devez pas exécuter en tant que système local car ce compte a des droits supérieurs à ceux d'un administrateur. Donc, cela vous laisse essentiellement au service réseau, au service local ou à un compte local/domaine autre que ces deux.
Quant à savoir quoi faire, cela dépend. Un avantage de le laisser comme service réseau est qu'il s'agit d'un compte à privilèges limités sur le serveur. Cependant, lorsqu'il accède aux ressources sur le réseau, il apparaît sous le nom Domain\ComputerName $, ce qui signifie que vous pouvez attribuer des autorisations qui permettent au compte Service réseau d'accéder à des ressources telles que SQL Server s'exécutant sur une autre zone. De plus, étant donné qu'il apparaît en tant que compte d'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 envisagez de modifier le pool d'applications en un compte de domaine Windows particulier si vous souhaitez qu'un compte particulier accède aux ressources en réseau, tel qu'un compte de service accédant à SQL Server pour une application Web. Il existe d'autres options dans ASP.NET pour le faire sans modifier l'identité du pool d'applications, donc ce n'est plus strictement nécessaire. Une autre raison pour laquelle vous envisagez d'utiliser un compte d'utilisateur de domaine est que vous effectuez l'authentification Kerberos et que plusieurs serveurs Web assurent la maintenance d'une application Web. Un bon exemple est si vous aviez deux serveurs Web ou plus servant SQL Server Reporting Services. Le front-end serait probablement une URL générique telle que reports.mydomain.com ou reporting.mydomain.com. Dans ce cas, le SPN ne peut être appliqué qu'à un seul compte dans AD. Si vous avez les pools d'applications exécutés sous Service réseau sur chaque serveur, cela ne fonctionnera pas, car lorsqu'ils quittent les serveurs, ils apparaissent sous la forme Domain\ComputerName $, ce qui signifie que vous auriez autant de comptes que vous aviez de serveurs servant la app. La solution consiste à créer un compte de domaine, à définir l'identité du pool d'applications sur tous les serveurs sur le même compte d'utilisateur de domaine et à créer le seul SPN, permettant ainsi l'authentification Kerberos. Dans le cas d'une application comme SSRS, où vous souhaiterez peut-être transmettre les informations d'identification de l'utilisateur au serveur de base de données principal, l'authentification Kerberos est un must car vous devrez alors configurer la délégation Kerberos.
Je sais que c'est beaucoup à prendre, mais la réponse courte est, sauf pour le système local, cela dépend.
IUSR = Internaute, c'est-à-dire tout visiteur anonyme et non authentifié de votre site Web (c'est-à-dire à peu près tout le monde)
IWAM = Internet Web Application Manager, c'est-à-dire que toutes vos applications ASP et .NET s'exécuteront sous ce compte
En règle générale, l'IUSR et l'IWAM ne devraient avoir accès qu'à ce dont ils ont besoin. Ils ne devraient jamais avoir accès à quoi que ce soit d'autre, au cas où ces comptes seraient compromis, ils ne pourraient pas accéder à quoi que ce soit de critique.
C'est à peu près tout ce que je peux vous aider en dehors de votre liste de questions, d'autres avec plus d'expérience en administration IIS administration pourraient être en mesure de vous aider davantage!
Je recourt toujours à ce guide -
http://learn.iis.net/page.aspx/140/understanding-the-built-in-user-and-group-accounts-in-iis-70/
Vous pouvez trouver beaucoup de choses sur iis.net
pour le dire simplement - IUSR est tout simplement hors de la boîte des comptes invités qui ont des autorisations sur c:\inetpub\wwwroot par défaut.