• Бесплатный ВЕБИНАР по OSINT с Екатериной Тьюринг: ➡️9 февраля в 19:00 (мск) пройдет урок

    Как безопасно искать информацию в открытых источниках

    🔥 Записаться 🔥

Перенос пользователя в иную иерархию имен

  • Автор темы Автор темы shershun4ik
  • Дата начала Дата начала
S

shershun4ik

Писал БД. Столкнулся с проблемой раздачи прав на отображаемые документы. Решил использовать readers-поля - не подошло из-за несоответствия организационной структуры предприятия и иерархии имен в Lotus (Все пользователи заведены как Имя_пользователя/Организация, а фактическое разделение более сложное). Решил создать нормальную иерархию. Создал ID-файлы для подразделений (ПодразделениеN/Организация). При попытке пересертифицировать пользователя Пользователь1/Организация сертификатом Подразделение1/Организация получаю ошибку "The following error occurred while trying to update the certificates stored in the Certifer id with whose from the directory on the server you selected: Entry not found in index. Do you wish to continue without updating the Certifier ID?"

Я так понимаю, что он не может найти сертификат для обновления в Cert ID с сертификатом Подразделение1/Организация. Но сертификат Подразделение1/Организация был сертифицирован сертификатом Организация.

Вопросы:
1. Что это такое?
2. Как побороть?
 
1.Пересаживание юзера с ветки на ветку - это не просто пересертификация. Там в Админке довольно муторная процедура по сдаче юзера старым сертификатором и приёму новым (участвуют оба ID-шника).
2.Редко удаётся дерево имён полностью подогнать под орг.структуру
а) банально не хватает уровней
б) орг.структура в наши неспокойные времена пересматривается слишком часто
в) часто бывает, что орг.структур БОЛЕЕ ОДНОЙ одновременно
Может тогда не стоит и стараться/мучаться? Для орг.структуры у Person в АК есть отдельные полечки: LEVELx LEVELx_y ..
 
Скелет организационной структуры нашей организации не менялся уже около 8 лет. И для меня имеет смысл заморочиться приведением иерархии имен в порядок.

В переводе help к администратору Domino 6.5.x (от ИнтерТраст) написано:

Когда вы перемещаете пользователя в иерархической схеме имен, сертификат пользователя изменяется, таким образом, изменяется иерархия имени пользователя. Вы можете использовать процесс администрирования для перемещения имени пользователя в иерархической схеме имен.
Например, если Alice Brown/Marketing/Acme оставляет работу в отделе Marketing и переходит работать в отдел Sales, вы можете сертифицировать ID пользователя с использованием сертификата /Sales/Acme, который в действительности, перемещает имя пользователя в иерархической схеме имен. Теперь полное, иерархическое имя пользователя будет Alice Brown/Sales/Acme


Если там написано не то - где же правда? Как правильно произвести пересаживание пользователя с ветки на ветку?
 
Domino Administrator - People & Groups - Rename - Request Move to New Certifier
 
Так я тоже пробовал. Выдает ошибку "Error locating a Domino Directory entry for certifier OU=Подразделение1/O=Организация".
Я понял, что не находится сам certifier (по русски - тот, кто сертифицирует). Как в DD прописать certifier?
 
Дык он при создании помещается в АК - посмотрите в Configuration -> Certificates, в категории Notes certifiers.
 
Не было там его. Я ручками добавил при помощи Migrate Certifier. Сейчас проходит на ура. И, я надеюсь, последний вопрос по этой теме:
Через какое время происходит смена имени в документе пользователя?
 
Не было там его.

А Вы когда Org Unit заводили в поле "Сервер" часом не Local оставили?

Через какое время происходит смена имени в документе пользователя?

Не помню - но "tell adminp pr all" в консоли хорошо помогает :-)
 
Не было там его. Я ручками добавил при помощи Migrate Certifier. Сейчас проходит на ура. И, я надеюсь, последний вопрос по этой теме:
Через какое время происходит смена имени в документе пользователя?

Смена происхождит когда юзер цепляется с клиенского компьютера к сервереру и в его ID файле пробивается новое имя...
Если орг. еденица не более 1 уровня - то достаточно одного сертификатора.

На самом деле - не стоит заморачиватся доступом к документу на основании его OU... Гораздо гибче организация доступа на основании групп.
 
А Вы когда Org Unit заводили в поле "Сервер" часом не Local оставили?
При создании Подразделение1/Организация точно писал текущий сервер, но до этого и Организация тоже не было в Certifier (Организация создавал не я). Подразделение1/Организация сертифицировалось при помощи Организация, когда ее еще небыло в DD, может поэтому Подразделение1/Организация и не добавилось?

На самом деле - не стоит заморачиватся доступом к документу на основании его OU... Гораздо гибче организация доступа на основании групп.

Организация нашего предприятия такова, что раздача прав идет на основе должностей (бывает когда права раздаются на основе функций работника).
Это как в армии: "Командир должен знать все чем занимается его подчиненный, вне зависимости от сегодняшних задач подчиненного".

Большое спасибо за помощь:
Constantin A Chervonenko и rins - за то, что заставили еще раз подумать над актуальностью проблемы
Sergey Berezka - за указатель в верном направлении
Мегареспект Мыш - за исполнение роли поводыря.
 
Хммм..Вы имеете в виду - Организации не было в АК?

Я имею ввиду Certifier Организация не было в DD. При сертификации пользователей или серверов, администраторы ручками выбирали ID-файл и вводили пароль. В Notes Certifiers было пусто.
 
администраторы ручками выбирали ID-файл и вводили пароль.
Это-то как раз нормально - личный ключ Certifier'a хранится в ID-файле, без него никак.
Но записи в АК - и для Организации, и для Юнита - все равно должны быть. У Вас права доступа к АК точно полные? А к базе Certification Log?
 
Но записи в АК - и для Организации, и для Юнита - все равно должны быть. У Вас права доступа к АК точно полные? А к базе Certification Log?
Права доступа полные. Записей не было. Вот вспомнил еще: если при регистрации выбрать Use CA process в списке CA configured certifier была одна строка - None Assigned.
 
Дык СА - это как бы вообще альтернативный механизм управления сертификатами. Я так понимаю, что Вы используете традиционный, лотусовый? Или у Вас СА поднят?
 
Дык СА - это как бы вообще альтернативный механизм управления сертификатами. Я так понимаю, что Вы используете традиционный, лотусовый? Или у Вас СА поднят?

Используем традиционный лотусовый. Я это так, вспомнил, вдруг в этом что-то есть. И при переносе пользователя из /Организация в Подразделение1/Организация после выбора старого Certifier он ничего не показывал в новом. Вот так. После Migrate Certifier стал отображать.
 
ЗЫ. Что-то у Вас не так настроено, ИМХО. Во избежание последующих проблем советую все-таки еще раз проверить права доступа... Кстати - у Вас названия Организации/Юнита русские или латинские? С русским проблемы вылезают периодически (от версии к версии) , не рекомендую использовать...
 
На самом деле - не стоит заморачиватся доступом к документу на основании его OU... Гораздо гибче организация доступа на основании групп.
Группы хороши, когда домен один. Когда доменов (и АК, и админов) много, это дыра...
 
To Мыш: Имена латинские. С кривостью настройки я согласен. Вот и разбираем "наследство" от предыдущих админов.
To Constantin A Chervonenko полностью поддерживаю мнение о группах. Но это только в том случае, если административно-территориальная структура организации стабильна, если это не так, то надо рассматривать каждый случай в отдельности.
 
Мы в соцсетях:

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