Quels sont tous les comptes d'utilisateur pour IIS/ASP.NET et comment diffèrent-ils ?

Question

Sous Windows Server 2008 avec ASP.NET 4.0 installé, il y a toute une série de comptes d'utilisateurs associés, et je n'arrive pas à comprendre lequel est lequel, comment ils diffèrent, et lequel est VRAIMENT celui sous lequel mon application fonctionne. Voici une liste :

• IIS_IUSRS
• IUSR
• DefaultAppPool
• ASP.NET v4.0
• SERVICE_RÉSEAU
• SERVICE LOCAL.

Qu'est-ce qui est quoi ?

Answer 1

C'est une très bonne question et malheureusement, de nombreux développeurs ne posent pas assez de questions sur la sécurité de IIS/ASP.NET dans le contexte d'un développeur web et de la mise en place de IIS. Voici donc....

Pour couvrir les identités énumérées :

IIS_IUSRS:

Ceci est analogue à l'ancien IIS6 IIS_WPG groupe. Il s'agit d'un groupe intégré dont la sécurité est configurée de telle sorte que tout membre de ce groupe peut agir en tant qu'identité de pool d'applications.

IUSR:

Ce compte est analogue à l'ancien IUSR_<MACHINE_NAME> le compte local qui était l'utilisateur anonyme par défaut pour les sites Web IIS5 et IIS6 (c'est-à-dire celui configuré via l'onglet Sécurité du répertoire des propriétés d'un site).

Pour plus d'informations sur IIS_IUSRS et IUSR voir :

Comprendre les comptes d'utilisateurs et de groupes intégrés dans IIS 7

DefaultAppPool:

Si un pool d'applications est configuré pour fonctionner à l'aide de la fonction d'identité de pool d'applications, un compte "synthétisé" appelé IIS AppPool\<pool name> sera créé à la volée pour être utilisé comme identité du pool. Dans ce cas, il y aura un compte synthétisé appelé IIS AppPool\DefaultAppPool créé pour la durée de vie du pool. Si vous supprimez le pool, ce compte n'existera plus. Lorsque vous appliquez des autorisations à des fichiers et des dossiers, ceux-ci doivent être ajoutés à l'aide de la commande IIS AppPool\<pool name> . Vous ne verrez pas non plus ces comptes de pool dans le Gestionnaire des utilisateurs de votre ordinateur. Pour plus d'informations, voir ce qui suit :

Identités des pools d'applications

ASP.NET v4.0: -

Il s'agit de l'identité du pool d'applications pour le pool d'applications ASP.NET v4.0. Voir DefaultAppPool ci-dessus.

NETWORK SERVICE: -

Le site NETWORK SERVICE est une identité intégrée introduite dans Windows 2003. NETWORK SERVICE est un compte à faible privilège sous lequel vous pouvez exécuter vos pools d'applications et vos sites Web. Un site Web exécuté dans un pool Windows 2003 peut toujours usurper l'identité du compte anonyme du site (IUSR_ ou ce que vous avez configuré comme identité anonyme).

Dans ASP.NET antérieur à Windows 2008, vous pouviez faire en sorte qu'ASP.NET exécute les requêtes sous le compte du pool d'applications (habituellement NETWORK SERVICE ). Vous pouvez également configurer ASP.NET pour qu'il se fasse passer pour le compte anonyme du site via la fonction <identity impersonate="true" /> à l'intérieur web.config localement (si ce paramètre est verrouillé, cela doit être fait par un administrateur dans l'espace de travail de l'entreprise). machine.config ).

Réglage de <identity impersonate="true"> est courant dans les environnements d'hébergement partagé où des pools d'applications partagés sont utilisés (en conjonction avec des paramètres de confiance partielle pour empêcher le déblocage du compte usurpé).

Dans IIS7.x/ASP.NET, le contrôle de l'impersonnalisation est désormais configuré via la fonction de configuration de l'authentification d'un site. Vous pouvez donc configurer l'exécution en tant qu'identité de pool, IUSR ou un compte anonyme personnalisé spécifique.

LOCAL SERVICE:

Le site LOCAL SERVICE est un compte intégré utilisé par le gestionnaire de contrôle des services. Il dispose d'un ensemble minimal de privilèges sur l'ordinateur local. Il a un champ d'utilisation assez limité :

Compte LocalService

LOCAL SYSTEM:

Vous n'avez pas posé de question à ce sujet, mais je l'ajoute par souci d'exhaustivité. Il s'agit d'un compte local intégré. Il possède des privilèges et une confiance assez étendus. Vous ne devriez jamais configurer un site Web ou un pool d'applications pour qu'il fonctionne sous cette identité.

Compte LocalSystem

En pratique :

Dans la pratique, l'approche préférée pour sécuriser un site web (si le site obtient son propre pool d'applications - ce qui est le cas par défaut pour un nouveau site dans la MMC d'IIS7) est d'exécuter sous Application Pool Identity . Cela signifie que l'identité du site dans les paramètres avancés de son pool d'applications doit être définie comme suit Application Pool Identity :

Dans le site Web, vous devez ensuite configurer la fonction d'authentification :

Cliquez à droite et modifiez l'entrée Authentification anonyme :

Veiller à ce que "Identité du pool d'applications" est sélectionné :

Au moment d'appliquer les autorisations de fichiers et de dossiers, vous accordez à l'identité du pool d'applications les droits nécessaires. Par exemple, si vous accordez l'identité du pool d'applications pour l'application ASP.NET v4.0 vous pouvez le faire via l'explorateur :

Cliquez sur le bouton "Vérifier les noms" :

Ou vous pouvez le faire en utilisant le ICACLS.EXE utilitaire :

icacls c:\\wwwroot\\mysite /grant "IIS AppPool\\ASP.NET v4.0":(CI)(OI)(M)

...ou...si le pool d'applications de votre site s'appelle BobsCatPicBlog alors :

icacls c:\\wwwroot\\mysite /grant "IIS AppPool\\BobsCatPicBlog":(CI)(OI)(M)

J'espère que cela aidera à clarifier les choses.

Mise à jour :

Je viens de tomber sur cette excellente réponse datant de 2009, qui contient un grand nombre d'informations utiles et qui vaut la peine d'être lue :

Quelle est la différence entre le compte "Système local" et le compte "Service réseau" ?