Veelvoorkomende problemen met machtigingen en beveiliging in ASP.NET oplossen

In dit artikel wordt uitgelegd hoe u veelvoorkomende problemen met machtigingen en beveiliging in ASP.NET kunt oplossen.

Oorspronkelijke productversie: ASP.NET
Origineel KB-nummer: 910449

Handige hulpprogramma's

Voordat u iets probeert op te lossen dat niet werkt, moet u vertrouwd raken met een aantal hulpprogramma's, waarmee u het probleem kunt beperken. In ons geval zijn we geïnteresseerd in hulpprogramma's zoals FileMon, RegMon en Security Auditing. Zie FileMon voor Windows v7.04 voor meer informatie over FileMon.

Zie Windows Sysinternals voor meer informatie over RegMon.

Inzoomen om het probleem te isoleren

  • Heeft de toepassing ooit gewerkt? Zo ja, wat is er dan veranderd waardoor de toepassing kan zijn onderbroken? Het is mogelijk dat software-updates of beveiligingsupdates zijn toegepast op de server. Een code-implementatie kan het probleem ook hebben veroorzaakt.
  • Dienen eenvoudige .html- en .asp-pagina's vanuit IIS?
  • Is de toepassing gemigreerd naar een andere versie van IIS?
  • Mislukken andere ASP.NET toepassingen op de server met dezelfde fout? Is dit de enige toepassing die mislukt?
  • Treedt het probleem op voor alle gebruikers of alleen voor specifieke gebruikers?
  • Kan het probleem worden gereproduceerd terwijl u lokaal op de webserver bladert of is het reproduceerbaar voor slechts enkele clients?
  • Als u imitatie gebruikt, heeft de geïmiteerde gebruiker dan de benodigde toegang tot de resource?

De bovenstaande vragen zijn handig om een probleem vast te stellen. Als u uw probleem op een van de ASP.NET forums plaatst en als u al de antwoorden op de meeste van deze vragen hebt, krijgt u waarschijnlijk een snelle aanwijzer of oplossing voor uw probleem. De sleutel is om de hele ASP.NET stacktraceringsfout te posten, indien van toepassing, in plaats van te zeggen'Ik krijg een fout Toegang geweigerd tijdens het uitvoeren van mijn ASP.NET-toepassing. Kan iemand helpen? Het is veel gemakkelijker voor iemand om de stacktracering te bekijken en u aanwijzers te geven wanneer ze een volledig foutbericht kunnen zien. Dus je moet jezelf afvragen...

Wat is het exacte foutbericht?

De eerste vraag die we klanten stellen is: 'Wat is het exacte foutbericht?' Als u een duidelijke beschrijving hebt van het foutbericht dat is gegenereerd door de Microsoft .NET Framework, kunt u deze sectie overslaan. Als uw toepassing het werkelijke foutbericht maskert en u in plaats daarvan een vriendelijk foutbericht geeft, zoals 'Er is een onverwachte fout opgetreden. Neem contact op met de beheerder van de website voor meer informatie. Hier volgen enkele stappen, waarmee u het daadwerkelijke foutbericht krijgt.

  • Zoek en open het Web.config-bestand in de toepassingsmap en wijzig customErrors in mode="Uit". Sla het bestand op en reproduceer het probleem.

  • Het is mogelijk dat het daadwerkelijke foutbericht na het uitvoeren van de bovenstaande stap nog steeds niet kan worden weergegeven vanwege aangepaste gebeurtenis-/foutafhandeling die is uitgevoerd door de ontwikkelaar van de toepassing. U kunt proberen de gebeurtenis Application_Error in het bestand Global.asax te vinden en code uit te voeren die de Server.Transfer("Errors.aspx") functie gebruikt om naar een aangepaste foutpagina te gaan.

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

Zodra het werkelijke foutbericht wordt weergegeven, leest u dit om te bepalen of de fout wordt veroorzaakt door ontbrekende machtigingen voor een lokale resource of voor een externe resource waartoe uw ASP.NET toepassing toegang probeert te krijgen.

Tip

U kunt contact opnemen met uw ontwikkelaar om erachter te komen hoe u het daadwerkelijke foutbericht kunt zien. Het is mogelijk dat uw ontwikkelaar de app in een bestand aanmeldt of e-mailmeldingen ontvangt. Vergeet niet om een back-up te maken van een bestand dat u gaat wijzigen. Als er een back-up beschikbaar is, kunt u eventuele wijzigingen altijd terugdraaien.

Probleem treedt op vanwege ontbrekende machtigingen voor een lokale resource waartoe de ASP.NET-toepassing toegang probeert te krijgen

Als u geen duidelijke beschrijving van het probleem kunt krijgen vanwege een aangepast foutbericht, voert u FileMon uit en reproduceert u het probleem. Stop de opname en sla deze op als FileMon.xls en open het bestand in Microsoft Excel. Klik in het menu Gegevens op Filter en klik vervolgens op AutoFilter om de filtermogelijkheden van Excel te gebruiken. Selecteer nu de vervolgkeuzelijst in de kolom F en zoek naar 'TOEGANG GEWEIGERD'-fouten.

Hieronder ziet u een voorbeeld van een FileMon-uitvoer.

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

Zoals u kunt zien in de gefilterde resultaten, hebben we de oorzaak van het probleem beperkt. FileMon laat zien dat er NTFS-machtigingen ontbreken voor het NT AUTHORITY\NETWORK SERVICE-account voor de C:\Winnt\Microsoft.net\Framework\v1.1.4322\Temporary ASP.NET Files map. Dit moet eenvoudig worden opgelost.

Tip

Een goede stap is om het ASP.NET procesaccount te wijzigen in een Beheer-account om te zien of het probleem hiermee is opgelost. In IIS 6.0 en latere versies wijzigt u de IIS AppPool-identiteit in 'Lokaal systeem' om te zien of de toepassing werkt.

Opmerking

Dit moet niet worden gebruikt als oplossing, maar alleen als een probleemoplossingsstap.

De meeste mensen zouden de Microsoft-.NET Framework opnieuw installeren of zelfs het besturingssysteem opnieuw installeren. Dit is geen aanbevolen probleemoplossingsstap en garandeert niet dat het probleem zich niet opnieuw voordoet. Ik zal zo'n voorbeeld geven. Onregelmatige problemen zijn vaak moeilijk te isoleren en op te lossen. In dit scenario zou de toepassing van de klant een paar uur goed werken en dan zou deze plotseling mislukken met de onderstaande fout. De klant heeft al geprobeerd de .NET Framework en het besturingssysteem opnieuw te installeren. Dit leek het probleem een paar dagen op te lossen, maar toen verscheen het opnieuw.

Bij het uitvoeren van FileMon zijn geen fouten weergegeven met TOEGANG GEWEIGERD . Alle benodigde machtigingen voor het ASPNET-account waren aanwezig. De enige manier om het probleem te herstellen, is door het vak opnieuw op te starten. Zelfs een IIS-reset zou niet helpen. U denkt:'Ah, Microsoft Software moet altijd opnieuw worden opgestart om te herstellen?' Je hebt het mis.

De sleutel hier is om het foutbericht goed te bekijken. De fout zegt duidelijk 'kan een bestand niet openen om te schrijven', en niet de gebruikelijke FOUT TOEGANG GEWEIGERD , dus ik denk dat het een ander proces is dat een vergrendeling van een bestand of map vasthoudt en ASP.NET niet toestaat om ernaar te schrijven. Het is logisch dat een herstart het andere proces doodde en de ASP.NET toepassing weer werkt totdat het rogue-proces het bestand opnieuw vergrendelt. Het logische zou zijn om alle antivirusprogramma's, spyware van derden of andere software voor bestandsbewaking die op de server wordt uitgevoerd, uit te schakelen. Ik wil geen specifieke software van derden aanwijzen. Maar over het algemeen is het bekend dat antivirussoftware veel verdriet veroorzaakt voor IIS- en ASP.NET-toepassingen. Een ander bekend probleem dat wordt veroorzaakt door antivirussoftware is sessieverlies als gevolg van het recyclen van AppDomain wanneer de map Bin of de .config bestanden worden aangeraakt.

