Ask the Expert: What's New in EMC Documentum 7.1?

Is there a special reason for EMC to "strongly recommend" configuring v7.1 in certificate-based ssl mode instead of native/dual/anonymous-ssl (previous versions didn't suggest any special configuration)?

Not so v7.1-related question: Will we see the day when dmbasic is completely removed from the cs?

PS: Any ETA on 7.1 developer edition?

This discussion is now open for questions. We look forward to a lively and informative event.

Best regards,

Roberto

Please can you explain what is the difference between database views _sp _sv or _rp _rv? They looke like they are the same.

Hi,

Server Certificate Authentication was not available as an Out-of-the-Box configuration before 7.1.  This mode provides enhanced trust when identifying Documentum servers using DFC clients.  Existing modes are still supported, but we recommend the new mode for a more secure system.

Alvaro de Andres wrote: Is there a special reason for EMC to "strongly recommend" configuring v7.1 in certificate-based ssl mode instead of native/dual/anonymous-ssl (previous versions didn't suggest any special configuration)?

Alvaro, are you asking about "DOCUMENTUM® CONTENT SERVER CERTIFICATE BASED SSL CONFIGURATION AND TROUBLESHOOTING" whitepaper (http://uk.emc.com/collateral/white-papers/h11525-certificate-based-ssl-wp.pdf)? I have read it carefully and now I'm confused too:

1. if I properly understand that whitepaper, Documentum SSL layer does not support two-factor SSL authentication, that means application tokens are still in play, though its are not properly documented
2. the purpose of distribution of SSL certificates to clients is make trust relationships between client and server before transmitting any data, and I was able to imagine the only one incredible case when such setup is required: attacker installs own content server (actually, I think I'm able to write some piece of python code, that will act as content server) and registers it on production docbroker, after that attacker is able to sniff user's passwords.

It's not so much about the whitepaper (which, by the way, should be revised as it is missing several important options/configurations), but about the installation guide, where in preinstallation tasks -> configuring SSL (I think, I don't have the pdf here) explains the new certificated-based ssl secure mode and "strongly recommends" (I know this sentence is somewhere in there ) to configure the content server using this mode.

I am just curious about this recommendation. Is it just a best practice (I guess so)? has something happened to any customer so it is recommended to use this setup? I was a bit surprised with this as if I'm not mistaken even changing the passphrase is just "recommended"

About your points, I'm no expert in security nor ssl certificates, and I'm still a bit confused about the stuff I've done to get the certificate-based secure mode working, so I'll wait until the experts say something.

We're interested in your feedback and experiences with this new release, including supporting material like the documentation.  Let me know if you have additional suggestions that would make the process more straightforward. 

Patrick Walsh wrote: Existing modes are still supported, but we recommend the new mode for a more secure system.

Patrick, could you provide more details about "more secure system"? In what cases the system is less secure if anonymous ssl mode is used?

And speaking about the secure configuration, will the behaviour with the docbroker ports and the docbroker logs be fixed? It is quite confusing the way it works now, and if the secure mode is the recommended setup it would be nice to either be clear about how it works in the installation guide or fix it.

From installation to workflow, docbasic is still prolific within Documentum.  It may never be completely removed.  Many customer solutions and workflows still depend on dmbasic where it would be difficult, and time consuming, to replace.  So it's safe to assume the current scripts and processing will remain throughout the lifetime of the D7.x codeline.

In the future, we may adopt a new EBS interpreter or add support for other scripting languages as core components evolve. 

It is exciting to see the interest in the upcoming Documentum 7.1 Developer Edition.  An announcement on availability will be made soon.  I'll repost it here when it breaks.

Thanks for the answers Patrick, some more questions:

Server Certificate Authentication was not available as an Out-of-the-Box configuration before 7.1.  This mode provides enhanced trust when identifying Documentum servers using DFC client

Was it something available with previous TCS versions or is it something new developed for 7.1?

We're interested in your feedback and experiences with this new release, including supporting material like the documentation.  Let me know if you have additional suggestions that would make the process more straightforward.

(Happening in both windows and linux 7.1 setups): If you configure the docbroker to work in secure mode only it will use port 1489 even when the log indicates it is using 1490. Launching the docbroker with -port 1490 will make the docbroker listen to 1490 while the log indicates it is using 1491. Either fix this behaviour or note it in the installation guide because as now it is... confusing.

Besides, the whitepaper @PanfilovAB linked before, should be included as a full section in the documentation. Even when the installer allows you to configure the certificate-based secure mode, the troubleshooting section of that WP is quite useful.

In the future, we may adopt a new EBS interpreter or add support for other scripting languages as core components evolve.

At least is being considered an update...

Anonymous SSL mode secures the communication between the DFC client and the Content Server.  The new SSL mode also establishes the identity of the Content Server.  As you pointed out earlier, this secures the system from malicious internal masquerade attacks that try to spoof the identity of the Content Server.

In that case it's not clear why such setup is strongly recommended (see initial Alvaro's question), why not restrict docbase registration on docbroker side? Actually such setup would more useful especially for DEV/TEST environments.

Another question about SSL implementation: now CS has four(?) certificates stores: netscape for LDAP, dm_public_key_certificate, dm_private_key_certificate and pkcs for SSL connections, in my opinion it is absolutely inconsistent - every new feature has its own cryptostore implementation (also need to add D2's lockbox). Why do not remove all redundant stuff and store all cryptography settings inside docbase?

The *p views are public views and can be used by clients/applications.

The *v are Content Server internal views which are subject to different optimizations and not meant to be used by clients/applications.