Solución de problemas comunes relacionados con los permisos y la seguridad en ASP.NET

En este artículo se presenta cómo solucionar problemas comunes relacionados con los permisos y la seguridad en ASP.NET.

              Versión original del producto: ASP.NET
Número de KB original: 910449

Herramientas útiles

Antes de intentar corregir todo lo que está roto, debe familiarizarse con algunas herramientas, lo que le ayudará a reducir el problema. En nuestro caso, nos interesarían herramientas como FileMon, RegMon y Auditoría de seguridad. Para obtener más información sobre FileMon, vea FileMon para Windows v7.04.

Para obtener más información sobre RegMon, vea Windows Sysinternals.

Explorar en profundidad para aislar el problema

• ¿Ha funcionado alguna vez la aplicación? Si es así, ¿qué cambio podría haber hecho que la aplicación se interrumpa? Es posible que se hayan aplicado actualizaciones de software o actualizaciones de seguridad en el servidor. Un lanzamiento de código también podría haber causado el problema.
• ¿Las páginas de .html y .asp sencillas sirven desde IIS?
• ¿Se migró la aplicación a otra versión de IIS?
• ¿Otras aplicaciones ASP.NET del servidor producen el mismo error? ¿Es esta la única aplicación que produce un error?
• ¿Se produce el problema para todos los usuarios o solo para usuarios específicos?
• ¿El problema se puede reproducir al examinar localmente en el servidor web o solo se puede reproducir para unos pocos clientes?
• Si usa la suplantación, ¿el usuario suplantado tiene el acceso necesario al recurso?

Las preguntas anteriores son útiles para diagnosticar un problema. Si va a publicar su problema en cualquiera de los foros de ASP.NET y si ya tiene las respuestas a la mayoría de estas preguntas, es probable que obtenga un puntero rápido o una solución a su problema. La clave es publicar todo el ASP.NET error de seguimiento de pila, si procede, en lugar de decir "Recibo un error de acceso denegado al intentar ejecutar mi aplicación ASP.NET. ¿Alguien puede ayudar?" Es mucho más fácil que alguien examine el seguimiento de la pila y le proporcione punteros cuando pueda ver un mensaje de error completo. Así que tienes que preguntarte a ti mismo...

¿Cuál es el mensaje de error exacto?

La primera pregunta que hacemos a los clientes es"¿ Cuál es el mensaje de error exacto?" Si tiene una descripción clara del mensaje de error generado por Microsoft .NET Framework, puede omitir esta sección. Si la aplicación enmascara el mensaje de error real y le proporciona un mensaje de error descriptivo en su lugar, por ejemplo, "Se ha producido un error inesperado. Póngase en contacto con el administrador del sitio web para obtener más información", no es de gran utilidad para nadie. Estos son algunos pasos que le ayudarán a obtener el mensaje de error real.

• Busque y abra el archivo Web.config en el directorio de la aplicación y cambie customErrors a mode="Off". Guarde el archivo y reproduzca el problema.

• Es posible que no sea posible ver el mensaje de error real después de seguir el paso anterior debido al control personalizado de errores o eventos realizado por el desarrollador de la aplicación. Puede intentar localizar el evento Application_Error en el archivo Global.asax y comentar cualquier código que use la Server.Transfer("Errors.aspx") función para ir a una página de error personalizada.

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

Una vez que reciba el mensaje de error real, léelo para determinar si el error se debe a la falta de permisos en un recurso local o en un recurso remoto al que está intentando acceder la aplicación ASP.NET.

El problema se produce debido a que faltan permisos en un recurso local al que intenta acceder la aplicación ASP.NET

Si no puede obtener una descripción clara del problema debido a un mensaje de error personalizado, ejecute FileMon y reproduzca el problema. Detenga y guarde la captura como FileMon.xls y abra el archivo en Microsoft Excel. En el menú Datos , haga clic en Filtrary, a continuación, haga clic en Autofiltro para usar las funcionalidades de filtrado de Excel. Ahora, seleccione la lista desplegable en la columna F y busque errores de "ACCESO DENEGADO".

A continuación se muestra una salida filemon de ejemplo.

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

Como puede ver en los resultados filtrados, hemos reducido la causa del problema. FileMon muestra que a la cuenta NT AUTHORITY\NETWORK SERVICE le faltan permisos NTFS en la C:\Winnt\Microsoft.net\Framework\v1.1.4322\Temporary ASP.NET Files carpeta. Esto debería ser directo para corregirlo.

La mayoría de las personas tienden a reinstalar Microsoft .NET Framework o incluso a volver a instalar el sistema operativo. Este no es un paso de solución de problemas recomendado y no garantiza que el problema no se repita. Voy a proporcionar un ejemplo de este tipo. Los problemas intermitentes suelen ser difíciles de aislar y solucionar. En este escenario, la aplicación del cliente funcionaría bien durante unas horas y, de repente, se produciría un error con el siguiente error. El cliente ya había intentado volver a instalar .NET Framework, así como el sistema operativo. Esto parecía solucionar el problema durante unos días, pero luego volvió a aparecer.

La ejecución de FileMon no mostró ningún error ACCESS DENIED . Se han implementado todos los permisos necesarios para la cuenta aspnet. La única manera de recuperarse del problema es reiniciar el cuadro. Incluso un restablecimiento de IIS no sería de ayuda. Está pensando "Ah, Microsoft Software siempre necesita un reinicio para recuperarse?" ¡Bueno, te equivocas!

La clave aquí es examinar detenidamente el mensaje de error. El error indica claramente que "no se puede abrir un archivo para escribir" y no el error ACCESS DENIED habitual, por lo que pienso que es algún otro proceso el que mantiene un bloqueo en un archivo o carpeta y no permite que ASP.NET escriba en él. Tiene sentido que un reinicio esté acabando con el otro proceso y que la aplicación ASP.NET empiece a funcionar de nuevo hasta que el proceso no autorizado bloquee de nuevo el archivo. Lo lógico sería desactivar todos los programas antivirus, spyware de terceros o cualquier otro software de supervisión de archivos que se ejecute en el servidor. No quiero señalar ningún software específico de terceros. Pero, en general, se sabe que el software antivirus causa mucho dolor para IIS y las aplicaciones ASP.NET. Otro problema conocido causado por el software antivirus es la pérdida de sesión debido a los reciclajes de AppDomain cuando se toca la carpeta Bin o los archivos .config.

Supervise la aplicación para ver si el problema se repite. Si ejecuta varios programas antivirus, use el método de prueba y error para determinar qué programa determinado está causando el problema.

Consulte ASP.NET Access Control Listas requeridas (ACL).

En su lugar, use un símbolo del sistema y ejecute el siguiente comando:

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

Como alternativa, antes de usar el Explorador de Windows, anule el registro de Shfusion.dll con el siguiente comando para conceder permisos a través de la GUI:

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

Después de establecer permisos con el Explorador de Windows, vuelva a registrar Shfusion.dll con el siguiente comando:

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

El problema se produce debido a que faltan permisos en un recurso remoto al que la aplicación ASP.NET está intentando acceder.

Cuando la aplicación ASP.NET accede a un recurso remoto como Microsoft SQL Server o un recurso compartido de convención de nomenclatura universal (UNC), hay muchas cosas que pueden salir mal. Además, muchas cosas pueden estar configuradas incorrectamente en el recurso remoto. Tendrá que solucionar esos problemas para que el recurso funcione.

El primer paso sería ver si puedes conectarte al servidor remoto a través del Explorador de Windows.

1. En el servidor remoto, cree una carpeta denominada Prueba. En las pestañas Compartir y seguridad de la carpeta Prueba, agregue su dominio o cuenta, así como la cuenta de proceso que usa la aplicación ASP.NET, y asígneles control total.

2. En el servidor IIS, inicie sesión con su dominio o cuenta, haga clic en Inicio, en Ejecutary, a continuación, escriba la ruta de acceso de recurso compartido UNC del servidor remoto: \\RemoteServerName*\Test.

   Si no puede acceder a esta carpeta, póngase en contacto con el administrador de red para solucionar este problema. Solo entonces puede la aplicación ASP.NET acceder al recurso compartido.

3. Cree un archivo denominado CreateUNCFile.aspx con el código siguiente y guarde el archivo en el directorio de la aplicación.

   <%@ 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. Asegúrese de modificar <RemoteServerName> en la siguiente línea de código.

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

   Para que refleje el nombre del servidor remoto.

5. Abra Windows Internet Explorer y vaya a http://**IISServerName**/**AppName**/CreateUNCFile.aspx desde un equipo cliente distinto del servidor IIS.

6. Si el archivo Test.txt se crea correctamente, la aplicación ASP.NET puede autenticarse en el recurso remoto.

7. Si se produce un error en la creación de archivos desde un explorador cliente de Internet Explorer, pero funciona si va a la misma página desde el propio servidor IIS, es probable que se encuentre en un escenario de "salto doble". Si usa elementos web personalizados compilados para acceder a recursos remotos que requieren autenticación y autorización del usuario, probablemente se encontrará con el problema de "salto doble". Para acceder al recurso remoto, es posible que tenga que proporcionar las credenciales del usuario final al recurso para que la salida del recurso se limite a los datos a los que el usuario final tiene permiso para acceder.

En los pasos anteriores se supone que la autenticación NTLM está activada en IIS. La autenticación básica no usa Kerberos.

Para obtener más información, consulte Solución de errores de Kerberos en Internet Explorer.

Para obtener más información sobre los métodos de autenticación de IIS, consulte la documentación técnica retirada de Visual Studio 2003.

Hay muchas otras causas para el mensaje de error "Aplicación de servidor no disponible". El registro de eventos es la mejor opción para obtener más detalles sobre la causa del problema.

Errores relacionados con IIS

Los registros de IIS son útiles en casos de errores relacionados con la autenticación de IIS.

Lo que debe buscar son los códigos de estado y subestado de este error en particular.

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

Vemos un 401 con el subestado 3, que indica "No autorizado debido a ACL en el recurso".

Esto indica que faltan permisos NTFS en un archivo o carpeta. Este error puede producirse incluso si los permisos son correctos para el archivo al que está intentando acceder, pero es posible que falten los permisos predeterminados y los derechos de usuario en otras carpetas SYSTEM e IIS. Por ejemplo, puede ver este error si la cuenta de IUSR_ComputerName no tiene acceso al directorio C:\Winnt\System32\Inetsrv.

La otra cosa de interés aquí es el código de estado 5. Puede usar el comando net helpmsg para obtener más información sobre este código de estado:

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

Acceso denegado.

Vamos a probar otro código de estado común, el código 50:

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

No se admite la solicitud.

La idea es usar toda la información registrada disponible para obtener los máximos detalles sobre el problema en cuestión.

Recursos

Para obtener más información, consulte:

• Introducción a ASP.NET Identity

• Creación de una cuenta de servicio para una aplicación ASP.NET 2.0

• Creación de aplicaciones de ASP.NET seguras: autenticación, autorización y comunicación segura