Cuenta de servicio de red que accede a una carpeta compartida

Tengo un escenario simple. Hay una aplicación en ServerA que se ejecuta con la cuenta de servicio de red incorporada. Necesita leer y escribir archivos en una carpeta compartida en ServerB. ¿Qué permisos necesito establecer en la carpeta compartida en ServerB?

Puedo hacer que funcione abriendo el cuadro de diálogo de seguridad del recurso compartido, agregando un nuevo usuario de seguridad, haciendo clic en "Tipos de objeto" y asegurándome de que "Computadoras" esté marcado, y luego agregando ServerA con acceso de lectura / escritura. Al hacer esto, ¿qué cuentas obtienen acceso al recurso compartido? ¿Solo servicio de red? Todas las cuentas locales en ServerA? ¿Qué debo hacer para otorgar acceso a la cuenta del Servicio de red de ServerA al recurso compartido de ServerB?

Nota:
Sé que esto es similar a esta pregunta . Sin embargo, en mi escenario, ServerA y ServerB están en el mismo dominio.

Los "Permisos de uso compartido" pueden ser "Todos / Control total", solo los permisos NTFS realmente importan. (Señale argumentos religiosos de personas que tienen un apego poco saludable a "Compartir permisos" aquí ...)

En los permisos NTFS en la carpeta en el ServidorB, puede obtener "DOMINIO \ ServidorA - Modificar" o "DOMINIO \ ServidorA - Escribir", dependiendo de si necesitaba poder modificar los archivos existentes o no. (Modificar es realmente el preferido porque su aplicación puede volver a abrir un archivo después de crearlo para escribir más; modificar le da ese derecho, pero Escribir no lo hace).

Solo los contextos "SISTEMA" y "Servicio de red" en ServerA tendrán acceso, suponiendo que nombre "DOMINIO \ ServerA" en el permiso. Las cuentas de usuario locales en la computadora ServerA son diferentes del contexto "DOMINIO \ ServerA" (y tendrían que nombrarse individualmente si de alguna manera desea otorgarles acceso).

Como comentario aparte: los roles de la computadora servidor cambian. Es posible que desee crear un grupo en el AD para este rol, colocar ServerA en ese grupo y otorgarle derechos de grupo. Si alguna vez cambia el rol del ServidorA y lo reemplaza con, digamos, ServidorC, solo necesita cambiar las membresías del grupo y nunca más necesita tocar el permiso de la carpeta nuevamente. Muchos administradores piensan en este tipo de cosas para los usuarios nombrados en los permisos, pero se olvidan de que "las computadoras también son personas" y sus roles a veces cambian. Minimizar tu trabajo en el futuro (y tu capacidad para cometer errores) es de lo que se trata ser eficiente en este juego ...

La cuenta de servicio de red de una computadora se asignará a otra computadora confiable como la cuenta del nombre de la computadora. Por ejemplo, si está ejecutando como la cuenta del Servicio de red en el ServidorA en MiDominio, eso debería asignarse como MiDominio \ ServidorA $ (sí, el signo de dólar es necesario). Esto se ve bastante cuando tiene aplicaciones IIS ejecutándose como la cuenta del Servicio de red que se conecta a un Servidor SQL en un servidor diferente, como una instalación escalada de SSRS o Microsoft CRM.

Estoy de acuerdo con Evan. Sin embargo, creo que la solución ideal, si la seguridad es una preocupación real para usted, sería crear una cuenta de usuario específicamente para que se ejecute esa aplicación / servicio y otorgarle a esa cuenta los permisos necesarios para la carpeta compartida. De esta manera, puede estar seguro de que solo esa aplicación / servicio está accediendo al recurso compartido. Sin embargo, esto puede ser excesivo.