Risoluzione dei problemi comuni relativi alle autorizzazioni e alla sicurezza in ASP.NET

Questo articolo illustra come risolvere i problemi comuni relativi alle autorizzazioni e alla sicurezza in ASP.NET.

Versione originale del prodotto: ASP.NET
Numero KB originale: 910449

Strumenti utili

Prima di tentare di riparare qualcosa che è rotto, è necessario acquisire familiarità con alcuni strumenti, che vi aiuteranno a individuare il problema. In questo caso, saremmo interessati a strumenti come FileMon, RegMon e Controllo della sicurezza. Per altre informazioni su FileMon, vedere FileMon per Windows v7.04.

Per altre informazioni su RegMon, vedere Windows Sysinternals.

Esplorare in dettaglio per isolare il problema

• L'applicazione ha mai funzionato? Se sì, cosa è cambiato che potrebbe aver causato l'interruzione dell'applicazione? È possibile che nel server siano stati applicati aggiornamenti software o aggiornamenti della sicurezza. Un'implementazione del codice potrebbe anche aver causato il problema.
• IIS serve pagine .html e .asp semplici?
• L'applicazione è stata migrata a una versione diversa di IIS?
• Le altre applicazioni ASP.NET nel server hanno esito negativo con lo stesso errore? Si tratta dell'unica applicazione che ha esito negativo?
• Il problema si verifica per tutti gli utenti o solo per utenti specifici?
• Il problema è riproducibile durante l'esplorazione locale nel server Web o è riproducibile solo per pochi client?
• Se si usa la rappresentazione, l'utente rappresentato ha l'accesso necessario alla risorsa?

Le domande precedenti sono utili per diagnosticare un problema. Se stai pubblicando il problema su uno dei forum di ASP.NET e se hai già le risposte alla maggior parte di queste domande, è probabile che riceverai un puntatore rapido o una soluzione al problema. La chiave consiste nel pubblicare l'intero errore di analisi dello stack ASP.NET, se applicabile, anziché pronunciare "Viene visualizzato un errore di accesso negato durante il tentativo di eseguire l'applicazione ASP.NET. Qualcuno può aiutare? È più semplice per qualcuno esaminare la traccia dello stack e fornire suggerimenti quando può visualizzare un messaggio di errore completo. Quindi devi chiederti...

Qual è il messaggio di errore esatto?

La prima domanda che chiediamo ai clienti è"Qual è il messaggio di errore esatto?" Se si dispone di una descrizione chiara del messaggio di errore generato da Microsoft .NET Framework, è possibile ignorare questa sezione. Se l'applicazione maschera il messaggio di errore effettivo e fornisce un messaggio di errore descrittivo, ad esempio "Si è verificato un errore imprevisto. Per informazioni dettagliate, contattare l'amministratore del sito Web", non è molto usato per nessuno. Ecco alcuni passaggi che consentono di ottenere il messaggio di errore effettivo.

• Individuare e aprire il file Web.config nella directory dell'applicazione e modificare customErrors in mode="Off". Salvare il file e riprodurre il problema.

• Potrebbe comunque non essere possibile visualizzare il messaggio di errore effettivo dopo aver seguito il passaggio precedente a causa della gestione personalizzata degli eventi o degli errori eseguita dallo sviluppatore dell'applicazione. È possibile provare a individuare l'evento Application_Error nel file Global.asax e impostare come commento qualsiasi codice che usa la Server.Transfer("Errors.aspx") funzione per passare a una pagina di errore personalizzata.

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

Dopo aver visualizzato il messaggio di errore effettivo, leggerlo per determinare se l'errore è causato da autorizzazioni mancanti per una risorsa locale o per una risorsa remota a cui sta tentando di accedere l'applicazione ASP.NET.

Il problema si verifica a causa di autorizzazioni mancanti per una risorsa locale a cui l'applicazione ASP.NET tenta di accedere

Se non è possibile ottenere una descrizione chiara del problema a causa di un messaggio di errore personalizzato, eseguire FileMon e riprodurre il problema. Arrestare e salvare l'acquisizione come FileMon.xls e aprire il file in Microsoft Excel. Scegliere Filtro dal menu Dati e quindi selezionare Filtro automatico per usare le funzionalità di filtro di Excel. Selezionare ora l'elenco a discesa nella colonna F e cercare gli errori "ACCESSO NEGATO".

Di seguito è riportato un output FileMon di esempio.

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

Come si può notare dai risultati filtrati, è stata ridotta la causa del problema. FileMon mostra che l'account NT AUTHORITY\NETWORK SERVICE non dispone delle autorizzazioni NTFS per la C:\Winnt\Microsoft.net\Framework\v1.1.4322\Temporary ASP.NET Files cartella. Questo dovrebbe essere facile da risolvere.

La maggior parte delle persone tende a reinstallare Microsoft .NET Framework o addirittura a reinstallare il sistema operativo. Questo passaggio non è consigliato per la risoluzione dei problemi e non garantisce che il problema non si verifica nuovamente. Fornirò un esempio del genere. I problemi intermittenti sono spesso difficili da isolare e risolvere i problemi. In questo scenario l'applicazione del cliente funzionerà correttamente per alcune ore, quindi tutto all'improvviso avrà esito negativo con l'errore riportato di seguito. Il cliente aveva già provato a reinstallare .NET Framework e il sistema operativo. Questo sembrava risolvere il problema per alcuni giorni, ma poi è apparso di nuovo.

L'esecuzione di FileMon non mostra errori DI ACCESSO NEGATO . Tutte le autorizzazioni necessarie per l'account ASPNET sono state applicate. L'unico modo per risolvere il problema consiste nel riavviare il dispositivo. Anche una reimpostazione di IIS non sarebbe utile. Stai pensando che "Ah, Software Microsoft ha sempre bisogno di un riavvio per il ripristino?" Beh, hai sbagliato!

La chiave qui è esaminare attentamente il messaggio di errore. L'errore indica chiaramente che "non è possibile aprire un file per la scrittura" e non il solito errore DI ACCESSO NEGATO , quindi sto pensando che si tratta di un altro processo che contiene un blocco su un file o una cartella e non consentendo ASP.NET di scrivere in esso. Ha senso che un riavvio stava uccidendo l'altro processo e l'applicazione ASP.NET inizia a funzionare di nuovo fino a quando il processo non autorizzato blocca nuovamente il file. La cosa logica da fare sarebbe disattivare tutti i programmi antivirus, spyware di terze parti o qualsiasi altro software di monitoraggio dei file eseguito sul server. Non voglio sottolineare alcun software specifico di terze parti. Tuttavia, in generale, è noto che il software antivirus crea molti problemi alle applicazioni IIS e ASP.NET. Un altro problema noto causato dal software antivirus è la perdita di sessione a causa del riciclo di AppDomain quando vengono toccati la cartella Bin o i file con estensione config.

Monitorare l'applicazione per verificare se il problema persiste. Se si eseguono più programmi antivirus, utilizzare il metodo trial-and-error per determinare quale particolare programma sta causando il problema.

Vedere ASP.NET Elenchi di Controllo di accesso obbligatori (ACL).

Usare invece un prompt dei comandi ed eseguire il comando seguente:

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

In alternativa, prima di usare Windows Explorer, annullare la registrazione di Shfusion.dll con il comando seguente per concedere le autorizzazioni tramite la GUI.

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

Dopo aver impostato le autorizzazioni con Esplora File, registrare nuovamente Shfusion.dll con il comando seguente:

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

Il problema si verifica a causa di autorizzazioni mancanti per una risorsa remota a cui l'applicazione ASP.NET sta tentando di accedere

Quando l'applicazione ASP.NET accede a una risorsa remota, ad esempio Microsoft SQL Server o una condivisione UNC (Universal Naming Convention), esistono molte cose che possono andare storte. Inoltre, molte cose potrebbero non essere configurate correttamente nella risorsa remota. È necessario risolvere questi problemi per ottenere il funzionamento della risorsa.

Il primo passaggio consiste nel verificare se è possibile connettersi al server remoto tramite Esplora risorse.

1. Nel server remoto creare una cartella denominata Test. Nelle schede Condivisione e sicurezza della cartella Test aggiungere il dominio o l'account e anche l'account di processo usato dall'applicazione ASP.NET e assegnare entrambi controllo completo.

2. Nel server IIS accedere con il dominio o l'account, selezionare Avvia, selezionare Esegui e quindi digitare il percorso di condivisione UNC del server remoto: \\RemoteServerName*\Test.

   Se non è possibile accedere a questa cartella, contattare l'amministratore di rete per risolvere il problema. Solo in questo caso l'applicazione ASP.NET accede alla condivisione.

3. Creare un file denominato CreateUNCFile.aspx con il codice seguente e salvare il file nella directory dell'applicazione.

   <%@ 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. Assicurarsi di modificare <RemoteServerName> nella riga di codice seguente

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

   In modo che rifletta il nome del server remoto.

5. Aprire Windows Internet Explorer e navigare su http://**IISServerName**/**AppName**/CreateUNCFile.aspx da un computer client diverso dal server IIS.

6. Se il file Test.txt viene creato correttamente, l'applicazione ASP.NET può eseguire l'autenticazione alla risorsa remota.

7. Se la creazione di file non riesce da un browser client di Internet Explorer, ma funziona se si passa alla stessa pagina dal server IIS stesso, è probabile che si stia eseguendo uno scenario "Double Hop". Se si usano Web Part personalizzate create su misura per accedere a risorse remote che richiedono l'autenticazione e l'autorizzazione dell'utente, probabilmente si verificherà il problema del "Double Hop". Per accedere alla risorsa remota, potrebbe essere necessario fornire le credenziali dell'utente finale alla risorsa in modo che l'output della risorsa sia limitato ai dati a cui l'utente finale ha l'autorizzazione per accedere.

I passaggi precedenti presuppongono che l'autenticazione NTLM sia attivata in IIS. L'autenticazione di base non usa Kerberos.

Per altre informazioni, vedere Risolvere gli errori Kerberos in Internet Explorer.

Per altre informazioni sui metodi di autenticazione IIS, vedere la documentazione tecnica ritirata di Visual Studio 2003.

Esistono numerose altre cause per il messaggio di errore "Applicazione server non disponibile". Il registro eventi è la scelta migliore per ottenere altri dettagli sulla causa del problema.

Errori correlati a IIS

I log IIS sono utili in caso di errori correlati all'autenticazione IIS.

Quello che è necessario cercare è lo stato e i codici di stato secondari per questo particolare errore.

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

Viene visualizzato un valore 401 con lo stato secondario 3, che indica "Non autorizzato a causa dell'ACL sulla risorsa".

Indica le autorizzazioni NTFS mancanti per un file o una cartella. Questo errore può verificarsi anche se le autorizzazioni sono corrette per il file a cui si sta tentando di accedere, ma le autorizzazioni predefinite e i diritti utente potrebbero non essere presenti in altre cartelle SYSTEM e IIS. Ad esempio, è possibile che venga visualizzato questo errore se l'account IUSR_ComputerName non ha accesso alla directory C:\Winnt\System32\Inetsrv.

L'altra cosa di interesse è il codice di stato 5. È possibile usare il comando net helpmsg per ottenere altre informazioni su questo codice di stato:

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

Accesso negato.

Si proverà ora un altro codice di stato comune, codice 50:

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

La richiesta non è supportata.

L'idea è quella di usare tutte le informazioni registrate disponibili per ottenere i dettagli massimi sul problema a portata di mano.

Risorse

Per altre informazioni, vedi:

• Introduzione ad ASP.NET Identity

• Come creare un account del servizio per un'applicazione ASP.NET 2.0

• Come compilare applicazioni ASP.NET protette: autenticazione, autorizzazione e comunicazioni protette