Replicación DFS y usuario del SISTEMA (permisos NTFS)

10

Pregunta para la que tengo problemas para encontrar una respuesta en Google o Technet ...

¿Otorgar SYSTEMpermisos de usuario a archivos y carpetas compartidos DFS tiene algún efecto en la replicación DFS? (Y mientras estamos en ello, ¿hay alguna buena razón para no permitir SYSTEMpermisos para archivos compartidos DFS?)

Aparece porque tengo una colección de espacios de nombres y carpetas DFS que no puedo resolver el problema de otra persona, y mientras soluciono un problema en el que una réplica DFS simplemente no se replicaba con otra sin razón aparente, observé que el SYSTEMla cuenta no tenía ningún permiso otorgado a ninguno de los archivos o carpetas en la carpeta en cuestión.

Así que configuré SYSTEMtener un control total y lo propagué, y nuestros informes de diagnóstico de salud DFS pasaron de mostrar una acumulación de ~ 80 archivos a una acumulación de ~ 100,000 ... y las cosas comenzaron a replicarse, incluyendo una cantidad de archivos que faltaban en un servidor u otro (por lo que más que solo los cambios de permisos comenzaron a replicarse).

Naturalmente, esto me hizo sentir curiosidad sobre si DFS necesita o no que la SYSTEMcuenta tenga permisos para hacer su trabajo, o si tal vez fue solo cualquier cambio en el árbol de carpetas en cuestión lo que llevó a DFS a entrar en acción. Si es importante, nuestros espacios de nombres DFS se configuraron en 2000/2003, y recientemente terminé de actualizar todos los servidores a 2008 R2 o 2012 (con UAC habilitado, blech), pero aún no he logrado aumentar la funcionalidad del espacio de nombres DFS niveles al servidor 2008.

(Y puntos de bonificación si alguien tiene un artículo oficial de Microsoft sobre permisos de archivos NTFS y la SYSTEMcuenta en lo que respecta a DFS o archivos de red).

file-permissions dfs

— HopelessN00b
fuente

Cuando actualizó los servidores, ¿siguió la guía de migración de FRS a DFS? microsoft.com/en-us/download/confirmation.aspx?id=580

— Rex

@Rex No hice la migración FRS -> DFS, y me arriesgaría a decir que algunas guías, mejores prácticas, sentido común o pensamiento racional probablemente no se siguieron, pero hemos estado usando DFS (en lugar de FRS) durante bastante tiempo. Tengo pocas dudas de que la razón por la que funciona tan mal es por la forma en que se configuró inicialmente, así como por la forma en que se migró. La actualización en cuestión fue una actualización de versión de espacio de nombres , no una actualización de FRS -> DFS. Corregiré esa palabra omitida ahora.

— HopelessN00b

si estuviera haciendo algún tipo de replicación en DFS bajo 2000/2003, habría estado usando FRS para hacer la replicación. DFS-R para la replicación DFS no estuvo disponible hasta 2003 R2. DFS en 2008 R2 ya no es compatible con FRS para la replicación y los servidores 2008 R2 no pueden replicarse con espacios de nombres DFS anteriores basados en 2003 a menos que haya actualizado todos los servidores a 2003 R2 (o posterior) y haya migrado a DFS-R para replicación.

— Rex

9

Este hilo en technet dice que SYSTEM necesita un control total. Sin embargo, no es una fuente muy oficial, y más pruebas demuestran que está mal .

Servicio de replicación DFS

Eché un vistazo a los servicios DFS en mi máquina Server 2008R2 con Process Explorer. dfsrs.exe, el servicio de replicación del sistema de archivos distribuido, se ejecuta como "NT Authority \ SYSTEM". Sin embargo, tiene SeBackupPrivilege y SeRestorePrivilege :

Captura de pantalla de los permisos dfsrs.exe

Desde Microsoft Privilege Constants :

SeBackupPrivilege : necesario para realizar operaciones de copia de seguridad. Este privilegio hace que el sistema otorgue todo el control de acceso de lectura a cualquier archivo, independientemente de la lista de control de acceso (ACL) especificada para el archivo. Toda solicitud de acceso que no sea lectura aún se evalúa con la ACL. 3

SeRestorePrivilege : necesario para realizar operaciones de restauración. Este privilegio hace que el sistema otorgue todo el control de acceso de escritura a cualquier archivo, independientemente de la ACL especificada para el archivo. Cualquier solicitud de acceso que no sea escritura aún se evalúa con la ACL. Además, este privilegio le permite establecer cualquier SID de usuario o grupo válido como propietario de un archivo.

Con esos permisos, el Servicio de replicación DFS puede ignorar cualquier permiso de archivo: se le otorga permiso para leer, escribir y establecer permisos en cualquier archivo que desee.

Pruebas

Creé una carpeta en uno de mis recursos compartidos DFS con algunos archivos, configuré mi cuenta como propietario y eliminé todos los permisos, excepto mi cuenta.

DFS lo replicó a todos los demás servidores sin problemas, y todas las réplicas tenían los mismos permisos.

Por lo tanto, DFS no depende de ningún permiso del sistema de archivos para replicarse.

Sospecho que en su caso, simplemente hacer cualquier cambio en los archivos habría causado que DFS se despertara y viera que necesitaban replicarse. Sin embargo, no tengo idea de lo que habría causado esa situación en primer lugar.

— Conceder
fuente

1

Excelente respuesta. Daré su marca de verificación y recompensa en 5 días, en caso de que alguien pueda venir y superar esto.

— HopelessN00b

2

¡Dangit, debería haber usado una imagen en mi publicación! :(

3

Según este artículo de Microsoft http://support.microsoft.com/kb/120929 "La cuenta del sistema y la cuenta del administrador (grupo de administradores) tienen los mismos privilegios de archivo, pero tienen funciones diferentes".

Esto significa que la cuenta del sistema es la misma que un administrador local, y existe con el propósito de ejecutar servicios del sistema con los privilegios de un administrador sin requerir una contraseña. El proceso de replicación en DFS-R se realiza con esta cuenta.

El usuario del sistema no tiene un significado especial en el Sistema de archivos o en una configuración DFS diferente de un administrador normal. Sin embargo, puede volverse confuso porque los administradores de Windows no siempre funcionan con privilegios administrativos dependiendo de cómo se llamó al programa o shell, mientras que una cuenta del sistema probablemente siempre operará con token escalado / admin. Supongo que su configuración de DFS estaba siendo defectuosa, y la modificación de las ACL tal vez provocó que se hicieran algunas llamadas al sistema, o que se abrieran / actualizaran los identificadores de archivos que sacudieron las telarañas proverbiales.