Configurar la identidad de un Application Pool en IIS 6.0

Por defecto, los Application Pools en IIS 6.0 se ejecutan bajo el principal Network Service


El principal Network Service aparece a la par que el principal Local Service y se presentan por primera vez en Windows XP y Windows Server 2003. El motivo de estos dos nuevos principals tiene su origen en los planteamientos de seguridad por defecto y ejecución con mínimos privilegios. Anteriormente a estos dos principals, muchos servicios se ejecutaban bajo el principal SYSTEM (aka Local System) teniendo por tanto un nivel de privilegios altísimo, en muchos casos absolutamente innecesarios.


Los permisos que poseen estos dos nuevos principals son básicamente lo mismos que posee una cuenta de usuario que solamente pertenezca el grupo Users. A mayores, poseen el derecho de iniciar sesión como un servicio (Logon as a service), lo cuál resulta obvio por su propósito de uso.


La diferencia entre estos dos principals está en cómo se gestionan los intentos de acceso a recursos compartidos en otros equipos de la red:



  • Un servicio ejecutandose bajo Network Service se identifica para la autenticación ante las otras máquina del dominio en la red usando la cuenta de equipo. Es decir, si el servicio Service1 ejecutándose bajo Network Service en la máquina Server1 perteneciente al dominio Dominio1 intenta acceder a una carpeta compartida en Server2, se le permitirá acceso o no en base a los permisos que Dominio1Server1 tenga sobre el recurso compartido.

  • Un servicio ejecutandose bajo Local System no será capaz de autenticarse y se representará en la máquina remota como una sesión nula o null session (que es como Windows representa un usuario anónimo)

Nota importante para los dos principals: si la máquina no pertenece a un dominio o pertenece a un dominio de Windows NT 4, ninguno de los dos principals tendrá credenciales de red.


A mayores de los privilegios comentados, a ambos principals se les asignan los privilegios SeAuditPrivilege y SeAssignPrimaryTokenPrivilege. Esto permite generar auditorias de seguridad e iniciar procesos bajo diferentes cuentas.


Cómo modificar la identidad bajo la que funciona un Application Pool


Para ejecutar un Application Pool bajo unas credenciales diferentes a Network Service será necesario crear una nueva cuenta. Si es necesario credenciales de red habrá que crear una cuenta de dominio. Si no son necesarias, es mejor usar una cuenta local.


Es muy, muy, muy, muy importante asignar una buena contraseña para esta cuenta. Microsoft no nos cobrará por su tamaño así que como no tendremos que introducir esa contraseña todas las mañana al llegar a la oficina no os cortéis. 20 caracteres o más… sin cortarse. Una frase… “Voy a escribir 2 posts sobre IIS.”


A esta cuenta es necesario asignarle los permisos “Log on as a batch job” y “Log on as a service“. También es necesario que la cuenta que hayamos creado sea miembro del grupo “IIS_WPG“.


Luego deberemos dar permisos de lectura sobre los ficheros que vayamos a publicar. Por ejemplo, en el caso en el cual los ficheros de nuestro sitio están en Inetpubwwwroot por defecto los miembros del grupo Users ya tendrán permisos de lectura.


En el caso de que vayamos a ejecutar aplicaciones ASP.NET, tendremos que dar permisos de escritura en la carpeta %Windir%Microsoft.NETFrameworkversionTemporary ASP.NET Files


Nota: No os peleéis intentando ejecutar Reporting Services bajo otra cuenta que no sea Network Services. No os funcionará…


Iván

4 comentarios en “Configurar la identidad de un Application Pool en IIS 6.0”

  1. Hola! A mi me da conflictos con la carpeta Temporal del ASP.net pues le asocio permisos full para el Network service, pero después de cierto tiempo (el cuiál es variable) me lo desasocia, dejandome sin poder ejecutar mi aplicación. ¿que podría hacer para evitar esto? Gracias y saludos

  2. Iván,
    Actualmente tengo un problema para la autenticacion de un Servicio de Windows y buscando post en geeks.com me encontre con tu articulo que me pareció muy interesante.

    Tengo un servicio windows en una red bajo un dominio.
    El servicio es un demonio que monitorea una carpeta (esta está compartida pero en otro dominio) y cuando detecta un archivo en esa carpeta realiza cierto procesamiento sobre el mismo.

    El servicio internamente utiliza la funcion NetworkCredential(usr,pass,dom) incluida en System.Net para obtener una credencial.

    Con esto me bastaría para que el servicio puede acceder a la carpeta compartida en el otro dominio?
    Muchas gracias,
    Federico

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *