Replica DFS e l'utente SYSTEM (autorizzazioni NTFS)

10

Domanda per la quale non riesco a trovare una risposta su Google o Technet ...

La concessione delle SYSTEMautorizzazioni utente ai file e alle cartelle condivisi da DFS ha alcun effetto sulla replica DFS? (E già che ci siamo, v'è alcuna ragione buona non lasciare che SYSTEMdispone delle autorizzazioni per i file DFS-condivisi?)

Viene fuori perché ho una raccolta di spazi dei nomi e cartelle DFS che non sono in grado di creare il problema di qualcun altro e durante la risoluzione di un problema in cui una replica DFS non si stava replicando con un'altra per nessun motivo riconoscibile, ho osservato che il SYSTEMall'account non sono state concesse autorizzazioni per nessuno dei file o delle cartelle nella cartella in questione.

Quindi ho impostato SYSTEMil controllo completo e l'ho propagato, e i nostri rapporti di diagnostica dello stato di DFS sono passati da un backlog di ~ 80 file a un backlog di ~ 100.000 ... e le cose hanno iniziato a replicarsi, incluso un numero di file che erano mancanti su un server o sull'altro (quindi non solo le modifiche alle autorizzazioni hanno iniziato a replicare).

Naturalmente, questo mi ha incuriosito dal fatto che DFS abbia o meno bisogno che l' SYSTEMaccount disponga delle autorizzazioni per svolgere il proprio lavoro, o se forse è stata proprio una modifica all'albero delle cartelle in questione a spingere DFS a entrare in azione. Se è importante, i nostri spazi dei nomi DFS sono stati configurati in base al 2000/2003 e ho appena finito di aggiornare tutti i server a 2008 R2 o 2012 (con UAC abilitato, blech), ma non sono ancora riuscito a rendere funzionale lo spazio dei nomi DFS livelli a Server 2008.

(E punti bonus se qualcuno ha un articolo ufficiale di Microsoft sulle autorizzazioni dei file NTFS e SYSTEMsull'account relativo ai file DFS o di rete.)

file-permissions dfs

— HopelessN00b
fonte

Quando hai aggiornato i server, hai seguito la guida alla migrazione da FRS a DFS? microsoft.com/en-us/download/confirmation.aspx?id=580

— Rex

@Rex Non ho fatto la migrazione FRS -> DFS, e rischierei di indovinare che probabilmente non sono state seguite guide, buonsenso o pensiero razionale, ma abbiamo usato DFS (al contrario di FRS) da parecchio tempo. Non dubito che il motivo per cui funzioni così male sia dovuto al modo in cui è stato inizialmente impostato, nonché al modo in cui è stato migrato. L'aggiornamento in questione era un aggiornamento della versione dello spazio dei nomi , non un aggiornamento FRS -> DFS. Ora correggerò quella parola omessa.

— HopelessN00b

se si eseguisse qualsiasi tipo di replica in DFS in base al 2000/2003, avrebbe utilizzato avrebbe dovuto utilizzare FRS per eseguire la replica. DFS-R per la replica DFS non era disponibile fino al 2003 R2. DFS su 2008 R2 non supporta più FRS per la replica e i server 2008 R2 non possono replicarsi con spazi dei nomi DFS basati su 2003 precedenti a meno che non siano stati aggiornati tutti i server a 2003 R2 (o successivo) e migrati a DFS-R per la replica.

— Rex,

9

Questo thread su technet afferma che SYSTEM ha bisogno del pieno controllo. Tuttavia, non è una fonte molto ufficiale e ulteriori test dimostrano che è sbagliato .

Servizio di replica DFS

Ho dato un'occhiata ai servizi DFS sulla mia macchina Server 2008R2 con Process Explorer. dfsrs.exe, il servizio di replica del file system distribuito, viene eseguito come "NT Authority \ SYSTEM". Tuttavia, ha SeBackupPrivilege e SeRestorePrivilege :

Schermata delle autorizzazioni dfsrs.exe

Dalle costanti di privilegi Microsoft :

SeBackupPrivilege - Richiesto per eseguire operazioni di backup. Questo privilegio fa sì che il sistema conceda il controllo di accesso in lettura a qualsiasi file, indipendentemente dall'elenco di controllo di accesso (ACL) specificato per il file. Qualsiasi richiesta di accesso diversa da quella di lettura viene comunque valutata con l'ACL. 3

SeRestorePrivilege - Richiesto per eseguire operazioni di ripristino. Questo privilegio fa sì che il sistema conceda tutto il controllo di accesso in scrittura a qualsiasi file, indipendentemente dall'ACL specificato per il file. Qualsiasi richiesta di accesso diversa da quella di scrittura viene comunque valutata con l'ACL. Inoltre, questo privilegio consente di impostare qualsiasi utente o gruppo SID valido come proprietario di un file.

Con tali autorizzazioni, il servizio di replica DFS può ignorare qualsiasi autorizzazione per i file: viene data l'autorizzazione per leggere, scrivere e impostare le autorizzazioni su qualsiasi file desiderato.

analisi

Ho creato una cartella in una delle mie condivisioni DFS con alcuni file, impostato il mio account come proprietario e rimosso tutte le autorizzazioni tranne il mio account.

DFS lo ha replicato su tutti gli altri server senza problemi e tutte le repliche avevano le stesse autorizzazioni.

Pertanto, DFS non dipende da alcuna autorizzazione del file system da replicare.

Sospetto che nel tuo caso semplicemente apportare modifiche ai file avrebbe provocato il risveglio di DFS e la necessità di replicarli. Non ho idea di cosa avrebbe causato quella situazione, in primo luogo.

— Concedere
fonte

1

Risposta eccezionale. Darò il segno di spunta e la generosità in 5 giorni, con la sola possibilità che qualcuno possa venire e completare questo.

— HopelessN00b

2

Dangit, avrei dovuto usare un'immagine nel mio post! :(

3

Secondo questo articolo di Microsoft http://support.microsoft.com/kb/120929 "L'account di sistema e l'account amministratore (gruppo Administrators) hanno gli stessi privilegi di file, ma hanno funzioni diverse."

Ciò significa che l'account di sistema è lo stesso di un amministratore locale ed esiste allo scopo di eseguire servizi di sistema con i privilegi di un amministratore senza richiedere una password. Il processo di replica in DFS-R viene eseguito con questo account.

L'utente del sistema non ha alcun significato speciale nel file system o in una configurazione DFS diverso da un normale amministratore. Tuttavia, può diventare confuso perché gli amministratori di Windows non funzionano sempre con privilegi di amministratore a seconda di come è stato chiamato il programma o la shell, mentre un account di sistema probabilmente funzionerebbe sempre con il token escalated / admin. Immagino che la tua configurazione DFS fosse solo buggy, e la modifica di ACL forse causava la creazione di alcune syscalls o l'apertura / aggiornamento di handle di file che scuotevano le proverbiali ragnatele.