To be honest, it's not really four easy steps. It's really three easy steps and one kind of tedious step. But public key mismatches in Lotus Notes and Domino are so important to correct that you'll want to do all four of them anyway, even if the last one is somewhat irksome.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Background on Lotus Notes public keys
Every Lotus Notes user's ID file stores a pair of extremely important security keys: the private key and the public key. These keys are mathematically related to each other and are unique to each user ID.
The public key is stored in your user ID and the Domino Directory. Your private key is a well-kept secret that is only stored in your user ID file. These two security keys have the same mathematical key ancestry, but have slightly different content and functionality. Think of them as fraternal twins rather than identical twins.
The private key and public key are used by Lotus Notes and Domino Server in a variety of security situations, such as authenticating with a server, signing email, or sending and receiving encrypted email. When someone sends you encrypted email, their Lotus Notes client reads your public key from the Notes Address Book (NAB) and uses it to encrypt the message. When you receive the message, your Lotus Notes client uses your private key in the process of decrypting the message.
Occasionally, mostly by accident or through someone not following best practices, the public key in a Lotus Notes ID file becomes different than the one in the Notes Address Book.
If the public key in the address book is not exactly the same as the public key in your ID file, many Lotus Notes processes, such as encrypting email, will cease to function correctly.
But that's not all. Renames and recertifications will fail, as will password checking and public key checking. Requests sent to the AdminP task break also, because the public key of the requestor doesn't match the one in the NAB.
IBM Lotus has published many documents with instructions on how to copy the public key from an ID to a person document in the address book. But how can you be proactive and find all the Notes users that have the mismatched public keys?
This is especially important if you want to implement password or public key checking for the first time. You'd hate to turn on those functions, only to find out that you've accidentally prevented a few hundred users from accessing servers. That would be a very unpleasant day.
How to fix Lotus Notes user IDs with mismatched public keys
Fortunately, the solution is a piece of cake, if you know these four steps:
- Know what to look for.
In releases 5.x and 6.x of Notes/Domino, an event is logged whenever a user with a mismatch is authenticated by a server. The error in the log and on the console looks like this in these versions:
WARNING: The public key for Liam Michaels/Technotics found in directory names.nsf on server Mail01/Servers/Technotics does not match the one used during authentication.
In ND7, server documents must be configured to log this event. You'll find the setting in the security tab.
This is the ND7 version of the public key mismatch message:
Mark McGurk/Technotics from host [10.200.100.163:1731] encountered non-fatal problem during authentication: Your public key was not found in the Name and Address Book.
Now that you know what's going to show up in the log, you can capture and analyze the information to find out which users have the problem.
- Create a database to hold all of the errors.
You don't really have to put all the errors in a database. You could use log analysis to find all of the occurrences. That works if you have just three or five servers.
But if you have 20 or 50 or 100 servers, pulling these incidents out of the logs would be painfully slow and a mind-numbing experience. Notes/Domino administrators like us are generally too busy to comb through data on every Lotus Domino server log in a big domain.
Instead, pick your favorite server and create a database using the Monitoring Results (statrep.ntf) template. Give the database a title and a file name that identifies what it contains, like "Public Key Mismatch Catcher" (pkstatrep.nsf).
- Configure an event handler to capture the logged event and place it in the database you created.
Open the Monitoring Configuration (events4.nsf) database on one of the Lotus Domino servers in your domain and create an Event Handler.
I like to choose "all servers" during the discovery process. I also select "Any Event," because we don't care what kind of event it is. We're going to be interested in a specific text string appearing in the server console and thus in the log.
For R5/6 configure the "Events must have this text in the message" to hold a portion of the error message, such as the following:
WARNING: The public key
This screenshot shows the Event tab of the Event Handler for R5/6.
If you're using ND7, you could use this line instead:
public key was not found
Lastly, configure the Action to be "Log to a database", and enter the filename of the database you created and the server that contains it.
The Event Handler is enabled by default.
Then just sit back and let the collection happen. In a very short amount of time, the database will start collecting the error and you'll know who has a public key mismatch.
- Fix the problem.
This is the tedious part. Use the instructions in this link to a Lotus knowledge base article about fixing public keys in the address book. This is the R6.5 method, but the other versions are very similar.
Unfortunately, I am not aware of any automated way to fix this problem. If you have one and share it with me, I will in turn share it with the extended family of Notes/Domino administrators here on SearchDomino.com and give you the credit. You can write to me at AndyP at Technotics dot com.
About the author: Andy Pedisich is President of Technotics, Inc. He has been working with Lotus Notes and Domino since Release 2. Technotics provides strategic consulting and training on collaborative infrastructure projects for customers throughout the world. You can contact Technotics through their Web site at www.technotics.com.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip is via the rating scale below. Do you have a useful Lotus Notes, Domino, Workplace or WebSphere tip or code snippet to share? Submit it to our tip contest and you could win a prize.