Résolution des problèmes courants liés aux autorisations et à la sécurité dans ASP.NET

Cet article explique comment résoudre les problèmes courants liés aux autorisations et à la sécurité dans ASP.NET.

              Version d’origine du produit : ASP.NET
Numéro de la base de connaissances d’origine : 910449

Outils utiles

Avant de tenter de résoudre un problème, vous devez vous familiariser avec quelques outils, qui vous aideront à limiter le problème. Dans notre cas, nous serions intéressés par des outils tels que FileMon, RegMon et l’audit de sécurité. Pour plus d’informations sur FileMon, consultez FileMon pour Windows v7.04.

Pour plus d’informations sur RegMon, consultez Windows Sysinternals.

Descendre dans la hiérarchie pour isoler le problème

• L’application a-t-elle déjà fonctionné ? Si oui, qu’est-ce qui a changé qui aurait pu interrompre l’application ? Il est possible que des mises à jour logicielles ou des mises à jour de sécurité aient été appliquées sur le serveur. Un déploiement de code peut également avoir provoqué le problème.
• Les pages .html et .asp simples sont-elles servies à partir d’IIS ?
• L’application a-t-elle été migrée vers une autre version d’IIS ?
• D’autres applications ASP.NET sur le serveur échouent-elles avec la même erreur ? S’agit-il de la seule application qui échoue ?
• Le problème se produit-il pour tous les utilisateurs ou uniquement pour des utilisateurs spécifiques ?
• Le problème est-il reproductible lors de la navigation locale sur le serveur web, ou est-il reproductible pour seulement quelques clients ?
• Si vous utilisez l’emprunt d’identité, l’utilisateur emprunt d’identité dispose-t-il de l’accès nécessaire à la ressource ?

Les questions ci-dessus sont utiles pour diagnostiquer un problème. Si vous publiez votre problème sur l’un des forums ASP.NET et si vous avez déjà les réponses à la plupart de ces questions, il est probable que vous obteniez un pointeur rapide ou une solution à votre problème. La clé consiste à publier l’ensemble de l’erreur de trace de pile ASP.NET, le cas échéant, au lieu de dire « J’obtiens une erreur Accès refusé lors de la tentative d’exécution de mon application ASP.NET. Quelqu’un peut-il vous aider ? Il est beaucoup plus facile pour quelqu’un d’examiner la trace de la pile et de vous donner des pointeurs lorsqu’il peut voir un message d’erreur complet. Vous devez donc vous poser la question...

Quel est le message d’erreur exact ?

La première question que nous posons aux clients est « Quel est le message d’erreur exact ? » Si vous avez une description claire du message d’erreur levée par Microsoft .NET Framework, vous pouvez ignorer cette section. Si votre application masque le message d’erreur réel et vous donne un message d’erreur convivial à la place, tel que « Une erreur inattendue s’est produite. Contactez l’administrateur du site web pour plus d’informations », ce n’est d’une grande utilité pour personne. Voici quelques étapes qui vous aideront à obtenir le message d’erreur réel.

• Recherchez et ouvrez le fichier Web.config dans le répertoire de l’application et remplacez customErrors par mode="Off ». Enregistrez le fichier et reproduisez le problème.

• Il est toujours impossible de voir le message d’erreur réel après avoir suivi l’étape ci-dessus en raison de la gestion personnalisée des événements/erreurs effectuée par le développeur de l’application. Vous pouvez essayer de localiser l’événement Application_Error dans le fichier Global.asax et commenter tout code qui utilise la Server.Transfer("Errors.aspx") fonction pour accéder à une page d’erreur personnalisée.

  //Global.asax 
  void Application_Error(object sender, EventArgs e) 
  { 
      // Code that runs when an unhandled error occurs 
      //Server.Transfer("Errors.aspx"); 
  }
  

Une fois que vous avez obtenu le message d’erreur réel, lisez-le pour déterminer si l’erreur est due à des autorisations manquantes sur une ressource locale ou sur une ressource distante à laquelle votre application ASP.NET tente d’accéder.

Le problème se produit en raison d’autorisations manquantes sur une ressource locale à laquelle l’application ASP.NET tente d’accéder

Si vous ne parvenez pas à obtenir une description claire du problème en raison d’un message d’erreur personnalisé, exécutez FileMon et reproduisez le problème. Arrêtez et enregistrez la capture en tant que FileMon.xls et ouvrez le fichier dans Microsoft Excel. Dans le menu Données , cliquez sur Filtrer, puis sur Filtre automatique pour utiliser les fonctionnalités de filtrage d’Excel. Sélectionnez maintenant la liste déroulante dans la colonne F et recherchez les erreurs « ACCÈS REFUSÉ ».

Un exemple de sortie FileMon est illustré ci-dessous.

10381 1:01:11 PM w3wp.exe:2320 OPEN C:\winnt\microsoft.net\framework\v1.1.4322\Temporary ASP.NET Files\sessiontest\8832e585\275ec327\global.asax.xml 
ACCESS DENIED NT 
AUTHORITY\NETWORK SERVICE

Comme vous pouvez le voir dans les résultats filtrés, nous avons réduit la cause du problème. FileMon indique que le compte NT AUTHORITY\NETWORK SERVICE ne dispose pas d’autorisations NTFS sur le C:\Winnt\Microsoft.net\Framework\v1.1.4322\Temporary ASP.NET Files dossier. Cela devrait être simple à corriger.

La plupart des gens ont tendance à réinstaller Microsoft .NET Framework ou même à réinstaller le système d’exploitation. Il ne s’agit pas d’une étape de dépannage recommandée et ne garantit pas que le problème ne se reproduise pas. Je vais vous donner un exemple. Les problèmes intermittents sont souvent difficiles à isoler et à résoudre. Dans ce scénario, l’application du client fonctionne correctement pendant quelques heures, puis tout à coup, elle échoue avec l’erreur ci-dessous. Le client avait déjà essayé de réinstaller le .NET Framework ainsi que le système d’exploitation. Cela semblait résoudre le problème pendant quelques jours, mais il est ensuite réapparu.

L’exécution de FileMon n’a pas affiché d’erreur ACCÈS REFUSÉ . Toutes les autorisations nécessaires pour le compte ASPNET étaient en place. La seule façon de récupérer du problème consiste à redémarrer la boîte. Même une réinitialisation IIS ne serait pas utile. Vous vous demandez « Ah, Microsoft Software a toujours besoin d’un redémarrage pour récupérer ? » Eh bien, vous avez tort !

La clé ici est d’examiner attentivement le message d’erreur. L’erreur indique clairement « Impossible d’ouvrir un fichier pour l’écriture » et non l’erreur d’accès refusé habituelle. Je pense donc qu’il s’agit d’un autre processus qui maintient un verrou sur un fichier ou un dossier et n’autorise pas ASP.NET à y écrire. Il est logique qu’un redémarrage ait tué l’autre processus et que l’application ASP.NET recommence à fonctionner jusqu’à ce que le processus non autorisé verrouille à nouveau le fichier. La chose logique à faire serait de désactiver tous les programmes antivirus, les logiciels espions tiers ou tout autre logiciel de surveillance de fichiers qui s’exécute sur le serveur. Je ne veux pas signaler de logiciels tiers spécifiques. Mais, en général, les logiciels antivirus sont connus pour causer beaucoup de peine pour LES applications IIS et ASP.NET. Un autre problème connu causé par un logiciel antivirus est la perte de session due au recyclage d’AppDomain lorsque le dossier Bin ou les fichiers .config sont touchés.

Surveillez votre application pour voir si le problème se reproduit. Si vous exécutez plusieurs programmes antivirus, utilisez la méthode d’essai et d’erreur pour déterminer quel programme particulier est à l’origine du problème.

Consultez ASP.NET Access Control Listes obligatoires (ACL).

Utilisez plutôt une invite de commandes et exécutez la commande suivante :

cacls %windir%\assembly /e /t /p domain\useraccount:r

Sinon, avant d’utiliser Windows Explorer, désinscrivez Shfusion.dll avec la commande suivante pour accorder des autorisations via l’interface graphique utilisateur :

C:\WINDOWS\Microsoft.NET\Framework\VersionNumber>regsvr32-u shfusion.dll

Après avoir défini les autorisations avec Windows Explorer, réinscrivez Shfusion.dll avec la commande suivante :

C:\WINDOWS\Microsoft.NET\Framework\VersionNumber>regsvr32 shfusion.dll

Le problème se produit en raison d’autorisations manquantes sur une ressource distante à laquelle l’application ASP.NET tente d’accéder

Lorsque votre application ASP.NET accède à une ressource distante telle que Microsoft SQL Server ou un partage UNC (Universal Naming Convention), il existe de nombreux problèmes. En outre, de nombreux éléments peuvent être configurés de manière incorrecte sur la ressource distante. Vous devez résoudre ces problèmes pour que la ressource fonctionne.

La première étape consiste à voir si vous pouvez vous connecter au serveur distant via Windows Explorer.

1. Sur le serveur distant, créez un dossier appelé Test. Sous les onglets Partage et Sécurité du dossier Test, ajoutez votre domaine/compte, ainsi que le compte de processus utilisé par votre application ASP.NET, puis donnez-leur le contrôle total.

2. Sur le serveur IIS, connectez-vous avec votre domaine/compte, cliquez sur Démarrer, sur Exécuter, puis tapez le chemin de partage UNC du serveur distant : \\RemoteServerName*\Test.

   Si vous ne parvenez pas à accéder à ce dossier, contactez votre administrateur réseau pour résoudre ce problème. C’est seulement alors que votre application ASP.NET pourra accéder au partage.

3. Créez un fichier appelé CreateUNCFile.aspx avec le code ci-dessous et enregistrez-le dans le répertoire de votre application.

   <%@ Page Language="vb" %>
   <%@ Import Namespace="System.IO" %>
   <html>
   <head>
   <title>Writing to a Text File</title>
   <script runat="server">
       Sub WriteToFile(ByVal sender As System.Object, ByVal e As System.EventArgs)
           Dim fp As StreamWriter
               fp = File.CreateText("\\<RemoteServerName>\Test\" & "test.txt")
               fp.WriteLine(txtMyFile.Text)
               lblStatus.Text = "The File Successfully created! Your ASP.NET process is able to access this remote share"
               fp.Close()
       End Sub
   </script>
   
   </head>
   <body style="font: 10pt verdana">
               <h3 align="center">Creating a Text File in ASP.NET</h3>
       <form id="Form1" method="post" runat="server">
                           Type your text:
                           <asp:TextBox ID="txtMyFile" TextMode="MultiLine" Rows="10" Columns="60" Runat="server" /><br>
                           <asp:button ID="btnSubmit" Text="Create File" OnClick="WriteToFile" Runat="server" />
                           <asp:Label ID="lblStatus" Font-Bold="True" ForeColor="#ff0000" Runat="server" />
       </form>
   </body>
   </html> 
   

4. Veillez à modifier <RemoteServerName> dans la ligne de code suivante

   fp = File.CreateText("\\<RemoteServerName>\Test\" &"test.txt")
   

   Afin qu’il reflète le nom de votre serveur distant.

5. Ouvrez Windows Internet Explorer et accédez à http://**IISServerName**/**AppName**/CreateUNCFile.aspx à partir d’un ordinateur client autre que le serveur IIS.

6. Si le fichier Test.txt est créé avec succès, votre application ASP.NET peut s’authentifier auprès de la ressource distante.

7. Si la création de fichiers échoue à partir d’un navigateur client Internet Explorer, mais fonctionne si vous accédez à la même page à partir du serveur IIS lui-même, il est probable que vous soyez dans un scénario de « double tronçon ». Si vous utilisez des composants WebPart personnalisés pour accéder à des ressources distantes qui nécessitent l’authentification et l’autorisation de l’utilisateur, vous rencontrerez probablement le problème de « double tronçon ». Pour accéder à votre ressource distante, vous devrez peut-être fournir les informations d’identification de l’utilisateur final à la ressource afin que la sortie de la ressource soit limitée aux données auxquelles l’utilisateur final est autorisé à accéder.

Les étapes ci-dessus supposent que l’authentification NTLM est activée dans IIS. L’authentification de base n’utilise pas Kerberos.

Pour plus d’informations, consultez Résoudre les échecs Kerberos dans internet Explorer.

Pour plus d’informations sur les méthodes d’authentification IIS, consultez La documentation technique de Visual Studio 2003 mise hors service.

Il existe de nombreuses autres causes pour le message d’erreur « Application serveur indisponible ». Le journal des événements est votre meilleur choix pour obtenir plus de détails sur la cause de votre problème.

Erreurs liées à IIS

Les journaux IIS sont utiles en cas d’erreurs liées à l’authentification IIS.

Ce que vous devez rechercher, c’est les codes status et sous-status pour cette erreur particulière.

2006-10-12 22:47:28 W3SVC1 65.52.18.230 GET /MyAPP/login.aspx - 80  
MyDomain\UserID_91 65.52.22.58 Mozilla/4.0+  
(compatible;+MSIE+6.0;+Windows+NT+5.2;+SV1;+.NET+CLR+1.1.4322;+.NET+CLR+2.0.50727;+InfoPath.1) 401 3 5

Nous voyons un 401 avec le sous-état 3, qui indique « Non autorisé en raison d’une liste de contrôle d’accès sur la ressource ».

Cela indique des autorisations NTFS manquantes sur un fichier ou un dossier. Cette erreur peut se produire même si les autorisations sont correctes pour le fichier auquel vous essayez d’accéder, mais les autorisations par défaut et les droits utilisateur peuvent être manquants sur d’autres dossiers SYSTEM et IIS. Par exemple, vous pouvez voir cette erreur si le compte IUSR_ComputerName n’a pas accès au répertoire C :\Winnt\System32\Inetsrv.

L’autre élément intéressant ici est le code status 5. Vous pouvez utiliser la commande net helpmsg pour obtenir plus d’informations sur ce code status :

C:\Documents and Settings\User> net helpmsg 5

L’accès est refusé.

Essayons un autre code status courant, code 50 :

C:\Documents and Settings\User> net helpmsg 50

La requête n’est pas prise en charge.

L’idée est d’utiliser toutes les informations journalisées disponibles pour obtenir un maximum de détails sur le problème en question.

Ressources

Pour plus d’informations, consultez l’article suivant :

• Introduction à ASP.NET Identity

• Comment créer un compte de service pour une application ASP.NET 2.0

• Création d’applications ASP.NET sécurisées : authentification, autorisation et communication sécurisée