Настройка фильтров наследуемых прав

[grekalov]

ОС NetWare 5.1 SP 8.0, проблема в следующем: посоветовали на вашем форуме прочитать книгу Д.Гаскина NetWare, книга для меня оказалась очень полезной, НО дошел до настройки фильтров наследуемых прав и ни с места; организация дерева у меня вышла такая, пример
дерево
|
организация
|
организационная единица->организационная единица1->пользователи.
Дал доступ организационной единице1 к директории на сервере: организационные единицы->организационная единица1, но внутри директории содержится еще три директории (А, Б, С), и для трех пользователей организационной единицы1 необходимо видеть только директории А и Б, а для для двух только С. Вычитал что это настраивается с помощью фильтров наследуемых прав, а не могу "врубиться" как, очень коротко все описано. Как я пробовал настроить фильтры с помощью ConsoleOne: организационная единица->организационная единица1->свойства, посмотрел права на файлы и директории (DATA:\организационные единицы->организационная единица1), затем NDS Rights->Inherited Rights Filters->Add filter, а какой выбирать, что бы пользователи одни видели две директории, а другие только одну. Окажите, пожалуйста, консультацию или ссылку "киньте" как правильно настраиваются фильтры, желательно на великом и могучем

[Андрей Тр. aka RH]

для трех пользователей организационной единицы1 необходимо видеть только директории А и Б, а для двух только С.

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

А фильтрами можно отнять только те права, которые кому-то где-то уже были назначены. Но отнимутся они сразу у всех, в данной точке - без разницы, к какой организационной единице или группе принадлежит тот или иной пользователь. ИМХО в данном случае это несколько корявый способ.

[grekalov]

Но функционально вам имеет смысл как-то сгруппировать тех "трех" и "двух" пользователей - и дать права первой группе на А и Б, а второй - на С.

Ну посоветуйте, как мне сделать чтобы работники бухгалтерии, занимающиеся начислением з.платы, не видели директории для отдела бухгалтерии, который занимается банковскими выписками и др. Именно не видели. Хотя бы намекните, а то уже голова кругом, на выходных нужно сдать сервер в эксплуатацию, а я не "врубаюсь" как выйти из этой ситуации

[Андрей Тр. aka RH]

Создать группу, занимающуюся начислением зарплаты ( включить в нее всех нужных пользователей ) и назначить ей требуемые права на нужную им директорию, и другую группу - занимающуюся банковскими выписками ( с ней проделать тоже самое ).

Если всей бухгалтерии выше по дереву ( имеется в виду файловая система ) у вас по какой-то причине назначены еще права, то первой группе еще назначить нулевые на директорию для второй и наоборот. Хотя это уже не совсем красиво .. но тут надо знать больше о структуре вашей ф/с и потребностях прочих пользователей в правах.

[Larico]

Поясню на примере.
Есть подразделение (пусть бухгалтерия), там 2 отдела - В и Г, каждый занимается своими делами, но вместе бух делает одно дело.
В дереве:
[root]
-O
--OU=Бух
---user1
---user2
---user3
---user4
---ГруппаВ (1 и 3 пользователь)
---ГруппаГ (2 и 4 пользователь)

На диске:
[некий корень]
-BuhCommon
--GroupВ
--GroupГ
--Прочие папки

Таким образом есть все вышепредставленное. Теперь мы даем права:на папку "BuhCommon" всему "OU=Бух" [rwecmf].
На папку "GroupВ" даем права только группе В + фильтруем всё.
То есть прямое назначение группе + снимаем все галочки с фильтров.
На папку "GroupГ" даем права только группе Г + фильтруем всё.

Теперь в "BuhCommon" они все могут творить что хотят, а в папках "GroupВ" и "GroupГ" может творить что хочет только указанная группа.

Понятно написал или нет?

[Музалёв Николай]

Предлагается вариант ДВА:
во-первых, отказаться от механизма фильтров прав, т.к. он действительно требует некоторых умственных усилий и (ИМНО) не всегда прозрачен для админа.
во-вторых рекомендую отобрать у PUBLICa права на просмотр корня тома, в котором размещаются рабочие файлы.
и в третьих - размежевав пользователей по группам, явно раздать права этим группам на соотв. участки рабочей файлловой структуры.

Идея не умозрительная - у меня ВСЕ домашние каталоги размещены в нескольких каталогах верхнего уровня, соответствующие отделам:
HOME (том)
HOME_OU1 - верхний каталог одного отдела.
HOME_OU2
...............
HOME_OUn
Далее
В каждом отдельском каталоге расположены домашние каталоги пользователей, один общий каталог отдела и каталоги подразделений отдела.

ПРИМЕР:
HOME_OUn - один из каталогов верхнего уровня. в нем...
USER1 - ....домашние каталоги пользователей,
USER2
.........
USERn
BRIGADA1 - ....общие каталоги соотв.подразделений,
BRIGADA2
...............
BRIGADAn
OTDEL - ... и общий каталог отдела на всех.

раздача прав:
-все пользователи отдела входят в группу OTDEL, которая имеет все права на каталог OTDEL
-все пользователи отдела входят в ту или иную бригаду, которая имееет все права на свой бригадный каталог
-все пользователи имеют свой домашний каталог со всеми правами

В результате после логина на томе, где живут все пользователи, каждый конкрентый индивид видит корень тома так:

BASA_PUPKIN - домашний каталог гр. Пупкина
BRIGADA_BELOVA - его родная бригада,
OTDEL - и его отдел.
и никого больше он не видит!!

Минусы:
- один раз надо создать группы, каталоги и связать группы и каталоги правами.
- все пользователи равны. При появлении нестандартной личности придется подумать, как его ограничить
Плюсы:
- все прозрачно: если Пупкин в отделе1, бригаде2, то и видеть он может ТОЛЬКО соотв. каталоги. При переходе Пупкина в др. подразделение смена видимых каталогов проходит прозрачно для админа-перевел из группы в группу и все.
- ну и никаких фильтров, конечно.

Несогласных призываю изложить своё ИМНО, а не критиковать это моё: оно мне дорого, т.к. за 10 лет ни разу не подвело...

Спасибо.

[Larico]

Николай, ваше сообщение еще раз подтверждает что лучшее оно и в африке лучшее. Так как я в результате пришел к практически аналогичной системе. Различие только в том что бригад у нас нет, а если и есть подобное то организуется внутри папки отдела. И еще есть некий ну совсем общий диск - где вся организация может обмениваться файлами (папка обмена чистится еженочно ).

Один из плюсов системы где разложено таким образом, что при желании вы легко можете посчитать сколько места на томе занимает конкретное подразделение.

Ну и варианты мапинга дисков может отличаться. насколько я понимаю у Николая пользователю мапится корень тома где все оно лежит. У нас же это несколько отдельных дисков. Пользователи приучены к этой систему и привыкли уже основательно.

[grekalov]

Ну и варианты мапинга дисков может отличаться.

Как я понял "варианты мапинга дисков" это тот текст команд для объекта profile, которые выполняются например для подключения сетевых дисков для клиентов (директорий). Вот у меня что -то не выходит, создал orgUnit, создал profile, в свойстве loginscript записал команды:
no_default
map root m:=nserver/data:all\

в свойстве nds rights объекта profile добавил public;
в свойстве login script объекта orgUnit в нижнем окне profile выбрал мой "профиль";
права к директории nserver/data/all разрешил для orgUnit;
Но при входе в сеть пользователя этот скрипт не выполняется, и пользователь, которого я завел в OrgUnit, не видет директорию nserver/data/allкак сетевой диск m: Не пойму в чем причина, не окажите консультацию?

[grekalov]

забыл дописать, что вижу три сетевых диска с содержимым директории public

[Larico]

1. Что касается написания скрипта. Я всегда пишу так. Работало и работает везде (4.х-6.5). (Речь о слешах и прочем):
map root s:=server\vol:\folder\
map root s:=server\vol:\

2. Про "варианты мапинга дисков" неправильно поняли. Это в общем-то текст, но кому-то удобнее скрипт
MAP ROOT S:=server\vol:\
и тогда пользователь внутри диска S сам ковыряется.

А кому-то
MAP ROOT M:=server\vol:\Common\
MAP ROOT H:=server\vol:\Homeroot\
MAP ROOT W:=server\vol:\Work\
и тогда пользователь привыкает к структуре дисков (M, H, W например) а вы при желании(возможности) разносите данные папки как хотите, переносите с сервера на сервер и так далее.

3. для проверки выполняется-ли вообще профиль или нет включите в него строчку write "Логин Скрипт Profile ХХХ". если видите её в результатах, то смотрите что с дисками (почему не назначаются), а если не видите то ищите почему скрипт не отработал.

4. Ну и последнее: данный вопрос никак не относится к теме топика "Настройка фильтров наследуемых прав". Я бы например не стал мешать данные темы.

Дерзайте!

[grekalov]

по совету

3. для проверки выполняется-ли вообще профиль или нет включите в него строчку write "Логин Скрипт Profile ХХХ". если видите её в результатах, то смотрите что с дисками (почему не назначаются), а если не видите то ищите почему скрипт не отработал.
Дерзайте!

я записал в loginscript write "тема", но в результатах не увидел до этого информацию о работе скрипта наблюдал с помощью client32 for XP, подключает только public, больше ничего. Где найти, почему скрипт не выполняется? второй день не могу настроить:(

[Музалёв Николай]

...почему...не выполняется?

Покажите текст, подумаем....

[grekalov]

текст loginscript:
write "test"
И главное если пользователю admin в свойстве loginscript выбираю профиль с вышеописанным содержанием, то при регистрации в client32 текст "test" вижу, а когда выбираю тоже самое для пользователя, находящегося в oc-ou-ou1-user, то для него текст "test" не отображается. Права на profile устанавливал так:properties->NDS Rights->add trustee-> и добавляю все содержимое дерева. Никак не дойдет, что я не так делаю, по идее если доступ к profile доступен всему дереву, то и admin, и все другие объекты должны иметь к нему доступ, т.е. иметь право на использование.

[grekalov]

Теперь вообще интересное сообщение только для admin:

-------------------------------------------------------------------
You are attached to server SERVER.

Script error:
LOGIN-4.22.00-600: This utility could not interpret the line.

The original line was:
test.serv

Drives A,C,D,E,F,G,H,I map to a local disk.
-------------------------------------------------------------------
Сообщение просматривал при проведении процедуры регистрации пользователя (client32)

[Андрей Тр. aka RH]

Права на profile устанавливал так:properties->NDS Rights->add trustee-> и добавляю все содержимое дерева. Никак не дойдет, что я не так делаю, по идее если доступ к profile доступен всему дереву, то и admin, и все другие объекты должны иметь к нему доступ, т.е. иметь право на использование.

В NDS существуют два типа прав .. права на объекты ( Object rights ) и права на свойства объектов ( Property rights ). Чтобы исполнялся скрипт из профиля, у пользователя должны быть как минимум право Read ( Property right ) на свойство Login script этого профиля. Это, впрочем, относится ко всем объектам, имеющим свойство Login script. Из приведенного выше непонятно, какие именно права вы назначили "всему дереву".

Вообще, все это должно быть описано в книге .. типа основы NDS .. Если таких вещей не знаете, то какой смысл было браться за работу, которую надо сдать через три дня ?