Репликация DFS и пользователь SYSTEM (разрешения NTFS)
Вопрос, на который я не могу найти ответ в Google или Technet ...
Предоставляет ли SYSTEM разрешения пользователей на общие файлы и папки DFS влияют на репликацию DFS? (И пока мы на этом, есть ли веская причина не позволить SYSTEM есть разрешения на общие файлы DFS?)
Это связано с тем, что у меня есть набор пространств имен и папок DFS, которые я не могу создать для кого-то другого, и при устранении проблемы, когда одна реплика DFS просто не реплицировалась с другой без видимой причины, я заметил, что SYSTEM У учетной записи не было разрешений ни к одному из файлов или папок в указанной папке.
Итак, я установил SYSTEM чтобы иметь полный контроль и распространять его вниз, и наши отчеты о диагностике работоспособности DFS перешли от невыполнения ~ 80 файлов до ~ 100000 ... и все начало реплицироваться, включая несколько файлов, которые отсутствовали на одном сервере или другой (так что начали реплицироваться не только изменения разрешений).
Естественно, это заставило меня задуматься о том, нужен ли DFS SYSTEM учетная запись, чтобы иметь разрешения для выполнения своей работы, или, возможно, это было просто какое-либо изменение в рассматриваемом дереве папок, которое побудило DFS перейти к действию. Если это имеет значение, наши пространства имен DFS были настроены в 2000/2003 годах, и я только что завершил обновление всех серверов до 2008 R2 или 2012 (с включенным UAC, черт возьми), но еще не дошел до повышения функциональности пространства имен DFS уровней до Server 2008.
(И бонусные баллы, если у кого-то есть официальная статья Microsoft о разрешениях файлов NTFS и SYSTEM учетной записи, поскольку она относится к DFS или сетевым файлам.)
Эта ветка на технет говорит, что СИСТЕМЕ нужен полный контроль. Однако не очень официальный источник, и дальнейшее тестирование доказывает, что это не так.
Служба репликации DFS
Я взглянул на службы DFS на моем компьютере Server 2008R2 с помощью Process Explorer. dfsrs.exe, служба репликации распределенной файловой системы, работает как «NT Authority \ SYSTEM». Однако у него есть SeBackupPrivilege и SeRestorePrivilege:
Из констант привилегий Microsoft:
SeBackupPrivilege - Требуется для выполнения операций резервного копирования. Эта привилегия заставляет систему предоставлять весь контроль доступа на чтение к любому файлу, независимо от списка контроля доступа (ACL), указанного для файла. Любой запрос доступа, кроме чтения, по-прежнему оценивается с помощью ACL.3
SeRestorePrivilege - Требуется для выполнения операций восстановления. Эта привилегия заставляет систему предоставлять все права доступа на запись к любому файлу, независимо от ACL, указанного для файла. Любой запрос доступа, кроме записи, по-прежнему оценивается с помощью ACL. Кроме того, эта привилегия позволяет вам установить любого действительного пользователя или группы SID в качестве владельца файла.
С этими разрешениями служба репликации DFS может игнорировать любые разрешения файлов - ей дается разрешение на чтение, запись и установку разрешений для любого файла, который ей нравится.
Тестирование
Я создал папку в одном из моих общих ресурсов DFS с несколькими файлами в ней, назначил свою учетную запись владельцем и удалил все разрешения, кроме моей учетной записи.
DFS без проблем реплицировала его на все остальные серверы, и все реплики имели одинаковые разрешения.
Таким образом, DFS не зависит от разрешений файловой системы на репликацию.
Я подозреваю, что в вашем случае простое внесение каких-либо изменений в файлы заставило бы DFS проснуться и увидеть, что они нуждаются в репликации. Не знаю, что вообще могло вызвать такую ситуацию.
Согласно этой статье от Microsoft http://support.microsoft.com/kb/120929 «Системная учетная запись и учетная запись администратора (группа администраторов) имеют одинаковые права доступа к файлам, но имеют разные функции».
Это означает, что системная учетная запись такая же, как у локального администратора, и существует для запуска системных служб с привилегиями администратора без необходимости ввода пароля. Процесс репликации в DFS-R выполняется с этой учетной записью.
Системный пользователь не имеет особого значения в файловой системе или в настройке DFS, отличной от обычного администратора. Однако это может сбивать с толку, потому что администраторы Windows не всегда работают с административными привилегиями в зависимости от того, как была вызвана программа или оболочка, тогда как системная учетная запись, скорее всего, всегда будет работать с расширенным токеном / администратором. Я предполагаю, что ваша установка DFS просто глючила, и изменение ACL, возможно, вызывало какие-то системные вызовы или открытие / обновление файловых дескрипторов, которые стряхивали пресловутую паутину.