EMC Documentum 7.2 migration and Murphy's laws

This month I completed a Documentum 7.2 migration of an existing Documentum 6.7 architecture. As in every Documentum project, I learned a lot. The first thing is that you can work hard in order to manage all possible risks but you will not cover ALL the risks: it happened the impossible but that is not a great point as well described by one of the Murphy's Laws.....

If anything simply cannot go wrong, it will anyway.

During the Documentum migration I learned something very simple, basic but really new to me: I discovered that the encrypted bof registry user password is validated as-is, by every Documentum Foundation Classes client, for example Documentum Administrator or Webtop, during every standard authentication process.

Introduction

The Global Registry is a special Documentum repository that is used to manage centrally, information like DFC client registrations, service-based business objects (SBOs), WDK presets and preferences, newtork locations. All Documentum DFC clients use the bof registry user credentials to access the Global Registry repository. Every Documentum client, directly or indirectly, uses DFC, the Documentum Foundation Classes and every DFC application, during the initialisation, reads the dfc.properties file where are defined some parameters. Three of these are related to the Global Registry:

1. dfc.globalregistry.repository, the name of the repository designated as Global Registry;
2. dfc.globalregistry.username, the login name of the bof registry user, usually dm_bof_registry;
3. dfc.globalregistry.password, the password of the bof registry user.

During every Documentum client deployment, you need to share the dfc.properties with system administrators, but you don't want to share a plain text password, right? As reported in every EMC Documentum manual, the bof registry password can be easily encrypted executing this command:

 java -cp dfc.jar com.documentum.fc.tools.RegistryPasswordUtils <password_to_be_encrypted>

Then you should copy the output of this command into the dfc.properties file. Since version 7.x, if needed, everyone can decrypt  the encrypted password just executing: 

java -cp dfc.jar com.documentum.fc.tools.RegistryPasswordUpgradeTool -decrypt_password  <encrypted_password> 

For example, let's encrypt / decrypt the SuperCoolPassword2016 string:

Something new I learned

There is no need to decrypt that password! I do admit: in many years I never tried to use the bof registry user encrypted password as a valid password in a Documentum client but one colleague did it. It worked!  That surprised me because because in my mind, encryption is useless without .... decryption!

Every Documentum developer/consultant knows that behind the scenes DFC libraries decrypt the encrypted password: Documentum clients have to (actually should) "register" the application to the Global Registry during first start-up or just to save information on behalf of the end user (WDK preferences). What I did not know is that DFC decrypts that password also during standard authentication for bof registry user, in every DFC client, so plain text password and the encrypted version are interchangeble, everywhere, in all Documentum clients (apart those based on dmcl).

Words are important and the "encrypted password" term in the dfc.properties file and in standard manuals is misleading, at least to me, but probably that is just my problem! In my opinion, a more correct term could be "client login ticket", something similar to the standard Documentum login ticket, something that does not need to be decrypted by end users or applications before to use it.

 I am thinking about a question again and again: why someone should encrypt a string if everyone can use it, as-it, in every application, without the need to decrypt it? It is more reasonable to use a plain text string instead: everyone can use it, as-is, as the encrypted password but ... you do not have to encrypt it, no need to read manuals, no need to to convert password encrypted using DFC 6.7 library for newer DFC 7.x environment. No need to decrypt a forgotten password.

My doubts can be summarized by a new, not pessimistic, Murphy's Law: 

Use Encryption just if Decryption is necessary....

Documentum login tickets could be a valuable alternative to the password encryption for the standard bof registry user: a login ticket  generated by a Documentum superuser (using a new Documentum Administrator feature?), can have a limted time validity and a great advantage: the term "login ticket" instead of the "encrypted password": more clear (at least to me!).

***

Good news after Documentum 7.2 migration

The new Documentum 7.2 architecture is working very well; better than the older one. At the moment we do not know what really improved performances. Many variables are changed during the migration: the Java runtime (from 1.6 to 1.7), the o.s. (from Solaris 10 to Solaris 11), Sparc CPUs and Documentum (from 6.7 SP2 to 7.2). One should isolate every single variable in order to discover what really changed performances but everybody spends time and money just when things or performances are not going well. I like to think (and I am supposing) that Documentum 7.2 added a great value to the overall architecture performances.