Pytanie, na które mam problem ze znalezieniem odpowiedzi w Google lub Technet ...
Czy udzielenie SYSTEM
uprawnień użytkownika do plików i folderów współdzielonych w systemie plików DFS ma jakikolwiek wpływ na replikację systemu plików DFS? (A skoro już nad tym pracujemy, czy jest jakiś dobry powód, aby nie pozwalać SYSTEM
mieć uprawnień do plików współdzielonych z DFS?)
Pojawia się, ponieważ mam kolekcję przestrzeni nazw i folderów DFS, których nie jestem w stanie zrobić z czyimś problemem, a podczas rozwiązywania problemu, w którym jedna replika DFS po prostu nie replikuje się z inną bez wyraźnego powodu, zauważyłem, że SYSTEM
konto nie miało żadnych uprawnień przyznanych żadnym plikom ani folderom w danym folderze.
Ustawiłem więc SYSTEM
pełną kontrolę i rozpropagowałem ją, a nasze raporty diagnostyczne DFS zmieniły się z pokazywania zaległości ~ 80 plików na zaległości ~ 100 000 ... i wszystko zaczęło się replikować, w tym wiele brakujących plików na jednym lub drugim serwerze (więc replikacja rozpoczęła więcej niż zmiany uprawnień).
Naturalnie zainteresowało mnie to, czy DFS potrzebuje SYSTEM
konta, aby mieć uprawnienia do wykonywania swojej pracy, czy może była to tylko jakaś zmiana w drzewie folderów, która skłoniła DFS do działania. Jeśli to ma znaczenie, nasze przestrzenie nazw DFS zostały skonfigurowane pod 2000/2003, a ja właśnie zakończyłem aktualizację wszystkich serwerów do 2008 R2 lub 2012 (z włączoną funkcją UAC, blech), ale jeszcze nie zacząłem zwiększać funkcjonalności przestrzeni nazw DFS poziomy do Server 2008.
(I punkty bonusowe, jeśli ktoś ma oficjalny artykuł Microsoft na temat uprawnień do plików NTFS i SYSTEM
konta w zakresie DFS lub plików sieciowych).
źródło
Odpowiedzi:
Wątek w witrynie technet mówi, że SYSTEM potrzebuje pełnej kontroli. Nie jest to jednak zbyt oficjalne źródło, a dalsze testy dowodzą, że jest to błąd .
Usługa replikacji systemu plików DFS
Rzuciłem okiem na usługi DFS na moim serwerze Server 2008R2 za pomocą Process Explorer. dfsrs.exe, usługa replikacji rozproszonego systemu plików, działa jako „NT Authority \ SYSTEM”. Ma jednak SeBackupPrivilege i SeRestorePrivilege :
Z Microsoft Privilege Stałe :
Dzięki tym uprawnieniom usługa replikacji systemu plików DFS może ignorować wszelkie uprawnienia do plików - otrzymuje uprawnienia do odczytu, zapisu i ustawiania uprawnień do dowolnego pliku, który mu odpowiada.
Testowanie
Utworzyłem folder w jednym z moich udziałów DFS z kilkoma plikami, ustawiłem moje konto jako właściciela i usunąłem wszystkie uprawnienia oprócz mojego konta.
DFS zreplikował go na wszystkich innych serwerach bez problemu, a wszystkie repliki miały takie same uprawnienia.
Dlatego DFS nie jest zależny od jakichkolwiek uprawnień systemu plików do replikacji.
Podejrzewam, że w twoim przypadku po prostu wprowadzenie jakichkolwiek zmian w plikach spowodowałoby, że DFS się obudził i zobaczył, że muszą się replikować. Nie mam jednak pojęcia, co spowodowałoby tę sytuację.
źródło
Zgodnie z tym artykułem Microsoft http://support.microsoft.com/kb/120929 „Konto systemowe i konto administratora (grupa Administratorzy) mają te same uprawnienia do plików, ale mają różne funkcje”.
Oznacza to, że konto systemowe jest takie samo jak lokalny administrator i istnieje w celu uruchamiania usług systemowych z uprawnieniami administratora bez wymagania hasła. Proces replikacji w DFS-R jest wykonywany przy użyciu tego konta.
Użytkownik systemu nie ma specjalnego znaczenia w systemie plików lub w konfiguracji DFS inaczej niż zwykły administrator. Może to jednak być mylące, ponieważ administratorzy systemu Windows nie zawsze działają z uprawnieniami administracyjnymi w zależności od tego, jak wywołano program lub powłokę, podczas gdy konto systemowe prawdopodobnie zawsze działałoby z eskalowanym / tokenem administratora. Domyślam się, że twoja konfiguracja DFS była po prostu błędna, a modyfikowanie list ACL prawdopodobnie spowodowało wykonanie niektórych połączeń systemowych lub otwarcie / odświeżenie uchwytów plików, które wstrząsnęły przysłowiową pajęczyną.
źródło