Behandeln allgemeiner Berechtigungen und sicherheitsrelevanter Probleme in ASP.NET

In diesem Artikel erfahren Sie, wie Sie häufige Berechtigungen und sicherheitsbezogene Probleme in ASP.NET behandeln.

              Originale Produktversion: ASP.NET
Ursprüngliche KB-Nummer: 910449

Nützliche Tools

Bevor Sie versuchen, probleme zu beheben, müssen Sie sich mit einigen Tools vertraut machen, mit denen Sie das Problem eingrenzen können. In unserem Fall interessieren wir uns für Tools wie FileMon, RegMon und Sicherheitsüberwachung. Weitere Informationen zu FileMon finden Sie unter FileMon für Windows v7.04.

Weitere Informationen zu RegMon finden Sie unter Windows Sysinternals.

Drilldown zum Isolieren des Problems

• Hat die Anwendung jemals funktioniert? Wenn ja, was hat sich geändert, was die Anwendung möglicherweise unterbrochen hätte? Es ist möglich, dass Softwareupdates oder Sicherheitsupdates auf den Server angewendet wurden. Auch ein Coderollout könnte das Problem verursacht haben.
• Werden einfache .html- und .asp-Seiten von IIS bereitgestellt?
• Wurde die Anwendung zu einer anderen Version von IIS migriert?
• Tritt bei anderen ASP.NET Anwendungen auf dem Server derselbe Fehler auf? Ist dies die einzige Anwendung, die fehlschlägt?
• Tritt das Problem für alle Benutzer oder nur für bestimmte Benutzer auf?
• Ist das Problem beim lokalen Surfen auf dem Webserver reproduzierbar, oder ist es für nur wenige Clients reproduzierbar?
• Wenn Sie einen Identitätswechsel verwenden, hat der identitätswechselende Benutzer dann den erforderlichen Zugriff auf die Ressource?

Die oben genannten Fragen sind nützlich, um ein Problem zu diagnostizieren. Wenn Sie Ihr Problem in einem der ASP.NET Foren veröffentlichen und bereits Antworten auf die meisten dieser Fragen haben, erhalten Sie wahrscheinlich einen schnellen Zeiger oder eine Lösung für Ihr Problem. Der Schlüssel besteht darin, den gesamten ASP.NET Stack-Ablaufverfolgungsfehler zu veröffentlichen, falls zutreffend, anstatt zu sagen: "Ich erhalte beim Versuch, meine ASP.NET Anwendung auszuführen, einen Fehler vom Typ Zugriff verweigert. Kann jemand helfen?" Es ist viel einfacher, sich die Stapelüberwachung anzusehen und Ihnen Zeiger zu geben, wenn eine vollständige Fehlermeldung angezeigt wird. Also müssen Sie sich fragen...

Wie lautet die genaue Fehlermeldung?

Die erste Frage, die wir Kunden stellen, lautet: "Was ist die genaue Fehlermeldung?" Wenn Sie eine klare Beschreibung der vom Microsoft-.NET Framework ausgelösten Fehlermeldung haben, können Sie diesen Abschnitt überspringen. Wenn Ihre Anwendung die tatsächliche Fehlermeldung maskiert und Stattdessen eine benutzerfreundliche Fehlermeldung wie "Ein unerwarteter Fehler ist aufgetreten. Wenden Sie sich an den Websiteadministrator, um Weitere Informationen zu erhalten" es ist für niemanden von großem Nutzen. Im Folgenden finden Sie einige Schritte, die Ihnen helfen, die tatsächliche Fehlermeldung zu erhalten.

• Suchen und öffnen Sie die Web.config Datei im Anwendungsverzeichnis, und ändern Sie customErrors in mode="Off". Speichern Sie die Datei, und reproduzieren Sie das Problem.

• Aufgrund der vom Anwendungsentwickler durchgeführten benutzerdefinierten Ereignis-/Fehlerbehandlung ist es möglicherweise immer noch nicht möglich, die tatsächliche Fehlermeldung nach dem obigen Schritt anzuzeigen. Sie können versuchen, das Application_Error-Ereignis in der Datei Global.asax zu suchen und codeauskommentieren, der die Server.Transfer("Errors.aspx") Funktion verwendet, um zu einer benutzerdefinierten Fehlerseite zu wechseln.

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

Nachdem Sie die tatsächliche Fehlermeldung erhalten haben, lesen Sie sie, um festzustellen, ob der Fehler durch fehlende Berechtigungen für eine lokale Ressource oder für eine Remoteressource verursacht wird, auf die Ihre ASP.NET-Anwendung zugreifen möchte.

Das Problem tritt aufgrund fehlender Berechtigungen für eine lokale Ressource auf, auf die die ASP.NET Anwendung zugreifen möchte.

Wenn Sie aufgrund einer benutzerdefinierten Fehlermeldung keine klare Beschreibung des Problems erhalten können, führen Sie FileMon aus, und reproduzieren Sie das Problem. Beenden und speichern Sie die Erfassung als FileMon.xls und öffnen Sie die Datei in Microsoft Excel. Klicken Sie im Menü Daten auf Filter, und klicken Sie dann auf AutoFilter , um die Filterfunktionen von Excel zu verwenden. Wählen Sie nun die Dropdownliste in der Spalte F aus, und suchen Sie nach den Fehlern "ZUGRIFF VERWEIGERT".

Unten sehen Sie eine FileMon-Beispielausgabe.

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

Wie Sie anhand der gefilterten Ergebnisse sehen können, haben wir die Ursache des Problems eingegrenzt. FileMon zeigt an, dass dem Konto NT AUTHORITY\NETWORK SERVICE NTFS-Berechtigungen für den C:\Winnt\Microsoft.net\Framework\v1.1.4322\Temporary ASP.NET Files Ordner fehlen. Dies sollte einfach zu beheben sein.

Die meisten Benutzer neigen dazu, die Microsoft-.NET Framework neu zu installieren oder sogar das Betriebssystem neu zu installieren. Dies ist kein empfohlener Problembehandlungsschritt und garantiert nicht, dass das Problem nicht erneut auftritt. Ich werde ein solches Beispiel nennen. Zeitweilige Probleme sind häufig schwer zu isolieren und zu beheben. In diesem Szenario würde die Anwendung des Kunden einige Stunden gut funktionieren, und dann würde sie plötzlich mit dem folgenden Fehler fehlschlagen. Der Kunde hatte bereits versucht, die .NET Framework sowie das Betriebssystem neu zu installieren. Dies schien das Problem für ein paar Tage zu beheben, aber dann wurde es wieder angezeigt.

Beim Ausführen von FileMon wurden keine ACCESS DENIED-Fehler angezeigt. Alle erforderlichen Berechtigungen für das ASPNET-Konto waren vorhanden. Die einzige Möglichkeit, das Problem zu beheben, besteht darin, die Box neu zu starten. Selbst eine IIS-Zurücksetzung würde nicht helfen. Sie denken: "Ah, Microsoft Software benötigt immer einen Neustart zur Wiederherstellung?" Nun, Sie liegen falsch!

Der Schlüssel ist hier, sich die Fehlermeldung genau anzusehen. Der Fehler besagt eindeutig "Eine Datei kann nicht zum Schreiben geöffnet werden" und nicht der übliche ACCESS DENIED-Fehler , daher denke ich, dass es sich um einen anderen Prozess handelt, der eine Sperre für eine Datei oder einen Ordner hält und ASP.NET nicht zulässt, in sie zu schreiben. Es ist sinnvoll, dass ein Neustart den anderen Prozess beendet hat und die ASP.NET Anwendung wieder funktioniert, bis der nicht autorisierte Prozess die Datei erneut sperrt. Die logische Vorgehensweise wäre, alle Antivirenprogramme, Spyware von Drittanbietern oder andere Dateiüberwachungssoftware, die auf dem Server ausgeführt wird, zu deaktivieren. Ich möchte keine spezifische Software von Drittanbietern herausstellen. Im Allgemeinen ist jedoch bekannt, dass Antivirensoftware viel Trauer für IIS und ASP.NET-Anwendungen verursacht. Ein weiteres bekanntes Problem, das durch Antivirensoftware verursacht wird, ist der Sitzungsverlust aufgrund von AppDomain wird wiederverwendet, wenn der Ordner Bin oder die .config Dateien berührt werden.

Überwachen Sie Ihre Anwendung, um festzustellen, ob das Problem erneut auftritt. Wenn Sie mehrere Antivirenprogramme ausführen, verwenden Sie die Trial-and-Error-Methode, um zu ermitteln, welches bestimmte Programm das Problem verursacht.

Weitere Informationen finden Sie unter ASP.NET Erforderliche Access Control Listen (ACLs).

Verwenden Sie stattdessen eine Eingabeaufforderung, und führen Sie den folgenden Befehl aus:

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

Alternativ können Sie vor der Verwendung von Windows Explorer die Registrierung Shfusion.dll mit dem folgenden Befehl aufheben, um Berechtigungen über die GRAFISCHE Benutzeroberfläche zu erteilen:

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

Nachdem Sie Berechtigungen mit Windows Explorer festgelegt haben, registrieren Sie Shfusion.dll mit dem folgenden Befehl erneut:

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

Das Problem tritt aufgrund fehlender Berechtigungen für eine Remoteressource auf, auf die die ASP.NET Anwendung zugreifen möchte.

Wenn Ihre ASP.NET Anwendung auf eine Remoteressource wie Microsoft SQL Server oder eine UNC-Freigabe (Universal Naming Convention) zugreift, kann vieles schief gehen. Außerdem kann es vorkommen, dass viele Dinge auf der Remoteressource falsch eingerichtet sind. Sie müssen diese Probleme beheben, damit die Ressource funktioniert.

Im ersten Schritt sollten Sie überprüfen, ob Sie über Windows Explorer eine Verbindung mit dem Remoteserver herstellen können.

1. Erstellen Sie auf dem Remoteserver einen Ordner namens Test. Fügen Sie auf den Registerkarten Freigabe und Sicherheit des Ordners Test Ihre Domäne/Ihr Konto sowie das Prozesskonto hinzu, das von Ihrer ASP.NET-Anwendung verwendet wird, und gewähren Sie ihnen beide Vollzugriff.

2. Melden Sie sich auf dem IIS-Server mit Ihrer Domäne/Ihrem Konto an, klicken Sie auf Start, klicken Sie auf Ausführen, und geben Sie dann den UNC-Freigabepfad des Remoteservers ein: \\RemoteServerName*\Test.

   Wenn Sie diesen Ordner nicht aufrufen können, wenden Sie sich an Ihren Netzwerkadministrator, um dieses Problem zu beheben. Nur dann kann Ihre ASP.NET Anwendung auf die Freigabe zugreifen.

3. Erstellen Sie eine Datei namens CreateUNCFile.aspx mit dem folgenden Code, und speichern Sie die Datei in Ihrem Anwendungsverzeichnis.

   <%@ 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. Stellen Sie sicher, dass Sie RemoteServerName> in der folgenden Codezeile ändern<.

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

   Damit er den Namen Ihres Remoteservers wiedergibt.

5. Öffnen Sie Windows Internet Explorer, und navigieren Sie von http://**IISServerName**/**AppName**/CreateUNCFile.aspx einem anderen Clientcomputer als dem IIS-Server zu.

6. Wenn die Test.txt-Datei erfolgreich erstellt wird, kann sich Ihre ASP.NET-Anwendung bei der Remoteressource authentifizieren.

7. Wenn die Dateierstellung über einen Internet Explorer-Clientbrowser fehlschlägt, aber funktioniert, wenn Sie vom IIS-Server selbst zur gleichen Seite navigieren, tritt wahrscheinlich ein "Double Hop"-Szenario auf. Wenn Sie benutzerdefinierte webparts für den Zugriff auf Remoteressourcen verwenden, die eine Benutzerauthentifizierung und -autorisierung erfordern, tritt wahrscheinlich das Problem "Double Hop" auf. Um auf Ihre Remoteressource zugreifen zu können, müssen Sie möglicherweise die Anmeldeinformationen des Endbenutzers für die Ressource angeben, damit die Ausgabe der Ressource auf die Daten beschränkt ist, für die der Endbenutzer über Zugriffsberechtigungen verfügt.

Bei den obigen Schritten wird davon ausgegangen, dass die NTLM-Authentifizierung in IIS aktiviert ist. Die Standardauthentifizierung verwendet kerberos nicht.

Weitere Informationen finden Sie unter Behandeln von Kerberos-Fehlern in Internet Explorer.

Weitere Informationen zu IIS-Authentifizierungsmethoden finden Sie in der technischen Dokumentation zu Visual Studio 2003 eingestellt.

Es gibt zahlreiche andere Ursachen für die Fehlermeldung "Serveranwendung nicht verfügbar". Das Ereignisprotokoll ist die beste Wahl, um weitere Details zur Ursache Ihres Problems zu erhalten.

IIS-bezogene Fehler

Die IIS-Protokolle sind bei Fehlern im Zusammenhang mit der IIS-Authentifizierung nützlich.

Sie müssen nach den codes status und sub status für diesen bestimmten Fehler suchen.

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

Es wird ein 401 mit dem Unterstatus 3 angezeigt, der "Nicht autorisiert aufgrund von ACL für Ressource" angibt.

Dies weist auf fehlende NTFS-Berechtigungen für eine Datei oder einen Ordner hin. Dieser Fehler kann auch dann auftreten, wenn die Berechtigungen für die Datei korrekt sind, auf die Sie zugreifen möchten, aber die Standardberechtigungen und Benutzerrechte in anderen SYSTEM- und IIS-Ordnern fehlen. Dieser Fehler kann beispielsweise angezeigt werden, wenn das IUSR_ComputerName-Konto keinen Zugriff auf das Verzeichnis C:\Winnt\System32\Inetsrv hat.

Das andere, was hier von Interesse ist, ist der status Code 5. Sie können den Befehl net helpmsg verwenden, um weitere Informationen zu diesem status Code zu erhalten:

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

Der Zugriff wurde verweigert.

Probieren wir einen anderen allgemeinen status Code aus, Code 50:

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

Die Anforderung wird nicht unterstützt.

Die Idee besteht darin, alle protokollierten Informationen zu verwenden, die verfügbar sind, um maximale Details zum vorliegenden Problem zu erhalten.

Ressourcen

Weitere Informationen finden Sie unter:

• Einführung in ASP.NET Identity

• Erstellen eines Dienstkontos für eine ASP.NET 2.0-Anwendung

• Erstellen von Anwendungen für sichere ASP.NET: Authentifizierung, Autorisierung und sichere Kommunikation