Tip

De eenvoudigste manier om services van derden uit te schakelen, is door het volgende te doen:

  1. Klik op Start, klik op Uitvoeren en typ msconfig.
  2. Selecteer Services en schakel Alle Microsoft-services verbergen in.
  3. Klik op Alles uitschakelen om de services van derden te stoppen.
  4. Klik op Start, klik op Uitvoeren en typ iisreset om de CLR opnieuw te laden in het werkproces.

Controleer uw toepassing om te zien of het probleem zich opnieuw voordoet. Als u meerdere antivirusprogramma's uitvoert, gebruikt u de trial-and-error-methode om te bepalen welk programma het probleem veroorzaakt.

Opmerking

Als dezelfde fout 100 procent van de tijd reproduceerbaar is, is uw antivirussoftware mogelijk niet de oorzaak. Er kunnen andere oorzaken voor deze fout zijn. Probeer een eenvoudige ASP.NET-testtoepassing te maken om te isoleren of dezelfde fout optreedt voor een Test.aspx-pagina. Als dit het geval is, controleert u of de vereiste Access Control Lijsten (ACL's) allemaal aanwezig zijn voor ASP.NET.

Zie ASP.NET Vereiste Access Control Lijsten (ACL's).

Tip

De %SystemRoot%\Assembly map is de globale assemblycache. U kunt Windows Verkenner niet rechtstreeks gebruiken om ACL's voor deze map te bewerken.

Gebruik in plaats daarvan een opdrachtprompt en voer de volgende opdracht uit:

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

U kunt ook, voordat u Windows Verkenner gebruikt, de registratie van Shfusion.dll ongedaan maken met de volgende opdracht om machtigingen te verlenen via de GUI:

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

Nadat u machtigingen hebt ingesteld met Windows Verkenner, registreert u Shfusion.dll opnieuw met de volgende opdracht:

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

Probleem treedt op vanwege ontbrekende machtigingen voor een externe resource waartoe de ASP.NET-toepassing toegang probeert te krijgen

Wanneer uw ASP.NET toepassing toegang heeft tot een externe resource zoals Microsoft SQL Server of een UNC-share (Universal Naming Convention), zijn er veel dingen die fout kunnen gaan. Ook kunnen veel dingen onjuist zijn ingesteld op de externe resource. U moet deze problemen oplossen om de resource te laten werken.

De eerste stap is om te zien of u verbinding kunt maken met de externe server via Windows Verkenner.

  1. Maak op de externe server een map met de naam Test. Voeg op de tabbladen Delen en beveiliging van de map Test uw domein/account toe, evenals het procesaccount dat wordt gebruikt door uw ASP.NET-toepassing en geef beide volledig beheer.

  2. Meld u op de IIS-server aan met uw domein/account, klik op Start, klik op Uitvoeren en typ vervolgens het UNC-sharepad van de externe server: \\RemoteServerName*\Test.

    Als u deze map niet kunt openen, neemt u contact op met uw netwerkbeheerder om dit probleem op te lossen. Alleen dan heeft uw ASP.NET toepassing toegang tot de share.

  3. Maak een bestand met de naam CreateUNCFile.aspx met de onderstaande code en sla het bestand op in uw toepassingsmap.

    <%@ 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. Zorg ervoor dat u RemoteServerName wijzigt<> in de volgende coderegel

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

    Zodat de naam van uw externe server wordt weergegeven.

  5. Open Windows Internet Explorer en blader naar http://**IISServerName**/**AppName**/CreateUNCFile.aspx vanaf een andere clientcomputer dan de IIS-server.

  6. Als het Test.txt-bestand is gemaakt, kan uw ASP.NET toepassing worden geverifieerd bij de externe resource.

  7. Als het maken van bestanden vanuit een Internet Explorer-clientbrowser mislukt, maar werkt als u vanaf de IIS-server zelf naar dezelfde pagina bladert, is het waarschijnlijk dat u te maken krijgt met een scenario met dubbele hop. Als u aangepaste webonderdelen gebruikt voor toegang tot externe resources waarvoor gebruikersverificatie en autorisatie is vereist, ondervindt u waarschijnlijk het probleem 'Double Hop'. Als u toegang wilt krijgen tot uw externe resource, moet u mogelijk de referenties van de eindgebruiker opgeven voor de resource, zodat de uitvoer van de resource wordt beperkt tot de gegevens waartoe de eindgebruiker gemachtigd is.

In de bovenstaande stappen wordt ervan uitgegaan dat NTLM-verificatie is ingeschakeld in IIS. Basisverificatie maakt geen gebruik van Kerberos.

Zie Kerberos-fouten in Internet Explorer oplossen voor meer informatie.

Zie Technische documentatie voor Visual Studio 2003 buiten gebruik gesteld voor meer informatie over IIS-verificatiemethoden.

Tip

Als u verbinding kunt maken met de externe UNC-share, maar u geen verbinding kunt maken met de externe server waarop SQL Server wordt uitgevoerd vanuit de ASP.NET-toepassing, moet u mogelijk de SPN's (Service Principal Names) voor SQL Server controleren of instellen. Schakel alleen Basisverificatie in voor uw toepassing in IIS en kijk of u verbinding kunt maken met de externe server waarop SQL Server wordt uitgevoerd.

Er zijn tal van andere oorzaken voor het foutbericht 'Servertoepassing niet beschikbaar'. In het gebeurtenislogboek kunt u het beste meer informatie krijgen over de oorzaak van uw probleem.

De IIS-logboeken zijn handig in het geval van iis-verificatiefouten.

Waar u naar moet zoeken, zijn de status- en substatuscodes voor deze specifieke fout.

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

We zien een 401 met de substatus 3, die 'Niet geautoriseerd vanwege ACL op resource' aangeeft.

Dit duidt op ontbrekende NTFS-machtigingen voor een bestand of map. Deze fout kan zelfs optreden als de machtigingen juist zijn voor het bestand dat u probeert te openen, maar de standaardmachtigingen en gebruikersrechten mogelijk ontbreken in andere SYSTEM- en IIS-mappen. Deze fout kan bijvoorbeeld worden weergegeven als het IUSR_ComputerName-account geen toegang heeft tot de map C:\Winnt\System32\Inetsrv.

Tip

Klik op Start, klik op Uitvoeren en typ logfiles om de map met de IIS-logboeken te openen. U kunt ook op de eigenschappenpagina voor uw website in IIS op het tabblad WebSiteName klikken en onder Actieve logboekindeling op Eigenschappen klikken om de map en de naam van het logboekbestand weer te geven.

Het andere wat hier interessant is, is de statuscode 5. U kunt de opdracht net helpmsg gebruiken voor meer informatie over deze statuscode:

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

De toegang wordt geweigerd.

Laten we een andere algemene statuscode proberen, code 50:

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

De aanvraag wordt niet ondersteund.

Tip

Wanneer u een ander algemeen berucht '500 Interne serverfout' ontvangt, is het een goed idee om beschrijvende HTTP-foutberichten uit te schakelen, zodat u een gedetailleerde beschrijving van de fout ontvangt. Vergeet niet om in de logboeken te kijken, omdat deze ook meer informatie kan bevatten.

Het idee is om alle geregistreerde informatie te gebruiken die beschikbaar is om maximale details over het probleem bij de hand te krijgen.

Middelen

Zie voor meer informatie: