Учетная запись заблокирована

[altena]

Пользователь входит в лотус нотус, а когда пробует открыть свою почту, выдается сообщение"Учетная запись заблокирована."
Как бы с этим расправиться?

 

[morpheus]

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

 

[Constantin A Chervonenko]

Пойти к Админу и выбить из него свою/новую id-шку

 

[altena]

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

уже пересертифицировали- без толку. Не может попасть только в почту

 

[morpheus]

<!--QuoteBegin-altena+17:11:2006, 15:09 -->
<span class="vbquote">(altena @ 17:11:2006, 15:09 )</span><!--QuoteEBegin-->Не может попасть только в почту

[snapback]48132" rel="nofollow" target="_blank[/snapback]​

[/quote]
а ACL почтового ящика, а в адресной книге у него этот мыльный ящик?

 

[altena]

а ACL почтового ящика, а в адресной книге у него этот мыльный ящик?

в ACL он (юзер) как манагер- вроде нормально?

 

[morpheus]

а на пост опен базы не происходит какойнить событий??
в дебагере попробуйте войти в базу

 

[altena]

а на пост опен базы не происходит какойнить событий??
в дебагере попробуйте войти в базу

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

 

[morpheus]

<!--QuoteBegin-altena+17:11:2006, 15:38 -->
<span class="vbquote">(altena @ 17:11:2006, 15:38 )</span><!--QuoteEBegin-->Но мне кажется, что дело все-таки не в базе. Потому как если пробовать открыть любую другую базу, то уже после того как выбираешь сервер- сразу пишут- "Ошибка сервера. ваша учетная запись заблокирована"

[snapback]48140" rel="nofollow" target="_blank[/snapback]​

[/quote]
и как это вяжетсья с
<!--QuoteBegin-altena+17:11:2006, 15:09 -->
<span class="vbquote">(altena @ 17:11:2006, 15:09 )</span><!--QuoteEBegin-->Не может попасть только в почту

[snapback]48132" rel="nofollow" target="_blank[/snapback]​

[/quote]



Персональный док пользователя... закладка Admin -> Check password убрать Lockout ID

 

[altena]

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

Персональный док пользователя... закладка Admin -> Check password убрать Lockout ID
[/quote]
а там стоит dont check password

 

[morpheus]

так... а група NoAccess

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

просмотрите в каких групах этот пользователь есть... возможно в ноаксесе висит

 

[altena]

если группы- это те, что под пиплами, то у нас такой группы просто-таки даже нет!
И этот юзер ни в одной группе не проскочил, даже AllDomainUsers

 

[Constantin A Chervonenko]

если группы- это те, что под пиплами, то у нас такой группы просто-таки даже нет!
И этот юзер ни в одной группе не проскочил, даже AllDomainUsers

NoAccess - группы хитрые, в общем списке их нет. Только админу видно

 

[altena]

NoAccess - группы хитрые, в общем списке их нет. Только админу видно

Как это ни грустно, я и есть админ

 

[Wanderstep]

Проверьте в настройках серверного документа:
закладка Security - раздел Server Access Who can-
что указано в строке Not access server?

 

[latif]

Unlocking the account
Only an administrator, who has access to the user's Person document, can unlock a user's account once it is locked out. The steps for unlocking an account are straightforward, but there's opportunity for error if the administrator doesn't complete the whole Adminp process or modifies the wrong fields by mistake.
First, the administrator deletes the password digest in the Person document. The next time the user logs onto the server they will still be denied access, however, because the user ID file still contains an expiration date that has expired. The user must change their password in their user ID file. This updates the password digest in the user ID file; and since there is no digest in the Person document, there is no "password digest check to take place" and the user is granted access. Because the last change date is more recent that recorded in the Person document, the client generates an Adminp request, to inform the server of the new password change.
After Adminp processes this change request, the Person document for the user will now have the same password digest and last change date as the user's ID file. No changes need to be made to the ID file since this request is a push from the client to the server. The user can now continue accessing the server.

Ссылка скрыта от гостей

 

[morpheus]

Для: altena
так в чем собственно была проблема?

Для: latif да может быть... волшебное слово Adminp process

 

[altena]

а проблема была в том, что была политика Sec, которая велела менять пароль каждые 45 дней. Эти 45 дней прошли, юзер пароль не поменял, его не пущали. добавила пару нулей к цифре 45- его сразу пустили. А сосед- сисадмин сказал, что он на своем серваке ее вовсе снес.
Товарищи ученые, а без нее-то можно?

 

[collection]

можно

 

[Wanderstep]

<!--QuoteBegin-altena+29:11:2006, 14:26 -->
<span class="vbquote">(altena @ 29:11:2006, 14:26 )</span><!--QuoteEBegin-->Товарищи ученые, а без нее-то можно? blink.gif

[snapback]49212" rel="nofollow" target="_blank[/snapback]​

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