DFS-Replikation und der SYSTEM-Benutzer (NTFS-Berechtigungen)

10

Frage, auf die ich bei Google oder Technet keine Antwort finde ...

Hat das Gewähren der SYSTEMBenutzerberechtigungen für gemeinsam genutzte DFS-Dateien und -Ordner Auswirkungen auf die DFS-Replikation? (Und wenn wir schon dabei sind, dann ist es ein guter Grund , nicht zu lassen , SYSTEMhaben Berechtigungen für DFS-freigegebene Dateien?)

Es tritt auf, weil ich eine Sammlung von DFS-Namespaces und -Ordnern habe, mit denen ich das Problem eines anderen nicht lösen kann, und während ich ein Problem behebte, bei dem ein DFS-Replikat ohne erkennbaren Grund nicht mit einem anderen repliziert wurde, stellte ich fest, dass das SYSTEMDas Konto hatte keine Berechtigungen für eine der Dateien oder Ordner in dem betreffenden Ordner.

Also stellte ich SYSTEMdie volle Kontrolle ein und gab sie weiter, und unsere DFS-Integritätsdiagnoseberichte zeigten einen Rückstand von ~ 80 Dateien auf einen Rückstand von ~ 100.000 ... und die Replikation begann, einschließlich einer Reihe von fehlenden Dateien auf dem einen oder anderen Server (also wurden mehr als nur die Berechtigungsänderungen repliziert).

Das hat mich natürlich neugierig gemacht, ob DFS das SYSTEMKonto benötigt , um seine Arbeit ausführen zu können, oder ob es möglicherweise nur eine Änderung des fraglichen Ordnerbaums war, die DFS zum Handeln veranlasste. Wenn es darauf ankommt, wurden unsere DFS-Namespaces unter 2000/2003 eingerichtet, und ich habe erst kürzlich das Upgrade aller Server auf 2008 R2 oder 2012 (mit aktivierter Benutzerkontensteuerung, blech) abgeschlossen, bin aber noch nicht dazu gekommen, die DFS-Namespace-Funktion zu erhöhen Ebenen auf Server 2008.

(Und Bonuspunkte, wenn jemand einen offiziellen Microsoft-Artikel über NTFS-Dateiberechtigungen und das SYSTEMKonto in Bezug auf DFS- oder Netzwerkdateien hat.)

file-permissions dfs

— HopelessN00b
quelle

Befolgen Sie beim Upgrade der Server das FRS-zu-DFS-Migrationshandbuch? microsoft.com/en-us/download/confirmation.aspx?id=580

— Rex

@Rex Ich habe die FRS -> DFS-Migration nicht durchgeführt, und ich würde die Vermutung wagen zu sagen, dass Leitfäden, bewährte Praktiken, gesunder Menschenverstand oder rationales Denken wahrscheinlich nicht befolgt wurden, aber wir haben DFS verwendet (im Gegensatz zu FRS) seit geraumer Zeit. Ich habe wenig Zweifel, dass der Grund dafür, dass es so schlecht funktioniert, in der Art und Weise liegt, wie es ursprünglich eingerichtet wurde, sowie in der Art und Weise, wie es migriert wurde. Das fragliche Upgrade war ein Namespace-Versions-Upgrade , kein FRS -> DFS-Upgrade. Ich werde das ausgelassene Wort jetzt korrigieren.

— HopelessN00b

Wenn Sie unter 2000/2003 irgendeine Art von Replikation in DFS durchgeführt hätten, hätte FRS für die Replikation verwendet werden müssen. DFS-R für die DFS-Replikation war erst 2003 R2 verfügbar. DFS unter 2008 R2 unterstützt FRS für die Replikation nicht mehr und 2008 R2-Server konnten nicht mit älteren 2003-basierten DFS-Namespaces repliziert werden, es sei denn, Sie haben alle Server auf 2003 R2 (oder höher) aktualisiert und zur Replikation auf DFS-R migriert.

— Rex

9

