Réplication DFS et utilisateur SYSTEM (autorisations NTFS)

Question pour laquelle j'ai du mal à trouver une réponse sur Google ou Technet ...

L'octroi des SYSTEMautorisations utilisateur aux fichiers et dossiers partagés DFS a-t-il un effet sur la réplication DFS? (Et tant que nous y sommes, y a-t-il une bonne raison de ne pas autoriser SYSTEMles fichiers partagés DFS?)

Il apparaît parce que j'ai une collection d'espaces de noms et de dossiers DFS que je ne suis pas en mesure de créer le problème de quelqu'un d'autre, et lors du dépannage d'un problème où une réplique DFS ne se répliquait tout simplement pas avec une autre sans raison perceptible, j'ai observé que le SYSTEMLe compte ne disposait d'aucune autorisation accordée à l'un des fichiers ou dossiers du dossier en question.

J'ai donc décidé SYSTEMd'avoir le contrôle total et de le propager, et nos rapports de diagnostic de santé DFS sont passés d'un arriéré de ~ 80 fichiers à un arriéré de ~ 100 000 ... et les choses ont commencé à se répliquer, y compris un certain nombre de fichiers qui manquaient sur un serveur ou l'autre (donc plus que les modifications des autorisations ont commencé à se répliquer).

Naturellement, cela m'a rendu curieux de savoir si DFS avait besoin du SYSTEMcompte pour avoir des autorisations pour faire son travail, ou si c'était peut-être juste une modification de l'arborescence de dossiers en question qui avait incité DFS à passer à l'action. Si cela est important, nos espaces de noms DFS ont été mis en place sous 2000/2003, et je viens de terminer la mise à niveau de tous les serveurs vers 2008 R2 ou 2012 (avec UAC activé, blech), mais je n'ai pas encore réussi à augmenter la fonctionnalité de l'espace de noms DFS niveaux à Server 2008.

(Et des points bonus si quelqu'un a un article Microsoft officiel sur les autorisations de fichiers NTFS et le SYSTEMcompte en ce qui concerne les fichiers DFS ou réseau.)

Ce fil sur technet dit que SYSTEM a besoin d'un contrôle total. Cependant, ce n'est pas une source très officielle et des tests supplémentaires prouvent que c'est faux .

Service de réplication DFS

J'ai regardé les services DFS sur ma machine Server 2008R2 avec Process Explorer. dfsrs.exe, le service de réplication du système de fichiers distribués, s'exécute en tant que "NT Authority \ SYSTEM". Cependant, il a SeBackupPrivilege et SeRestorePrivilege :

De Microsoft Privilege Constants :

SeBackupPrivilege - Requis pour effectuer des opérations de sauvegarde. Ce privilège oblige le système à accorder tout contrôle d'accès en lecture à n'importe quel fichier, quelle que soit la liste de contrôle d'accès (ACL) spécifiée pour le fichier. Toute demande d'accès autre que lecture est toujours évaluée avec l'ACL. 3

SeRestorePrivilege - Requis pour effectuer des opérations de restauration. Ce privilège oblige le système à accorder tout contrôle d'accès en écriture à n'importe quel fichier, quelle que soit l'ACL spécifiée pour le fichier. Toute demande d'accès autre que l'écriture est toujours évaluée avec l'ACL. En outre, ce privilège vous permet de définir n'importe quel utilisateur ou groupe SID valide en tant que propriétaire d'un fichier.

Avec ces autorisations, le service de réplication DFS peut ignorer toutes les autorisations de fichier - il est autorisé à lire, écrire et définir des autorisations sur n'importe quel fichier qu'il souhaite.

Essai

J'ai créé un dossier dans l'un de mes partages DFS avec quelques fichiers, défini mon compte en tant que propriétaire et supprimé toutes les autorisations à l'exception de mon compte.

DFS l'a répliqué sur tous les autres serveurs sans problème, et toutes les répliques avaient les mêmes autorisations.

Par conséquent, DFS ne dépend d'aucune autorisation du système de fichiers à répliquer.

Je soupçonne que dans votre cas, le simple fait d'apporter des modifications aux fichiers aurait provoqué la réactivation de DFS et la nécessité de les répliquer. Aucune idée de ce qui aurait pu causer cette situation en premier lieu cependant.

Selon cet article de Microsoft http://support.microsoft.com/kb/120929 "Le compte système et le compte administrateur (groupe Administrateurs) ont les mêmes privilèges de fichier, mais ils ont des fonctions différentes."

Cela signifie que le compte système est le même qu'un administrateur local et qu'il existe dans le but d'exécuter des services système avec les privilèges d'un administrateur sans nécessiter de mot de passe. Le processus de réplication dans DFS-R est effectué avec ce compte.

L'utilisateur du système n'a aucune signification particulière dans le système de fichiers ou dans une configuration DFS différente de celle d'un administrateur ordinaire. Cependant, cela peut devenir déroutant car les administrateurs Windows ne fonctionnent pas toujours avec des privilèges administratifs selon la façon dont le programme ou le shell a été appelé, tandis qu'un compte système fonctionnerait probablement toujours avec un jeton escaladé / administrateur. Je suppose que votre configuration DFS était juste boguée, et la modification des listes de contrôle d'accès a peut-être provoqué des appels système ou ouvert / actualisé des poignées de fichier qui ont secoué les toiles d'araignée proverbiales.