Identité du processus et de la demande dans ASP.NET

Traductions disponibles Traductions disponibles
Numéro d'article: 317012 - Voir les produits auxquels s'applique cet article
Cet article peut contenir des liens vers des informations en langue anglaise (pas encore traduites).
Agrandir tout | Réduire tout

Sommaire

Résumé

Cet article présente les droits d'accès qui sont accordés au compte de processus par défaut et décrit des situations dans lesquelles ces droits peuvent être trop restrictifs pour certaines tâches.

Dans l'installation par défaut d'ASP.NET sur Microsoft Windows 2000 et Microsoft Windows XP, ASP.NET exécute le code d'application Web dans un processus de traitement. L'identité de ce processus utilise par défaut un compte local appelé compte ASPNET (son nom complet est le compte aspnet_wp). Dans les versions bêtas d'ASP.NET, l'identité du processus est System, qui est un compte administratif puissant incluant de nombreux droits d'accès sur l'ordinateur. Pour fournir une installation par défaut offrant moins de privilèges, la version commerciale d'ASP.NET utilise un compte ASPNET plus faible qui convient à la plupart des applications Web.

Remarque Par défaut, si vous utilisez Microsoft Internet Information Services (IIS) 6.0, vos applications Web ASP.NET s'exécuteront dans le contexte de sécurité du compte NetworkService.

Plus d'informations

Configuration de l'identité de processus

Vous pouvez configurer l'identité de processus dans la section <processModel> du fichier Machine.config, dans le sous-répertoire Config du répertoire racine d'installation. Les attributs userName et password commandent l'identité du processus. Les valeurs par défaut pour ces domaines sont les suivantes :
<processModel  userName="machine" password="AutoGenerate" />
				
Les valeurs machine et AutoGenerate instruisent ASP.NET d'utiliser le compte ASPNET intégré ainsi qu'un mot de passe aléatoire à cryptage fort qui est stocké dans l'autorité de sécurité locale (LSA) pour ce compte.

Pour utiliser un processus qui possède davantage de droits d'accès, vous pouvez définir l'attribut userName sur System, ce qui entraîne l'exécution du processus de traitement ASP.NET avec la même identité que le processus Inetinfo.exe. Le processus Inetinfo.exe s'exécute par défaut avec l'identité System. Lors de la configuration du processus de traitement ASP.NET en vue d'utiliser l'identité System, le processus de traitement ASP.NET peut accéder à pratiquement toutes les ressources sur l'ordinateur local. Sur des ordinateurs qui exécutent Windows 2000 ou Windows XP, le compte System possède également des informations d'identification réseau et peut accéder aux ressources du réseau en tant que compte d'ordinateur. Pour configurer le processus à exécuter en tant qu'identité System, modifiez l'attribut userName dans la section <processModel> comme suit :
<processModel  userName="SYSTEM" password="AutoGenerate" />
				

Autorisations par défaut pour le compte ASPNET

Le compte ASPNET est créé en tant que compte local lorsque vous installez ASP.NET. Le compte ASPNET appartient uniquement au groupe Utilisateurs sur cet ordinateur. C'est pourquoi, le compte ASPNET possède tous les droits associés au groupe Utilisateurs et peut accéder à toutes les ressources auxquelles le groupe Utilisateurs a accès. Le compte ASPNET hérite des droits d'utilisateur suivants du groupe Utilisateurs :
  • SeChangeNotifyPrivilege
  • SeUndockPrivilege
  • SeInteractiveLogonRight
  • SeNetworkLogonRight
En outre, les droits suivants sont également accordés par défaut au compte ASPNET :
  • SeServiceLogonRight
  • SeBatchLogonRight
  • SeDenyInteractiveLogonRight
ASP.NET accorde des autorisations d'accès intégral spécifiques au compte ASPNET pour les dossiers suivants :
  • Fichiers temporaires ASP.NET
  • %windir%\temp
Par ailleurs, ASP.NET accorde une autorisation de lecture sur le répertoire d'installation Microsoft .NET Framework.

