Dela via

Felsöka vanliga behörigheter och säkerhetsrelaterade problem i ASP.NET

  • Artikel

Den här artikeln beskriver hur du felsöker vanliga behörigheter och säkerhetsrelaterade problem i ASP.NET.

Ursprunglig produktversion: ASP.NET
Ursprungligt KB-nummer: 910449

Användbara verktyg

Innan du försöker åtgärda något som är trasigt måste du bekanta dig med några verktyg, vilket hjälper dig att begränsa problemet. I vårt fall skulle vi vara intresserade av verktyg som FileMon, RegMon och säkerhetsgranskning. Mer information om FileMon finns i FileMon för Windows v7.04.

Mer information om RegMon finns i Windows Sysinternals.

Öka detaljnivån för att isolera problemet

  • Har programmet någonsin fungerat? Om ja, vad har då ändrats som kunde ha gjort att programmet bröts? Det är möjligt att programuppdateringar eller säkerhetsuppdateringar tillämpades på servern. En koddistribution kan också ha orsakat problemet.
  • Fungerar enkla .html och .asp sidor från IIS?
  • Migrerades programmet till en annan version av IIS?
  • Misslyckas andra ASP.NET program på servern med samma fel? Är det här det enda programmet som misslyckas?
  • Uppstår problemet för alla användare eller endast för specifika användare?
  • Är problemet reproducerbart när du söker lokalt på webbservern, eller är det reproducerbart för endast ett fåtal klienter?
  • Har den personifierade användaren nödvändig åtkomst till resursen om du använder personifiering?

Ovanstående frågor är användbara för att diagnostisera ett problem. Om du publicerar ditt problem på någon av de ASP.NET forumen, och om du redan har svar på de flesta av dessa frågor, är det troligt att du får en snabbpekare eller lösning på ditt problem. Nyckeln är att publicera hela ASP.NET stackspårningsfel, om tillämpligt, i stället för att säga "Jag får ett felmeddelande om nekad åtkomst när jag försöker köra mitt ASP.NET program. Kan någon hjälpa till?" Det är mycket enklare för någon att titta på stackspårningen och ge dig tips när de kan se ett fullständigt felmeddelande. Så du måste fråga dig själv...

Vilket är det exakta felmeddelandet?

Den första frågan vi ställer till kunderna är: "Vad är det exakta felmeddelandet?" Om du har en tydlig beskrivning av felmeddelandet från Microsoft .NET Framework kan du hoppa över det här avsnittet. Om ditt program maskerar det faktiska felmeddelandet och ger dig ett eget felmeddelande i stället, till exempel "Ett oväntat fel har inträffat. Kontakta webbplatsadministratören om du vill ha mer information." det är inte till stor nytta för någon. Här följer några steg som hjälper dig att få det faktiska felmeddelandet.

  • Leta upp och öppna Web.config-filen i programkatalogen och ändra customErrors till mode="Off". Spara filen och återskapa problemet.

  • Det kanske fortfarande inte går att se det faktiska felmeddelandet efter att ha följt ovanstående steg på grund av anpassad händelse-/felhantering som görs av programutvecklaren. Du kan försöka hitta händelsen Application_Error i filen Global.asax och kommentera ut all kod som använder Server.Transfer("Errors.aspx") funktionen för att gå till en anpassad felsida.

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

När du får det faktiska felmeddelandet läser du det för att avgöra om felet orsakas av saknade behörigheter för en lokal resurs eller på en fjärrresurs som ditt ASP.NET program försöker komma åt.

Tips

Du kan kontakta utvecklaren för att ta reda på hur du ser det faktiska felmeddelandet. Det är möjligt att utvecklaren kan logga den till en fil eller få e-postaviseringar. Kom alltid ihåg att göra en säkerhetskopia av alla filer som du ska ändra. Med en säkerhetskopia tillgänglig kan du alltid återställa alla ändringar.

Problemet uppstår på grund av att behörigheter saknas för en lokal resurs som ASP.NET-programmet försöker komma åt

Om du inte kan få en tydlig beskrivning av problemet på grund av ett anpassat felmeddelande kör du FileMon och återskapar problemet. Stoppa och spara avbildningen när FileMon.xls och öppna filen i Microsoft Excel. På menyn Data klickar du på Filter och sedan på Autofilter för att använda filtreringsfunktionerna i Excel. Välj listrutan i kolumnen F och leta efter "ÅTKOMST NEKAD"-fel.

Ett exempel på FileMon-utdata visas nedan.

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

Som du ser i de filtrerade resultaten har vi begränsat orsaken till problemet. FileMon visar att NT AUTHORITY\NETWORK SERVICE-kontot saknar NTFS-behörigheter i C:\Winnt\Microsoft.net\Framework\v1.1.4322\Temporary ASP.NET Files mappen. Detta bör vara rättframt att åtgärda.

Tips

Ett bra steg är att ändra ASP.NET bearbeta kontot till ett Admin konto för att se om det löser problemet. I IIS 6.0 och senare versioner ändrar du IIS AppPool-identiteten till "Lokalt system" för att se om programmet fungerar.

Obs!

Detta bör inte användas som en lösning, utan bara som ett felsökningssteg.

De flesta brukar installera om Microsoft .NET Framework eller till och med installera om operativsystemet. Detta är inte ett rekommenderat felsökningssteg och garanterar inte att problemet inte återkommer. Jag ska ge ett sådant exempel. Tillfälliga problem är ofta svåra att isolera och felsöka. I det här scenariot skulle kundens program fungera bra i några timmar, och plötsligt skulle det misslyckas med felet nedan. Kunden hade redan provat att installera om .NET Framework och operativsystemet. Detta verkade åtgärda problemet i några dagar, men sedan dök det upp igen.

Vid körning av FileMon visades inga fel med NEKAD ÅTKOMST . Alla nödvändiga behörigheter för ASPNET-kontot fanns på plats. Det enda sättet att återställa från problemet är att starta om rutan. Inte ens en IIS-återställning skulle hjälpa. Du tänker "Ah, Microsoft Software behöver alltid en omstart för att återställa?" Du har fel!

Nyckeln här är att titta närmare på felmeddelandet. Felet säger tydligt "det går inte att öppna en fil för skrivning" och inte det vanliga felet ÅTKOMST NEKAD , så jag tror att det är någon annan process som håller ett lås på en fil eller mapp och inte tillåter ASP.NET att skriva till den. Det är vettigt att en omstart dödade den andra processen och ASP.NET-programmet börjar fungera igen tills den falska processen låser filen igen. Det logiska vore att stänga av alla antivirusprogram, spionprogram från tredje part eller andra filövervakningsprogram som körs på servern. Jag vill inte påpeka någon specifik programvara från tredje part. Men i allmänhet är antivirusprogram kända för att orsaka mycket sorg för IIS och ASP.NET program. Ett annat känt problem som orsakas av antivirusprogram är sessionsförlust på grund av AppDomain-återvinningar när mappen Bin eller .config-filerna berörs.

Tips

Det enklaste sättet att stänga av tjänster från tredje part är att:

  1. Klicka på Start, klicka på Kör och skriv sedan msconfig.
  2. Välj Tjänster och markera Dölj alla Microsoft-tjänster.
  3. Klicka på Inaktivera alla för att stoppa tjänsterna från tredje part.
  4. Klicka på Start, klicka på Kör och skriv sedan iisreset för att läsa in CLR i arbetsprocessen igen.

Övervaka ditt program för att se om problemet uppstår igen. Om du kör flera antivirusprogram använder du metoden trial-and-error för att avgöra vilket visst program som orsakar problemet.

Obs!

Om samma fel kan återskapas 100 procent av tiden kanske inte ditt antivirusprogram är orsaken. Det kan finnas andra orsaker till det här felet. Prova att skapa ett enkelt ASP.NET testprogram för att isolera om samma fel inträffar för en Test.aspx sida. Om så är fallet kontrollerar du att alla nödvändiga Access Control Listor (ACL: er) finns på plats för ASP.NET.

Se ASP.NET nödvändiga Access Control Listor (ACL:er).

Tips

Mappen %SystemRoot%\Assembly är den globala sammansättningscacheminnet. Du kan inte direkt använda Utforskaren för att redigera ACL:er för den här mappen.

Använd i stället en kommandotolk och kör följande kommando:

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

Innan du använder Utforskaren kan du också avregistrera Shfusion.dll med följande kommando för att ge behörigheter via användargränssnittet:

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

När du har angett behörigheter med Utforskaren registrerar du om Shfusion.dll med följande kommando:

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

Problemet uppstår på grund av att behörigheter saknas för en fjärrresurs som ASP.NET-programmet försöker komma åt

När ditt ASP.NET program har åtkomst till en fjärrresurs som Microsoft SQL Server eller en UNC-resurs (Universal Naming Convention) finns det många saker som kan gå fel. Dessutom kan många saker vara felaktigt konfigurerade på fjärrresursen. Du måste felsöka dessa problem för att få resursen att fungera.

Det första steget är att se om du kan ansluta till fjärrservern via Utforskaren.

  1. Skapa en mapp med namnet Test på fjärrservern. På flikarna Delning och säkerhet i mappen Test lägger du till din domän/ditt konto och även det processkonto som används av ditt ASP.NET program och ger dem båda fullständig kontroll.

  2. Logga in med din domän/ditt konto på IIS-servern, klicka på Start, klicka på Kör och skriv sedan UNC-resurssökvägen för fjärrservern: \\RemoteServerName*\Test.

    Om du inte kan komma åt den här mappen kontaktar du nätverksadministratören för att åtgärda problemet. Först då kan ditt ASP.NET program komma åt resursen.

  3. Skapa en fil med namnet CreateUNCFile.aspx med koden nedan och spara filen i programkatalogen.

    <%@ 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. Kontrollera att du ändrar <RemoteServerName> på följande kodrad

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

    Så att den återspeglar namnet på fjärrservern.

  5. Öppna Windows Internet Explorer och bläddra till http://**IISServerName**/**AppName**/CreateUNCFile.aspx från en annan klientdator än IIS-servern.

  6. Om Test.txt-filen skapas kan ditt ASP.NET-program autentisera till fjärrresursen.

  7. Om det inte går att skapa en fil från en Internet Explorer-klientwebbläsare men fungerar om du bläddrar till samma sida från själva IIS-servern är det troligt att du stöter på ett "Double Hop"-scenario. Om du använder anpassade webbdelar för att komma åt fjärrresurser som kräver användarautentisering och auktorisering stöter du förmodligen på "Double Hop"-problemet. För att få åtkomst till fjärrresursen kan du behöva ange slutanvändarens autentiseringsuppgifter till resursen så att utdata från resursen begränsas till de data som slutanvändaren har behörighet att komma åt.

Stegen ovan förutsätter att du har NTLM-autentisering aktiverat i IIS. Grundläggande autentisering använder inte Kerberos.

Mer information finns i Felsöka Kerberos-fel i Internet Explorer.

Mer information om IIS-autentiseringsmetoder finns i Visual Studio 2003 Tillbakadragen teknisk dokumentation.

Tips

Om du kan ansluta till den fjärranslutna UNC-resursen, men du inte kan ansluta till fjärrservern som kör SQL Server från ASP.NET program, kan du behöva kontrollera eller ange tjänsthuvudnamn (SPN) för SQL Server. Prova att bara aktivera grundläggande autentisering för ditt program i IIS och se om du kan ansluta till fjärrservern som kör SQL Server.

Det finns många andra orsaker till felmeddelandet "Serverprogrammet är inte tillgängligt". Händelseloggen är ditt bästa val för att få mer information om orsaken till problemet.

IIS-loggarna är användbara vid IIS-autentiseringsrelaterade fel.

Det du behöver leta efter är status- och understatuskoderna för det här felet.

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

Vi ser en 401 med understatus 3, som anger "Obehörig på grund av ACL på resursen".

Detta anger saknade NTFS-behörigheter för en fil eller mapp. Det här felet kan inträffa även om behörigheterna är korrekta för filen som du försöker komma åt, men standardbehörigheterna och användarrättigheterna kan saknas i andra SYSTEM- och IIS-mappar. Du kan till exempel se det här felet om IUSR_ComputerName-kontot inte har åtkomst till katalogen C:\Winnt\System32\Inetsrv.

Tips

Klicka på Start, klicka på Kör och skriv sedan logfiles för att öppna mappen som innehåller IIS-loggarna. Du kan också klicka på fliken WebSiteName på egenskapssidan för din webbplats i IIS. Under Aktivt loggformat klickar du på Egenskaper för att se loggfilens katalog och namn.

Det andra intressanta här är statuskoden 5. Du kan använda kommandot net helpmsg för att få mer information om den här statuskoden:

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

Åtkomst nekas.

Nu ska vi prova en annan vanlig statuskod, kod 50:

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

Begäran stöds inte.

Tips

När du får ett annat allmänt ökändt "500 Internt serverfel" är det en bra idé att inaktivera egna HTTP-felmeddelanden, så att du får en detaljerad beskrivning av felet. Glöm inte att titta i loggboken eftersom den också kan innehålla mer information.

Tanken är att använda all loggad information som är tillgänglig för att få maximal information om problemet.

Resurser

Mer information finns i: