IIS AppPoolIdentity et autorisations d'accès en écriture au système de fichiers

Voici un problème avec IIS 7.5 et ASP.NET que j'ai recherché et que je n'ai trouvé nulle part. Toute aide serait grandement appréciée.

Ma question est la suivante: en utilisant ASP.NET dans IIS 7.5, comment IIS et / ou le système d'exploitation permettent-ils à l'application Web d'écrire dans un dossier comme C:\dumplors d'une exécution en toute confiance? Comment se fait-il que je n'ai pas à ajouter explicitement un accès en écriture à l'utilisateur du pool d'applications (dans ce cas ApplicationPoolIdentity)?

Ce que je sais:

• Dans IIS 7.5, l'identité par défaut d'un pool d'applications est ApplicationPoolIdentity.
• ApplicationPoolIdentity représente un compte d'utilisateur Windows appelé "IIS APPPOOL \ AppPoolName", qui est créé lors de la création du pool d'applications, où AppPoolName est le nom du pool d'applications.
• L'utilisateur "IIS APPPOOL \ AppPoolName" est par défaut un membre du IIS_IUSRSgroupe.
• Si vous utilisez en pleine confiance, votre application web peut écrire dans de nombreux domaines du système de fichiers ( à l' exclusion des dossiers comme C:\Users, C:\Windows, etc.). Par exemple, votre application aura accès à écrire à certains dossiers, comme, C:\dump.
• Par défaut, le IIS_IUSRSgroupe ne dispose pas d'un accès en lecture ou en écriture C:\dump(du moins pas un accès visible via l'onglet "Sécurité" dans l'Explorateur Windows).
• Si vous refusez l'accès en écriture à IIS_IUSRS, vous obtiendrez une exception SecurityException lors de la tentative d'écriture dans le dossier (comme prévu).

Ainsi, compte tenu de tout cela, comment l'accès en écriture est-il accordé à l'utilisateur "IIS APPPOOL \ AppPoolName"? Le processus w3wp.exe s'exécute en tant qu'utilisateur, alors qu'est-ce qui permet à cet utilisateur d'écrire dans un dossier auquel il ne semble pas avoir d'accès explicite?

Veuillez noter que je comprends que cela a probablement été fait pour des raisons de commodité, car il serait difficile d'accorder à un utilisateur l'accès à tous les dossiers dans lesquels il doit écrire si vous exécutez sous Full Trust. Si vous souhaitez limiter cet accès, vous pouvez toujours exécuter l'application sous Medium Trust. Je souhaite en savoir plus sur la manière dont le système d'exploitation et / ou IIS autorise ces écritures, même s'il ne semble pas y avoir d'accès explicite au système de fichiers.

L' ApplicationPoolIdentityappartenance est affectée au Usersgroupe ainsi qu'au IIS_IUSRSgroupe. À première vue, cela peut sembler quelque peu inquiétant, mais le Usersgroupe dispose de droits NTFS quelque peu limités.

Par exemple, si vous essayez de créer un dossier dans le C:\Windowsdossier, vous constaterez que vous ne pouvez pas. Le ApplicationPoolIdentitydoit encore être capable de lire des fichiers à partir des dossiers système de Windows (sinon, comment le processus de travail serait-il capable de charger dynamiquement les DLL essentielles).

En ce qui concerne vos observations sur la possibilité d'écrire dans votre c:\dumpdossier. Si vous regardez les autorisations dans les paramètres de sécurité avancés, vous verrez ce qui suit:

Voir cette autorisation spéciale héritée de c:\:

C'est la raison pour laquelle votre site ApplicationPoolIdentitypeut lire et écrire dans ce dossier. Ce droit est hérité du c:\lecteur.

Dans un environnement partagé où vous possédez peut-être plusieurs centaines de sites, chacun avec son propre pool d'applications et son identité de pool d'applications, vous stockez les dossiers de site dans un dossier ou un volume dont le Usersgroupe a été supprimé et les autorisations définies de telle sorte que seuls les administrateurs et les Le compte SYSTEM a accès (avec héritage).

Vous devez ensuite attribuer individuellement les autorisations requises dont chacun a IIS AppPool\[name]besoin sur son dossier racine de site.

Vous devez également vous assurer que tous les dossiers que vous créez dans lesquels vous stockez des fichiers ou des données potentiellement sensibles ont le Usersgroupe supprimé. Vous devez également vous assurer que toutes les applications que vous installez ne stockent pas de données sensibles dans leurs c:\program files\[app name]dossiers et qu'elles utilisent à la place les dossiers de profil utilisateur.

Donc, oui, à première vue, il semble que le pays ApplicationPoolIdentityait plus de droits qu'il ne devrait, mais il n'a en fait pas plus de droits que ne le prévoit l'appartenance à un groupe.

Une ApplicationPoolIdentityadhésion de groupe » peut être examinée à l' aide de Sysinternals Process outil Explorateur . Recherchez le processus de travail qui s'exécute avec l'identité du pool d'applications qui vous intéresse (vous devrez ajouter la User Namecolonne à la liste des colonnes à afficher:

Par exemple, j'ai ici un pool nommé 900300qui a une identité de pool d'applications IIS APPPOOL\900300. En cliquant avec le bouton droit sur les propriétés du processus et en sélectionnant l'onglet Sécurité, nous voyons:

Comme nous pouvons le voir, IIS APPPOOL\900300est membre du Usersgroupe.

1. Faites un clic droit sur le dossier.

2. Cliquez sur Propriétés

3. Cliquez sur l'onglet Sécurité. Vous verrez quelque chose comme ceci:

4. Cliquez sur le bouton "Modifier ..." dans l'écran ci-dessus. Vous verrez quelque chose comme ceci:

5. Cliquez sur le bouton "Ajouter ..." dans l'écran ci-dessus. Vous verrez quelque chose comme ceci:

6. Cliquez sur le bouton "Emplacements ..." dans l'écran ci-dessus. Vous verrez quelque chose comme ça. Maintenant, allez tout en haut de cette arborescence et sélectionnez le nom de votre ordinateur, puis cliquez sur OK.

7. Tapez maintenant "iis apppool \ your_apppool_name" et cliquez sur le bouton "Vérifier les noms". Si l'apppool existe, vous verrez votre nom apppool dans la zone de texte avec un soulignement. Cliquez sur le bouton OK.

8. Cochez / décochez tout accès dont vous avez besoin pour accorder au compte

9. Cliquez sur le bouton Appliquer, puis sur OK.

Chaque pool d'applications dans IIs crée son propre dossier utilisateur sécurisé avec une autorisation de lecture / écriture COMPLÈTE par défaut sous c: \ users. Ouvrez votre dossier Utilisateurs et voyez quels sont les dossiers du pool d'applications, cliquez avec le bouton droit et vérifiez leurs droits pour le compte virtuel du pool d'applications attribué. Vous devriez déjà voir votre compte de pool d'applications ajouté avec un accès en lecture / écriture attribué à sa racine et à ses sous-dossiers.

Ainsi, ce type d'accès au stockage de fichiers se fait automatiquement et vous devriez pouvoir écrire ce que vous voulez dans les dossiers des comptes d'utilisateurs des pools d'applications sans rien changer. C'est pourquoi des comptes d'utilisateurs virtuels pour chaque pool d'applications ont été créés.

J'ai essayé cela pour résoudre les problèmes d'accès à un site Web IIS, qui se manifestaient par quelque chose comme ce qui suit dans les journaux d'événements → Windows → Application:

Nom du journal: application
Source: ASP.NET 4.0.30319.0
Date: 1/5/2012 4:12:33 PM
ID d'événement: 1314
Catégorie de tâche: événement Web
Niveau: Information
Mots-clés: Classique
Utilisateur: N / A
Ordinateur: SALTIIS01

La description:
Code d'événement: 4008 
Message d'événement: Échec de l'autorisation de fichier pour la demande. 
Heure de l'événement: 1/5/2012 4:12:33 PM 
Heure de l'événement (UTC): 1/6/2012 12:12:33 AM 
ID d'événement: 349fcb2ec3c24b16a862f6eb9b23dd6c 
Séquence d'événements: 7 
Occurrence de l'événement: 3 
Code détail de l'événement: 0 

Informations sur l'application: 
    Domaine d'application: / LM / W3SVC / 2 / ROOT / Application / SNCDW-19-129702818025409890 
    Niveau de confiance: complet 
    Chemin virtuel d'application: / Application / SNCDW 
    Chemin d'application: D: \ Sites \ WCF \ Application \ SNCDW \ 
    Nom de la machine: SALTIIS01 

Traitement de l'information: 
    ID du processus: 1896 
    Nom du processus: w3wp.exe 
    Nom du compte: iisservice 

Informations requises: 
    URL de demande: http: //webservicestest/Application/SNCDW/PC.svc 
    Chemin de demande: /Application/SNCDW/PC.svc 
    Adresse de l'hôte utilisateur: 10.60.16.79 
    Utilisateur: js3228 
    Est authentifié: Vrai 
    Type d'authentification: Négocier 
    Nom du compte de discussion: iisservice 

À la fin, j'ai dû donner au Everyonegroupe Windows un accès en lecture à ce dossier pour qu'il fonctionne correctement.