Question: I have an MS Access application that can send Lotus Notes email via VBA macro. With Access 2003 it is no problem to get a Notes.NotesSession. With Access 2010 it gives a problem that says "\Automation -Embedding.nsf" does not exist. (I don't know what to do.) Another way is when I use Lotus.NotesSession and initializing the session. It works, the macro continues, but afterwards asks for Lotus Notes password (the user has to type in), but it is not quite handy to always type in this password.  

 

Answer:

From Dave Kern, Rich Schwartz, and Peter Rosenberg in a forum topic on this same question:

The ID file password is the password used to decrypt the ID file...so by definition can't be stored in the ID file. 

The "Notes password" is used to generate an encryption key which is used to encrypt and decrypt the ID file, which contains the keys used to access servers and perform secure mail operations. There is no way to "extract" the password from the ID file, because the password isn't stored in the ID file.

But what you can do is change a setting in the Notes client. This setting has been available in Notes for at least 15 years, but the location and wording has changed in different versions. In Notes 8.5, the setting is located in the User Security dialog. It is a checkbox with the label "Don't prompt for password from other Notes-based programs (reduces security)". 

If you turn on this setting, and your users are already running the Notes client, they will not have to enter the password again for your macro. But there is a good reason the setting has the warning "(reduces security)" in the label: it means that Notes will allow all programs that use the Notes API to gain access without re-typing the password. With this setting turned off, any virus that tries to use the Notes API to read data (for example, the email address of user's contacts) will get a password prompt -- and well-trained users should recognize that something bad is happening and have the opportunity to stop the virus. If the setting is turned on, users lose this protection. You will have to balance this risk against the benefit of avoiding having to type the password.

Another possible solution: Have you considered using SMTP mail instead? You probably found that your MS Access solution did sent mails showing your name as sender - which might be the intention. But if your'e running server-like solutions, this could easily be replaced by (I believe its native within MS Acces 2010) a component that allowed you to send SMTP mails.

The ID Recovery mechanism is basically simple. If an ID has been created with a certifier that has recovery information, the ID file contains at least one recovery password that is randomly generated and encrypted with an administrator's public key. The password is unique for each administrator and user. For example, administrator Cindy HelpDesk has a unique recovery password for user Bubba Smith, and that password is stored in Bubba's ID file.

Before ID Recovery, if a user lost the password to her ID, the administrator had to either get the ID file from an archive or create a new ID file for the user. Both options posed problems:

• If the ID was obtained from the archive, the old ID file might not contain recent X.509 keys, encryption keys, name changes, or new keys from recertification.
• If the administrator created a new ID file for the user, even with the same user name as before, the user would not be able to read previously encrypted mail or documents.

ID and Password Recovery makes user ID management simpler and better with these new features:

• The ability to "open" an existing ID Recovery–enabled ID file and assign a new password to it.
• The ability for an administrator to unlock an ID over the phone.
• The ability to harvest IDs from R5 clients and back up the IDs in a secure, centralized database.
• The ability to enable any ID to support ID Recovery via Notes mail.
• The ability to automatically archive IDs at the time of new user registration.
• The ability to manage the recovery information in each ID based on the OU level certifier.

These powerful features allow an enterprise Domino installation to securely manage ID files while also providing better service to users.