Solucionar permisos normales y problemas relacionados con la seguridad en ASP.NET

Esto proviene A.G de Vignesh del equipo ASP.NET. Agradezca a la columna Voz de Compatibilidad de ASP.NET! Me he encontrado un Ingeniero de soporte técnico para desarrolladores ahora en Microsoft más de por dos años e invertido mi tiempo que me estoy centrando en ASP.NET y Servicios de Microsoft Internet Information Server (IIS).

El foco de esta columna no será explicar seguridad de ASP.NET pero describir algunas técnicas y sugerencias que le ayudarán a resuelven algunos y a que aísla para solución de problemas. Los permisos y problemas relacionados con la seguridad en ASP.NET se documentan muy bien. Habrá de hecho un número bueno de personas que se podrían haber quedado en el mismo problema antes de usted. Por lo tanto, la intención es que esta columna es un punto de partida bueno encontrar información relevante y exhaustiva sobre seguridad de ASP.NET. No hay ningún sentimiento mejor que corrige el problema usted.

Herramientas útiles

Antes de intentar corregir algo que está roto, se debe familiarizar con algunas herramientas que le ayudarán a reducir el problema. En nuestro caso, nosotros estaremos interesados en herramientas similares a FileMon, a RegMon y a auditoría de seguridad. Para más información acerca de FileMon, visite el sitio Web de Microsoft siguiente: Para más información acerca de RegMon, visite el sitio Web de Microsoft siguiente:

Profundice hacia abajo para aislar el problema

• ¿Ha funcionado la aplicación alguna vez? En caso afirmativo, qué cambió aquél podría haber realizado a continuación el salto de aplicación? Es posible que se aplicaran actualización de software o actualizaciones de seguridad en el servidor. También una distribución de código podría haber causado el problema.
• ¿Sirven las páginas simples .html y .asp de IIS?
• ¿Se migró la aplicación a una versión diferente de IIS?
• ¿Realiza otras aplicaciones ASP.NET en el error de servidor con el mismo error? ¿Es esto sólo la aplicación que falla?
• ¿Se produce el problema para todos los usuarios o usuarios sólo específicos?
• ¿Se puede reproducir el problema mientras explora localmente en el servidor Web o se lo puede reproducir sólo para pocos clientes?
• ¿Si está utilizando suplantación, tiene el usuario suplantado entonces el acceso necesario al recurso?

Las preguntas anteriores son útiles para diagnosticar un problema. Si está registrando su problema en cualquiera de los foros ASP.NET y si ya tiene las respuestas a estas más preguntas, obtener un puntero o una solución rápidos a su problema es a continuación probable. La clave es enviar todo el error de seguimiento de pila de ASP.NET si es aplicable en vez de indicar "obtengo un error Acceso denegado al intentar ejecutar mi aplicación ASP.NET" "Puede ayudar cualquiera?" Ver el seguimiento de pila y proporcionarle punteros cuando pueden ver un mensaje de error completo es mucho más fácil. Por tanto, le necesita pedir...

¿Qué es el mensaje de error exacto?

La primera pregunta que formulamos a clientes es de "Qué es el mensaje de error exacto"? Si tiene una descripción clara del mensaje de error iniciado por el Microsoft .NET Framework, puede omitir esta sección. Si su aplicación enmascara el mensaje de error real y en su lugar, le muestra un mensaje descriptivo de error "tal como ha ocurrido un error inesperado" "Se consulta de cuánto uso para cualquiera," no es el administrador de sitio Web para detalles. Hay pocos pasos que le ayudarán al mensaje de error real aparecer.

• Busca el archivo Web.config del directorio de aplicación lo abre y cambia customErrors a modo = Off. Guarde el archivo y reproduzca el problema.
• Aún quizás no es posible ver el mensaje de error real después de seguir el paso anterior a causa del control event/error personalizado de hacer por el desarrollador de aplicación. Puede intentar buscar el evento Application Error en el archivo Global.asax y en el comentario fuera de cualquier código que utilice la función Server.Transfer("Errors.aspx") para ir a una página personalizada de error.

Una vez que el mensaje de error real aparezca, leer para determinar si el error es causado por permisos faltados en un recurso local o un recurso remoto en el que intenta la aplicación la aplicación obtener acceso.

Sugerencia Se puede poner en contacto con Su programador encontrado por Usted fuera de cómo ver el mensaje de error real. Es posible que su programador lo pueda registrar en un archivo o que pueda obtener notificaciones de correo electrónico. Recuerde siempre si realiza una copia de seguridad de cualquier archivo que vaya a cambiar. Con una copia de seguridad disponible, siempre puede revocar cualquier cambio.

El problema se produce a causa de pierde permisos en un recurso local en el que intenta la aplicación ASP.NET obtener acceso

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

A continuación, se muestra un resultado de ejemplo FileMon. Como puede ver de los resultados filtrados, nosotros hemos reducido la causa del problema. FileMon muestra que la cuenta NT AUTHORITY\NETWORK SERVICE pierde permisos NTFS en la carpeta Archivos de ASP.NET de C:\Winnt\Microsoft.net\Framework\v1.1.4322\Temporary. Debería ser esto corregir hacia adelante directamente. Para más información acerca de utilizar FileMon para solucionar ASP.NET, haga clic en el número de artículo siguiente para ver el artículo en el Microsoft Knowledge Base: Sugerencia Un paso bueno será cambiar la cuenta de proceso ASP.NET a una cuenta Administrador para verla si corrige el problema. En 5.x de IIS, cambiará el userName a "SYSTEM" del archivo machine.config en la sección de proceso de modelo de base de datos y en IIS 6.0, cambiará la identidad AppPool de IIS a "Sistema local" para verlo si la aplicación funciona.

Nota Esto no se debería utilizar como una solución pero sólo un paso de solución de problemas.

Se tenderá a que la mayoría de personas vuelva a instalar el Microsoft .NET Framework o a que vaya incluso a la extensión de reinstalar el sistema operativo. Esto no es un paso recomendado de solución de problemas y no garantiza que el problema no volverá a aparecer. Yo proporcionaré un dicho ejemplo. Es difícil a menudo aislar y solucionar problemas intermitentes. En este escenario, la el cliente aplicación funcionará correctamente de pocas horas y a continuación, fallará all of a sudden con el error siguiente. El cliente ya hubo probado a volver a instalar el .NET Framework así como el sistema operativo. Esto pareció que el problema se soluciona de algunos días pero a continuación, volvió a aparecer.



Ejecutar FileMon no mostró ningún error ACCESS DENIED. Todos los permisos necesarios para la cuenta ASPNET estuvieron en su lugar. La forma única que se recuperará del problema es reiniciar el cuadro. Incluso un restablecimiento de IIS no ayudará. Está creyendo "AH, Software de Microsoft necesitar un reinicio siempre de recuperarlo"? Es incorrecto!

Aquí la clave es examinar el mensaje de error atentamente. El error claramente indica "no puede abrir un archivo para escritura" y no el error habitual ACCESS DENIED conque estoy pensando que es algún otro proceso que mantiene un bloqueo en un archivo o una carpeta y que no permite que ASP.NET escriba a ello. Tiene sentido de un reinicio eliminar el otro proceso y la aplicación ASP.NET iniciar al funcionar de nuevo hasta que el proceso falso bloquee el archivo de nuevo. La cosa lógica que se hará será desactivar todos los programas de antivirus, spyware de tercero o cualquier otro archivo que supervise software que se ejecuta en el servidor. Yo no deseo señalar cualquier software específico de tercero. Pero en general, se sabe que el software de antivirus causa mucha aflicción para aplicaciones IIS y ASP.NET. Otro problema conocido causado por software de antivirus es sesión cuando se recicla la pérdida debido a AppDomain cuando se tocan la carpeta Bin o los archivos .config.

Sugerencia Hay la forma más sencilla de desactivar servicios de otros fabricantes para:

1. Haga clic en Inicio, haga clic en Ejecutar y a continuación, escriba msconfig.
2. Seleccione Servicios y compruebe Ocultar todos los servicios de Microsoft.
3. Haga clic en Deshabilitar todo para que detenga los servicios de otros fabricantes.
4. Haga clic en Inicio, haga clic en Ejecutar y a continuación, escriba iisreset Para volver a cargar el CLR en el proceso de trabajo.

Supervise su aplicación para ver si el problema vuelve a aparecer. Si ejecuta varios programas de antivirus, utilice el método trial-and-error para determinar qué programa determinado causa el problema.

Nota Si se puede reproducir el mismo error 100 % de la vez, su software de antivirus no puede ser la causa. Puede haber otras causas de este error. Intente crear una aplicación de prueba ASP.NET sencilla de aislar si se produce el mismo error para una página Test.aspx. Si, a continuación, compruebe que las listas de control de acceso necesarias (ACL) son en todo el lugar para ASP.NET.

Vea que ASP.NET requirió listas de control de acceso (ACL): http://msdn2.microsoft.com/en-us/library/kwzs111e.aspx

Sugerencia La carpeta %SystemRoot%\Assembly es el caché de ensamblados global. No puede utilizar Explorador de Windows directamente para modificar ACL para esta carpeta. En su lugar, pueda utilizar un símbolo del sistema y en su lugar, ejecute el comando siguiente: Antes de utilizar Explorador de Windows, anule el registro de Shfusion.dll con el comando siguiente que concede permisos vía el GUI como alternativa: Después de establecer permisos con Explorador de Windows, vuelva a registrar Shfusion.dll con el comando siguiente:

El problema se produce a causa de pierde permisos en un recurso remoto en el que intenta la aplicación ASP.NET obtener acceso

Cuando su aplicación ASP.NET obtiene acceso a un recurso remoto similar a Microsoft SQL Server o un recurso UNC, hay muchas cosas que se pueden poner en incorrecto. También muchas cosas se pueden configurar de manera incorrecta en el recurso remoto. Necesitará solucionar aquellos problemas para obtener el trabajo de recurso. Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base Su primer paso será ver si puede conectar con el servidor remoto a través de Explorador de Windows.

1. En el servidor remoto, cree una carpeta llamada Test. En las fichas Compartir y Seguridad de la carpeta de prueba, agregue su domain/account y la cuenta de proceso utilizada por su aplicación ASP.NET también y dar ambos Control total.
   
   Nota Consulte891031
   (http://support.microsoft.com/kb/891031/ )
   Para técnicas o soluciones que obtienen acceso a recursos remotos desde ASP.NET.
2. En el servidor IIS, registre con su domain/account, haga clic en Inicio, haga clic en Ejecutar y a continuación, escriba la ruta UNC compartida del servidor remoto:
   \\RemoteServerName\Test
   Si no puede obtener a esta carpeta, a continuación, póngase en contacto con su administrador de red para solucionar este problema. Sólo a continuación, su aplicación ASP.NET puede tener acceso al recurso.
3. Cree un archivo denominado CreateUNCFile.aspx con el código siguiente y guarde el archivo en su directorio de 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 que modifica <RemoteServerName> en la línea siguiente de código

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

   Para que refleja el nombre de su servidor remoto.
5. Abre Internet Explorer de Windows busca http:// IISServerName / /CreateUNCFile.aspx AppName desde un equipo de cliente a no ser el servidor IIS.
6. Si el archivo Test.txt se crea correctamente, a continuación, su aplicación ASP.NET puede realizar la autenticación al recurso remoto.
7. Si no se puede crear archivo desde un explorador de cliente Internet Explorer pero trabajos si va a la misma página desde el servidor IIS, tener un escenario "Salto Doble" es a continuación probable. Si está utilizando elemento generado personalizado Web para tener acceso a recursos remotos que requieren autenticación de usuario y autorización, ejecutará probablemente con el problema "Salto Doble". Para obtener acceso a su recurso remoto, puede deber proporcionar las credenciales del usuario final al recurso para que el resultado del recurso esté limitado a los datos a los que tienen los usuarios finales permiso de acceso.

En los pasos anteriores se supone que tenga activada autenticación NTLM en IIS. Autenticación básica no utiliza Kerberos. Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base Para más información acerca de métodos de autenticación de IIS, consulte el sitio Web siguiente Microsoft Developer Network ( MSDN ):

Sugerencia Si puede conectar con el recurso compartido remoto UNC pero si no puede conectar con el servidor remoto que ejecuta SQL Server de la aplicación ASP.NET, podría tener que comprobar o establecer a continuación los nombres principales de servicio (SPN) para SQL Server. Intente habilitar sólo autenticación básica para su aplicación en IIS y vea si es posible conectar con el servidor remoto que ejecuta SQL Server. Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base Sugerencia No ha recomendado nunca utilizar unidades asignadas para conectarse a un recurso remoto porque las asignaciones de unidades son una extensión del comando net use y se crean para cada usuario. El método preferido de acceso a contenido para el servidor Web que existe en un equipo remoto es utilizar recursos que siguen al UNC. Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base

Seguridad de acceso a código (CAS) relacionó problema

Mensaje de error en ASP.NET se detalla e indica con frecuencia cuál es el problema exactamente. En algunos casos, FileMon o RegMon no pueden capturar nada útil. Observemos un escenario de tipo.

Escenario

Al intentar explorar una aplicación ASP.NET, falla con un error genérico como el error infamous siguiente: El registro de sucesos muestra: Cuando se crea un dominio de aplicación ASP.NET, ASP.NET lee que el valor especificado para el atributo de nivel del elemento de configuración de trust crea una instancia de la clase AspNetHostingPermission con el atributo especificado Nivel y que a continuación, agrega la clase al conjunto de permisos para el dominio de aplicación. Verá el error anterior si los niveles de confianza se configuran o si se modifican incorrectamente. Para más información, vea "ASP.NET Trust Levels and Policy Files" en el sitio Web de MSDN siguiente: Para solucionar este problema, puede probar esto Superponga En "se produce problema a causa de pierde permisos en un recurso local en el que intenta la aplicación ASP.NET obtener acceso," sección pero no obtenga disheartened si la aplicación no funciona con una cuenta de Administrador o de SYSTEM. Debe consultar si el problema se puede deber a seguridad de acceso a código. Esto puede ser hacer fácilmente utilizando la utilidad de Caspol.exe desactivar seguridad de acceso a código. Una vez que haya ejecutado caspol ûs off, restablezca IIS e intente explorar la aplicación. Si este paso funciona, a continuación, debe comprobar el conjunto de permisos para los grupo de código. Puede tener acceso a los grupo de código en la herramienta de Configuración VersionNumber Microsoft .NET Framework de buscarse en Herramientas administrativas.

En este escenario, el conjunto de permisos para el grupo de código Zona Mi PC se estableció en Nothing. Cambiarlo a Plena confianza resolvió el problema

Nota Para tener acceso al grupo de código Zona Mi PC, siga estos pasos:

1. En Panel de control, haga doble clic en Herramientas administrativas.
2. Haga doble clic Configura VersionNumber Microsoft .NET Framework.
3. Haga doble clic en Runtime Security Policy.
4. Haga doble clic en Equipo.
5. Haga doble clic en grupos de código.
6. Haga doble clic en All Code.
7. Haga doble clic en zona Mi PC.

Sugerencia Recuerde si ejecuta caspol ûs on para activar CAS una vez que haya corregido el problema.

Para más información, vea seguridad de acceso a código de ASP.NET: http://msdn2.microsoft.com/en-us/library/87x8e4d1.aspx

Hay otras causas numerosas para el mensaje de error "Disponible de aplicación de servidor". El registro de sucesos es mejor de obtener más detalles sobre la causa de su problema su bet.

Errores relacionados con IIS

Los registro de IIS son muy útiles en casos de errores de IIS relacionados con la autenticación. Un escenario común es cuando el usuario normalmente verá lo siguiente: Debe buscar los códigos de estado de estado y sub de este error determinado. Nosotros vemos unos del sub-status 401 3 que indica "No autorizado debido a ACL de recurso"

Esto indica permisos NTFS faltados en un archivo o una carpeta. Este error se puede producir aunque los permisos son correctos para el archivo al que está intentando tener acceso pero ser que los permisos predeterminados y los derechos de usuario falten en otras carpetas de SISTEMA y de IIS. Por ejemplo, ve este error probablemente si la cuenta IUSR_NombreDeEquipo no tiene acceso al directorio C:\Winnt\System32\Inetsrv. Para más información acerca de códigos de estado de IIS, haga clic en el número de artículo siguiente para ver el artículo en el Microsoft Knowledge Base: Sugerencia Haga clic en Inicio, haga clic en Ejecutar y a continuación, escriba logfiles Para abrir la carpeta, aquél contiene los registro de IIS. En la página de propiedades para su Sitio Web en IIS, haga clic en la ficha WebSiteName y bajo Formato de registro activo, haga clic en Propiedades como alternativa para ver el Directorio del archivo de registro y el nombre.

La otra cosa aquí de interés es el código de estado 5. Puede utilizar el comando net helpmsg para obtener más información en este código de estado: Probemos otro código común de estado, Code 50: Para más información acerca de cómo deshabilitar mensajes descriptivos de error HTTP, haga clic en el número de artículo siguiente para ver el artículo en el Microsoft Knowledge Base: La idea es utilizar toda la información registrada disponible para obtener detalles máximos a mano acerca del problema.

Recursos

Para obtener más información, haga clic en el número de artículo siguiente para verlo en Microsoft Knowledge Base Yo espero que estas técnicas simples sean útiles en ayudarle a resolver problemas relativos de seguridad y permisos. Recuerde que hay las columnas Voz de Compatibilidad para usted! Cree libre de utilizar como siempre Ask For It forme para enviar ideas sobre temas que desea ver dirigido en columnas posteriores o en el Knowledge Base.