C'est parce que ce sont deux choses différentes. IIS_IUSRS est le groupe des comptes de processus de travail IIS . Cela signifie l'identité sous laquelle le pool d'applications s'exécute. IUSR est l'identité de l'utilisateur anonyme. Cela signifie l'identité qu'IIS pense être l'utilisateur qui accède au site.
Maintenant, même si vous ne l'avez pas dit, laissez-moi deviner - cette application est un asp classique? (Sinon, s'il s'agit de .Net, vous devez utiliser l'emprunt d'identité). Quoi qu'il en soit, ce qui se passe est que les ressources sont accessibles en tant qu'identité usurpée, c'est-à-dire l'utilisateur anonyme dans votre cas, c'est-à-dire IUSR. C'est pourquoi vous devez lui accorder les droits. Dans .Net, si vous désactivez l'emprunt d'identité, vous constaterez que IIS_IUSRS entrera en jeu comme prévu. Dans Classic ASP (et pour les fichiers statiques), vous n'avez pas le choix, l'emprunt d'identité est toujours "activé"; donc c'est toujours l'identité de l'utilisateur qui est utilisée, pas l'identité du pool. Donc, puisque IIS_IUSRS est pour les identités de pool, il n'est pas en jeu.
Modifier après OP a ajouté plus d'informations:
Il est facile de confondre IUSR et IIS_IUSRS en raison de leurs noms. Pour voir comment ils sont différents, il faut se rappeler que IIS_IUSRS remplace IIS_WPG dans IIS6, qui était le groupe de processus de travail. À ces groupes, vous ajoutez des comptes sous lesquels vous souhaitez exécuter vos pools, et non des identités anon, les privilèges anon sont censés être plus limités. par exemple. Parfois, vous souhaiterez peut-être utiliser un compte de domaine pour exécuter le pool de délégation Kerberos vers d'autres ressources réseau. Ensuite, vous ajouteriez ce compte de service à ce groupe.
Lorsque l'emprunt d'identité est activé, le pool / processus fait semblant d'être l'utilisateur parce qu'il lui a été demandé. En cas de non-authentification (votre cas), cet utilisateur est IUSR. En cas d'authentification Windows, ce serait l'identité Windows \ domain de l'utilisateur. C'est également pourquoi vous obtenez un impact sur les performances avec l'emprunt d'identité, car le processus doit basculer vers une identité différente pour l'accès aux ressources.
Si vous utilisez .NET et l'authentification anonyme, je ne vois pas pourquoi vous activez cependant l'emprunt d'identité. Dans le cas où vous n'utilisez pas ou n'avez pas besoin d'emprunt d'identité, vous devez être conscient de quelques astuces supplémentaires dans le cas d'IIS7: vous pouvez faire disparaître complètement votre IUSR et mettre fin à toute confusion. Je pense que cela vous plairait, et c'est aussi ma méthode préférée. Tout ce que vous avez à faire est de lui dire de réutiliser l'identité du pool comme identité anonyme .
Donc, après cela, vous n'aurez plus qu'à traiter avec le groupe IIS_IUSRS. Mais ne vous y trompez pas, cela ne veut toujours pas dire que ces deux-là sont les mêmes! Il peut être possible que l'identité du processus se substitue à l'IUSR, mais pas l'inverse!
Encore une astuce IIS7 à connaître: si vous regardez IIS_IUSRS, il peut être vide. C'est parce que vos identités de pool virtuel y sont automatiquement ajoutées lorsque le pool démarre, vous n'avez donc pas à vous soucier de ces choses.
Ce tableau devrait aider à mieux clarifier la façon dont l'identité d'exécution du thread est déterminée:
Usurpation d'identité des ressources d'accès anonyme accessibles en tant que
Activé Activé IUSR_computer dans IIS5 / 6 ou,
IUSR dans IIS7 ou,
Si vous avez modifié le compte utilisateur anon
dans IIS, quoi que vous y définissiez
Activé Désactivé MYDOM \ MyName
Désactivé Activé Autorité NT \ Service réseau (identité de pool)
Désactivé Désactivé Autorité NT \ Service réseau (identité de pool)
