Странное поведение ntfs разрешений - постоянно меняется Владелец фаила.
 

Всем доброго времени суток! Есть определенная странность в NTFS разрешениях. Установлен Windows server 2008 r2 введен в домен. Установлены фаиловые службы. Есть общая папка со включенным Access-based enumeration. Общая папка подключена как сетевой диск через Group policy preference на группу безопасности пользователи домена. Суть такая: в этой общей папке есть несколько папок - на родительскую папку даны разрешение на уровне общей папки ВСЕм полный дуступ - ntfs - тоже ВСЕм - только чтение. На дочерних папках отменено наследие и удалено разрешение для ВСЕх - на каждую папку добавлены свои группы, чтобы корректно работал ABE. Т.е список получается такой: Администраторы, СОЗДАТЕЛЬ-ВЛАДЕЛЕЦ, система, своя группа и учетка domain admina - соответсвенно у всех полный доступ кроме своей группы. Да и учетка определенного domain adminа появилась там после копирования - т.к. все папки были перенесены при помощи копирования(не переноса) с одной машины на другую. и теперь domain admin владелец всего(причем не группа администраторы, а сам domain admin, что странно т.к. если создавать фаил из под учетки локального админа - то иммено группа будет создателем владельцем, а не сам администратор.) Вообщем суть в чем - после любого редактирования фаила пользователем(у кого есть разрешения на запись, он становится владельцем, и так постоянно, кто отредактировал тот и владелец, хотя прав у него таких. Есть только на изменение. А как отредактировал, так стал владельцем и получил полные права... И при этом, что очень важно, как мне кажется - что если отредактировать тот же фаил из под учетки domain adminа, он НЕ СТАНОВИТСЯ владельцем - остается последний пользователь, который редактировал(правда поменять конечно владельца можно)... Может это конечно и нормальное поведение ntfs. Но допустим если есть наследование и нужно поменять разрешения на родительской папке и при это на фаилах внутри папки владелец сменился на пользователя - появляется ошибка что нет доступа.. система имеет ввиду что не может добавить родительские разрешения - т.к. владелец поменялся, а на родительской папке естевственно владелец другой. Хотя делается это все из-под domain adminа, кто и являлся изначально владельцем всех папок и фаилов.

Полагаю, проблема вызвана не NTFS, а конкретно тем приложением, которое сохраняет файл. Оно наверняка создаёт новый и удаляет оригинал. Так работает, к примеру, Microsoft Office. С этим ничего не сделаешь, this is by design.

Ясно. В моем случае это и есть фаилы word,excel. Ну если с этим ничего не поделаешь и владелец будет меняться, то вопрос о том, почему domain admin и локальный админ не становится владельцем после редактирования остается открытым. Хотя на домашней машине эксперементировал(дома конечно домена нет )))) и лок. админ после редактирования становился владельцем фаила, а в рабочей среде не становится и все тут. в общем то это то мне больше всего и не нравится, а не то что владелец меняется постоянно. Конечно не критично - право владение можно всегда присвоить, но все-таки.

Допускаю, что причина в том же Office. Он проверяет наличие административных привилегий и, если таковые имеются, переназначает владельца нового файла принудительно. То есть, изначально Domain Admins всё же становится владельцем, NTFS не обманешь. Но потом MS Office эту проблему "решает" по-своему.

Опять же все бы ничего, но дома я создаю такой же докумен word, но при этом если отредактировать сначала, скажем, обычным пользователем, то он становится его владельцем. А потом когда редактируешь пользюком, который входит в административную группу, то он забирает право владения. Не понятно почему на работе такого не происходит - причем ни в случае с domain admins, ни в случае пользователем, который добавлен в локальную административную группу через restricted groups. И если даже самим администратором редактировать, то он тоже не становится... Сначала вкрадывались мысли, что в ad у пользователя по-любому есть Основная группа, поставил для domain adminа принудительно основую группу domain admins - не помогло... Хотя, допустим, в случае создания объекта в ADSI по политике паролей - присвоив допустим определенной группе более гуманную политику по смене паролей - если у пользователей входящих в эту группу основная группа не та, на которую задана новая политика паролей - то применяется основная политика, а не эта.