Dado que hay tanta confusión sobre la funcionalidad de las cuentas de servicio estándar, intentaré dar un vistazo rápido.
encima cuando se habla de acceso a la red, esto se refiere únicamente a SPNEGO (Negociar), NTLM y Kerberos y no a cualquier otro mecanismo de autenticación. Por ejemplo, el procesamiento que se ejecuta como LocalService aún puede acceder a Internet.
El problema general con la ejecución de una cuenta estándar estándar es que si modifica alguno de los permisos predeterminados, está expandiendo el conjunto de cosas que se ejecutan como esa cuenta puede hacer. Por lo tanto, si otorga DBO a una base de datos, no solo su servicio que se ejecuta como Servicio local o Servicio de red puede acceder a esa base de datos, sino que todo lo demás que se ejecuta como esas cuentas también puede hacerlo. Si cada desarrollador hace esto, la computadora tendrá una cuenta de servicio que tiene permisos para hacer prácticamente cualquier cosa (más específicamente, el superconjunto de todos los diferentes privilegios adicionales otorgados a esa cuenta).
Siempre es preferible, desde una perspectiva de seguridad, ejecutar como su propia cuenta de servicio que tiene precisamente los permisos que necesita para hacer lo que hace su servicio y nada más. Sin embargo, el costo de este enfoque es configurar su cuenta de servicio y administrar la contraseña. Es un acto de equilibrio que cada aplicación debe gestionar.
En su caso específico, la cuestión que probablemente vea es que la activación de DCOM o COM + está limitada a un conjunto determinado de cuentas. En Windows XP SP2, Windows Server 2003 y superior, el permiso de Activación se restringió significativamente.Debe utilizar el complemento de MMC de servicios de componentes para examinar su objeto COM específico y ver los permisos de activación. Si no está accediendo a nada en la red como cuenta de la máquina, debería considerar seriamente usar el servicio local (no el sistema local, que es básicamente el sistema operativo).
En Windows Server 2003 you cannot run a scheduled task como
NT_AUTHORITY\LocalService (también conocido como la cuenta de servicio local), oNT AUTHORITY\NetworkService (también conocido como la cuenta de servicio de red).
Esa capacidad solo se agregó con la Tarea Scheduler 2.0, que solo existe en Windows Vista/Windows Server 2008 y posteriores.
Un servicio que se ejecuta como NetworkService presenta las credenciales de la máquina en la red. Esto significa que si el equipo se llamaba mango, it would present as the machine accountMANGO$:
Creo que [Cuentas de Servicios Gestionados] (http://technet.microsoft.com/en-us/library/dd548356%28v= ws.10% 29.aspx) elimina parte del dolor de configurar la cuenta y administrar la contraseña (o pasarla a un administrador de dominio o delegado). –
Hola, gracias por la explicación. Sin embargo, tengo una pregunta: utilizando la cuenta del servicio de sistema/red local es posible agregar/eliminar entradas a contenedores en el directorio activo (siempre que el contenedor en el directorio activo haya otorgado permisos completos a la computadora en la que se ejecutan estos servicios de Windows). Tenga en cuenta que todo funciona, cuando ejecuté el servicio como uno de los usuarios del dominio, pero no como un sistema local/servicio de red (para más detalles http://stackoverflow.com/questions/20943436/service-running-as-network- service-or-local-system-failed-to-add-entries-to-act) Recuerdos – Dreamer
Sí, debería. Responderé a su pregunta directamente ya que esta pregunta es más abstracta y es una implementación específica. –