Quel rôle joue «App Pool Identity» pour un pool d'applications?

En parlant de sécurité IIS 7.5, AFAIK:

Identité du pool d'applications décide qui exécute mon application Web.

La méthode d'authentification décide à qui les clients sont authentifiés.

J'ai un dossier virtuel configuré comme ceci:

• J'utilise l'authentification anonyme dans l'espoir que tous les clients doivent être authentifiés comme IUSR .
• Je donne à l'IUSR le contrôle total du dossier.
• Mon identité de pool d'applications est définie comme le compte XXX, qui n'a aucune autorisation sur le dossier. (J'ai intentionnellement réglé cela)

Mais il s'avère que je ne peux pas parcourir les fichiers de ce dossier. Une fois que j'ai donné au compte XXX l'autorisation d'accéder à ce dossier, tout se passe bien.

Alors, quel rôle joue l'identité du pool d'applications dans l'authentification anonyme? Il est totalement inattendu que je doive accorder au compte App Pool Identity l'autorisation d'accéder au dossier. Je pensais que l'authentification anonyme serait suffisante?

Merci.

Beaucoup de termes surchargés ici et un changement entre IIS 7 et 7.5.

Identité App Pool vs compte App Pool

Commençons par l'identité du pool d'applications (minuscule I, alias compte du pool d'applications ):

D'après ce que je dis, le compte du pool d'applications est le compte utilisé pour démarrer un pool d'applications et l'identité que le pool d'applications assume lorsqu'il ne se fait passer pour personne d'autre.

Quelle que soit l'identité que vous donnez à l'App Pool, il devra être capable de lire les fichiers dans le dossier de contenu : en particulier {mais sans s'y limiter} tous les fichiers web.config (qui font partie de la configuration IIS et contrôlent ce que le fichier App Pool va faire).

S'il ne peut pas accéder à un dossier, il supposera qu'il pourrait y avoir un fichier web.config important (qui change la donne) et affichera une erreur. Le compte App Pool a donc besoin d'un accès en lecture à tous les dossiers de contenu.

ApplicationPoolIdentity

Pourquoi différencier le compte du pool d'applications (l'identité du pool d'applications) de l'identité du pool d'applications? Parce que ApplicationPoolIdentity utilisé par des majuscules spéciales est un nouveau type de compte - un compte de service géré - introduit et rendu par défaut dans IIS 7.5 / Windows 2008 R2, et disponible à partir de Windows 2008 SP2 également (mais pas par défaut).

Voir Identités du pool d'applications sur IIS.Net

Lorsque vous créez un site Web sous R2 à l'aide de l'interface graphique:

• un pool d'applications sera créé pour héberger ce site Web, et
• le type de compte sera ApplicationPoolIdentity, au lieu de Service réseau (par défaut 2008), Service local ou Système local.

Avec 2008 RTM, le compte de pool d'applications par défaut était Service réseau plus une identité / uniquificateur de pool d'applications unique; le nouveau R2 / SP2 AppPoolIdentity type de compte est un réseau Service- comme compte (c. -à- est l'ordinateur lors de la connexion hors zone), mais l' usurpation d' identité empêche d' une autre piscine App dans le même cadre.

Retour à la question d'origine:

• Le compte du pool d'applications définit qui exécute votre application lorsqu'elle n'emprunte pas l'identité d'une autre personne

• La méthode d'authentification décrit comment vous allez authentifier les clients (afin de les usurper l'identité)

• Le compte d'utilisateur anonyme définit qui vous allez exécuter lors de l'emprunt d'identité d'un utilisateur pour une demande qui n'est pas authentifiée - IUSR est un tel utilisateur.

Soit dit en passant, avec IIS 7.5, vous pouvez définir le compte d'utilisateur anonyme comme l'identité du pool d'applications (propriétés de la méthode d'authentification anonyme), ce qui pourrait faciliter l'isolement et la sécurisation du contenu d'un site Web donné.

Définissez les autorisations à l'aide de IIS AppPool \ YourSiteName pour le format de nom. (voir aussi ce post )

Vous voyez deux choses, qui sont souvent confondues dans ASP.NET:

1. "identité d'utilisateur" - L'authentification d'un compte d'utilisateur n'a rien à voir avec le compte ou l'identité qui s'exécute réellement sous les II et ASP.NET. L'authentification anonyme permet à tout utilisateur d'accéder à tout contenu public sans fournir de nom d'utilisateur et de mot de passe au navigateur client. Le compte IUSR anonyme qui est authentifié par défaut dans IIS applique simplement l'accès au contenu du site Web public. Il n'affecte pas les processus ou les ressources utilisés par les services II ou ASP.NET sous-jacents.
2. "identité d'application" - Il s'agit du compte "WindowsIdentity" réel sur le serveur qui s'exécute réellement derrière IIS et ASP.NET, qui est le compte d'identité du pool d'applications attribué au pool par les II et attribué à ASP.NET. Votre processus ASP.NET s'exécute par défaut sous ce compte d'identité du pool d'applications (appelé compte virtuel dans IIs version 7.5+).

Explication: Tout d'abord, "l'authentification" dans ASP.NET n'est qu'un événement généralement configuré dans le web.config qui connecte un compte d'utilisateur donné qui est transmis en tant que jeton utilisateur par IIs à ASP.NET en tant qu'objet HttpContext ordinaire ... c'est-à-dire la session ou le contexte actuel de l'utilisateur actuel. Il ne modifie pas réellement WindowsIdentity qui exécute le processus ASP.NET, lui transmet simplement un jeton d'ID utilisateur. En utilisant HttpContext, votre code peut utiliser cet identifiant ou ce nom pour stocker les droits de base de données sur diverses sections de votre site Web. Mais cela n'affectera pas l'accès aux fichiers par ASP.NET car il n'affecte ni ne modifie l'identité du compte "processus" d'application réel qui exécute ASP.NET sous IIs.

Cela ne se produit que lorsque vous effectuez "Emprunt d'identité" qui indique à ASP.NET d'usurper l'identité du jeton qui lui est transmis par les II et de s'exécuter ensuite sous cet ID de compte. Vous pouvez définir l'emprunt d'identité dans votre web.config. Lorsque vous activez l'emprunt d'identité dans ASP.NET, WindowsIdentity change sur le processus de travail quel que soit le compte authentifié transmis à ASP.NET à partir d'IIS, et vous pouvez ensuite accéder aux fichiers, en fonction bien sûr des droits que vous attribuez à ce compte d'utilisateur. Il est important de noter que lorsque cela se produit, son ASP.NET temporaire peut revenir à son identité de processus par défaut, qui est dans les versions IIs actuelles, le compte d'identité du pool d'applications attribué à un pool d'applications donné.

Lorsque les II utilisent uniquement le compte d'utilisateur anonyme simple sans authentification explicite définie dans ASP.NET, les II démarrent par défaut le compte d'identité du pool d'applications du pool d'applications affecté au site Web et le transmettent à ASP.NET et au processus de travail qui l'exécute. Ce compte d'identité du pool d'applications traite toutes les demandes d'IIS et exécute ASP.NET pour ce site.

Lorsque IIs démarre sous cette configuration et est accessible par un utilisateur, il authentifie réellement en arrière-plan par défaut le compte IUSR anonyme qui détermine l'accès aux pages Web et autres ressources de base. Mais ce compte n'est PAS transmis à ASP.NET. Et cela n'affecte pas les exécutions d'IIS d'identité du pool d'applications et sous lesquelles ASP.NET s'exécute.

Si vous définissez Impersonate sur "true" dans, par exemple, votre web.config, ET que vous utilisez le compte IUSR anonyme par défaut dans IIs pour l'accès public, ET que vous définissez explicitement sur true la propriété anonymousAuthentication dans le web.config (au lieu d'utiliser Windows ou autre compte de connexion), les II jetteront l'identité du pool d'applications et les II et ASP.NET exécuteront désormais leurs processus d'application en tant que compte anonyme et authentifié IUSR.

Lorsque vous faites cela, ASP.NET et ses processus s'exécuteront désormais sous le compte IUSR .... c'est-à-dire que le processus des applications d'ASP.NET exécutera son compte WindowsIdentity en tant que compte IUSR. Vous pouvez maintenant appliquer un accès en lecture / écriture à ce compte IUSR anonyme et aux dossiers auxquels vous souhaitez que ce compte accède. (Remarque: assurez-vous toutefois d'ajouter le compte de processus par défaut, le compte Pool d'applications pour le pool, les droits également sur ces dossiers. Cela est conforme à la recommandation de Microsoft)

Bonne chance!

Il y a deux contextes d'authentification en jeu. Le processus du serveur Web (qui gère vos demandes Web) s'exécute en tant qu'utilisateur App Pool Identity. Lorsqu'une demande arrive pour votre hôte virtuel, le pool d'applications emprunte l'identité de l'utilisateur répertorié dans les "Informations d'authentification anonyme" du site spécifique - par défaut IUSR.

Tous les scripts exécutés à partir de votre site Web s'exécuteront comme IUSR, mais la journalisation et certaines autres fonctions seront exécutées en tant qu'utilisateur du pool d'applications (par défaut, Service réseau - bien que cela ait été modifié récemment pour utiliser un utilisateur spécial du pool d'applications virtuelles). L'identité du pool d'applications (service réseau) doit pouvoir répertorier les fichiers dans votre répertoire car certaines vérifications sont effectuées dans la pile de demandes avant que le contrôle ne soit transféré à votre script.

Il est recommandé d'exécuter un site par pool et de définir l'identité du pool d'applications pour qu'elle s'exécute avec le même utilisateur que l'utilisateur anonyme de votre site Web. Il est possible de sortir du contexte de l'utilisateur anonyme (IUSR) et d'élever les privilèges à ceux de l'identité du pool d'applications lui-même.