La liste suivante met en évidence les listes de contrôle d'accès (ACL) nécessaires pour le compte ASPNET. Les installations par défaut de Windows 2000 et Microsoft .NET Framework comprennent ces ACL.
  • Emplacement : %installroot%\ASP.NET Temporary Files
    Type d'accès : lecture/écriture sur le dossier et Affichage du contenu du dossier sur le dossier racine du pilote
    Compte : compte de processus et comptes d'emprunt d'identité configurés
    Description : il s'agit de l'emplacement de la compilation dynamique ASP.NET. Sous cet emplacement, un code d'application est généré dans un répertoire discret pour chaque application. Vous pouvez utiliser l'attribut tempDir dans la section <compilation> pour configurer l'emplacement racine.

    Remarque Si vous modifiez le fichier machine.config pour enregistrer les fichiers temporaires ASP.NET dans un emplacement différent, le compte ASPNET doit disposer d'un accès de type Affichage du contenu du dossier sur la racine du lecteur.
  • Emplacement : %windir%\temp
    Type d'accès : lecture/écriture
    Compte : compte de processus
    Description : il s'agit de l'emplacement utilisé par les services Web XML (Extensible Markup Language) pour générer des proxies de sérialisation.
  • Emplacement : annuaire d'applications
    Type d'accès : lecture
    Compte : compte de processus et comptes d'emprunt d'identité configurés
    Description : il s'agit de l'emplacement du contenu application (seul un accès en lecture est nécessaire).
    Pour plus d'informations, reportez-vous au site Web de Microsoft à l'adresse suivante (en anglais) :
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT01.asp
  • Emplacement : racine du site Web (%systemdrive%\inetpub\wwwroot ou le chemin d'accès vers lequel pointe le site Web par défaut)
    Type d'accès : lecture
    Compte : compte de processus et comptes d'emprunt d'identité configurés
    Description : ASP.NET essaie de lire les fichiers de configuration et les modifications de surveillance sur Lecteur:\inetpub\wwwroot\web.config.
  • Emplacement : hiérarchie %installroot%
    Type d'accès : lecture
    Compte : compte de processus et comptes d'emprunt d'identité configurés
    Description : ASP.NET doit être capable d'accéder aux assemblys .NET Framework dans le fichier Machine.config (dans le sous-répertoire \Config sous %installroot%).
  • Emplacement : %windir%\assembly
    Type d'accès : lecture
    Compte : compte de processus et comptes d'emprunt d'identité configurés
    Description : il s'agit du Global Assembly Cache qui contient les assemblys partagés.
Pour plus d'informations sur les ACL par défaut des ordinateurs Windows 2000, reportez-vous à la référence "Paramètres de contrôle d'accès par défaut de Windows 2000" dans la section RÉFÉRENCES.

Remarque Par défaut, le compte ASPNET n'a en général pas les droits d'accès corrects pour effectuer une partie des tâches décrites dans cet article.

Accès aux ressources

Les sections suivantes décrivent comment utiliser différentes ressources. Vous pouvez accéder localement à nombre d'entre elles si vous activez l'emprunt d'identité et si vous accordez au compte avec emprunt d'identité un accès aux ressources. Toutefois, il est fréquent que l'emprunt d'identité ne fonctionne pas lorsque vous essayez d'accéder à des ressources distantes, à moins que l'application utilise un mécanisme d'authentification qui peut être délégué, tel que l'authentification Kerberos ou Basic. Vous pouvez utiliser également des services COM+ pour accéder à des ressources, ce qui est décrit dans la section Exécution de code avec une identité fixe.

Utilisation des ressources de fichiers

Pour autoriser une application qui s'exécute avec le compte ASPNET à écrire dans des fichiers, vous pouvez emprunter l'identité d'un utilisateur spécifique dans du code avant d'écrire dans les fichiers ou vous pouvez accorder des autorisations d'écriture au compte ASPNET. Vous pouvez accorder des autorisations d'écriture pour un fichier individuel ou pour des hiérarchies de répertoires.

Important Lorsque vous accordez des autorisations d'écriture pour un fichier individuel ou pour des hiérarchies de répertoires au compte ASPNET, toutes les applications Web ASP. NET qui s'exécutent sous le compte ASPNET sur le serveur sont également en mesure d'écrire dans ce fichier ou dans les hiérarchies de répertoires. Pour plus d'informations sur l'emprunt d'identité d'un utilisateur spécifique dans du code, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft.
306158 Comment faire pour implémenter l'emprunt d'identité dans une application ASP.NET
Pour modifier la liste de contrôle d'accès d'un fichier, procédez comme suit :
  1. Ouvrez l'Explorateur Windows.
  2. Sélectionnez le fichier ou le dossier dont vous souhaitez modifier les autorisations.
  3. Dans le menu Fichier, cliquez sur Propriétés.
  4. Cliquez sur l'onglet Sécurité. Activez les cases à cocher correspondant aux autorisations ACL.
Vous pouvez également utiliser un script ou l'outil de ligne de commande Cacls.exe (qui est inclus dans Windows) pour modifier l'ACL d'un fichier.

ASP.NET 1.1 utilise le dossier <Nom_Lecteur>\Documents and Settings\<Nom_Ordinateur>\ASPNET pour stocker les fichiers de processus (où <Nom_Lecteur> est le lecteur de votre ordinateur sur lequel ASP.NET est installé et <Nom_Ordinateur> est le nom de votre ordinateur).

Activation de l'emprunt d'identité

Avec l'emprunt d'identité, l'application s'exécute dans le contexte de sécurité de l'entité de demande, soit en tant qu'utilisateur authentifié, soit en tant qu'utilisateur anonyme. Dans ASP.NET, l'emprunt d'identité est facultatif et n'est pas activé par défaut. Pour activer l'emprunt d'identité au niveau de l'ordinateur ou de l'application, ajoutez la directive de configuration suivante dans la section <system.web> du fichier Machine.config ou Web.config :
<identity impersonate="true"/>
				

Utilisation de bases de données

Les applications qui utilisent l'authentification SQL pour se connecter à une base de données ne sont en général pas affectées par le passage au compte ASPNET. Cela concerne également les applications qui utilisent une authentification et un emprunt d'identité intégrés. Toutefois, si une application n'emprunte pas l'identité et utilise l'authentification Windows, vous devez accorder au compte ASPNET l'accès à la base de données.

Vous ne pouvez pas utiliser le compte ASPNET lorsque vous essayez de vous authentifier sur Microsoft SQL Server à l'aide de l'authentification Windows intégrée sur des canaux nommés. Toutefois, vous pouvez utiliser le compte ASPNET avec l'authentification Windows intégrée sur le transport TCP (Transmission Control Protocol).

Si une application doit utiliser une base de données Microsoft Access, le compte ASPNET doit être en mesure d'écrire dans le fichier de base de données. Les administrateurs doivent ajuster les autorisations de fichiers en conséquence.

Utilisation du journal des événements

Les applications qui doivent écrire dans le journal des événements d'application peuvent le faire pendant qu'elles s'exécutent sous le compte ASPNET. Si une application doit créer une nouvelle catégorie de journal des événements, elle doit créer une clé de Registre sous la ruche de Registre HKEY_LOCAL_MACHINE, ce que le compte ASPNET ne peut pas faire.

Pour créer la catégorie lors de l'exécution, vous devez activer l'emprunt d'identité, puis emprunter l'identité d'un compte qui possède davantage de droits d'accès. Un administrateur peut également créer la catégorie, et l'application écrire dans la catégorie lors de l'exécution.

Si des applications doivent créer de nouvelles catégories de journaux des événements, créez-les lors de l'installation. Une fois la catégorie créée, le compte ASPNET peut écrire dans le journal des événements Application.

Utilisation de System.DirectoryServices et Active Directory

Pour accéder à Active Directory, une application Web peut utiliser l'emprunt d'identité dans un environnement qui prend en charge la délégation. Elle peut également fournir des informations d'authentification explicites au constructeur de DirectoryEntry dans l'espace de noms System.DirectoryServices pour accéder à Active Directory. Si l'application utilise des informations d'authentification explicites, celles-ci doivent être stockées de manière appropriée à l'aide d'une technique telle que les chaînes de construction COM+ ou les interfaces de programmation d'applications (API) de protection des données Windows.

Utilisation de compteurs de performance

Le compte ASPNET possède des autorisations suffisantes pour écrire (mais pas pour lire) des données de compteurs de performances. Si l'application doit lire les données du compteur de performance ou créer des catégories de compteurs de performances, les autorisations Administrateur ou Utilisateur avec pouvoir sont nécessaires.

Si une application doit créer de nouvelles catégories de compteurs de performances, créez-les lors de l'installation. Une fois les catégories créées, le compte ASPNET peut écrire dans les compteurs.

Vous pouvez toujours utiliser l'outil Analyseur de performances (Perfmon.exe) pour surveiller les compteurs de performances ASP.NET lors de l'utilisation du compte ASPNET.

Dans Windows 2000, procédez comme suit :
  1. Exécutez l'Éditeur du Registre.
  2. Localisez la clé de Registre suivante :
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ASP.NET_1.1.4322\Names
  3. Cliquez sur l'onglet Sécurité.
  4. Ajoutez l'identité du processus de travail avec les autorisations suivantes :
    • Retrouver la valeur
    • Définir la valeur
    • Créer une sous-clé
    • Énumérer les sous-clés
    • Avertir d'un Contrôle en lecture
Dans Windows Server 2003, ajoutez l'identité au groupe IIS_WPG.

Démarrage de serveurs COM out-of-process

Les applications qui doivent démarrer des serveurs COM out-of-process pendant qu'elles s'exécutent sous le compte ASPNET peuvent accorder de manière spécifique des autorisations de démarrage au compte au moyen de l'outil Dcomcnfg.exe.

Débogage des problèmes

Par défaut, vous ne pouvez pas effectuer de pas à pas détaillé dans un appel de service Web XML à partir d'une application cliente. Pour entrer dans les services Web XML, vous devez ajouter le compte ASPNET au groupe Utilisateurs du débogueur sur l'ordinateur sur lequel le service Web XML s'exécute.

Exécution de code avec une identité fixe

Dans les services COM+, vous pouvez exécuter du code avec une identité fixe. Vous pouvez utiliser la classe ServicedComponent de l'espace de noms System.EnterpriseServices pour écrire des composants de code gérés qui utilisent des services COM+. Vous pouvez renvoyer à la ligne une fonctionnalité privilégiée dans une classe dérivée de ServicedComponent, puis exécuter cette classe en tant qu'application serveur COM+ avec une identité configurée.

Compilation de fichiers code-behind sur des partages UNC

Dans ASP.NET, vous pouvez appliquer plusieurs méthodes pour développer des fichiers d'applications :
  • Vous pouvez utiliser le langage HTML (Hypertext Markup Language) dans un fichier .aspx, puis stocker le code de la page dans un assembly précompilé du répertoire Corbeille. Il s'agit du modèle Microsoft Visual Studio .NET.
  • Vous pouvez créer un package des code et contenu HTML dans un fichier source unique compilé à la demande.
  • Vous pouvez placer la présentation HTML dans un fichier ASP.NET, puis compiler dynamiquement tout code source associé à ce fichier à l'aide d'un attribut src dans la directive <%@ Assembly %>.
Remarque Si le contenu d'application se trouve sur un partage réseau, le compilateur démarre dans le compte ASPNET et ne dispose pas des informations d'identification réseau nécessaires pour accéder au fichier. Si vous utilisez des partages réseau, vous ne pouvez pas utiliser l'attribut src pour pointer sur un fichier. Vous devez plutôt utiliser l'une des autres méthodes.

Utilisation d'ASP.NET sur un contrôleur de domaine principal ou secondaire


Par défaut, si vous utilisez ASP.NET 1.1 sur un contrôleur de domaine, vos applications Web ASP.NET s'exécuteront dans le contexte de sécurité du compte IWAM_<Nom_Ordinateur> (où <Nom_Ordinateur> est le nom de votre ordinateur).

Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
315158 CORRECTIF : ASP.NET ne fonctionne pas avec le compte ASPNET par défaut sur un contrôleur de domaine
Retour au début

Lecture de la base de données IIS

Le compte ASPNET ne peut pas lire la métabase Microsoft Internet Information Services (IIS). Si une application doit accéder aux paramètres de la métabase, vous pouvez accorder de manière sélective l'accès aux noeuds de la base de données à l'aide de l'utilitaire Metaacl.exe.

Si une application doit utiliser des fichiers .disco, qui dépendent de la capacité à lire la métabase IIS pour fournir des services de découverte, vous devez accorder un accès en lecture à la métabase pour le compte ASPNET.

Utilisation de System.Management et WMI

WMI (Windows Management Instrumentation) est une puissante fonctionnalité administrative que vous pouvez utiliser pour gérer et surveiller des ordinateurs Windows. Toutefois, lorsque des applications ASP.NET s'exécutent sous le compte ASPNET, ce compte possède seulement les mêmes autorisations d'accès par défaut que Tout le monde. Ces autorisations comprennent la lecture de données WMI, l'écriture des données du fournisseur et l'exécution des méthodes des fournisseurs sur l'ordinateur local. Vous trouverez plus d'informations sur les mécanismes de sécurité WMI dans la documentation du Kit de développement de la plateforme WMI ou sur MSDN.

Remarque Sur Windows 2000 sans le Service Pack 3 (SP3) ou version ultérieure ou sur Windows XP sans le Service Pack 1 (SP1) ou version ultérieure, les applications Web ASP.NET qui s'exécutent sous le compte ASPNET peuvent ne pas fonctionner et vous pouvez recevoir un message d'erreur « Accès refusé (0x80041003) ». Cela se produit car le compte ne possède pas de privilèges suffisants pour accéder à certains noms d'espaces WMI. Pour résoudre ce problème, installez Service Pack 1 Windows XP ou version ultérieure ou Service Pack 3 Windows 2000 ou version ultérieure. Pour contourner ce problème, procédez comme suit :
  1. Ouvrez le composant logiciel enfichable MMC (Microsoft Management Console).
  2. Développez Services et applications, puis sélectionnez Contrôle WMI.
  3. Cliquez avec le bouton droit sur Contrôle WMI, puis cliquez sur Propriétés.
  4. Dans la boîte de dialogue Propriétés de Contrôle WMI, cliquez sur l'onglet Sécurité.
  5. Développez Root, sélectionnez CIMV2, puis cliquez sur Sécurité.
  6. Dans la boîte de dialogue Sécurité, cliquez sur Paramètres avancés.
  7. Dans la boîte de dialogue Paramètres de sécurité avancée, cliquez sur Ajouter. Sélectionnez nom_machine_locale\ASPNET, puis cliquez sur OK.
  8. Dans la boîte de dialogue Entrée d'autorisation, assurez-vous que Appliquer à est défini sur Cet espace de noms et les sous-espaces de noms.
  9. Assurez-vous que les cases à cocher Autoriser 'Activer le compte' et Autoriser 'Appel à distance autorisé' sont activées.
  10. Cliquez sur OK dans chaque boîte de dialogue jusqu'à ce que soyez de retour dans la boîte de dialogue Propriétés de Contrôle WMI.
  11. Répétez les étapes 5 à 10 pour les autres noms d'espaces WMI auxquels votre application accédera.
  12. Redémarrez IIS. Pour cela, exécutez IISRESET depuis la ligne de commande.
Par défaut, ASP.NET génère un mot de passe à cryptage fort pour le compte ASPNET. C'est pourquoi, ce contournement est sûr, à condition que le mot de passe du compte ASPNET ne soit pas partagé entre ordinateurs ou rétabli à une valeur différente de sa valeur par défaut.

Interactivité avec le Bureau

Lorsque les services IIS sont configurés de façon à autoriser l'interaction avec le Bureau, le compte ASPNET ne dispose pas des droits corrects pour accéder au Bureau à cause des listes de contrôle d'accès discrétionnaire (DACL, Discretionary Access Control Lists) sur le Bureau et la station windows par défaut. Les administrateurs peuvent modifier ces contrôles d'accès discrétionnaires, ou vous pouvez exécuter le processus avec un compte qui possède l'autorisation d'accéder à ces objets.

Désinstallation d'ASP.NET

Lors de la désinstallation d'ASP.NET, le compte ASPNET est désactivé et reste sur le système. Vous pouvez supprimer le compte ASPNET si vous ne prévoyez pas de réinstaller ASP.NET.

Si vous réinstallez ASP.NET après avoir explicitement supprimé le compte ASPNET, un nouveau compte ASPNET est créé avec un nouvel identificateur de sécurité (SID). Toute ACL qui faisait référence au précédent compte ASPNET ne s'applique désormais plus au nouveau compte ASPNET.

Références

Pour plus d'informations sur les listes de contrôle d'accès par défaut de Windows 2000, reportez-vous au Livre blanc Microsoft suivant (en anglais) :
http://www.microsoft.com/windows2000/docs/SecDefs.doc
Pour plus d'informations, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
329290 Comment faire pour utiliser l'utilitaire ASP.NET pour chiffrer des chaînes d'identification et de connexion pour l'état de la session
315158 CORRECTIF : ASP.NET ne fonctionne pas avec le compte ASPNET par défaut sur un contrôleur de domaine

Propriétés

Numéro d'article: 317012 - Dernière mise à jour: mardi 8 novembre 2005 - Version: 12.3
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
Mots-clés : 
kbconfig kbhttpruntime kbinfo kbsecurity KB317012
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com