Replikacja DFS i użytkownik SYSTEM (uprawnienia NTFS)

10

Pytanie, na które mam problem ze znalezieniem odpowiedzi w Google lub Technet ...

Czy udzielenie SYSTEMuprawnień 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ć SYSTEMmieć 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 SYSTEMkonto nie miało żadnych uprawnień przyznanych żadnym plikom ani folderom w danym folderze.

Ustawiłem więc SYSTEMpeł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 SYSTEMkonta, 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 SYSTEMkonta w zakresie DFS lub plików sieciowych).

file-permissions dfs

— Beznadziejny
źródło

Czy po aktualizacji serwerów postępowałeś zgodnie z instrukcją migracji z FRS do DFS? microsoft.com/en-us/download/confirmation.aspx?id=580

— Rex

@Rex Nie przeprowadziłem migracji FRS -> DFS i zaryzykuję stwierdzenie, że prawdopodobnie nie zastosowano się do żadnych przewodników, dobrych praktyk zdrowego rozsądku lub racjonalnego myślenia, ale używamy DFS (w przeciwieństwie do FRS) od dłuższego czasu. Nie mam wątpliwości, że powodem, dla którego tak źle działa, jest sposób, w jaki został początkowo skonfigurowany, a także sposób migracji. Uaktualnienie, o którym mowa, było uaktualnieniem wersji przestrzeni nazw , a nie FRS -> uaktualnieniem DFS. Poprawię teraz to pominięte słowo.

— HopelessN00b,

gdybyś robił jakąkolwiek replikację w DFS pod 2000/2003, byłaby ona używana, musiałaby używać FRS do wykonania replikacji. DFS-R dla replikacji DFS był dostępny dopiero w 2003 R2. DFS w 2008 R2 nie obsługuje już FRS do replikacji, a serwery 2008 R2 nie mogły się replikować ze starszymi przestrzeniami nazw DFS opartymi na 2003, chyba że zaktualizowano wszystkie serwery do 2003 R2 (lub nowszej) i migrowano do DFS-R w celu replikacji.

— Rex

9

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 :

Zrzut ekranu uprawnień programu dfsrs.exe

Z Microsoft Privilege Stałe :

SeBackupPrivilege - Wymagany do wykonywania operacji tworzenia kopii zapasowej. To uprawnienie powoduje, że system przyznaje całą kontrolę dostępu do odczytu każdemu plikowi, niezależnie od listy kontroli dostępu (ACL) określonej dla pliku. Każde żądanie dostępu inne niż odczyt jest nadal analizowane za pomocą ACL. 3)

SeRestorePrivilege - Wymagany do wykonania operacji przywracania. To uprawnienie powoduje, że system przyznaje całą kontrolę dostępu do zapisu do dowolnego pliku, niezależnie od listy ACL określonej dla pliku. Każde żądanie dostępu inne niż zapis jest nadal analizowane za pomocą ACL. Ponadto to uprawnienie umożliwia ustawienie dowolnego prawidłowego identyfikatora SID użytkownika lub grupy jako właściciela pliku.

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ę.

— Dotacja
źródło

1

Znakomita odpowiedź. Dam ci znacznik wyboru i nagrodę za 5 dni, z szansą, że ktoś może przyjść i zająć to miejsce.

— HopelessN00b,

2

Cholera, powinienem był użyć zdjęcia w swoim poście! :(

3

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ą.