NetworkService
En equipos con Windows Server 2003 los servicios también pueden configurarse para iniciar sesión con la cuenta NetworkService. Como LocalSystem no necesita contraseña, es decir, su contraseña es una contraseña vacía.
Cuenta integrada del sistema tiene los privilegios de un usuario autentificado; por lo que ofrece una alternativa para la ejecución de servicios en lugar de la cuenta LocalSystem. No hay directiva de bloqueo para la cuenta NetworkService ya que no está protegida por contraseña. El mecanismo de protección es qué sólo un proceso ejecutándose bajo la cuenta LocalSystem puede relizar un inicio de sesión con NetworkService (o LocalSystem), y debe ser un servicio tipo con inicio de sesión.
La cuenta NetworkService está prevista para servicios que no tienen la necesidad de privilegios locales extensivos, ya que no necesita acceso a red autentificada. Los servicios que se ejecutan bajo esta cuenta acceden a los recursos locales como usuarios corrientes. Cuando acceden a recursos de red, deben utilizar las credenciales del equipo. Un servicio ejecutándose con NetworkService tiene el mismo acceso de red como uno que se ejecuta bajo LocalSystem, pero con un acceso local significativamente reducido.
Los privilegios siguientes están disponibles para servicios ejecutándose con la cuenta NetworkService:
- SeShutdownPrivilege
- SeAuditPrivilege
- SeChangeNotifyPrivilege
- SeUndockPrivilege
- SeImpersonatePrivilege
Para información sobre estos privilegios http://msdn.microsoft.com/en-us/library/bb530716(VS.85).aspx
LocalService
En equipos con Windows Server 2003 también puede usarse para iniciar sesión servicios, e igualmente a las anteriores esta cuenta no necesita de contraseña.
La cuenta LocalService se provee para servicios que son locales del equipo, no tiene privilegios extendidos y no necesita autentificación de red. Tanto bajo LocalService como bajo NetworkService se disponen de los mismos privilegios. Acceden a los recursos locales como usuarios corrientes y acceden a los recursos de red como usuarios anónimos. Un servicio ejecutándose con esta cuenta tiene menos autoridad que uno que lo hace bajo LocalSystem, tanto en local como en red.
La lista de privilegios es idéntica a la expuesta arriba.
Cuenta de usuario del dominio
Muchos servicios necesitan ejecutarse con una cuenta de inicio de sesión separada con permisos más específicos que LocalSystem, NetworkService o LocalService. Los programas instaladores de estos servicios se encargan de crear la cuenta de inicio de sesión y configurar las listas de control de acceso (ACLs) necesarias para darle los derechos apropiados a la cuenta.
Instalar un servicio con el uso de una cuenta de usuario del dominio con contraseña permite al servicio tener el acceso que la cuenta de dominio ofrece. Esta cuenta puede ser miembro de múltiples grupos de seguridad y no está sujeta a eliminación o renovación si el equipo abandona o se vuelve a unir al dominio. Para asignar acceso a áreas de Active Directory a servicios que usan cuentas de usuario de inicio de sesión, podemos fácilmente usar pertenencias a grupos; sin embargo, ejecutar un servicio bajo este contexto tiene ciertas desventajas:
- La cuenta debe crearse antes que el servicio pueda ejecutarse. Si el programa de instalación del servicio crea la cuenta, éste debe ejecutarse desde una cuenta con los suficientes privilegios para la creación de cuentas en el servicio de directorio.
- Los nombres y contraseñas de cuentas se almacenan en cada equipo donde el servicio se instala. Si la contraseña de una cuenta del servicio de un equipo se cambia o caduca, el servicio no podrá iniciarse en el equipo hasta que la contraseña se establezca como nueva contraseña para ese servicio. La recomendación es utilizar LocalService y NetworkService siempre que sea posible en lugar de una cuenta que requiere de contraseña, con ello simplificamos la administración de contraseñas.
- Si una cuenta de servicio se renombra, bloquea, desactiva o elimina, el servicio no podrá iniciarse en el equipo hasta reiniciarla.
Una cuenta de usuario del dominio tiene dos formatos que necesitamos para realizar diversas operaciones: el nombre distinguido del objeto usuario en el directorio y el formato DOMINIONOMBRE_USUARIO utilizado por el SCM local.
Cuando configuramos un servicio para ejecutarse con cierta cuenta, el SCM llamará a Lsass.exe para mirar la cuenta mediante las APIs LsaLookup. LocalSystem es una excepción ya que hay demasiadas variaciones para el nombre. Si la cuenta es válida, SCM permite el cambio de configuración. La próxima vez que el servicio se inicie, SCM llama a LogonUser para la cuenta mediante la contraseña especificada (usando el nombre _SC-Service como contraseña, técnicamente) para realizar el inicio de sesión del servicio-tipo, e inicia el proceso con el token de inicio de sesión devuelto. Si el proceso recibe el SID del servicio en su token, el proceso se identifica como un proceso de servicio.
Cuenta de usuario Local
Una cuenta de usuario local sólo existe en la base de datos SAM del equipo local; no tiene objeto de usuario en AD. Esto significa que un usuario local no puede autentificarse en el dominio. Consecuentemente, un servicio ejecutándose con una cuenta de usuario local no tiene acceso a recursos de red(excepto como usuario anónimo) y no es compatible con Kerberos. Por estas razones, este tipo de cuenta resulta inapropiado para servicios relacionados con el directorio. Sin embargo, bajo este contexto de seguridad se tienen muy pocos privilegios y puede causarse poco daño en el caso malintencionado de la cuenta.
Los servicios ejecutándose como administradores en controladores de dominio son una excepción para las cuentas bajo el contexto de seguridad de cuentas de usuario local para servicios de directorio; consecuentemente, los mismos cuidados son de aplicación a cuentas de usuario local en cuanto a nombre de cuenta y contraseña como a las cuentas de usuario del dominio.