NO. Las “Local Security Policy | User Rights Assignment” de “Debug programs” asignadas a Administradores es solo necesaria para poder hacer debugging de aplicaciones externas que hayan sido lanzadas por usuarios distintos al Local User Account. Para el desarrollo de aplicaciones standard, incluidas aplicaciones Windows, aplicaciones web y web services, solo es necesario que los usuarios sean miembros de los siguientes grupos locales:
- VS Developers
- Debugger Users
- Advanced Users
VS Developers
Este grupo otorga los siguientes permisos:
- Acceso de Lectura, Escritura, Borrar y Modificar sobre wwwroot$
- Acceso de Lectura, Escritura, Borrar y Modificar sobre el directorio de archivos \wwwroot (solo NTFS)
- Acceso de Operador (Administrativo) al IIS Metabase (IIS Local) Debugger User
- Lanzar procesos con la cuenta de usuario.
- Terminar procesos con la cuenta de usuario.
- Enumerar procesos corriendo en el sistema.
- Comunicarse con el Machine Debug Manager.
- Localizar el archivo “C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG\machine.config”
- Buscar el tag
<processModel>
y modificar las credenciales con el usuario que queremos trabajar
Permite a los miembros:
Permite tener acceso de Lectura y Escritura sobre el directorio: “C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files”
Debugging ASP.NET Web Applications y Servicios
Para poder debuguear una ASP.NET web application o web service el Visual Studio debugger necesita poder attacharse al ASPNET Worker Process, aspnet_wp.exe. El ASP Worker Process normalmente con una predefinida cuenta de usuario llamada”ASPNET”, la cual fue creada durante la instalación del .NET Framework con el IIS. Como por defecto uno utiliza una cuenta de Administrador, no va a tener problemas nuncas para hacer un attach a un proceso lanzado por otro usuario, en este caso el usuario ASPNET.
Lo que debemos hacer es configurar al ASPNET Worker Process para que corra con nuestra cuenta de usuario.
Configurar el “machine.config”
<processModel userName="machine" password="AutoGenerate" ...... />
por
<processModel userName="YourUserName" password="YourPassword" ...... />
Otra opción más segura, dado que el password queda visible, es encriptándolo utilizando la aplicación aspnet_setreg.exe
aspnet_setreg.exe -k:SOFTWARE\MY_SECURE_APP\processModel -u:"YourUserName" -p:"YourPassword"
Entonces hay que modificar el processModel con lo siguiente:
<processModel
userName="registry:HKLM\SOFTWARE\MY_SECURE_APP\processModel\ASPNET_SETREG,userName"
password="registry:HKLM\SOFTWARE\MY_SECURE_APP\processModel\ASPNET_SETREG,password"
...... />
Es necesario tener permisos de administrador para poder agregar esto en el registro, por lo cual será necesaria la asistencia cada vez que haya que actualizar la contraseña.
Consideraciones
Para poder trabajar con proyectos Web ya existentes, va a ser necesario:
Crear un proyecto web en blanco desde nuestro Visual Studio, el cual cuenta con permisos para crear el Directorio Virtual en el IIS local.
Reemplazar los archivos del proyecto web creado por los fuentes del anterior proyecto existente.
Referencias
Visual Studio .NET User Groups – Use, Permissions, Security
Overview on the use, permissions, and security provided to Visual Studio users for developing and debugging Windows applications, ASP.NET web applications, and ASP.NET web services.
Informacion sobre aspnet_setreg.exe http://support.microsoft.com/default.aspx?scid=329290
http://msruniv.corp.bcentral.com/shared%20documents/dotNETDevVSGROUPS.doc
http://msruniv.corp.bcentral.com/shared%20documents/dotNETDevVSGROUPS.pdf
http://msdn.microsoft.com/en-us/library/aa289173.aspx
http://cyberforge.com/weblog/aniltj/articles/254.aspx
No hay comentarios:
Publicar un comentario