Чрезмерные права в ролевом управлении - неаккуратненько

Обсуждение технических вопросов по продуктам Novell

Чрезмерные права в ролевом управлении - неаккуратненько

Сообщение Сергей Дубров » 18 мар 2009, 12:21

Давно над этим размышлял, и не афишировал сей факт, но один шустрый соратник раскрыл сию великую тайну. Речь идёт о ролевом управлении в eDir. Назначил двум своим коллегам роль хелпдеска: Help Desk Management.Role Based Service 2.CSD.BINP. А это приводит к тому, что они получают права (Compare Read Write Self) на ВСЕ атрибуты ВСЕХ объектов в управляемых контейнерах. Как-то некрасивенько получается...
Аватара пользователя
Сергей Дубров
 
Сообщения: 2093
Зарегистрирован: 05 июн 2002, 06:07
Откуда: Новосибирск, ин-т ядерной физики СО РАН

Сообщение Андрей Тр. aka RH » 18 мар 2009, 14:44

Даешь отдельный раздел по ZENworks ... :bad-words: .. и печати !
Аватара пользователя
Андрей Тр. aka RH
 
Сообщения: 3937
Зарегистрирован: 18 июн 2002, 11:27

Сообщение Сергей Дубров » 18 мар 2009, 17:55

Андрей Тр. aka RH писал(а):RBS- оно такое .. Eliminate Excessive RBS Granted Rights for Password Sync Status Check.

Ух ты, это ещё хуже, чем я себе представлял! Вот это:

That’s all well and good if you are NEVER going to add another member association to a role. Since every NEW member association will reset the ACL’s for all existing members, and since it is impractical to think your role will be setup correctly and finally on day one, it makes sense that you need to manage the ACL’s after new members are added.

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

Не ожидал, честно говоря, что так топорно отображение роль -> ACL сделано. У венды в этом смысле гораздо аккуратнее ролевое управление реализовано - если дано право сброса пароля или блокировки/разблокировки акаунта - только это и можно будеть делать из любого инструмента. А тут фикция, а не безопасность - в iManager-е, вроде как, ограничивают, а в C1 или NWAdmin-е - полный доступ ко всем атрибутам. Неужели нельзя было поаккуратнее раставить права только на требуемые атрибуты? Они ведь нормально наследуются. Дичь, других слов у меня просто нет :twisted:
Аватара пользователя
Сергей Дубров
 
Сообщения: 2093
Зарегистрирован: 05 июн 2002, 06:07
Откуда: Новосибирск, ин-т ядерной физики СО РАН

Вариант решения

Сообщение Сергей Дубров » 22 апр 2009, 07:53

Наконец-то дошли руки, и я исправил ситуацию с избыточными правами. Всё, что нужно было изначально -- чтобы субадмины могли сбросить (поменять) пароль и разрешить/запретить пользовательский account. Роль HelpDesk RBS назначала при этом на соответствующие OU чрезмерные права, с огромным перебором, судите сами:

Код: Выделить всё
Property Name                     Assigned Rights   Inherit

Locked By Intruder               Supervisor
Login Intruder Attempts          Supervisor
Password Management              Supervisor
SAS:Login Configuration          Write
SAS:Login Configuration Key      Write
[All Attributes Rights]          Compare Read Write
[Entry Rights]                   Browse Create   


Что сделал:

1. Создал группу, имя произвольное (я назвал её Account_manager).

2. Дал этой группе права (Read Write) на нужные атрибуты, в нужных OU, не забывая включить при этом наследование (Inherit). Сделано было вот таким простеньким скриптом, хотя это можно было сделать и в любом GUI:

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

for /f %n in (ou_list.txt) do (
setacl %n "Login Disabled" .Account_manager.csd-o.binp rwi
setacl %n "Password Management" .Account_manager.csd-o.binp rwi
)


Setacl - утилита от тов. Baird-а. В файле ou_list.txt список OU в виде .OU.OU.O. Список сгенерён другой утилиткой от JRBsoftware, но в данном случае это совершенно непринципиально.

3. Небольшой фокус с RBS -- если в 'Edit member association' просто убрать у пользователя все назначения на все Scope для роли HelpDesk в iManager-е, то пользователь при входе в iManager обнаружит, что у него вообще нет назначенной ему роли HelpDesk (логично). Но один из админов уже привык работать именно через iManager и переучиваться не хотел. Я изобрёл такой workaround - назначил-таки для группы Account_manager роль HelpDesk для какого-то произвольного OU и - ключевой момент! - убрал у роли птичку в колонке 'Assign Rights'. Т.е., роль назначена, но у самой роли права отобраны (по сути не назначены).

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

Сейчас изучаю вопрос, как можно из готовой роли выбросить ненужные пункты (типа создания объекта) и добавить недостающий пункт 'Enable/disable login'. Никто с этим не игрался, как это делается? Я, конечно, найду рецепт, но просто времени не хватает.
Аватара пользователя
Сергей Дубров
 
Сообщения: 2093
Зарегистрирован: 05 июн 2002, 06:07
Откуда: Новосибирск, ин-т ядерной физики СО РАН


Вернуться в Novell

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2

cron