If the local id file or the keyfilename parameter referencing the id is deleted, Notes pops up the error message “Could not open the ID file” and the user must switch to another user.id stored locally.Wouldn’t it be better if Notes tries to identify the most propably user entity by evaluating keyfilename_owner and/or location parameter in the notes.ini, to find a user.id in a vault and download it, and asking the user for the appropriate password, then?
It’d more convenient to the user and I can’t see a security hole, because one still need the password of the id.
Subject: Please retest one of those scenarios and tell me what you experience
If you are running Notes with a vaulted ID, exit the Notes client, delete (or rename) that file in the OS, then restart the Notes client you should receive the normal password prompt, and if the ID was found in the vault and the entered password was correct, the ID will be downloaded silently from the vault. The end user shouldn’t even notice that their ID file was temporarily missing.
We’re currently investigating the other scenario involving deleting the keyfilename parameter from the notes.ini; that case should work smoothly as well. Ideally, the user would never even notice that there had been a problem before we fixed it automatically.
Subject: ID Vault: “File cannot be created” and “Could not open the ID file” error messages in various test cases
Test: user.id was renamed or deletedThe ID was downloaded from the vault and the user was prompted for the correct password
Test: Keyfilename-Parameter was deleted, but user.id files was unmodified
The user was prompted for the password, but after entering it, an error message “File cannot be created” appeared, after that the Options menu “You cannot log in using the supplied User ID…”
Test: Keyfilename-Parameter and ID files were deleted
The user was asked for the password, after that an error message “File cannot be created” appeared and finally the Options dialog “You cannot log in using the supplied User ID…”
Test: Keyfilename-Parameter, Keyfilename_Owner-Parameter and ID files were deleted
An error dialog “IBM Lotus Notes: Could not open the ID file” appeared,after that the dialog “Choose user ID to switch to”, because no ID is stored locally, cancel was chosen and finally the Option dialog “You cannot log in using the supplid User ID…” was presented and “Exit Notes” was chosen.
This is the debug.log for Test case 4 (with Debug parameters vor Vault Server selection, IDVault Update & Client Clock set):
I’ve written up an SPR – DKEN7JD47B – for the second and third scenarios, which are both encountering that error due to the lack of the keyfilename parameter in the notes.ini file. Can you think of a scenario in your environment where an end user might encounter this form of corruption to their notes.ini file? That would help us considerably during triage.
Case four is working as expected, since without the parameter telling us which ID file to download from the vault, we can’t silently trigger a download. A user with no relevant notes.ini parameters and no ID files to recover could still recover, however, by contacting a vault admin and having a copy of their ID file extracted from the vault.
We considered another feature that would have helped in your last scenario – switch to ID in the vault – but received feedback that other features were more important, such as registering users directly into the vault, and so switch to ID in the vault didn’t make the cut for 8.5.
Replace notes.ini with one that contains just the first 4 lines to trigger client setup. Type in user name and server name and the ID file will be downloaded.