HCL Domino Ideas Portal
Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.
For more information and upcoming events around #dominoforever, please visit our Destination Domino Page
Dear team,
This feature should be have in the future because it very important for users to prevent any attempt.
I agree with the Guest comments about this. There is a need for better controlling access to and use of Notes ID's.
I wonder though if not the "Check passwords on Notes IDs" on the "Security" pane on the server document in combination with the "Check password" option on the person documents could help - at least some part of the way, it would solve the "issue" that it's not the server that authenticates the user as Thomas Hampel made clear. It is cumbersome to use and very inflexible, I know. Bbeen there, Done that, Got the picture ;-) But if HCL would give it a little love (it is after all a very old solution) and bring it into the 21st. century I think it could work. Maybe combine it with the ID vault somehow?
Nevertheless, this is a very important need in terms of security requirements in large corporations.
This is implemented in the asset directory and, accordingly, in Microsoft EXCHANGE.
I am not saying that this should be done in this way, but setting up a block to enter to the Notes with a few incorrect password entries should be avoided.
The password for the Notes client does not authenticate the user against the server - it does unlock the local notes.id file. So lockout mechanism can not work as suggested.