Freigeben über

Behandeln allgemeiner Berechtigungen und sicherheitsbezogener Probleme in ASP.NET

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

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

Nützliche Tools

Bevor Sie versuchen, alles zu beheben, was beschädigt ist, müssen Sie sich mit einigen Tools vertraut machen, die Ihnen helfen, das Problem einzugrenzen. 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 hätte den Anwendungsunterbrechung gemacht? Es ist möglich, dass Softwareupdates oder Sicherheitsupdates auf dem Server angewendet wurden. Ein Coderollout könnte auch das Problem verursacht haben.
  • Werden einfache .html und .asp Seiten von IIS bereitgestellt?
  • Wurde die Anwendung zu einer anderen Version von IIS migriert?
  • Schlagen andere ASP.NET Anwendungen auf dem Server mit demselben Fehler fehl? 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 während des lokalen Browsens auf dem Webserver reproduzierbar oder ist es für nur wenige Clients reproduzierbar?
  • Wenn Sie den Identitätswechsel verwenden, hat der imitierte Benutzer 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 Stapelablaufverfolgungsfehler zu veröffentlichen, falls zutreffend, anstatt zu sagen: "Ich erhalte einen Zugriff verweigert-Fehler, während ich versuche, meine ASP.NET Anwendung auszuführen. Kann jeder helfen?" Es ist einfacher, dass jemand die Stapelablaufverfolgung betrachtet und Ihnen Zeiger gibt, wenn sie eine vollständige Fehlermeldung sehen können. Sie müssen sich also fragen...

Wie lautet die genaue Fehlermeldung?

Die erste Frage, die wir Kunden stellen, ist: "Was ist die genaue Fehlermeldung?" Wenn Sie eine klare Beschreibung der von Microsoft .NET Framework ausgelösten Fehlermeldung haben, können Sie diesen Abschnitt überspringen. Wenn Ihre Anwendung die eigentliche Fehlermeldung maskiert und Stattdessen eine anzeigefreundliche Fehlermeldung angibt, z. B. "Unerwarteter Fehler ist aufgetreten. Wenden Sie sich an den Websiteadministrator, um Details zu erhalten". Hier sind einige Schritte, die Ihnen helfen, die eigentliche 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.

  • Möglicherweise ist es weiterhin nicht möglich, die tatsächliche Fehlermeldung nach dem Ausführen des obigen Schritts aufgrund der vom Anwendungsentwickler durchgeführten benutzerdefinierten Ereignis-/Fehlerbehandlung anzuzeigen. Sie können versuchen, das Application_Error-Ereignis in der Datei "Global.asax" zu finden und code, 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.

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 möglicherweise in einer Datei protokolliert oder E-Mail-Benachrichtigungen erhält. Denken Sie immer daran, eine Sicherung aller Dateien vorzunehmen, die Sie ändern werden. Mit einer verfügbaren Sicherung können Sie jederzeit ein Rollback aller Änderungen vornehmen.

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 Aufzeichnung als FileMon.xls, und öffnen Sie die Datei in Microsoft Excel. Wählen Sie im Menü "Daten " die Option "Filtern" und dann "AutoFilter " aus, um die Filterfunktionen von Excel zu verwenden. Wählen Sie nun die Dropdownliste in 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 aus den gefilterten Ergebnissen sehen können, haben wir die Ursache des Problems eingegrenzt. FileMon zeigt an, dass das NT AUTHORITY\NETWORK SERVICE-Konto NTFS-Berechtigungen für den C:\Winnt\Microsoft.net\Framework\v1.1.4322\Temporary ASP.NET Files Ordner fehlt. Dies sollte sofort behoben werden.

Tipp

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

Notiz

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

Die meisten Personen würden in der Regel das Microsoft .NET Framework neu installieren oder sogar in das Ausmaß der Neuinstallation des Betriebssystems gehen. Dies ist kein empfohlener Schritt zur Problembehandlung 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 würde die Anwendung des Kunden einige Stunden lang einwandfrei funktionieren, und dann würde es plötzlich mit dem folgenden Fehler fehlschlagen. Der Kunde hatte bereits versucht, .NET Framework und 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 wurden eingerichtet. Die einzige Möglichkeit zum Wiederherstellen des Problems besteht darin, das Feld neu zu starten. Selbst eine IIS-Zurücksetzung würde nicht helfen. Sie denken an "Ah, Microsoft Software benötigt immer einen Neustart, um wiederherzustellen?" Nun, Du bist falsch!

Der Schlüssel hier ist, die Fehlermeldung genau zu betrachten. Der Fehler besagt eindeutig" "Kann keine Datei zum Schreiben öffnen", und nicht der übliche ACCESS VERWEIGERT-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 es ASP.NET nicht erlaubt, in die Datei zu schreiben. Es ist sinnvoll, dass ein Neustart den anderen Prozess tötete und die ASP.NET Anwendung wieder funktioniert, bis der nicht autorisierte Prozess die Datei erneut sperrt. Das logische Ziel 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 Software von Drittanbietern herausstellen. Aber im Allgemeinen ist Antivirensoftware bekannt, um viel Ärger für IIS und ASP.NET Anwendungen zu verursachen. Ein weiteres bekanntes Problem, das durch Antivirensoftware verursacht wird, ist der Sitzungsverlust aufgrund von AppDomain-Papierkorbs, wenn der Ordner "Bin" oder die CONFIG-Dateien berührt werden.

Tipp

Die einfachste Möglichkeit zum Deaktivieren von Drittanbieterdiensten besteht in:

  1. Wählen Sie "Start" aus, wählen Sie "Ausführen" aus, und geben Sie dann "msconfig" ein.
  2. Wählen Sie "Dienste " aus, und aktivieren Sie " Alle Microsoft-Dienste ausblenden".
  3. Wählen Sie "Alle deaktivieren " aus, um die Dienste von Drittanbietern zu beenden.
  4. Wählen Sie "Start" aus, wählen Sie "Ausführen" aus, und geben Sie "iisreset" ein, um die CLR in den Arbeitsprozess neu 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.

Notiz

Wenn derselbe Fehler 100 Prozent der Zeit reproduzierbar ist, ist Ihre Antivirensoftware möglicherweise nicht die Ursache. Für diesen Fehler kann es andere Ursachen geben. Versuchen Sie, eine einfache ASP.NET Testanwendung zu erstellen, um zu isolieren, ob für eine Test.aspx Seite derselbe Fehler auftritt. Wenn dies der Fall ist, überprüfen Sie, ob die erforderlichen Zugriffssteuerungslisten (Access Control Lists, ACLs) für ASP.NET vorhanden sind.

Siehe ASP.NET Erforderliche Zugriffssteuerungslisten (ACLs)

Tipp

Der %SystemRoot%\Assembly Ordner ist der globale Assemblycache. Sie können acLs für diesen Ordner nicht direkt mithilfe des Windows-Explorers 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 für Windows Explorer festgelegt haben, registrieren Sie Shfusion.dll mit dem folgenden Befehl erneut:

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

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, gibt es viele Dinge, die schief gehen können. Außerdem sind viele Dinge möglicherweise falsch für die Remoteressource eingerichtet. Sie müssen diese Probleme beheben, um die Ressource funktionsfähig zu machen.

Der erste Schritt wäre, festzustellen, 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 weisen Sie ihnen beide Vollzugriff zu.

  2. Melden Sie sich auf dem IIS-Server mit Ihrer Domäne/Ihrem Konto an, wählen Sie "Start" aus, wählen Sie "Ausführen" aus, 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 den 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 entspricht sie dem Namen Ihres Remoteservers.

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

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

  7. Wenn die Dateierstellung von einem Internet Explorer-Clientbrowser fehlschlägt, aber funktioniert, wenn Sie vom IIS-Server selbst zur gleichen Seite navigieren, liegt es wahrscheinlich an einem "Double Hop"-Szenario. Wenn Sie benutzerdefinierte Webparts verwenden, um auf Remoteressourcen zuzugreifen, die eine Benutzerauthentifizierung und -autorisierung erfordern, tritt wahrscheinlich das "Doppel-Hop-Problem" auf. Um auf Ihre Remoteressource zuzugreifen, müssen Sie möglicherweise die Anmeldeinformationen des Endbenutzers für die Ressource angeben, sodass die Ausgabe der Ressource auf die Daten beschränkt ist, auf die der Endbenutzer über die Berechtigung für den Zugriff 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 Problembehandlung von Kerberos-Fehlern in Internet Explorer.

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

Tipp

Wenn Sie eine Verbindung mit der Remote-UNC-Freigabe herstellen können, aber aus der ASP.NET-Anwendung keine Verbindung mit dem Remoteserver herstellen können, auf dem SQL Server 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 Ihr bestes Suchergebnis, um weitere Details zur Ursache Ihres Problems zu erhalten.

Die IIS-Protokolle sind in Fällen von IIS-Authentifizierungsfehlern hilfreich.

Was Sie suchen müssen, ist die Status- und Unterstatuscodes für diesen bestimmten Fehler.

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

Wir sehen eine 401 mit dem Unterstatus 3, 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 fehlen möglicherweise in anderen SYSTEM- und IIS-Ordnern. Möglicherweise wird dieser Fehler angezeigt, wenn das IUSR_ComputerName Konto keinen Zugriff auf das Verzeichnis "C:\Winnt\System32\Inetsrv" hat.

Tipp

Wählen Sie "Start", wählen Sie "Ausführen" aus, und geben Sie dann Protokolldateien ein, um den Ordner zu öffnen, der die IIS-Protokolle enthält. Alternativ wählen Sie auf der Eigenschaftenseite für Ihre Website in IIS die Registerkarte "WebSiteName" aus, und wählen Sie unter "Aktives Protokollformat" die Option "Eigenschaften" aus, um das Protokolldateiverzeichnis und den Namen anzuzeigen.

Interessant ist hier auch der Statuscode 5. Sie können den Net helpmsg-Befehl verwenden, um weitere Informationen zu diesem Statuscode zu erhalten:

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

Zugriff verweigert.

Versuchen wir es mit einem anderen allgemeinen Statuscode, Code 50:

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

Die Anforderung wird nicht unterstützt.

Tipp

Wenn Sie eine weitere generische fehlermeldung "500 Interner Serverfehler" erhalten, empfiehlt es sich, freundliche HTTP-Fehlermeldungen zu deaktivieren, damit Sie eine detaillierte Beschreibung des Fehlers erhalten. Vergessen Sie nicht, in der Ereignisanzeige zu suchen, da sie auch weitere Informationen enthalten kann.

Die Idee besteht darin, alle protokollierten Informationen zu verwenden, um maximale Details zum Problem zu erhalten.

Ressourcen

Weitere Informationen finden Sie unter: