Comment se fait-il que lorsque j'ajoute un accès IIS_IUSRS RW à un dossier, il n'autorise pas automatiquement l'accès ISUR RW?


11

J'utilise IIS7 (Windows Server 2008 x64) et j'ai une configuration de site Web utilisant une authentification anonyme. L'identité de l'utilisateur anon est configurée comme IUSR. L'application écrit des fichiers dans un dossier et j'accorde au groupe IIS_IUSRS des autorisations RW sur le dossier. Ça ne marche pas. Je dois explicitement donner des autorisations IUSR RW pour permettre à l'application d'écrire dans le dossier.

Je crois comprendre que l'identité du pool d'applications est automatiquement ajoutée au groupe IIS_IUSRS. J'ai supposé que l'IUSR (ou toute identité d'utilisateur anonyme) était également un membre implicite du groupe IIS_IUSRS. Il ne semble pas que ce soit le cas.

Lors du dépannage, j'utilise Process Monitor pour afficher l'accès au dossier et j'ai déterminé que le service réseau (l'identité du pool d'applications) usurpe l'identité IUSR (c'est ce à quoi je m'attendais), mais donner des autorisations RW au groupe IIS_IUSRS n'a pas permis à IUSR d'accéder à la l'acccès au dossier n'a pas été accepté).

Quelqu'un peut-il expliquer si l'IUSR est ou n'est pas membre du groupe IIS_IUSRS?

J'ai examiné la documentation suivante et je n'ai trouvé aucune réponse solide:

Présentation des comptes d'utilisateurs et de groupes intégrés dans IIS 7

Identités du pool d'applications

Réponses:


14

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)


Nous utilisons certainement .Net (3.5 ciblé) mais il se peut qu'il utilise l'emprunt d'identité. Je vais devoir vérifier avec mes développeurs pour en être certain. Ma confusion vient du fait que j'ai supposé (à tort il semble) que l'identité de l'utilisateur anonyme était automatiquement membre du groupe IIS_IUSRS. Puisqu'il ne me permet pas alors de clarifier et de me corriger s'il vous plaît.

1) En utilisant l'ASP classique, les autorisations d'accès aux fichiers utilisent l'identité d'utilisateur anonyme. Dans IIS 7 ou version ultérieure, cet utilisateur n'est pas membre du groupe IIS_IUSRS par défaut. 2) À l'aide d'ASP.Net, les autorisations d'accès aux fichiers utilisent l'identité de l'utilisateur anonyme si l'emprunt d'identité est activé. Dans IIS 7 ou version ultérieure, cet utilisateur n'est pas membre du groupe IIS_IUSRS par défaut. 3) À l'aide d'ASP.Net, les autorisations d'accès aux fichiers utilisent l'identité du processus de travail si l'emprunt d'identité est désactivé. Dans IIS 7 ou version ultérieure, cet utilisateur est toujours membre du groupe IIS_IUSRS par défaut.

Oui absolument correct sur tous les points! Pour être parfaitement clair, dans # 1 et # 2, vous devez ajouter "si l'authentification anon IIS est activée", que je n'ai pas dû inclure plus tôt parce que vous avez déjà dit que vous utilisez anon. Voir le tableau que j'ai ajouté pour mieux expliquer cela.
Amit Naidu du

Merci beaucoup d'avoir clarifié cela. Il est d'accord avec ce que j'ai trouvé par essais et erreurs, mais je n'ai vu cela documenté très clairement nulle part.Il est essentiel pour les administrateurs qui utilisent LUA sur leurs serveurs lors de la configuration des applications IIS qui nécessitent une autorisation d'écriture.
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.