Переезд Netware --> WIN

[Андрей Старков]

Коллеги, добрый день.
В Флейм писать не стал,, этот форум более "живой"
Как я не сопротивлялся, вышестоящая "контора" заставляет переезжать исключительно на Windows Server.
Я уже 3 подразделения, разные площадки, сервера, перевел но система прав на файловую систему NTFS меня просто выбешивает. Я скорее всего не умею ее готовить (как тех котов)
С тем, что установка прав на каталоги с большим количеством папок и файлов занимает ощутимое время я уже смирился. Хотя не верится что нельзя как то по другому.

Может поделитесь ссылками или документами на лучшие практики по раздаче прав в сети на NTFS. Если есть документы ориентированные на мозги человека использующего Netware c 93 года буду вам совсем признателен. Особенно угнетает, когда необходимо раздать права в одной из вложенных папок.

В общем буду признателен за любую полезную информацию, совет

Спрашиваю здесь а не на виндовом форуме каком-нибудь потому что вы лучше меня поймете.

[URRY]

Смирись , установка прав на каталоги с большим числом файлов занимает до и больше времени , такова ntfs.
Тебе нужно перетащить права из nss в ntfs ? посмотри в сторону команды cacls в винде. Я попробовал бы сделать следующее:
В RM Netware создать отчет об опекунах нужного тома ,и отредактировать полученный отчет под формат команды cacls.

[Андрей Старков]

за cacls спасибо!
но меня больше волнует не разовый перенос, а как жить с этим дальше.
Общий том. на котором куча разной инфы для всего предприятия. Например общий каталог, в котором каждая служба должна видеть свой каталог, кто то еще должен видеть все только по чтению, кто то иметь полные права. Я не могу дать права службе только на ее каталог. Я должен дать всем чтение и траверс папок на общий каталог, а потом, чтобы каждая служба не видела структуру вложенных папок всех остальных служб (правда файлов не видят) я уже убираю наследование с верхнего каталога (с копированием существующих прав), удаляю всем права и даю уже конкретной группе. Изврат.
А есть службы в которых в определенной папке все работники имеют все права, но пяток файлов надо чтобы править могли 1-2 человека и эти файлы по смыслу лежат в разных каталогах. в Netware решалось просто, я грамотному инженеру давал права управления и они у себя руководили. Сейчас сложнее, я сам еще не понимаю как эти "особые" права настроить, не то что объяснить людям

[URRY]

погугли Access-based Enumeration (ABE) , помогает скрыть папки к которым нет доступа.

[Андрей Старков]

О, этот ABE мне знаком! Как говорят эта фича вроде появилась только с 2008 Сервера, а как раньше жили не представляю. Чтобы скрыть папки к которым нет доступа его надо сначала на верхнем уровне дать, а потом у всех групп кроме одной забрать

[URRY]

О, этот ABE мне знаком! Как говорят эта фича вроде появилась только с 2008 Сервера, а как раньше жили не представляю. Чтобы скрыть папки к которым нет доступа его надо сначала на верхнем уровне дать, а потом у всех групп кроме одной забрать

в 2003 воде как тоже есть , но правда как отдельная фича

[Доменика]

О, этот ABE мне знаком! Как говорят эта фича вроде появилась только с 2008 Сервера, а как раньше жили не представляю. Чтобы скрыть папки к которым нет доступа его надо сначала на верхнем уровне дать, а потом у всех групп кроме одной забрать

Это появилось только с W2k8R2 и на официальных курсах при разборе прав на файловую систему так и называется - в стиле NetWare.

Интересно, чего стоит ОДИН файл случайной удаленный большим начальником на серверах NetWare или на виндовых шарах?
И сакраментальный вопрос чем Вы занимаетесь на работе если даже простого, как восстановить файл, сделать не в состоянии.
Выбираем что? Лучшее или как все....

[URRY]

Это появилось только с W2k8R2 и на официальных курсах при разборе прав на файловую систему так и называется - в стиле NetWare.

https://www.microsoft.com/en-us/downloa ... x?id=17510

[Павел Гарбар]

Правильнее всего будет заново придумать принцип размещения файлов и каталогов (например, по-другому структуру папок сделать), с тем, чтобы по-новому раздавать права на расшаренные папки, потому как один-в-один воссоздать не получится.
Надо научиться использовать сильные стороны и стараться избегать или нивелировать слабые стороны. Например, присвоение прав на папку с большим количеством вложенных файлов занимает много времени, потому что права статично прописываются в каждый файл. Поэтому при переносе каких-либо файлов я сначала делаю папку, даю на нее права и только потом начинаю переписывать туда файлы, таким образом файлы сразу получают нужные права.
Переделывание прав во вложенных каталогах не самая приятная, быстрая и удобная процедура. Это я смог сравнить еще в 1996 году, когда в дружественной конторе виндовый админ назначал права "тут читаем, там пишем, а тут снова читаем" разным отдельным пользователям.

[Сергей Дубров]

Это появилось только с W2k8R2 и на официальных курсах при разборе прав на файловую систему так и называется - в стиле NetWare.

https://www.microsoft.com/en-us/downloa ... x?id=17510

Да, правильно, эта фича (ABE) появилась как опция в Windows 2003SP1. Кстати, её активация (скрытие папок, к которым нет доступа) ощутимо подтормаживает (Микрософт говорит про 2-3 секундные задержки вывода списка папок при их кол-ве ~несколько сотен). И - важный момент - скрытие работает только для сетевой шары, на локальной файловой системе вы всё равно будете видеть все папки, к которым не имеете доступа.

Долгое "прорастание" прав по ACL в развесистой файловой системе, как правильно написал Павел, объясняется статическим прописыванием в ACL каждого(!) нижележащего файлового объекта, обеспечивающее реализацию наследования ("засеренные" права в GUI). У Новела запись в ACL не приводит ни к каким write amplifier, запись производится ровно в один ACL .

Скорость "прорастания" по ACL у венды - это вообще песня - не контролируется, не управляется, не мониторится, прилично грузит CPU. Знаю пару замечательных случаев, когда, не дав правам прорасти, нижнюю часть развесистой файловой структуры переместили внутри тома в другое место. В итоге права остались в раскоряченном состоянии - часть прорасти успела, часть нет. Недопроросшие ACL так и остались неправильными даже спустя пару суток. В итоге права пришлось переназначать заново (и опять ждать несколько часов).

Побочный эффект от статического прописывания прав в ACL - при перемещении подпапок в другое место файловой иерархии они с собой переносят права . Т.е., дал права на корневую папочку \DOC, потом одну из подпапок \DOC\DEP1 переносишь в корень - а у неё права остались, унаследованные от \DOC.

Но не всё плохо у венды с правами, мне, н-р, очень нравится возможность назначать права для Creator-Owner - очень удобный механизм, в новеловском подходе не хватало.

[Сергей Дубовский]

Год назад осуществил аналогичную процедуру, до сих пор плююсь от многих вещей... Хотя и плюсы тоже есть, но некоторые вещи бесят конкретно. Поделюсь некоторыми моментами. Может и для себя что новое узнаю.
1) у статичного назначения прав есть еще один побочный эффект, который для новелиста будет совсем неочевидным (по крайней мере для меня это было неожиданностью). Дело в том, что при переносе папки с файлами или файлов в рамках одного тома, права не обновляются в соответствии с правами папки назначения. Т.е. тупо переносится ссылка, а все права на папки/файлы остаются без изменений, в итоге возможна ситуация, когда вы перенесли файлы из доступной всем папки в папку с ограниченными правами доступа, но перенесенные файлы/папки будут по прежнему доступны всем.
Либо вы решили перенести файлы из домашней папки одного пользователя в домашнюю папку другого, хозяин парки назначения не будет иметь к ним доступа. При копировании создаются копии файлов с правами папки назначения. Так что рекомендуется не злоупотреблять командой Move. Для меня на уровне рефлексов было сложно принять что права файлов в папке живут отдельно от прав папки.

2) при изменении прав на папку устанавливается архивный атрибут на все файлы в папке. Если используется система инкрементального бэкапа на основании этого атрибута, то объем инкрементальных копий увеличится.

3) Для просмотра инфы о том, кто открыл тот или иной файл я нашел три способа, и все с недостатками:
fsmgmt.msc - выдает все открытые файлы на сервере, нет никаких возможностей фильтрации по имени пользователя или файлу
net files - консольная утилита - не показывает полный путь, если он длинный (в середину вставляет троеточие)
psfiles - консольная утилита от Sysinternals - не корректно отображает пути с русскими буквами.
Есть еще команды PowerShell, но проблемы те же, что и с NET FILES. Ничего стороннего найти не удалось, если кто-то что-то посоветует буду признателен!

4) Корзина на вин-сервере не восстанавливает файлы, удаленные по сети через сетевую шару с этого сервера. Заменой служит создание теневых копий.
http://interface31.ru/tech_it/2012/07/windows-server-nastraivaem-tenevye-kopii-dlya-obshhih-papok.html Плюсом то что можно восстановить не только удаленные но и измененные файлы, минусы - расход места для копий и выполнение их по расписанию, т.е. если файл был создан, заполнен и удален между созданием теневых копий, то восстановить его никак не удастся. Ну и эту службу надо настроить, хотя это и не сложно. По умолчанию она отключена.

5) Бесит что нельзя изменить и запомнить размеры окна свойств файла/пользователя и т.п. и приходится все время прокручивать список прав, или параметров пользователя. Настраиваемый интерфейс Netware Administrator, где можно было включать/выключать разделы и менять их порядок вспоминается в такие минуты с особой теплотой. Вообще я бы сказал, что об удобстве администрирования (в мелочах, которые могут тем не менее экономить много часов и нервов) никто не заботится и не собирается.

6) Когда переходил, думал что теперь то быстрый поиск файлов по содержанию с использованием Windows Search будет доступен и на сетевых дисках, т.е. я по наивности предполагал, что десктопный widows search будет прозрачно использовать индексы с сервера. Как бы не так. Искать по индексам на сервере можно только локально на сервере, либо через rdp.

7) При использовании WinVista и старше со включенным UAC, при работе под пользователем с правами локального админа будут разнообразные траблы с работой логин-скриптов. Связано это с особенностями работы UAC. Одна из статей на эту тему https://support.microsoft.com/ru-ru/kb/937624. Нормального решения, как я понял нет. Либо отключать UAC либо отрубать права локального админа (что в принципе MS и рекомендует) и вводить имя пароль другого пользователя с правами, при запросе UAC, либо запускать логин скрипт в ручную.

[Сергей Дубров]

Год назад осуществил аналогичную процедуру, до сих пор плююсь от многих вещей... Хотя и плюсы тоже есть, но некоторые вещи бесят конкретно. Поделюсь некоторыми моментами. Может и для себя что новое узнаю.
1) у статичного назначения прав есть еще один побочный эффект, который для новелиста будет совсем неочевидным (по крайней мере для меня это было неожиданностью). Дело в том, что при переносе папки с файлами или файлов в рамках одного тома, права не обновляются в соответствии с правами папки назначения. Т.е. тупо переносится ссылка, а все права на папки/файлы остаются без изменений, в итоге возможна ситуация, когда вы перенесли файлы из доступной всем папки в папку с ограниченными правами доступа, но перенесенные файлы/папки будут по прежнему доступны всем.
Либо вы решили перенести файлы из домашней папки одного пользователя в домашнюю папку другого, хозяин парки назначения не будет иметь к ним доступа. При копировании создаются копии файлов с правами папки назначения. Так что рекомендуется не злоупотреблять командой Move. Для меня на уровне рефлексов было сложно принять что права файлов в папке живут отдельно от прав папки.

Угу, я про это чуть выше писал - когда столкнулся с этим впервые (давно уже дело было) - долго соображал, почему юзеры по-прежнему имеют доступ к папке, которую я перенёс в корень тома

3) Для просмотра инфы о том, кто открыл тот или иной файл я нашел три способа, и все с недостатками:
fsmgmt.msc - выдает все открытые файлы на сервере, нет никаких возможностей фильтрации по имени пользователя или файлу
net files - консольная утилита - не показывает полный путь, если он длинный (в середину вставляет троеточие)
psfiles - консольная утилита от Sysinternals - не корректно отображает пути с русскими буквами.
Есть еще команды PowerShell, но проблемы те же, что и с NET FILES. Ничего стороннего найти не удалось, если кто-то что-то посоветует буду признателен!

Рекомендую свою любимую контору JRBSoftware, они уже несколько лет делают утилита и для AD. Конкретно:

http://www.jrbsoftware.com/jrbutils_ad/ ... Adopenfile

Код: Выделить всё

Adopenfile

Adopenfile displays the files held open on a server by network connections. It can do the following:

    List all open files in and below a given network path.
    List all files on a server held open by network connections.
    Display open files for a given user or for objects selected via wildcards.
    Close open files.
    Display the number of locks on each file and the permissions used to open it.
    Has flexible output options allowing fields to be displayed in any combination and order, and optionally in csv format.
    The results may be sorted on any field.


Утилиты, как и их же утилиты для Novell - сильно небесплатные, но они того стОят (сейчас цены заметно снижены, 600$ на год за 53 утилиты + документация, в позапрошлом году было 900$). Плюс автор очень отзывчивый и приятный в общении человек, в утилитах для Новела (мы их покупали с 1998-го года) он делал несколько серьёзных изменений, исправлений конкретно по моим просьбам, в частности, полностью решил проблемы с кодировками для файлов с русскими именами (н-р, в openfile).

4) Корзина на вин-сервере не восстанавливает файлы, удаленные по сети через сетевую шару с этого сервера. Заменой служит создание теневых копий.
http://interface31.ru/tech_it/2012/07/windows-server-nastraivaem-tenevye-kopii-dlya-obshhih-papok.html Плюсом то что можно восстановить не только удаленные но и измененные файлы, минусы - расход места для копий и выполнение их по расписанию, т.е. если файл был создан, заполнен и удален между созданием теневых копий, то восстановить его никак не удастся. Ну и эту службу надо настроить, хотя это и не сложно. По умолчанию она отключена.

Shadow copy, это конечно, здорово, но мне пришлось несколько раз сталкиваться с серьёзными проблемами, связанными с этой технологией. Недавний пример: бэкапил MAC OS X (штатная Time Machine) на Win-сервер (Windows Home Server 2011 - это подпиленный Windows 2008 R2), используя sparse-файлы (почти штатная процедура, требует для инициализации немного ручной работы). Sparse-файл, который видит MAC OS X, на вендовой файловой системе превращался в кучу пронумерованных файлов размером (chunk) 8 МБайт. Бэкапилось всё, бэкапилось, потом - ба-бах - ошибка, говорит, давай заново инициализируем. Не, думаю, у меня же теневая копия есть. Захожу в свойства папки, выбираю нужную теневую копию, говорю восстанавливай все файлы (chunk-и) в ней. Началось восстановление и... через пять-десять минут - "Фатальная ошибка, восстановление невозможно". И, что особенно прелестно - исчезли ВСЕ теневые копии. Просто шикарно!

После повторных отказов теневого копирования (точнее, восстановления) в третий или четвёртый раз, я его (shadow copy) выключил совсем, полностью, по причине невозможности реального использования. Бэкаплю акронисом на внешний диск. Кстати, выключение shadow copy заняло несколько часов, со 100% занятыми обоими ядрами CPU (массив 6ТБ, занято около 1.5Тб). И теневое копирования - использовалось умолчание, 6:00 и 13:00 - кроме занятого места на дисках, ощутимо подтормаживало машину, так, что даже видеопотоок с неё начинал заикаться.

Подобные проблемы при восстановление, с использованием теневых копий, я наблюдал в своей практике несколько раз, включая "залёт" уже в этом году, на Win2012 R2. С тех пор у меня стойкое ощущение недоверия к этой технологии. И, как гласит мудрость сисадмина: "Неважно, какой у тебя бэкап, главное - какой у тебя restore"
...

7) При использовании WinVista и старше со включенным UAC, при работе под пользователем с правами локального админа будут разнообразные траблы с работой логин-скриптов. Связано это с особенностями работы UAC. Одна из статей на эту тему https://support.microsoft.com/ru-ru/kb/937624. Нормального решения, как я понял нет. Либо отключать UAC либо отрубать права локального админа (что в принципе MS и рекомендует) и вводить имя пароль другого пользователя с правами, при запросе UAC, либо запускать логин скрипт в ручную.

О, да, секас с правами при работе логин-скриптов - это ещё одна песня. И, действительно, нормального решения до сих пор нет - такая модель безопасности.

[Сергей Дубовский]

Да, с теневым копированием тоже была один раз проблема при попытке восстановить папку большого объема. В итоге я его не стал отключать, но ни в коем разе не считаю его заменой бэкапу, скорее его дублированием с возможностью быстрого восстановления и просмотра бОльшего числа состояний (бэкап у меня раз в сутки ночью, а теневых копий несколько в течении дня). ну и по любому это нельзя рассматривать как надежный бэкап с точки зрения того что диски те же, что и у рабочих файлов. Ну и у меня объем томов на порядок поменьше будет, так что может тоже сказалось.

За наводку на утилиты спасибо! А что значит 600$ на год? Имеется ввиду возможность получения апдейтов?
Или через год работать перестанут, если не продлить? При нынешнем курсе сумма то немаленькая...

[Сергей Дубров]

Да, с теневым копированием тоже была один раз проблема при попытке восстановить папку большого объема. В итоге я его не стал отключать, но ни в коем разе не считаю его заменой бэкапу, скорее его дублированием с возможностью быстрого восстановления и просмотра бОльшего числа состояний (бэкап у меня раз в сутки ночью, а теневых копий несколько в течении дня). ну и по любому это нельзя рассматривать как надежный бэкап с точки зрения того что диски те же, что и у рабочих файлов. Ну и у меня объем томов на порядок поменьше будет, так что может тоже сказалось.

Да, я тоже заметил, теневое копирование спотыкается именно на больших объёмах.

За наводку на утилиты спасибо! А что значит 600$ на год? Имеется ввиду возможность получения апдейтов?
Или через год работать перестанут, если не продлить? При нынешнем курсе сумма то немаленькая...

Нет, Baird никаких timebomb не практиковал и не практикует, всё продолжает работать и через год и через десять (сейчас специально позапускал утилиты образца 2003 года - всё работает). Никаких файлов лицензий, ключей, привязок не было, расчитано на честность. Оплата - это получение поддержки и обновлений (у него новые версии выходят традиционно в конце года, к рождеству, примерно до 5-10 декабря можно будет скачивать апдейты). После оплаты он присылает логин/пароль на дистрибутив, пароль на зашифрованный архив с документацией (если её оплатили) и логин/пароль для скачивания апдейтов.

Хотя всё вышесказанное относится к утилитам JRBSoftware for Novell, скорее всего с утилитами для AD то же самое (мы их ещё ни разу не покупали, вот прямо сейчас я занят оформлением их первой покупки).

Мне у него очень нравится документация, хотя у всех утилит есть online help, иногда его бывает недостаточно. Вот реальный пример командной строки, когда без доков такую комбинацию ключей было бы сочинить практически нереально:

trstlist . /# /dt /cd /su /wo /yd /j

UPD: цитата с сайта:

Код: Выделить всё

To continue receiving updates to JRButils for AD after 12 months from the initial purchase, renewal of registration is available at the following pricing, provided that the renewal is paid within 6 months. After that time, full pricing applies.

    Software plus documentation US$400


