Реплікація DFS та користувач SYSTEM (дозволи NTFS)

10

Питання, на яке у мене виникають проблеми з пошуку відповіді в Google чи Technet ...

Чи надає SYSTEMкористувачеві дозволи на файли та папки, що поділяються DFS, впливає на реплікацію DFS? (І хоча ми це робимо, чи є якась вагома причина не дати SYSTEMдозволу на файли, що поділяються DFS?)

Це з'являється тому, що у мене є колекція просторів імен DFS та папок, які я не в змозі скласти чужу проблему, і під час вирішення проблеми, коли одна репліка DFS просто не реплікувалася з іншою без видимих причин, я помітив, що SYSTEMв обліковому записі не було надано жодних дозволів жодному з файлів чи папок у відповідній папці.

Тому я встановив SYSTEMповний контроль і розповсюдив його, і наші діагностичні звіти про стан здоров’я DFS перейшли від показу відставання від ~ 80 файлів до відставання ~ 100 000 ... і все почало реплікуватися, включаючи ряд файлів, які були відсутні на одному або іншому сервері (тому більше, ніж просто зміни дозволів почали реплікувати).

Звичайно, мене це цікавило, чи потрібен DFS SYSTEMобліковому запису, щоб мати дозволи на виконання своєї роботи, чи, можливо, саме будь-яка зміна дерева папок викликала питання, що спонукало DFS до переходу до дії. Якщо це має значення, наші простори імен DFS були створені під 2000/2003, і я нещодавно закінчив оновлення всіх серверів до 2008 R2 або 2012 (з увімкненим UAC, відбілювання), але ще не взявся за підвищення функціонального простору імен DFS рівнів до сервера 2008.

(І бонусні бали, якщо хтось має офіційну статтю Microsoft про дозволи дозволу на файли NTFS та SYSTEMобліковий запис у відповідності до DFS або мережевих файлів.)

file-permissions dfs

— БезнадійноN00b
джерело

Під час оновлення серверів ви дотримувалися посібника з міграції FRS-to DFS? microsoft.com/en-us/download/confirmation.aspx?id=580

— Rex

@Rex Я не робив міграцію FRS -> DFS, і я ризикую здогадатися, щоб сказати, що жодних посібників, найкращих практик здорового глузду чи раціональної думки, ймовірно, не дотримувались, але ми використовували DFS (на відміну від FRS) досить довгий час. Я мало сумніваюся, що причина, на якій вона працює так погано, пов’язана з тим, як вона була створена спочатку, а також із способом її міграції. Розглянуте оновлення було оновленням версії простору імен , а не оновленням FRS -> DFS. Я зараз виправлю це пропущене слово.

— HopelessN00b

якби ви робили будь-яку реплікацію в DFS за 2000/2003 р., вона б мала використовуватись FRS, щоб виконати реплікацію. DFS-R для тиражування DFS був недоступний до 2003 року. DFS на 2008 R2 більше не підтримує FRS для реплікації, а сервери 2008 R2 не могли реплікувати зі старими просторами імен DFS на основі 2003 року, якщо ви не оновили всі сервери до 2003 R2 (або пізнішої версії) та перенесли на DFS-R для реплікації.

— Рекс

9

Цей потік в техніці говорить, що СИСТЕМА потребує повного контролю. Однак не дуже офіційне джерело, і подальше тестування доводить, що це неправильно .

Служба реплікації DFS

Я ознайомився з послугами DFS на моїй машині Server 2008R2 за допомогою Process Explorer. dfsrs.exe, служба реплікації файлів розподіленої файлової системи, працює як "NT Authority \ SYSTEM". Однак у нього є SeBackupPrivilege та SeRestorePrivilege :

Знімок екрана дозволів dfsrs.exe

Від привілейованих констант Microsoft :

SeBackupPrivilege - необхідний для виконання операцій із резервного копіювання. Цей привілей змушує систему надавати весь контроль доступу для читання будь-якому файлу, незалежно від списку контролю доступу (ACL), визначеного для файлу. Будь-який запит на доступ, окрім читання, все ще оцінюється за допомогою ACL. 3

SeRestorePrivilege - необхідний для виконання операцій відновлення. Цей привілей змушує систему надавати весь контроль доступу для запису в будь-який файл, незалежно від ACL, вказаного для файлу. Будь-який запит доступу, крім запису, все ще оцінюється за допомогою ACL. Крім того, ця привілей дозволяє встановити будь-якого дійсного SID користувача або групи як власника файлу.

За допомогою цих дозволів служба реплікації DFS може ігнорувати будь-які дозволи файлів - надається дозвіл на читання, запис та встановлення дозволів на будь-який файл, який йому заманеться.

Тестування

Я створив папку в одній зі своїх спільних файлів DFS з кількома файлами в ній, встановив обліковий запис як власника та видалив усі дозволи, крім мого.

DFS без проблем копіював його на всі інші сервери, і всі репліки мали однакові дозволи.

Таким чином, DFS не залежить від дозволів файлової системи на реплікацію.

Я підозрюю, що у вашому випадку просто внесення будь-яких змін у файли призвело б до пробудження DFS та переконання, що вони потребують реплікації. Хоча навіть не знаю, що могло б спричинити таку ситуацію.

— Грант
джерело

1

Видатна відповідь. Я дам вам ваші галочки та щедрості за 5 днів, з випадковою можливістю, що хтось може прийти і поповнити це.

— HopelessN00b

2

Dangit, я повинен був використовувати зображення у своєму дописі! :(

3

Відповідно до цієї статті від Microsoft http://support.microsoft.com/kb/120929 "Обліковий запис системи та обліковий запис адміністратора (група адміністраторів) мають однакові привілеї файлів, але вони мають різні функції".

Це означає, що системний обліковий запис такий же, як і локальний адміністратор, і він існує для того, щоб запустити системні служби з привілеями адміністратора, не вимагаючи пароля. Процес реплікації в DFS-R виконується з цим обліковим записом.

Користувач системи не має особливого значення у файловій системі або в налаштуваннях DFS, який не відрізняється від звичайного адміністратора. Однак це може стати заплутаним, оскільки адміністратори Windows не завжди працюють з адміністративними привілеями залежно від того, як викликалася програма або оболонка, тоді як системний обліковий запис, ймовірно, завжди працюватиме з ескалацією / адміністратором. Я б здогадувався, що ваша настройка DFS просто баггі, і зміна ACL, можливо, спричинила якісь систематичні дзвінки або відкриття / оновлення ручок файлів, що відхилило поговорні павутини.