Если Id файл дискредитирован

[Akupaka]

Принципы Лотусёвой аутентификации

Константин, но это же, если у юзера уже есть! кросс-сертификат. И тем более частный случай - в одной организации.

А вопрос был таков:

А если пришел документ с ЦП на сервер от стороннего адресата, то возможно же, что открытый ключ адресата не попал на сервер в АК?

Т.е. от неизвестного. И пусть там будет внутри сертификат, но, если он заверяется каким-то внутренним сервером той организации (адресанта), то он до одного места - его нельзя проверить адресату.

 

[seoman2]

самое простое решение это включить проверку пароля и заставитьв всех сменить пароль

Для теста включил эту проверку пасса, ввел с одного ид неверный пароль раз 5, а в 6-ой раз верный, и спокойно зашел.
В чем тогда суть этой проверки пароля сервером на практике?

Ещё сделал группу DENY. в ней тип группы указал - Deny List only.
В группу внес юзера, но под ним все равно спокойно зашел в базу на сервере.

 

[Sergey Berezka]

Deny List - нужно прописать в конфиге сервера в Not Access Server

 

[Akupaka]

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

Если у кого-то оказался id-файл со старым паролем, он не сможет войти (если пользователь сменил свой пароль).

 

[Klido]

seoman2
рекомендую вооружиться редбуком "Lotus Domino Security Handbook" и переведенной книгой "Вопросы безопасности Lotus Notes и Domino" + редбук

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

99% вопросов отпадут, остальной 1% - отдельные статьи вроде

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

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

и т.д.

 

[Constantin A Chervonenko]

Константин, но это же, если у юзера уже есть! кросс-сертификат. И тем более частный случай - в одной организации.
А вопрос был ..
от неизвестного.

Точно? Совсем от исходного уклонились.. Но я больше на промежуточные вопросы отвечал: в упомянутом первоисточнике все случаи рассмотрены.
О кросс-сертификатах: это сертификат чужого сертификатора, заверенный нашим сертификатором.
Т.е. сначала кросс-сертификат проверяется по общим правилам (на соответствие сертификатам ИЗ ID, не из какой-то базы). А потом добытый т.о. чужой сертификат используется для проверки сертификатов из подписи.

Это главное в алгоритме: никогда не верить "на слово" чему-то из-вне (даже из общей АК), чего нельзя проверить своим личным ID

 

[seoman2]

по поводу Check passwords on Notes IDs
а менять пароль на id, который возможно украли, нельзя менять у клиента?
сделал ид с паролем 123, зашел на сервер.
сделал копию ид,
сменил пароль на клиенте на 321 - зашел на сервер. По идее сервак должен знать что новый пасс 321.
но и под старым ид с паролем 123 бд на серваке открываются!

про

Deny List - нужно прописать в конфиге сервера в Not Access Server

работает для юзеров, а как туда ид старый добавить?

 

[Klido]

seoman2
эх...

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

я написал, что ссыль №1 в гугле там все разжевано....

На а вообще - все понятно из Setting up password verification в админском хелпе...

 

[seoman2]

Сделал как в статье. На сервере включил проверку пароля "Check passwords on Notes IDs" - yes.
У юзера в домино директории включаю Check password в "Check password".
Делаю копию ид, на новой меняю пароль. Старый ид - типа ворованный.
При этом ид со старым паролем сервак принимает, а ид с новым паролем нет!

 

[seoman2]

Кто то сталкивался с подобной проблемой?

 

[Akupaka]

Может зменения пароля на сервере не прошли?

 

[seoman2]

Я делал все с интервалом в не более минуту.

 

[Klido]

все с интервалом в не более минуту

я бы быстрее 30 минут не ждал результата

 

[HotDog]

В чем проблема пользователю сделать запрос из клиента на смену ключей, в admin4 администратору подтвердить запрос на смену ключей для пользователя, а пользователю при следующем заходе в клиент Lotus принять новые ключи?

А в документе сервера на вкладке Security выставить Compare public keys: Enforce key checking for ... (кому что надо)

С украденным ID злоумышленник, даже если знает пароль, больше не зайдет на сервер

 

[seoman2]

А как сделать этот запрос из клиента на смену ключей? В книге по администрированию домино не нашел.

 

[Мыш]

А как сделать этот запрос из клиента на смену ключей? В книге по администрированию домино не нашел.

В 8.5 так - в меню клиента File-Security-User Security. Далее в открывшемся окне Your Identity-Your certificates-Other Actions-Create new public keys...

А в документе сервера на вкладке Security выставить Compare public keys: Enforce key checking for ... (кому что надо)

Черт, у меня дизайн с 6-го сервера реплицируется, всю АК облазил, нигде не нашел эту опцию с выбором вариантов. А она, оказывается, существенно улучшена в поздних версиях

 

[seoman2]

В Administration Requests database нету никаких запросов от юзера, при выполнении у юзера: Your Identity-Your certificates-Other Actions-Create new public keys...

 

[HotDog]

В Administration Requests database нету никаких запросов от юзера, при выполнении у юзера: Your Identity-Your certificates-Other Actions-Create new public keys...

Посмотрите в admin4 вид Certify New Key Requests

P.S. Вы можете не заставлять пользователя принимать участие в процессе смены ключей. Достаточно сделать Recertify его ID в админе. При этом тоже произойдет смена ключей

 

[Constantin A Chervonenko]

.. Достаточно сделать Recertify его ID в админе. При этом тоже произойдет смена ключей

Точно-точно?
А кто личный ключ генерить будет? Админ?? Тогда это - НЕ ЛИЧНЫЙ ключ ("что знают двое...")

AFAIR, ресертификация - это обновление эл.подписи. Т.е. Сертификатор своей эл.подписью подтверждает, что имя/подпись(и ключи!!) юзера (всё ещё) достоверны.
А смена ключей - это отдельное действо (пара ключей генерится на стороне юзера; личный - прячется в ID, публичный - публикуется (шлётся админу))

 

[Мыш]

AFAIR, ресертификация - это обновление эл.подписи. Т.е. Сертификатор своей эл.подписью подтверждает, что имя/подпись(и ключи!!) юзера (всё ещё) достоверны.

Точно так. И - насколько я помню - даже при смене сертификатора ключи не меняются.