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

395

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.

— rsbarro
source

403

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:

entrez la description de l'image ici

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

entrez la description de l'image ici

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:

entrez la description de l'image ici

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:

entrez la description de l'image ici

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

— Kev
source

@Kev [+1] J'ai posté une question similaire concernant les autorisations NTFS pour les identités de pool d'applications ici: stackoverflow.com/questions/11232675/… - Je vous serais reconnaissant de bien vouloir jeter un œil.

— one.beat.consumer

@ one.beat.consumer - désolé, je n'ai jamais vu votre commentaire. Vous êtes toujours coincé avec cette question?

— Kev

@Kev - oui, c'est devenu moins un problème car j'ai été mis de côté pour d'autres conneries, mais ce n'est toujours pas résolu. Des pensées?

— one.beat.consumer

7

Votons pour que cette section soit incluse sur MSDN. Je n'ai jamais pris le temps de comprendre cela, c'est donc d'une grande aide (et j'ai honte de ne jamais le savoir).

— Grimace of Despair

67

On ne sait pas pourquoi cette documentation principale de Microsoft IIS est sur SO au lieu de MSDN.

— Amit Naidu

40

Faites un clic droit sur le dossier.
Cliquez sur Propriétés
Cliquez sur l'onglet Sécurité. Vous verrez quelque chose comme ceci:

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

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

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.

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.

Cochez / décochez tout accès dont vous avez besoin pour accorder au compte
Cliquez sur le bouton Appliquer, puis sur OK.

— fluidguid
source

0

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.

— Stokely
source

Cela ne se produit que si "Charger le profil utilisateur" est défini sur True.

— JamesQMurphy

C'est vrai, ce qui signifie que le dossier de l'utilisateur AppPool ne serait pas créé s'il n'était pas vrai, n'est-ce pas? C'est pourquoi ils l'ont construit de cette façon ... pour empêcher les II d'accéder et de stocker les fichiers indésirables dans windows / temp et partout sur le disque dur au lieu d'un dossier sécurisé géré juste pour ce compte.

— Stokely

0

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.

— SharpC
source