Behandeln allgemeiner Berechtigungen und sicherheitsrelevanter Probleme in ASP.NET

  • Artikel
  • 10 Minuten Lesedauer

In diesem Artikel wird erläutert, wie Sie allgemeine Berechtigungen und sicherheitsrelevante Probleme in ASP.NET behandeln.

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

Nützliche Tools

Bevor Sie versuchen, Fehlerhaftes zu beheben, müssen Sie sich mit einigen Tools vertraut machen, die Ihnen helfen, das Problem einzugrenzen. In unserem Fall sind wir an Tools wie FileMon, RegMon und Security Auditing interessiert. 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, welche Änderungen hätte die Anwendung unterbrechen können? Es ist möglich, dass Softwareupdates oder Sicherheitsupdates auf dem Server angewendet wurden. Ein Coderollout könnte auch das Problem verursacht haben.
  • Dienen einfache .html- und ASP-Seiten von IIS?
  • Wurde die Anwendung zu einer anderen Version von IIS migriert?
  • Führen andere ASP.NET-Anwendungen auf dem Server zu einem Fehler? 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 Browsen auf dem Webserver oder nur für einige wenige Clients reproduzierend?
  • Wenn Sie den Identitätswechsel verwenden, hat der imitierte Benutzer dann den erforderlichen Zugriff auf die Ressource?

Die obigen Fragen sind hilfreich, um ein Problem zu diagnostizieren. Wenn Sie Ihr Problem in einem der ASP.NET Foren veröffentlichen und bereits die 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 Stapelablaufverfolgungsfehler zu posten, falls zutreffend, anstatt zu sagen: "Ich erhalte einen Fehler beim Zugriff verweigert, während ich versuche, meine ASP.NET Anwendung auszuführen. Kann jeder helfen?" Es ist viel einfacher für jemanden, sich die Stapelüberwachung anzusehen und Ihnen Zeiger zu geben, wenn eine vollständige Fehlermeldung angezeigt wird. Sie müssen sich also fragen...

Was ist 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 anzeigefreundliche Fehlermeldung erhält, z. B. "Ein unerwarteter Fehler ist aufgetreten. Wenden Sie sich an den Websiteadministrator, um Weitere Informationen zu erhalten." Dies ist für niemanden von großer Nutzen. Hier sind 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 kann die tatsächliche Fehlermeldung nach dem Ausführen des obigen Schritts möglicherweise nicht angezeigt werden. Sie können versuchen, das Application_Error-Ereignis in der Datei "Global.asax" zu suchen und codeauskommentiert, 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 zuzugreifen versucht.

Tipp

Sie können sich an Ihren Entwickler wenden, um herauszufinden, wie die tatsächliche Fehlermeldung angezeigt wird. Es ist möglich, dass Ihr Entwickler sie in einer Datei protokolliert oder E-Mail-Benachrichtigungen erhält. Denken Sie immer daran, eine Sicherung aller Dateien zu erstellen, die Sie ändern werden. Wenn eine Sicherung verfügbar ist, können Sie jederzeit ein Rollback aller Änderungen ausführen.

Das Problem tritt aufgrund fehlender Berechtigungen für eine lokale Ressource auf, auf die die ASP.NET Anwendung zuzugreifen versucht.

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 Aufnahme als FileMon.xls, und öffnen Sie die Datei in Microsoft Excel. Klicken Sie im Menü "Daten" auf "Filtern" und 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 "ACCESS DENIED"-Fehlern.

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 NT AUTHORITY\NETWORK SERVICE-Konto NTFS-Berechtigungen für den C:\Winnt\Microsoft.net\Framework\v1.1.4322\Temporary ASP.NET Files Ordner fehlen. Dies sollte sofort behoben werden.

Tipp

Ein guter Schritt wäre, das ASP.NET Prozesskonto in ein Administratorkonto zu ändern, um festzustellen, ob das Problem behoben wird. In IIS 6.0 und späteren Versionen würden Sie die IIS-AppPool-Identität in "Lokales System" ändern, um festzustellen, ob die Anwendung funktioniert.

Hinweis

Dies sollte nicht als Lösung, sondern nur als Problembehandlungsschritt verwendet werden.

Die meisten Benutzer tendieren 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 angeben. Zeitweilige Probleme sind häufig schwer zu isolieren und zu beheben. In diesem Szenario funktionierte die Anwendung des Kunden einige Stunden lang einwandfrei, und dann würde sie plötzlich mit dem folgenden Fehler fehlschlagen. Der Kunde hat bereits versucht, die .NET Framework sowie das Betriebssystem neu zu installieren. Dadurch wurde das Problem für einige Tage behoben, aber dann erneut 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, das Feld neu zu starten. Selbst eine IIS-Zurücksetzung wäre nicht hilfreich. Sie denken: "Ah, Microsoft Software muss immer neu gestartet werden, um wiederhergestellt zu werden?" Nun, Sie liegen falsch!

Der Schlüssel hier besteht darin, die Fehlermeldung genauer zu betrachten. Der Fehler besagt eindeutig" kann eine Datei zum Schreiben nicht öffnen" und nicht den üblichen ACCESS DENIED-Fehler. Daher gehe ich davon aus, dass es sich um einen anderen Prozess handelt, der eine Sperre für eine Datei oder einen Ordner enthält und ASP.NET das Schreiben in diese Datei oder einen Ordner nicht zulässt. Es ist sinnvoll, dass bei einem Neustart der andere Prozess aufgehoben wurde und die ASP.NET Anwendung erneut funktioniert, bis der nicht autorisierte Prozess die Datei erneut sperrt. Die logische Aufgabe wäre, alle Antivirenprogramme, Spyware von Drittanbietern oder andere Dateiüberwachungssoftware, die auf dem Server ausgeführt wird, zu deaktivieren. Ich möchte keine bestimmte Drittanbietersoftware herausstellen. Im Allgemeinen ist jedoch bekannt, dass Antivirensoftware für IIS- und ASP.NET-Anwendungen viel Leid verursacht. Ein weiteres bekanntes Problem, das durch Antivirensoftware verursacht wird, ist der Sitzungsverlust aufgrund von AppDomain-Wiederverwendungen, wenn der Ordner "Bin" oder die .config-Dateien berührt werden.

Tipp

Die einfachste Möglichkeit, Dienste von Drittanbietern zu deaktivieren, ist:

  1. Klicken Sie auf "Start", klicken Sie auf "Ausführen", und geben Sie dann "msconfig" ein.
  2. Wählen Sie "Dienste" aus, und aktivieren Sie "Alle Microsoft-Dienste ausblenden".
  3. Klicken Sie auf "Alle deaktivieren", um die Dienste von Drittanbietern zu beenden.
  4. Klicken Sie auf "Start", klicken Sie auf "Ausführen", und geben Sie "iisreset" ein, um die CLR erneut in den Arbeitsprozess zu laden.

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

Hinweis

Wenn der gleiche Fehler 100 Prozent der Zeit reproduzieren kann, ist Ihre Antivirensoftware möglicherweise nicht die Ursache. Dieser Fehler kann andere Ursachen haben. Versuchen Sie, eine einfache ASP.NET Testanwendung zu erstellen, um zu isolieren, ob für eine Seite "Test.aspx" derselbe Fehler auftritt. Falls ja, überprüfen Sie, ob die erforderlichen Zugriffssteuerungslisten (Access Control Lists, ACLs) für ASP.NET vorhanden sind.

Siehe ASP.NET Erforderliche Zugriffssteuerungslisten (Required Access Control Lists, ACLs).

Tipp

Der %SystemRoot%\Assembly Ordner ist der globale Assemblycache. Sie können Windows Explorer nicht direkt verwenden, um ACLs für diesen Ordner zu bearbeiten.

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 GUI zu erteilen:

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

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

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 zuzugreifen versucht.

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

Der erste Schritt besteht darin, zu sehen, 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 geben 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 nicht zu diesem Ordner gelangen 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 die Änderungen <RemoteServerName> in der folgenden Codezeile vornehmen.

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

    Damit der Name des Remoteservers angezeigt wird.

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

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

  7. Wenn die Dateierstellung in einem Internet Explorer-Clientbrowser fehlschlägt, aber funktioniert, wenn Sie vom IIS-Server selbst zu derselben Seite navigieren, tritt wahrscheinlich ein Szenario mit doppeltem Hop auf. Wenn Sie benutzerdefinierte integrierte Webparts verwenden, um auf Remoteressourcen zuzugreifen, die eine Benutzerauthentifizierung und Autorisierung erfordern, tritt wahrscheinlich das Problem "Doppelter 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, auf die der Endbenutzer zugreifen kann.

Bei den obigen Schritten wird davon ausgegangen, dass die NTLM-Authentifizierung in IIS aktiviert ist. Für die Standardauthentifizierung wird Kerberos nicht verwendet.

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

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

Tipp

Wenn Sie eine Verbindung mit der UNC-Remotefreigabe herstellen können, aber keine Verbindung mit dem Remoteserver herstellen können, auf dem SQL Server von der ASP.NET-Anwendung ausgeführt wird, müssen Sie möglicherweise die Dienstprinzipalnamen (Service Principal Names, SPNs) für SQL Server überprüfen oder festlegen. Versuchen Sie, nur die Standardauthentifizierung für Ihre Anwendung in IIS zu aktivieren, und überprüfen Sie, ob Sie eine Verbindung mit dem Remoteserver herstellen können, auf dem SQL Server ausgeführt wird.

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

Die IIS-Protokolle sind nützlich, wenn iis-Authentifizierungs-bezogene Fehler auftreten.

Sie müssen nach den Status- und Unterstatuscodes 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 einer 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, auf die Sie zugreifen möchten, korrekt sind, aber die Standardberechtigungen und Benutzerrechte in anderen SYSTEM- und IIS-Ordnern fehlen. Dieser Fehler wird beispielsweise angezeigt, wenn das IUSR_ComputerName Konto keinen Zugriff auf das Verzeichnis "C:\Winnt\System32\Inetsrv" hat.

Tipp

Klicken Sie auf "Start", klicken Sie auf "Ausführen", und geben Sie dann Protokolldateien ein, um den Ordner zu öffnen, der die IIS-Protokolle enthält. Alternativ können Sie auf der Eigenschaftenseite ihrer Website in IIS auf die Registerkarte "WebSiteName" und unter "Aktives Protokollformat" auf "Eigenschaften" klicken, um das Verzeichnis und den Namen der Protokolldatei anzuzeigen.

Das andere, was hier interessant ist, ist der Statuscode 5. Sie können den Befehl "net helpmsg" verwenden, um weitere Informationen zu diesem Statuscode zu erhalten:

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

Der Zugriff wurde verweigert.

Probieren wir einen weiteren allgemeinen Statuscode aus, Code 50:

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

Die Anforderung wird nicht unterstützt.

Tipp

Wenn Sie eine weitere generische "500 Internal Server Error"-Meldung erhalten, empfiehlt es sich, benutzerfreundliche HTTP-Fehlermeldungen zu deaktivieren, damit Sie eine detaillierte Beschreibung des Fehlers erhalten. Vergessen Sie nicht, in der Ereignisanzeige zu suchen, da sie möglicherweise auch weitere Informationen enthält.

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

Ressourcen

Weitere Informationen finden Sie unter: