Compartir a través de

Solución de problemas comunes relacionados con la seguridad y los permisos 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 cualquier cosa que se rompa, debe familiarizarse con algunas herramientas, lo que le ayudará a reducir el problema. En nuestro caso, estaríamos interesados en 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, consulta Windows Sysinternals.

Explorar en profundidad para aislar el problema

  • ¿Ha funcionado alguna vez la aplicación? Si es así, ¿qué pudo haber cambiado para que la aplicación dejara de funcionar? Es posible que se apliquen 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 .html y .asp sencillas sirven desde IIS?
  • ¿Se migró la aplicación a otra versión de IIS?
  • ¿Fallan otras aplicaciones ASP.NET en el servidor con 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?
  • ¿Es el problema reproducible al navegar localmente en el servidor web o es reproducible solo 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 publica 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 error de seguimiento de la pila de ASP.NET, si procede, en lugar de decir "Estoy obteniendo un error de acceso denegado al intentar ejecutar mi aplicación de ASP.NET". ¿Alguien puede ayudar? Es más fácil que alguien examine la traza de la pila y le proporcione consejos cuando puede ver un mensaje de error completo. Así que necesitas preguntarte...

¿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 producido 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, 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 mucho uso 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 modo="Off". Guarde el archivo e intente reproducir el problema.

  • Es posible que no sea posible ver el mensaje de error real después de seguir el paso anterior debido al control de errores o eventos personalizados realizados por el desarrollador de aplicaciones. 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 que faltan permisos en un recurso local o en un recurso remoto al que la aplicación de ASP.NET está intentando acceder.

Sugerencia

Puede ponerse en contacto con el desarrollador para averiguar cómo ver el mensaje de error real. Es posible que el desarrollador pueda registrarlo en un archivo o recibir notificaciones por correo electrónico. Recuerde siempre realizar una copia de seguridad de cualquier archivo que vaya a cambiar. Con una copia de seguridad disponible, siempre puede revertir los cambios.

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

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 , seleccione Filtrar y, a continuación, seleccione 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 la cuenta NT AUTHORITY\NETWORK SERVICE faltan permisos NTFS en la C:\Winnt\Microsoft.net\Framework\v1.1.4322\Temporary ASP.NET Files carpeta. Esto debe ser sencillo para corregir.

Sugerencia

Un buen paso sería cambiar la cuenta de proceso de ASP.NET a una cuenta de administrador para ver si corrige el problema. En IIS 6.0 y versiones posteriores, cambiaría la identidad de AppPool de IIS a "Sistema local" para ver si la aplicación funciona.

Nota:

Esto no se debe usar como solución, sino solo como paso de solución de problemas.

La mayoría de las personas tienden a reinstalar Microsoft .NET Framework o incluso ir a la medida de 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. 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, fallaría con el error que se muestra a continuación. El cliente ya había intentado reinstalar .NET Framework y el sistema operativo. Esto parecía corregir el problema durante unos días, pero luego volvió a aparecer.

Al ejecutar FileMon no se mostraron errores de ACCESO DENEGADO. Se han implementado todos los permisos necesarios para la cuenta de ASPNET. La única manera de resolver el problema es reiniciar la caja. Incluso un restablecimiento de IIS no sería útil. Está pensando en "Ah, Microsoft Software siempre necesita un reinicio para recuperarse?" Bueno, ¡estás equivocado!

La clave aquí es examinar detenidamente el mensaje de error. El error dice claramente "no se puede abrir un archivo para escribir", y no el error habitual ACCESS DENIED , por lo que pienso que es otro proceso que contiene un bloqueo en un archivo o carpeta y no permite que ASP.NET escribir en él. Tiene sentido que un reinicio estaba matando al otro proceso y la aplicación ASP.NET comienza a funcionar de nuevo hasta que el proceso no autorizado bloquea el archivo de nuevo. Lo lógico que debe hacer 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 en las aplicaciones IIS y 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.

Sugerencia

La manera más fácil de desactivar los servicios de terceros es:

  1. Seleccione Inicio, Ejecutar y, a continuación, escriba msconfig.
  2. Seleccione Servicios y active Ocultar todos los servicios de Microsoft.
  3. Seleccione Deshabilitar todo para detener los servicios de terceros.
  4. Seleccione Iniciar, seleccione Ejecutar y, a continuación, escriba iisreset para volver a cargar el CLR en el proceso de trabajo.

Supervise la aplicación para ver si el problema se repite. Si ejecuta varios programas antivirus, use el método trial-and-error para determinar qué programa concreto está causando el problema.

Nota:

Si el mismo error es reproducible el 100 % del tiempo, es posible que el software antivirus no sea la causa. Puede haber otras causas de este error. Intente crear una aplicación de prueba de ASP.NET sencilla para aislar si se produce el mismo error para una página de Test.aspx. Si lo hace, compruebe que todas las listas de control de acceso (ACL) necesarias están en vigor para ASP.NET.

Consulte las listas de control de acceso (ACL) necesarias de ASP.NET.

Sugerencia

La %SystemRoot%\Assembly carpeta es la caché global de ensamblaje. No puedes usar directamente el Explorador de Windows para editar las ACL de esta carpeta.

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 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 comando siguiente:

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 de 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 ir mal. Además, es posible que muchas cosas se configuren incorrectamente en el recurso remoto. Debe solucionar esos problemas para que el recurso funcione.

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

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

  2. En el servidor IIS, inicie sesión con su dominio o cuenta, seleccione Inicio, Ejecutar y, a continuación, escriba la ruta de acceso del 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 corregir este problema. Solo entonces la aplicación de ASP.NET puede 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 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 navega a la misma página desde el propio servidor IIS, es probable que se esté ejecutando en un escenario de "doble salto". Si usa elementos web integrados personalizados para acceder a recursos remotos que requieren autenticación y autorización de usuario, probablemente se encontrará con el problema de "doble salto". Para acceder al recurso remoto, es posible que tenga que proporcionar las credenciales del usuario final al recurso para que la salida del recurso esté limitada a los datos a los que el usuario final tiene permiso para acceder.

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

Para obtener más información, vea Solución de problemas 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.

Sugerencia

Si puede conectarse al recurso compartido UNC remoto, pero no puede conectarse al servidor remoto que ejecuta SQL Server desde la aplicación de ASP.NET, es posible que tenga que comprobar o establecer los nombres de entidad de seguridad de servicio (SPN) para SQL Server. Intente habilitar solo la autenticación básica para la aplicación en IIS y vea si puede conectarse al servidor remoto que ejecuta SQL Server.

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

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

Lo que necesita buscar es el estado y los códigos de subestado para 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 intenta 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.

Sugerencia

Seleccione Iniciar, seleccione Ejecutar y escriba logfiles para abrir la carpeta que contiene los registros de IIS. Como alternativa, en la página de propiedades del sitio web en IIS, seleccione la pestaña WebSiteName y, en Formato de registro activo, seleccione Propiedades para ver el directorio y el nombre del archivo de registro.

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

Se denegó el acceso.

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

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

No se admite la solicitud.

Sugerencia

Cada vez que obtenga otro mensaje genérico e infame de "500 Error Interno del Servidor", es una buena idea deshabilitar los mensajes de error HTTP amigables, para que reciba una descripción detallada del error. No olvide buscar en el visor de eventos, ya que también puede contener más información.

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

Recursos

Para más información, vea: