Tengo un escenario simple. Hay una aplicación en el Servidor A que se ejecuta con la cuenta de servicio de red integrada. Necesita leer y escribir archivos en una carpeta compartida en el Servidor B. ¿Qué permisos necesito configurar 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 objetos" y asegurándome de que "Equipos" esté marcado, y luego agregando el ServidorA con acceso de lectura/escritura. Al hacer esto, ¿qué cuentas obtienen acceso a la acción? ¿Solo servicio de red? ¿Todas las cuentas locales en el Servidor A? Quédebería¿Qué haré para otorgar acceso a la cuenta de servicio de red del Servidor A al recurso compartido del Servidor B?
Nota:
Sé que esto es similar aesta pregunta. Sin embargo, en mi escenario, ServerA y ServerB están en el mismo dominio.
Respuesta1
Los "Permisos para compartir" pueden ser "Todos/Control total"; sólo los permisos NTFS realmente importan. (Indique aquí los argumentos religiosos de personas que tienen un apego poco saludable a "Compartir permisos"...)
En los permisos NTFS en la carpeta del ServidorB, puede arreglárselas con "DOMINIO\ServidorA - Modificar" o "DOMINIO\ServidorA - Escribir", dependiendo de si es necesario poder modificar 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 otorga ese derecho, pero Escribir no).
Solo los contextos "SISTEMA" y "Servicio de red" en el ServidorA tendrán acceso, suponiendo que nombre "DOMINIO\ServidorA" en el permiso. Las cuentas de usuario locales en la computadora del ServidorA son diferentes del contexto "DOMINIO\ServidorA" (y tendrían que nombrarse individualmente si de alguna manera quisiera otorgarles acceso).
Además: las funciones de la computadora servidor cambian. Es posible que desee crear un grupo en AD para esta función, colocar el Servidor A en ese grupo y otorgarle derechos al grupo. Si alguna vez cambia la función del ServidorA y lo reemplaza con, digamos, ServidorC, solo necesitará cambiar las membresías del grupo y nunca más necesitará tocar el permiso de la carpeta. Muchos administradores piensan en este tipo de cosas cuando se nombra a los usuarios en los permisos, pero olvidan 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...
Respuesta2
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 la cuenta de Servicio de red en el ServidorA en MiDominio, 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.
Respuesta3
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 accede al recurso compartido. Sin embargo, esto puede ser excesivo.