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

[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]

DIAEclipse
мои соболезнования....
а Руководство понимало на что идёт, когда оно ?

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

 

[Klido]

оставлять ящики - если было шифрование почты - читать они не смогут её...

Иван Иванов/Sale/FGS, но когда пользователь проходит аутентификацию, то имя написано Ivan Ivanov/Sale/FGS а не на русском как раньше.

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

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

 

[DIAEclipse]

оставлять ящики - если было шифрование почты - читать они не смогут её...



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

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

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

 

[Alexander (Criz)]

И оставили только корень организации.

Ну это уже слишком... Когда несколько тыщ юзеров, то ну очень неудобно...

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

Ну а по поводу ошибок, надо попробовать перенести пользователя из одной OU в другую и проследить все процедуры, может где затык, и надо что-то поправить...

 

[DIAEclipse]

при ресертификации пользователя новым ID OU выдает ошибку

Где это в логах посмотреть не нашел, подскажите плиз где можно посмотреть логи сертификации (Certifikation Log)

 

[Klido]

Когда несколько тыщ юзеров, то ну очень неудобно...

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

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

 

[Alexander (Criz)]

Я не понял, вы его пересертифицируете, или перемещаете в иерархии, если перемещаете, то пользуйтесь "Request Move to New Certifier"...

 

[DIAEclipse]

Я не понял, вы его пересертифицируете, или перемещаете в иерархии, если перемещаете, то пользуйтесь "Request Move to New Certifier"...

Одних юзеров я переместил и все хорошо, но соскачили права на ящик почтовый, а есть юзеры которые остались в подразделениях, но иерархия самого подразделения изменилась, я пересертифицировал айдишники организационного юнита и ими теперь пытаюсь пересертифицировать пользователя, так как у них все еще старая иерархия забита в айдишнике

 

[Constantin A Chervonenko]

Одних юзеров я переместил и все хорошо, но соскачили права на ящик почтовый

А у ПЯ Админ.сервер назначен был?

 

[DIAEclipse]

А у ПЯ Админ.сервер назначен был?

назанчен...

Вопрос, почему срубается в ошибку процесс обновления иерархии при Rename (Request Move и Upgrade to), или при Recertify. Создал новый ключ для подразделения и пытаюсь им пересертифицировать пользователя в этом подразделении, не получается

 

[DIAEclipse]

Господа помогите плиз...не хотят пользователи переделываться. Точнее их ID не обновляются если их как то пересертифицировать или обновлять иерархию или вообще как нить по другому. Пересертифицирован ID подразделения в котором находятся пользователи...а как же тогда пересертифицировать id пользователя из данного подразделения????

 

[HotDog]

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

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

 

[Klido]

HotDog

Если у Ваших пользователей есть альтернативные (например русские) имена, не вставляйте их в ACL

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

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

DIAEclipse

права добавляются как Иван Иванов/Sale/FGS, но когда пользователь проходит аутентификацию, то имя написано Ivan Ivanov/Sale/FGS а не на русском как раньше

как я написал во 2-м посте - искренне сочувствую ситуации... тему с именами не могу представить как повторить - явно что-то с сертификатами и их несоответствием в АК и на юзерской стороне...

 

[HotDog]

Primary Name но на РУССКОМ языке

Такое разве возможно? Это не извращение?

 

[Klido]

HotDog
а домены в зоне .рф возможны? это не извращение?

а какая разница каков язык лотусиного имени? лишь бы домино его понимало а оно понимает - так говорит IBM, мы не до конца верим в это, но тысячи юзеров жаждут видеть ФИО на родном языке - и они его видят...

 

[HotDog]

тысячи юзеров жаждут видеть ФИО на родном языке

Для этого же и существует возможность добавления альтернативного имени. Или я чего-то не понимаю?

 

[DIAEclipse]

Вообще чего вы пристали к альтернативным именам! У меня не альтернативные имена, а Измененные Common Name на русские. Да и тема не про альтернативные имена. А при переделку иерархии OU и перенос пользователей из одного OU в другое

 

[Klido]

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