Работа с ключами

[motogarri]

Привет. Появилась необходимость автоматизировать смену публичного ключа. Чтобы пользователю просто нажать кнопку "Сменить ключ", ввести пароль и все. Админу улетел запрос на заверение нового ключа.
Что-то не могу найти ничего такого ни в скрипте ни в апи. Может сталкивался кто?

 

[lmike]

смену публичного ключа

ключи в ИД - это и есть основа аутентификации пользователя, смена ключей - смена пользователя (с утерей всех шифрованных доков/полей)
или речь идет о смене "других" ключей, не связанных с ИД?

 

[motogarri]

Именно об этих ключах. В интерфейсе девятки это выглядит так:
1. File/Security/User Security
2. Набор пароля
3. Your identity/Your Certificates
4. Нажать кнопку Other Actions/Create New Public Keys
5. Выбрать Mail Protocol, нажать кнопку Resubmit
6. Ввести почтовый адрес, отправить

При некоторых условиях, пользователю иногда нужно сменить ключи (такие моменты возникают, почему не могу сказать), это сложно. Для многих это вообще непреодолимое препятствие. Вот, ищу способ облегчить им жизнь.

Видел, что с помощью notes api можно извлечь публичный ключ из id файла. Это тоже пригодилось. А вот как-бы его сменить и отправить запрос на заверение администратору.

 

[lmike]

При некоторых условиях, пользователю иногда нужно сменить ключи

на уровне vault есть

User key rollover
The ID vault server takes care of the User key rollover process. For all vaulted users, the option for users to create new publics keys from a Notes client is disabled. User key rollover is automatically triggered as configured via policy when needed, and is also automatically completed of by the ID vault. An advantage of this is that users will never receive dialogs related to User key rollover. Also, User key rollover will always only be initiated once on the ID vault server. Users should not attempt rolling over keys using pre-Notes 8.5 clients themselves, as this could lead to discrepancies between the user's local ID file and the vaulted ID file.

[doublepost=1487584301,1487581285][/doublepost]что бы ассоциировать с вопросом

For IBM® Lotus® Domino® 6 and earlier servers, creating and certifying a new public key requires the following procedures, which are described below:

• The user creates the new public key and submits it for certification.
• The certification administrator certifies the user's public key with a IBM® Lotus® Notes® certificate and adds it to the Domino Directory.
• The user merges the new certificate into the user's ID file.

For Domino 7 and later servers, administrators can use the key rollover process for creating new public keys through a security settings policy document. Users can also trigger key rollover through the User Security dialog box.

 

[ToxaRat]

автоматизировать смену публичного ключа

че там автоматизировать, заходим в его учетку в АК и спокойно на закладке сертификат меняем поле Notes certified public key:

только зачем?

 

[Baneslaer]

че там автоматизировать, заходим в его учетку в АК и спокойно на закладке сертификат меняем поле Notes certified public key:

только зачем?

а в ID как сменишь? И как шифрованные доки читать будешь?

 

[ToxaRat]

а в ID как сменишь? И как шифрованные доки читать будешь?

1) вот и я спрашиваю ЗАЧЕМ?
2) шифрованные доки читаются личным ключем а не публичным

 

[Baneslaer]

1) вот и я спрашиваю ЗАЧЕМ?
2) шифрованные доки читаются личным ключем а не публичным

человек спрашивает, как вместо кучи нажиманий по кнопкам сделать одну удобную всем кнопку...
соответственно ответ на вопрос Зачем? - Затем=)

 

[ToxaRat]

человек спрашивает, как вместо кучи нажиманий по кнопкам сделать одну удобную всем кнопку...
соответственно ответ на вопрос Зачем? - Затем=)

одна удобная кнопка есть у админа
зачем юзерам вообще что-то нажимать?

 

[lmike]

да и в принципе - ресертификация персоны, КМК, даст смену ключа

 

[Constantin A Chervonenko]

да и в принципе - ресертификация персоны, КМК, даст смену ключа

Не-а... Ресертификация ПЕРЕзаверит существующий ключ

 

[lmike]

Не-а... Ресертификация ПЕРЕзаверит существующий ключ

значит я ошибся

 

[Мыш]

Не проще ли пользователя перерегистрировать с тем же именем? Эта процедура точно создаст новые ключи.
Вопрос- как подсунуть новый ID... Если настроен Vault, то в API есть ф-ции для работы с ним....

 

[Constantin A Chervonenko]

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

Предварительно придётся существующего юзера ДЕрегистрировать. Что тоже геморрой

 

[Мыш]

Предварительно придётся существующего юзера ДЕрегистрировать. Что тоже геморрой

А зачем ДЕрегистрировать? В стародавние времена проблему забытых паролей от ID-файлов решали именно перерегистрацией пользователя прям поверх... Ессно, базу почтовую надо как-то сохранить, доступ к зашифрованным документам утратится... Кстати, с зашифрованными не помню как проблема-то решается при штатной замене ключей - старые сохраняются в ID что ли?...

 

[ToxaRat]

Появилась необходимость автоматизировать смену публичного ключа.

вернёмся к истокам - зачем это потребовалось вообще?

 

[Constantin A Chervonenko]

А зачем ДЕрегистрировать? В стародавние времена проблему забытых паролей от ID-файлов решали именно перерегистрацией пользователя прям поверх... Кстати, с зашифрованными не помню как проблема-то решается при штатной замене ключей - старые сохраняются в ID что ли?...

Гм.. Поверх? Вообще-то оно брыкаться будет - неуникальные имена и всё такое.. "В стародавние времена" просто удаляли док-т из АК и тогда уж регистрировали
Да, старые ключи в ID по идее должны сохраняться. Ведь на них завязана аутентификация, а не только шифрование. Вдруг юзер ткнётся в домен, куда его новые ключи не дошли ещё?
[doublepost=1490113680,1490113547][/doublepost]

вернёмся к истокам - зачем это потребовалось вообще?

Полагаю - паранойя. Периодическая плановая замена ключей. А если и не плановая (при дискредитации) - а в конторе самопальный IDM

 

[motogarri]

Там все сложно в организационном плане. Именно пользователь должен сменить свой ключ, а администратор у себя его заверить. Я уже понял, что не получится "свою" кнопку сделать.

 

[Constantin A Chervonenko]

Именно пользователь должен сменить свой ключ, а администратор у себя его заверить. Я уже понял, что не получится "свою" кнопку сделать.

"И это правильно, товарищи!"(с)
Вы представляете, если-бы начальник 1-го отдела в-тихомолку шмонал карманы сотрудников и подкидывал им другие ключи от сейфов и личные печати? А потом привлекал к ответственности на том основании, что дверь опечатана не той печатью!

Вы рассматриваете что-то подобное. Секретные документы и юр.значимые подписи - это серьёзно. Они невозможны без ответственного/сознательного отношения сотрудника

 

[ToxaRat]

Вы рассматриваете что-то подобное. Секретные документы и юр.значимые подписи - это серьёзно. Они невозможны без ответственного/сознательного отношения сотрудника

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

чо не так?

а если это старый совок с ИД файловой помойкой на компе юзера - то где гарантия, что комп не включил сосед и в отпуске не зашёл под коллегой?

чтобы понять проблему - нужно самому стать проблемой