Проблема с переделкой иерархии и пользователями

  • Автор темы Автор темы DIAEclipse
  • Дата начала Дата начала
D

DIAEclipse

Руководство утвердило новую иерархическую структуру...и получилось так...что в верхней уровень допихнули новое подразделение и оно теперь над всеми главное, назовем его 02. ПРОБЛЕМА.
Итак 01-название самой организации (т.е. cert.id) воткнули 02. Теперь остальные 03, 04 подчиняются 02.
Выбрал сертификат 01, пересертифицировал 02, потом 02 все остальные. Вроде все прошло нормально, но в схеме не изменилась иерархичное подчинение.
Теперь о пользователях. Появилось так же новое подразделение на уровне с 03 и 04, скажем 05, но в него надо перенести пару человек из 02.
Перенос выполнился и люди появились в 05, но пропали почтовые базы, точнее доступ к ним. Сходил руками добавил пользователей в их базы. Но у меня русифицированы пользователи и права добавляются как Иван Иванов/Sale/FGS, но когда пользователь проходит аутентификацию, то имя написано Ivan Ivanov/Sale/FGS а не на русском как раньше.
Короче проблемы:
1. Не изменяется иерархичное подчинение в разделе People by Organization
2. Не могу пересертифицировать пользователей новыми пересертифицированными ID OU
3. У пользователей нет доступа к своим почтовым базам, хотя и прописаны права
 
Klido сказал(а):
DIAEclipse
мои соболезнования....
а Руководство понимало на что идёт, когда оно ?
Нажмите, чтобы раскрыть...

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

DIAEclipse сказал(а):
Иван Иванов/Sale/FGS, но когда пользователь проходит аутентификацию, то имя написано Ivan Ivanov/Sale/FGS а не на русском как раньше.
Нажмите, чтобы раскрыть...

а в самом документе персоны что и как?

Оргюниты... в какой-то момент я и мои коллеги пришли к выводу, что оргюниты-зло. И оставили только корень организации. В чем-то ограничения, но зато почти гарантия отсутствия всяких мегаграблей...
 
Klido сказал(а):
оставлять ящики - если было шифрование почты - читать они не смогут её...



а в самом документе персоны что и как?

Оргюниты... в какой-то момент я и мои коллеги пришли к выводу, что оргюниты-зло. И оставили только корень организации. В чем-то ограничения, но зато почти гарантия отсутствия всяких мегаграблей...
Нажмите, чтобы раскрыть...
Эт точно, но безопасность труднее рулить, особенно если поднят документооборот. В person все зачипок, все имена прописаны, и со старой иерархией и с новой...в этом то и проблема не могу понять почему, когда добавляю права на ящик, пользователь прописывается со старой иерархие, админпроцесс принудительно запускал, зависонов нигде нет в логах админ процесса все ок
 
Klido сказал(а):
И оставили только корень организации.
Нажмите, чтобы раскрыть...
Ну это уже слишком... Когда несколько тыщ юзеров, то ну очень неудобно...

А в принципе у нас вместо 3-х уровней иерархии в сертификатах отображёны только 2-а, хотя можно и на одном остановиться, а полность иерархию указывать в полях секции "Corporate Hierarchy lnformation", благо они для этого и существуют..

Ну а по поводу ошибок, надо попробовать перенести пользователя из одной OU в другую и проследить все процедуры, может где затык, и надо что-то поправить...
 
при ресертификации пользователя новым ID OU выдает ошибку
1.JPG
Где это в логах посмотреть не нашел, подскажите плиз где можно посмотреть логи сертификации (Certifikation Log)
 
Alexander (Criz) сказал(а):
Когда несколько тыщ юзеров, то ну очень неудобно...
Нажмите, чтобы раскрыть...

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

наибольшую полезность, по моему мнению, оргюниты в сертификате имеют, если строить на них политику доступов и разных прав (что не всегда актуально в достаточно целостной организации) или если структура лотусиной сети достаточно детерминирована и управляема не централизованно...
иначе это достаточно серьёзный напряг для админов, особенно ввиду частых ротаций персонала...
 
Я не понял, вы его пересертифицируете, или перемещаете в иерархии, если перемещаете, то пользуйтесь "Request Move to New Certifier"...
 
Alexander (Criz) сказал(а):
Я не понял, вы его пересертифицируете, или перемещаете в иерархии, если перемещаете, то пользуйтесь "Request Move to New Certifier"...
Нажмите, чтобы раскрыть...
Одних юзеров я переместил и все хорошо, но соскачили права на ящик почтовый, а есть юзеры которые остались в подразделениях, но иерархия самого подразделения изменилась, я пересертифицировал айдишники организационного юнита и ими теперь пытаюсь пересертифицировать пользователя, так как у них все еще старая иерархия забита в айдишнике
 
Constantin A Chervonenko сказал(а):
А у ПЯ Админ.сервер назначен был?
Нажмите, чтобы раскрыть...
назанчен...

Вопрос, почему срубается в ошибку процесс обновления иерархии при Rename (Request Move и Upgrade to), или при Recertify. Создал новый ключ для подразделения и пытаюсь им пересертифицировать пользователя в этом подразделении, не получается
 
Господа помогите плиз...не хотят пользователи переделываться. Точнее их ID не обновляются если их как то пересертифицировать или обновлять иерархию или вообще как нить по другому. Пересертифицирован ID подразделения в котором находятся пользователи...а как же тогда пересертифицировать id пользователя из данного подразделения????
 
DIAEclipse сказал(а):
Но у меня русифицированы пользователи и права добавляются как Иван Иванов/Sale/FGS, но когда пользователь проходит аутентификацию, то имя написано Ivan Ivanov/Sale/FGS а не на русском как раньше.
Нажмите, чтобы раскрыть...


Возьмите за правило:
Если у Ваших пользователей есть альтернативные (например русские) имена, не вставляйте их в ACL. Используйте Primary Names, и Лотус работает как правило ними. А альтернативное имя - это всего лишь строка. Оно конечно работает в ACL, но потом можно столько косяков огрести
 
HotDog
HotDog сказал(а):
Если у Ваших пользователей есть альтернативные (например русские) имена, не вставляйте их в ACL
Нажмите, чтобы раскрыть...
:)

это ж надо такое придумать :) хотя кто-то бы и мог...

но тут речь не про альтернативное имя, а как раз Primary Name но на РУССКОМ языке.

DIAEclipse
DIAEclipse сказал(а):
права добавляются как Иван Иванов/Sale/FGS, но когда пользователь проходит аутентификацию, то имя написано Ivan Ivanov/Sale/FGS а не на русском как раньше
Нажмите, чтобы раскрыть...
как я написал во 2-м посте - искренне сочувствую ситуации... тему с именами не могу представить как повторить - явно что-то с сертификатами и их несоответствием в АК и на юзерской стороне...
 
HotDog
а домены в зоне .рф возможны? это не извращение? :)

а какая разница каков язык лотусиного имени? лишь бы домино его понимало :) а оно понимает - так говорит IBM, мы не до конца верим в это, но тысячи юзеров жаждут видеть ФИО на родном языке - и они его видят...
 
Вообще чего вы пристали к альтернативным именам! У меня не альтернативные имена, а Измененные Common Name на русские. Да и тема не про альтернативные имена. А при переделку иерархии OU и перенос пользователей из одного OU в другое
 
надо пройти весь процесс по шагам и понять где фича... например, если в один из верхних сертификатов не была заложена возможность русског оимени - может быть ситуация с подстановкой латинского? откуда вообще возникло латинское? осталось со старог осертификата? а если вытереть его в алиасах? надо копнуть свойства .ид и посмотреть что там про имя..
в общем - огромное поле для поисков :offtop:
 
Для ответа нужно войти/зарегистрироваться
Мы в соцсетях:

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

Верх Низ