Comment puis-je donner à ASP.NET l’autorisation d’écrire dans un dossier dans Windows 7?

J’ai un nouveau poste de travail Win7 et j’essaie de faire fonctionner le wiki ScrewTurn sur la machine. Mon installation STW utilise l’option de système de fichiers pour stocker ses données et, en tant que telle, je dois accorder des permissions d’écriture au processus de travail ASP.NET dans le dossier dans lequel le site Web est installé.

Cependant, je n’arrive pas à trouver le nom du processus de travail dans Win7 pour l’append aux permissions du dossier. Dans XP, c’était ASPNET_WP, si je me souviens bien, mais ce n’est pas son nom dans Win7.

Est-ce que quelqu’un peut me dire s’il vous plaît?

Edité pour append:

En réponse à @Dragan_Radivojevic, voici à quoi ressemble le pool d’applications en question (nommé ScrewTurnWiki):

Pools d'applications IIS7

L’identité est “ApplicationPoolIdentity”

Donner des permissions d’écriture à tous les groupes IIS_USRS est une mauvaise idée du sharepoint vue de la sécurité. Vous n’avez pas besoin de le faire et vous pouvez accorder des permissions uniquement à l’utilisateur du système exécutant le pool d’applications.

Si vous utilisez II7 (et je suppose que vous le faites), procédez comme suit.

  1. Ouvrir IIS7
  2. Sélectionnez le site Web pour lequel vous devez modifier les permissions
  3. Accédez aux parameters de base et consultez le pool d’applications que vous utilisez.
  4. Accédez aux pools d’applications et recherchez le pool d’applications à partir de # 3
  5. Rechercher le compte système utilisé pour exécuter ce pool d’applications (colonne Identité)
  6. Accédez à votre dossier de stockage dans IIS, sélectionnez-le et cliquez sur Modifier les permissions (sous le sous-menu Actions à droite).
  7. Ouvrez l’onglet Sécurité et ajoutez les permissions nécessaires uniquement pour l’utilisateur que vous avez identifié dans # 3

Remarque n ° 1: si vous voyez ApplicationPoolIdentity dans # 3, vous devez faire référence à cet utilisateur du système comme cet AppPool IIS {nom_max_application}. Par exemple IIS AppPool \ DefaultAppPool

Remarque n ° 2: lorsque vous ajoutez cet utilisateur, veillez à définir les emplacements corrects dans la boîte de dialog Sélectionner les utilisateurs ou les groupes. Cela doit être défini sur l’ordinateur local car il s’agit d’un compte local.

Je sais que c’est un ancien thread, mais pour développer la réponse ici, par défaut, IIS 7.5 crée des comptes d’identité de pool d’applications pour exécuter le processus de travail. Vous ne pouvez pas rechercher ces comptes comme des comptes d’utilisateur normaux lors de l’ajout d’permissions de fichiers. Pour les append à l’autorisation NTFS, vous pouvez taper le nom complet de l’identité du pool d’applications et cela fonctionnera.

Il n’ya qu’une légère différence dans la façon dont les comptes d’identité du pool d’applications sont gérés car ils sont considérés comme des comptes virtuels.

Le nom d’utilisateur de l’identité du pool d’applications est également “IIS AppPool \ nom du pool d’applications”. Par conséquent, s’il s’agissait du pool d’applications DefaultAppPool, le compte d’utilisateur serait “IIS AppPool \ DefaultAppPool”.

Celles-ci peuvent être vues si vous ouvrez la gestion de l’ordinateur et regardez les membres du groupe local IIS_IUSRS. Le SID ajouté à leur fin n’est pas nécessaire lors de l’ajout du compte dans une liste de contrôle d’access NTFS.

J’espère que cela pourra aider

Ma solution immédiate (car je n’ai pas pu trouver le processus de traitement ASP.NET) était de donner l’autorisation d’écriture (c’est-à-dire, de modification) à IIS_IUSRS. Cela a fonctionné. Il me semble rappeler que, dans WinXP, je devais donner spécifiquement l’autorisation d’écriture du processus de travail ASP.NET pour accomplir cela. Peut-être que ma mémoire est défectueuse, mais de toute façon …

@DraganRadivojevic a écrit qu’il pensait que c’était dangereux du sharepoint vue de la sécurité. Je ne suis pas en désaccord, mais comme il s’agissait de mon poste de travail et non d’un serveur de réseau, cela semblait relativement sûr. Dans tous les cas, sa réponse est meilleure et c’est ce que j’ai finalement décidé après avoir recherché un chemin d’access en raison du fait que le domaine AppPool n’était pas spécifié.