Dieser Technet-Thread besagt, dass SYSTEM die volle Kontrolle benötigt. Keine sehr offizielle Quelle, und weitere Tests beweisen, dass es falsch ist .

DFS-Replikationsdienst

Ich habe mir die DFS-Dienste auf meinem Server 2008R2-Computer mit Process Explorer angesehen. dfsrs.exe, der Distributed File System Replication-Dienst, wird als "NT Authority \ SYSTEM" ausgeführt. Es hat jedoch SeBackupPrivilege und SeRestorePrivilege :

Screenshot der Berechtigungen für dfsrs.exe

Aus Microsoft-Berechtigungskonstanten :

SeBackupPrivilege - Erforderlich, um Sicherungsvorgänge auszuführen. Dieses Privileg veranlasst das System, jeder Datei die gesamte Lesezugriffskontrolle zu gewähren, unabhängig von der für die Datei angegebenen Zugriffssteuerungsliste (ACL). Jede andere Zugriffsanforderung als Lesen wird weiterhin mit der ACL ausgewertet. 3

SeRestorePrivilege - Erforderlich, um Wiederherstellungsvorgänge auszuführen. Dieses Privileg veranlasst das System, jeder Datei die gesamte Schreibzugriffskontrolle zu gewähren, unabhängig von der für die Datei angegebenen ACL. Jede andere Zugriffsanforderung als Schreiben wird weiterhin mit der ACL ausgewertet. Darüber hinaus können Sie mit dieser Berechtigung eine gültige Benutzer- oder Gruppen-SID als Eigentümer einer Datei festlegen.

Mit diesen Berechtigungen kann der DFS-Replikationsdienst alle Dateiberechtigungen ignorieren. Er erhält die Berechtigung zum Lesen, Schreiben und Festlegen von Berechtigungen für jede gewünschte Datei.

Testen

Ich habe in einer meiner DFS-Freigaben einen Ordner mit einigen Dateien erstellt, mein Konto als Eigentümer festgelegt und alle Berechtigungen außer meinem Konto entfernt.

DFS hat es ohne Probleme auf alle anderen Server repliziert, und alle Replikate hatten die gleichen Berechtigungen.

Daher ist DFS nicht von Dateisystemberechtigungen zum Replizieren abhängig.

Ich vermute, in Ihrem Fall hätte das einfache Vornehmen von Änderungen an den Dateien dazu geführt, dass DFS aufwachte und feststellte, dass sie repliziert werden mussten. Keine Ahnung, was diese Situation überhaupt verursacht hätte.

— Gewähren
quelle

1

Hervorragende Antwort. Ich werde Ihr Häkchen und Kopfgeld in 5 Tagen geben, für die Gelegenheit, dass jemand mitkommt und das übertrifft.

— HopelessN00b

2

Verdammt, ich hätte ein Bild in meinem Beitrag verwenden sollen! :(

3

Laut diesem Artikel von Microsoft http://support.microsoft.com/kb/120929 "Das Systemkonto und das Administratorkonto (Administratorgruppe) haben dieselben Dateiberechtigungen, aber unterschiedliche Funktionen."

Dies bedeutet, dass das Systemkonto mit einem lokalen Administrator identisch ist und zum Ausführen von Systemdiensten mit den Berechtigungen eines Administrators ohne Kennwort vorhanden ist. Der Replikationsprozess in DFS-R wird mit diesem Konto ausgeführt.

Der Systembenutzer hat im Dateisystem oder in einem DFS-Setup keine besondere Bedeutung, die sich von einem normalen Administrator unterscheidet. Es kann jedoch verwirrend werden, da Windows-Administratoren je nach Aufruf des Programms oder der Shell nicht immer mit Administratorrechten arbeiten, während ein Systemkonto wahrscheinlich immer mit einem eskalierten / Administrator-Token arbeitet. Ich würde vermuten, dass Ihr DFS-Setup nur fehlerhaft war und das Ändern von ACLs möglicherweise dazu führte, dass einige Systemaufrufe durchgeführt oder Dateihandles geöffnet / aktualisiert wurden, die die sprichwörtlichen Spinnweben abschüttelten.