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

  • Artículo
  • Tiempo de lectura: 12 minutos

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

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

Herramientas útiles

Antes de intentar corregir cualquier cosa que esté rota, 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 acerca de FileMon, vea FileMon for Windows v7.04.

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

Profundizar para aislar el problema

  • ¿Alguna vez ha funcionado la aplicación? If yes, then what changed that could have made the application break? 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 .html sencillas y las páginas .asp sirven desde IIS?
  • ¿Se ha migrado la aplicación a una versión diferente de IIS?
  • ¿Otras ASP.NET en el servidor fallan con el mismo error? ¿Es la única aplicación que falla?
  • ¿Se produce el problema para todos los usuarios o solo para usuarios específicos?
  • ¿El problema se puede reproducir mientras se explora 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 el problema en cualquiera de los foros de ASP.NET y ya tiene las respuestas a la mayoría de estas preguntas, es probable que obtenga un puntero rápido o una solución al problema. La clave es publicar todo el error de seguimiento de la pila de ASP.NET, si procede, en lugar de decir "Obtención de un error de acceso denegado al intentar ejecutar mi ASP.NET aplicación. ¿Alguien puede ayudar?" Es mucho más fácil que alguien vea el seguimiento de la pila y le dé punteros cuando pueda ver un mensaje de error completo. Por lo tanto, debes 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 lanzado 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", que no es de gran 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 aplicaciones y cambie customErrors a mode="Off". Guarde el archivo y reproduzca el problema.

  • Es posible que aún no sea posible ver el mensaje de error real después de seguir el paso anterior debido al control personalizado de eventos o errores 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 función para ir Server.Transfer("Errors.aspx") 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éalo para determinar si el error se debe a la falta de permisos en un recurso local o en un recurso remoto al que la aplicación ASP.NET está intentando tener acceso.

Sugerencia

Puedes ponerse en contacto con el desarrollador para averiguar cómo ver el mensaje de error real. Es posible que el desarrollador lo esté registrando en un archivo o recibiendo 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 cualquier cambio.

El problema se produce debido a la falta de permisos en un recurso local al que la 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, haga clic en Filtrar y, a continuación, haga clic en Autofiltro para usar las funciones de filtrado de Excel. Ahora seleccione la lista desplegable en la columna y F busque los errores "ACCESO DENEGADO".

A continuación se muestra una salida de 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 no tiene permisos NTFS en la C:\Winnt\Microsoft.net\Framework\v1.1.4322\Temporary ASP.NET Files carpeta. Esto debe ser directamente para corregir.

Sugerencia

Un buen paso sería cambiar la cuenta 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 debe usarse como una solución, sino solo como un paso de solución de problemas.

La mayoría de las personas tienden a reinstalar microsoft .NET Framework o incluso ir hasta el punto de reinstalar el sistema operativo. Este no es un paso de solución de problemas recomendado y no garantiza que el problema no vuelva a ocurrir. 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 reinstalar el .NET Framework, así como el sistema operativo. Esto pareció solucionar el problema durante unos días, pero volvió a aparecer.

La ejecución de FileMon no muestra ningún error ACCESS DENIED. Se han puesto en marcha todos los permisos necesarios para la cuenta ASPNET. La única forma de recuperarse del problema es reiniciar el cuadro. Incluso un restablecimiento de IIS no ayuda. ¿Cree que Microsoft Software siempre necesita un reinicio para recuperarse? Bueno, estás equivocado.

La clave aquí es mirar de cerca el mensaje de error. El error claramente indica "no se puede abrir un archivo para escribir" y no el error ACCESS DENIED habitual, por lo que estoy pensando que es otro proceso que mantiene un bloqueo en un archivo o carpeta y no permite que ASP.NET escribir en él. Tiene sentido que un reinicio matara al otro proceso y la aplicación ASP.NET empezara a funcionar de nuevo hasta que el proceso no fiable vuelva a bloquear 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 de terceros específico. Pero, en general, se sabe que el software antivirus causa mucho dolor para IIS y ASP.NET aplicaciones. 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 .config archivos.

Sugerencia

La forma más sencilla de desactivar servicios de terceros es:

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

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

Nota

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

Vea ASP.NET listas de control de acceso obligatorias (ACL).

Sugerencia

La %SystemRoot%\Assembly carpeta es la caché global de ensamblados. No puede usar directamente el 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 Windows Explorer, desinscriba 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 Windows explorer, vuelva a registrar Shfusion.dll con el siguiente comando:

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

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

Cuando la aplicación ASP.NET está accediendo a un recurso remoto como Microsoft SQL Server o un recurso compartido de la 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. Deberá solucionar estos problemas para que el recurso funcione.

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

  1. En el servidor remoto, cree una carpeta denominada Test. En las pestañas Uso compartido 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í mismo déles control total.

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

    Si no puede llegar a esta carpeta, póngase en contacto con el administrador de red para solucionar este problema. Solo entonces la aplicación ASP.NET acceso 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 desde un equipo cliente que no http://**IISServerName**/**AppName**/CreateUNCFile.aspx sea el servidor IIS.

  6. Si el 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 navega a la misma página desde el propio servidor IIS, es probable que se esté ejecutando en un escenario de "salto doble". Si está usando una elementos web personalizada para obtener acceso a recursos remotos que requieren autenticación y autorización de usuario, probablemente se encontrará con el problema de "salto doble". Para obtener acceso al recurso remoto, es posible que deba proporcionar las credenciales del usuario final al recurso para que el resultado del recurso se limite a los datos a los que el usuario final tiene permiso de acceso.

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, vea Troubleshoot Kerberos failures in Internet Explorer.

Para obtener más información sobre los métodos de autenticación de IIS, vea Visual Studio documentación técnica retirada de 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 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 se ejecuta SQL Server.

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.

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

Lo que necesita buscar es los códigos de estado y sub estado 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 substatus 3, que indica "Unauthorized due to ACL on resource".

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 obtener acceso, pero los permisos y derechos de usuario predeterminados pueden faltar en otras carpetas de SYSTEM e IIS. Por ejemplo, puede que vea este error si la cuenta IUSR_ComputerName no tiene acceso al directorio C:\Winnt\System32\Inetsrv.

Sugerencia

Haga clic en Inicio , en Ejecutar y, a continuación, escriba archivos de registro para abrir la carpeta que contiene los registros de IIS. Como alternativa, en la página de propiedades del sitio web de IIS, haga clic en la pestaña WebSiteName y, en Formato de registro activo, haga clic en 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. Puedes 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.

Sugerencia

Siempre que reciba otro mensaje genérico infame "Error de servidor interno 500", es buena idea deshabilitar los mensajes de error HTTP descriptivos, de modo 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 los máximos detalles sobre el problema en la mano.

Resources

Para más información, vea: