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

DIAEclipse

Well-Known Member
07.07.2009
80
0
#1
Руководство утвердило новую иерархическую структуру...и получилось так...что в верхней уровень допихнули новое подразделение и оно теперь над всеми главное, назовем его 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. У пользователей нет доступа к своим почтовым базам, хотя и прописаны права
 

DIAEclipse

Well-Known Member
07.07.2009
80
0
#3
DIAEclipse
мои соболезнования....
а Руководство понимало на что идёт, когда оно ?
Нук тут наверное немного мой косяк...первоначальную схему утвердили, только вот я не взял под роспись...так что теперь руководство говорит что и знать не знало и ведать не ведало...по каким принципам было создано это иерархичное подчинение. На сколько я понима...а верить в это не очень хочется, но для грамотной работы придется всех пользователей и подразделения убить и создать все по новой :-( оставив почтовые ящики
 
K

Klido

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

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

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

DIAEclipse

Well-Known Member
07.07.2009
80
0
#5
оставлять ящики - если было шифрование почты - читать они не смогут её...



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

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

Alexander (Criz)

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

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

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

DIAEclipse

Well-Known Member
07.07.2009
80
0
#7
при ресертификации пользователя новым ID OU выдает ошибку
1.JPG
Где это в логах посмотреть не нашел, подскажите плиз где можно посмотреть логи сертификации (Certifikation Log)
 
K

Klido

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

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

Alexander (Criz)

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

DIAEclipse

Well-Known Member
07.07.2009
80
0
#10
Я не понял, вы его пересертифицируете, или перемещаете в иерархии, если перемещаете, то пользуйтесь "Request Move to New Certifier"...
Одних юзеров я переместил и все хорошо, но соскачили права на ящик почтовый, а есть юзеры которые остались в подразделениях, но иерархия самого подразделения изменилась, я пересертифицировал айдишники организационного юнита и ими теперь пытаюсь пересертифицировать пользователя, так как у них все еще старая иерархия забита в айдишнике
 

DIAEclipse

Well-Known Member
07.07.2009
80
0
#12
А у ПЯ Админ.сервер назначен был?
назанчен...

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

DIAEclipse

Well-Known Member
07.07.2009
80
0
#13
Господа помогите плиз...не хотят пользователи переделываться. Точнее их ID не обновляются если их как то пересертифицировать или обновлять иерархию или вообще как нить по другому. Пересертифицирован ID подразделения в котором находятся пользователи...а как же тогда пересертифицировать id пользователя из данного подразделения????
 
H

HotDog

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

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

Klido

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

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

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

DIAEclipse
права добавляются как Иван Иванов/Sale/FGS, но когда пользователь проходит аутентификацию, то имя написано Ivan Ivanov/Sale/FGS а не на русском как раньше
как я написал во 2-м посте - искренне сочувствую ситуации... тему с именами не могу представить как повторить - явно что-то с сертификатами и их несоответствием в АК и на юзерской стороне...
 
K

Klido

Гость
#17
HotDog
а домены в зоне .рф возможны? это не извращение? :)

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

DIAEclipse

Well-Known Member
07.07.2009
80
0
#19
Вообще чего вы пристали к альтернативным именам! У меня не альтернативные имена, а Измененные Common Name на русские. Да и тема не про альтернативные имена. А при переделку иерархии OU и перенос пользователей из одного OU в другое
 
K

Klido

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