[Clericos]

7) При использовании WinVista и старше со включенным UAC, при работе под пользователем с правами локального админа будут разнообразные траблы с работой логин-скриптов. Связано это с особенностями работы UAC. Одна из статей на эту тему https://support.microsoft.com/ru-ru/kb/937624. Нормального решения, как я понял нет. Либо отключать UAC либо отрубать права локального админа (что в принципе MS и рекомендует) и вводить имя пароль другого пользователя с правами, при запросе UAC, либо запускать логин скрипт в ручную.

О, да, секас с правами при работе логин-скриптов - это ещё одна песня. И, действительно, нормального решения до сих пор нет - такая модель безопасности.

А что помещается в logon скрипт, что требует прав администратора?

К чему вопрос: У меня там только подключение сетевых дисков. Но были случаи, когда требовались права администратора. Конкретно - требовалось проверить установлена ли нужная программа и если нет - установить. Так это решается групповой политикой с скриптом прикрученной на уровне "Конфигурация компьютера" (на всякий случай повторюсь: не на Конфигурацию пользователя, а на Конфигурацию компьютера). Там всё работает под админскими правами ДО входа пользователя в компьютер (между запуском и "нажатия ctrl+alt+del"). Вот пример проблемы - решения.


Кстати, очень часто читаю о проблемах с долгим назначением прав на папки. Чуть выше писали - что окно маленькое и невидно каким пользователям какие права назначены. Согласен.
Просто хочу обратить внимание (хотя это вроде как очевидно, но может это очевидно только мне как win админу) - что назначение прав на папки в среде Windows на уровне пользователя - это дурной тон.
Права, в 99,90% случаев, следует назначать на группы пользователей ОДИН РАЗ. Если сложная система прав - создается несколько групп (например contracts_readonly, contracts_fullaccess, contracts_onlydistributors, contracts_onlysomething), а затем группы пользователей и пользователи добавляются в эти группы доступа. Например в группу contracts_fullaccess добавляется группа SalesDep + Ivan.Ivanov. А если Иванову не нужен более доступ, то из группы contracts_fullaccess - Иванов удаляется (и после "перевхода" (пере логина) в windows - Иванов потеряет права. Это, КСТАТИ, отдельная особенность которую нужно знать Netware админу. После добавления в группу/исключения из группы - это вступает в силу через некоторое (лень искать в документации) время, либо сразу если человек перелогинился.).

Кроме того крупные шары лучше просто изолировать отдельными шарами (Если это возможно, а это всегда возможно). Это изначально решает множество проблем.
Например отдельные шары
\\Server\Public
\\Server\Sales
\\Server\название-отдела
\\Server\название-отдела
\\Server\название-отдела
и тогда во многих случаях можно не назначать NTFS права вообще. Пользоваться правами на "шару".

Добавлено 1: Кроме того пропадает ещё одна головная боль. Когда кто-то переносит папку с правами только для одного отела (\\Server\Sales\Folder) в папку с правами для всех сотрудников (\\Server\Public\Folder) (т.е. между шарами)... файлы, по факту, при переносе копируются, а оригиналы удаляются. Т.е. NTFS права в такой ситуации пересоздаются автоматически и корректно (о чем жаловались выше).

Добавлено 2:Кстати, у Windows server есть настройка запрещающая перенос NTFS прав (в пределах одной шары). Файлы переносятся немного дольше, т.к. на них при переносе выставляются заново NTFS права. Легко найдете в интернете. (Я её не пробовал, думаю работает).

К чему я тут капитаню... Каждый пятый пишет про нюансы с ACL. Ну да они есть, однако при правильном планировании и знании мат части они не являются проблемой.


P.S. Прошу прощения, если опять задел чьи-то чувства (что уже бывало, к сожалению). Я не фанат MS. Просто 15 лет админю Win сети и чуть-чуть netware/groupwise, с проблемами этими сталкивался только в начале карьеры.

p.s. Знаю, у Novell попроще и удобнее будет.