Recovering the dm_bof_registry Password

Last week I was installing xPlore in a Documentum environment I inherited from another architect. All I was given — and expected to need — was the repository owner and dmadmin’s password. It turned out that the xPlore installer needed to know the dm_bof_registry user’s password too. Uh oh. No one knew that password any more. No problem, I knew how to decrypt passwords…or so I thought.

I copied the dfc.globalregistry.password from the file and called the decrypttext API method in iAPI32. But, I got the following error:

API> initcrypto,c

API> decrypttext,c,DM_ENCR_TEXT=+53GKxjWODisd1NGXD1u+A\=\=

[DM_CRYPTO_E_DECRYPTTEXT_FAILED]error: “Failed to decrypt string”

[DM_CRYPTO_F_KEYSTORE_INIT]fatal: “Unable to initialize key store at C:\Documentum\dba\secure\aek.key”

javax.crypto.BadPaddingException: Given final block not properly padded

I immediately copied the database password from C:\Documentum\dba\config\repo1\dbpasswd.txt into the decrypttext API method and got the following results:

API> decrypttext,c,DM_ENCR_TEXT=1YxipAZcCOHMXBqR1T7tpj6G0WhWNc95yesPOdXamSTWBnHkvf ExjpF0w2zvUqcM


OK, so I knew the aek.key wasn’t corrupted and the error was erroneous. But what was going on here?

Digging into the EDN, I found a little snippet of DFC code that claimed to decrypt the dm_bof_registry password, and in fact it did. I discovered that the BOF passwords and the passwords stored for inline users are short and Base64 encoded, compared to the dbpassword and other passwords encrypted by dm_encrypt_password, which are longer and don’t appear to be Base64 encoded. After a little more poking around, I found a DFC method that decrypts these longer, non-Base64 encoded passwords too.

I combined these two little code snippets into a class that can now decrypt either type of password. Here is the code if you ever need it.

package com.dm_misc.recoverPW;

public class RecoverPW {

public static void main(String args[]) {

  try {
    if (args.length != 1) {
      System.err.println("usage: recoverPW password");

String password = args[0];

// try decrypting with BOF utils - shorter, base64 encoded passwords
      try {
      } catch (Exception e) {
      // try decrypting with API - longer, dm_encrypt_password passwords
      try {
	  System.out.println(com.documentum.dmcl.impl.DmclApi.getInstance().get("decrypttext,c,DM_ENCR_TEXT=" + password));
      } catch (Exception e) {

    } catch(Exception e) {

In the end, I recovered the dm_bof_registry password and got xPlore installed.  But, this whole adventure left me with some questions:

  • Why are the passwords for BOF modules, inline users and the database encrypted differently? It appears that:
    • BOF uses the RegistryPasswordUtils.decrypt() method to decrypt passwords;
    • the Content Server uses the API decrypttext method to decrypt passwords encrypted with dm_encrypt_password;
    • and the Content Server uses an unknown method to decrypt inline passwords. Anyone know more about this?
  • Why is the dm_bof_registry user’s password in the dm_user_s table different from what is in the file? And why can’t I decrypt it using either method in the code above?

I’d be interested to hear from anyone with more experience or insight in this matter.

It’s funny how when you aren’t searching for something you always find it. I ran across this recently and thought I would post it as an update. From the D6.5 EMC Documentum Content Server Administration Guide, p. 353.

Use encryptPassword to encrypt any password that you want to pass in encrypted form to the one of the following methods:

  • IDfSession.assume
  • A method to obtain a new or shared session
  • authenticateIn IDfSessionManager,IDfSession, or IDfClient
  • IDfPersistentObject.signoff
  • IDfSession.changePassword

Passwords encrypted with encryptPassword cannot be decrypted explicitly by an application or user. There is no method provided to perform decryption of passwords encrypted with encryptPassword. DFC decrypts those passwords internally when it encounters the password in the arguments of one of the above methods. Passwords encrypted with encryptPassword are prefixed with DM_ENCR_PASS. For complete information about using this method, refer to the Javadocs.


About Scott
I have been implementing Documentum solutions since 1997. In 2005, I published a book about developing Documentum solutions for the Documentum Desktop Client (ISBN 0595339689). In 2010, I began this blog as a record of interesting and (hopefully) helpful bits of information related to Documentum, and as a creative outlet.

9 Responses to Recovering the dm_bof_registry Password

  1. Stuart says:

    Sorry for this kind of post:

    Im new to the documentum world… I have been asked to test DR our docbase setup. However i dont know any of the system passwords other than the installer account details. I have sorted most of the issues apart from bof registry. I think/i know this script will sort this issue, however i dont know how to implement it. Sorry to ask but could send me or post an idiots guide on how to use it (im working in a windows enviroment).



    • Scott says:

      You should be able to copy the code from the blog post into an Eclipse project, compile it and run it. I don’t have access to my Eclipse environment where this code was developed at the moment, but I can email it to you this evening. Hope it works out for you.


  2. Lisa says:

    GREAT Post!! I have a few more questions…can you also forward me the code?


  3. Frederik says:

    Great explanation!

    I also added this functionality into the Qit utility. You can encrypt and decrypt the the DFC passwords from a GUI. It simply uses the RegistryPasswordUtils .decrypt(ENCRYPTED_PASSWORD) method. You can find this class in the following package:

    Or simply download Qit @ and find a UI for this functionality.


  4. Hicham says:

    Thanks for the useful code. May I suggest an improvement? In D7, the database password seems to be encrypted using a new algorithm because the prefix DM_ENCR_TEXT has been replaced by DM_ENCR_TEXT_V2. However, the decrypttext API is able to decrypt it nonetheless. I suggest to simply remove the DM_ENCR_TEXT= prefix from the following code line. The user just needs to provide the entire string as input.

    com.documentum.dmcl.impl.DmclApi.getInstance().get(“decrypttext,c,DM_ENCR_TEXT=” + password));

    About the question of why the password is stored differently in the dm_user object, I suppose that the Content Server just stores a hash of the password. It doesn’t need to store the password (in fact, it’s more secure not to store the password). All it needs is to verifiy that the stored hash matches the provided password when it is hashed with the same function.


    • Scott says:

      Hicham, Thanks for the comment and the suggestion. This post and code needs to be updated for D7. I will try to get to it in the near future. Thanks for reading.


  5. Pingback: Recovering Passwords, version 2 | dm_misc: Miscellaneous Documentum Information

  6. Pingback: Links to All of My Source Code | dm_misc: Miscellaneous Documentum Information

  7. Pingback: EMC Documentum 7.2 migration and Murphy’s laws | Information Organization & Access Today

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: