//
you're reading...
Domino, Exchange

Lotus Notes Encryption and Migrations of Email to Exchange

My name is Perry Hiltz. I am a Solutions Architect with Binary Tree. My primary back ground is in Domino Administration and Development and with over 16 years in this field, let explain what I know.

In my role as a Solutions Architect, I typically speak with customers and Partners, and get asked questions about Migrations to Exchange where Lotus Notes may or may not have encrypted email.

While in most production environments, there is not a hoard of these objects the Lotus Notes client allows end users to encrypt messages very simply. For example, the act of sending an email in Lotus Notes makes this simple. Under the delivery options a user can check the Encrypt option to encrypt single emails.
emcrypt mail

However this can be set via policies and on individual workstations on the Preferences area of the client. When a user opens the Mail/Sending and Receiving area of the Workstation Preferences, the user can turn on Encrypt saved copies of sent messages and Encrypt messages that I send.
emcrypt mail

In both of these cases when a message is sent to a user, only the intended recipient can open it. This is a security feature of Lotus Notes and Domino that prevents an Administrator using an ID with Elevated Privileges or a Server ID from accessing messages with sensitive content.

With this in mind the question then is how can we migrate emails from Domino that contain these levels of encryption? Well the first point of understanding the process, you need to have a clear understanding of how mail is first encrypted.

In the case of Domino Encryption, the process involves a public/private key architecture. When an individual is planning on sending a message for encryption, the intended recipient(s) are first addressed in the email. Next, when the author of the email sends the message, the message is first encrypted with the public key for each recipient, that is found in the Domino Directory. This message copy bound for that individual is encrypted and routed.

When the intended recipient opens the message, a private key found in the users Lotus Notes ID file unlocks the encryption and displays the message to the individual. For everyone else, this means that the message cannot be read; nor can the encryption be broken; ever!

So this means that if the end user is the only particular person who can read this email.

How can we migrate this then with a migration account? Very simply put, we cannot. The header and subject of the email can still be read but the body of the message is what is encrypted. So there are two ways that this message can be migrated to Exchange. The first is to have end user do this; after all they are the only one who can read it, right? The other option is to have the end user decrypt this email. My experience is that the end user has their own job to do, truly does not care about the migration and the most certainly they do not want to do the job for you.

What I have seen work best, is a communication to the user explaining that we are in the process of migrating. An audit review of the user’s mail has uncovered that there are encrypted emails within their mail and without encryption they cannot be migrated. The user then knows that the migration is underway, and they have messages that may not be migrated over. The user can then either exit the email or a button based in Lotus Notes can then use the end user’s ID File to remove the encryption from the messages. They can now be migrated successfully to Exchange. This is part of the basic functionality of Binary Tree’s CMT For Exchange.

An altrernative method is to use a Notes Database as a vessel to maintain the Notes Encryption. These messages can be added to a small Lotus Notes database with the encryption in place. In this event the user will need to keep a Notes Client with thier current ID. When the message is migrated to Exchange, the encrypted message in the database is migrated as an attachment. The user opens the attachment with thier existing Notes ID and this will decrypte the message in the Notes client.

Without these steps in the process, these messages and their content cannot be migrated. This is Lotus Notes and Domino working as designed.

Advertisements

About pwhiltz

I am a Domino Administrator and Developer who has been working with IBM Domino solutions since 1997. I work for an Enterprise Email Migration company and am delving into the realm of Microsoft Exchange now.

Discussion

9 thoughts on “Lotus Notes Encryption and Migrations of Email to Exchange

  1. So in short: double infrastructure or loss of security are the consequences of a migration from Notes to Exchange. Thank you for clarifying that.

    Posted by Stephan H. Wissel | June 3, 2013, 11:46 am
    • Stephan

      Unfortunately such is the case during the migration or the message can also be added to a simple Notes Database and migrated to the user as an attachment. It will still however require the Notes Client to remain behind to read the message.

      Perry

      Posted by pwhiltz | June 3, 2013, 11:50 am
  2. what about those Notes apps that use encryption? shall we keep them also?

    Posted by Patrick Kwinten | June 10, 2013, 6:04 am
    • This will depend upon the application. Can they be reprovisioned on another platform or migrated. The purpose of the article focused around strictly email but there are instances of applications where private encryption keys are used.

      Posted by pwhiltz | June 10, 2013, 6:12 am
  3. Why not run a notes agent which will decrypt all the users messages with their notes ID and encrypt them again via smime encryption key on the new exchange PKI infrastructure. With ” over 16 years in this field” it should be a piece of cake for you.

    Posted by Easy | October 29, 2013, 6:58 am
    • Well, this is a great question. I actuality this isn’t that difficult of an agent and I have in fact build this agent. It requires the following to work properly:

      1. All ID files for Domino must have a valid and known password.
      2. All ID files for Domino must have access to the Domino Server and not listed in a Deny Access group.
      3. All ID files for Domino must have valid and current certificates. If the escrow storage ID file cannot be expired.
      4. The Workstation ECL settings must be wide open for all LotusScript options.
      5. The passwords must be validated against the actual ID files via a Lotus API call.

      All of these can in fact be done. With that in mind, that 16 years of experience has taught me that each ID file that is programmatically switch to, will result in three different workstation ECL prompts that cannot be suppressed . As a result this becomes a very tedious process in most environments.

      Additionally experience shows that most of the five points mentioned above are not found in production environments.

      To further respond to your comment, this is only one of three parts if the process. Next, is the actual migration which will almost always be donee it have tired party tool.

      Lastly an entire new process must be employed to first identify the documents that were encrypted within the Domino Mail system, and then apply the Exchange specific PKI keys for the individual messages.

      So my point is that while the concept seems “simple” in actuality is not a simple agent to “knock out”. LotusScript doesn’t work on Exchange.

      Posted by pwhiltz | October 29, 2013, 7:45 am
  4. this is not an easy task but in my opinion it is doable. Forget about using Lotus Script… you have to use the Notes C API. I well understand all the problems. In my opinion the only solution is to do something in each client workstation. For example you can deploy an extension manager in each workstation (this could be done by using policies for example). Then the extension manager will do its job since it is in the best environment: The user is logged and entered a password (so there is no need to ask for the password nor for the .id). The extension manager would simply call the NSFNoteDecrypt for each email that is encrypted and will copy those emails to a dedicated NSF . Everything would be transparent to the end user. In my opinion this is the way of doing this on a big corporate company. Send me an email for further questions.

    Posted by Paul | April 11, 2014, 10:12 am
  5. Is the alternative method where the encrypted message becomes an attachment part of the Binary Tree CMTsuite or something else?

    Posted by Rich Thomsen | May 8, 2014, 12:36 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: