• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Область видимости документов

  • Автор темы K-Fire
  • Дата начала
K

K-Fire

Есть следующая интересная задачка:

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

Имеем в некоей базе 2 документа.
1й документ должны видеть только пользователи департамента N.
2й документ должны видеть все, кроме пользователей департамента N.

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

Есть идеи как организовать такие права?
 
A

Akupaka

хм... может быть тут полезно по роли организовать?..
но, если будут появляться такие другие документы, где другой департамент должен иметь эксклюзивный доступ, то лучше организовывать через перебор псевдо-групп (wildcard entries), если такие организованы нормально.
если локальные реплики не используются - обычные группы.
 
K

K-Fire

Никаких ролей и групп нет и использовать нельзя. Нотес-имена имеют неизвестный формат.

Такие вот рамки, уж сорри :)
 
S

susinmn

1. а есть возможность по @UserName на @ получить департамент N?
2. в 1-ом и 2-ом документе есть признак департамента?
 
K

K-Fire

1. а есть возможность по @UserName на @ получить департамент N?
2. в 1-ом и 2-ом документе есть признак департамента?

1. Да, в принципе даже из языка формул можно.
2. В первом нет, во втором конечно есть.
 
S

susinmn

Embedded View(Shared, privata on first use) ну напишем, что в Pages c Show Single Category(в первом категоризованном столбце - департамент N или департамент не N)
а в Show Single Category получаем на @ либо департамент N либо департамент не N по @username. Но во всех доках прописываешь, что их видят все

P.S.: яйцами не закидывать :)
 
A

Akupaka

Никаких ролей и групп нет и использовать нельзя. Нотес-имена имеют неизвестный формат
ну, тогда майтесь с перебором конкретных нотес-имен, решайте проблему с 32К и 64К соотв...
а почему нельзя группу создать? для ясности :)
 
S

susinmn

по идеи нужно в той бд, где хранится информация о LN <-> Департамент, сделать агента, который будет обновлять группы Департамент N и Департамент не N при добавлении новых сотрудников(но нужно смотреть, в группы, по-моему, нельзя больше скольки-то записей добавлять, по крайней мере NotesRegistration не дает)
 
K

K-Fire

ну, тогда майтесь с перебором конкретных нотес-имен, решайте проблему с 32К и 64К соотв...
а почему нельзя группу создать? для ясности :(

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

Одним словом, группы это крайний вариант, если не подойдут все остальные. Но я тут думаю, похоже что других нормальных вариантов просто нет :)

Тут у меня вопрос: ладно, со 2м документом все понятно, ридерское поле заполняем, вставляем группу соответствующего депа.
А с 1м документом как? Вставлять туда все остальные группы?
 
A

abbatik

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

Одним словом, группы это крайний вариант, если не подойдут все остальные. Но я тут думаю, похоже что других нормальных вариантов просто нет :(

Тут у меня вопрос: ладно, со 2м документом все понятно, ридерское поле заполняем, вставляем группу соответствующего депа.
А с 1м документом как? Вставлять туда все остальные группы?

Уж поверь, лучше один раз заморочиться с группами, чем потом все время мучаться с 32к :( Для меня это сейчас крайне актуально :)

А по поводу первого документа - да, конечно. Это будет логично. Если исключать надо постоянно одну и ту же группу, то можно завести еще группу, в которую добавить все группы, кроме этой :)
 
A

Akupaka

Соответственно модифицировать справочник ... я могу, но это совсем нежелательно
смотри сам, тебе с твоего места виднее...
"когда я был маленьким"... справочник организации входил в группу полностью реплицируемых баз...
а что это за документы такие создаются? это к ознакомлению что-то или как?..
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!