Autorisations d'accès en écriture du système de fichiers et de l'AppPoolIdentity de IIS

Question

Voici un problème avec IIS 7.5 et ASP.NET sur lequel j'ai fait des recherches et qui n'aboutit à rien. 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 tel que C:\dump lorsqu'il fonctionne en toute confiance ? Comment se fait-il que je n'aie pas à ajouter explicitement un accès en écriture pour l'utilisateur du pool d'applications (dans ce cas-ci ApplicationPoolIdentity ) ?

Voilà ce que je sais :

• Dans IIS 7.5, l'identité par défaut d'un pool d'applications est la suivante ApplicationPoolIdentity .
• ApplicationPoolIdentity représente un compte utilisateur Windows appelé "IIS APPPOOL". \AppPoolName ", qui est créé lorsque le pool d'applications est créé, où AppPoolName est le nom du pool d'applications.
• L'option "IIS APPPOOL \AppPoolName L'utilisateur " est par défaut un membre de la IIS_IUSRS groupe.
• Si vous vous exécutez sous Full Trust, votre application web peut écrire dans de nombreuses zones du système de fichiers (à l'exception des dossiers tels que C:\Users , C:\Windows etc). Par exemple, votre application aura accès en écriture à certains dossiers, comme, C:\dump .
• Par défaut, le IIS_IUSRS ne dispose pas d'un accès en lecture ou en écriture à C:\dump (du moins pas l'accès visible par l'onglet "Sécurité" de l'Explorateur Windows).
• Si vous refusez l'accès en écriture à IIS_IUSRS vous obtiendrez une SecurityException lorsque vous tenterez d'écrire dans le dossier (comme prévu).

Donc, en prenant tout cela en compte, comment l'accès en écriture est accordé à l'"APPPOOL IIS". \AppPoolName utilisateur " ? Le processus w3wp.exe s'exécute sous cet 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 pénible d'accorder à un utilisateur l'accès à chaque dossier dans lequel il doit écrire si vous exécutez l'application sous Full Trust. Si vous voulez limiter cet accès, vous pouvez toujours exécuter l'application sous Medium Trust. Ce qui m'intéresse, c'est de savoir comment le système d'exploitation et/ou IIS permet à ces écritures d'avoir lieu, même si aucun accès explicite au système de fichiers ne semble être accordé.

Answer 1

Le site ApplicationPoolIdentity se voit attribuer la qualité de membre de la Users ainsi que le groupe IIS_IUSRS groupe. À première vue, cela peut sembler inquiétant, mais le Users a des droits NTFS quelque peu limités.

Par exemple, si vous essayez de créer un dossier dans le dossier C:\Windows dossier puis vous découvrirez que vous ne pouvez pas. Le site ApplicationPoolIdentity doit encore être capable de lire les fichiers des dossiers du système Windows (sinon, comment le processus de travail pourrait-il charger dynamiquement les DLL essentielles).

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

Vous voyez que la permission spéciale est héritée de c:\ :

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

Dans un environnement partagé où vous avez 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 sites dans un dossier ou un volume qui a reçu le nom de l'application. Users supprimé et les permissions définies de telle sorte que seuls les administrateurs et le compte SYSTEM y aient accès (avec héritage).

Vous devez ensuite attribuer individuellement les autorisations requises à chaque utilisateur. IIS AppPool\[name] doit être placé dans le dossier racine de son site.

Vous devez également veiller à ce que tous les dossiers que vous créez et dans lesquels vous stockez des fichiers ou des données potentiellement sensibles disposent de l'accès à l'Internet. Users groupe supprimé. Vous devez également vous assurer que les applications que vous installez ne stockent pas de données sensibles dans leur fichier c:\program files\[app name] et qu'ils utilisent les dossiers du profil de l'utilisateur à la place.

Donc, oui, à première vue, il semble que la ApplicationPoolIdentity a plus de droits qu'il ne devrait, mais il n'a en fait pas plus de droits que ce que son appartenance à un groupe lui impose.

Un ApplicationPoolIdentity L'appartenance à un groupe peut être examinée à l'aide de l'outil SysInternals Outil Process Explorer . Trouvez le processus de travailleur qui s'exécute avec l'identité du pool d'applications qui vous intéresse (vous devrez ajouter l'attribut User Name à la liste des colonnes à afficher :

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

Comme on peut le voir IIS APPPOOL\900300 est un membre de la Users groupe.

Answer 2

1. Cliquez avec le bouton droit de la souris 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 "Editer..." 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 "Locations..." dans l'écran ci-dessus. Vous verrez quelque chose comme ceci. Maintenant, allez tout en haut de cette arborescence et sélectionnez le nom de votre ordinateur, puis cliquez sur OK.

7. Maintenant, tapez "iis apppool \your_apppool_name "et cliquez sur le bouton "Check Names". Si l'apppool existe, vous verrez le nom de votre apppool dans la zone de texte avec un soulignement. Cliquez sur le bouton OK.

8. Cochez/décochez les accès que vous devez accorder au compte.

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

Answer 3

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

Ce type d'accès au stockage des fichiers est donc automatiquement effectué et vous devriez pouvoir écrire ce que vous voulez dans les dossiers du compte utilisateur des pools d'applications sans rien changer. C'est pourquoi des comptes d'utilisateurs virtuels ont été créés pour chaque pool d'applications.

Answer 4

J'ai essayé de résoudre des problèmes d'accès à un site web IIS, qui se sont manifestés comme suit comme les suivantes dans les journaux d'événements → Windows → Application :

Log Name:      Application
Source:        ASP.NET 4.0.30319.0
Date:          1/5/2012 4:12:33 PM
Event ID:      1314
Task Category: Web Event
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      SALTIIS01

Description:
Event code: 4008 
Event message: File authorization failed for the request. 
Event time: 1/5/2012 4:12:33 PM 
Event time (UTC): 1/6/2012 12:12:33 AM 
Event ID: 349fcb2ec3c24b16a862f6eb9b23dd6c 
Event sequence: 7 
Event occurrence: 3 
Event detail code: 0 

Application information: 
    Application domain: /LM/W3SVC/2/ROOT/Application/SNCDW-19-129702818025409890 
    Trust level: Full 
    Application Virtual Path: /Application/SNCDW 
    Application Path: D:\\Sites\\WCF\\Application\\SNCDW\\ 
    Machine name: SALTIIS01 

Process information: 
    Process ID: 1896 
    Process name: w3wp.exe 
    Account name: iisservice 

Request information: 
    Request URL: http://webservicestest/Application/SNCDW/PC.svc 
    Request path: /Application/SNCDW/PC.svc 
    User host address: 10.60.16.79 
    User: js3228 
    Is authenticated: True 
    Authentication Type: Negotiate 
    Thread account name: iisservice 

En fin de compte, j'ai dû donner à Windows Everyone groupe accès en lecture à ce dossier pour qu'il fonctionne correctement.