With its new eDocs DM roadmap OpenText has made clear that security is a priority. The roadmap focuses on ways organizations can protect themselves from both internal and external threats.
It’s easier than you might think to start securing your DM environment. While you wait for DM 16 to be released, or contemplate purchasing Guardian for eDOCS, consider locking down your DM Servers and securing client communication to DM Servers with HTTPS.
Internal Threats
We’ve already taken a look at OpenText Guardian for eDOCS, which has improved in its stability and feature set since our last post about the add-on tool from last year.
DM 16 will have new features that make the management of ethical walls, metadata security, and user/group permissions a more seamless experience for administrators and end-users.
External Threats (and Internal too!)
If you’re looking for a way to better protect your OpenText eDOCS environment from external threats, you don’t have to wait for the release of DM 16 and you don’t have to purchase any add-on tools – you can lock down your DM Servers by enabling HTTPS protocol in your environment.
We’ve seen a recent push towards enabling HTTPS for DM from OpenText, but documentation and support for this process is lacking thus far. The HTTPS Certificate Installer is tucked away in the Tools\Support folder on the DM 10 ISO, and there are a couple of articles in the OT Knowledge Base that can be piecemealed together in order to get HTTPS up and running.
Here are some key points we learned from the implementation process and our quest to lock down communications to and from our DM Servers:
You don’t need the HTTPS Certificate Installer application if you are using an Active Directory generated certificate.
- OpenText provides instructions on how to setup an AD generated certificate on your DM Server in its KB Article 61752109.
- You still need to add the server and client-side registry keys required with HTTPS for eDOCS and set the primary network bindings accordingly.
You need to use the fully qualified domain name for the DM Server in the DM Connection Wizard and when creating your CNF File.
- There are instructions in OpenText document 30559992 on how to use the HTTPS Certificate Installer.
- Regardless of whether you are using your own certificate or using the OpenText tool to generate one, you should use your DM Server FQDN with the DM Connection Wizard.
If you are running DM 10, you do not need to download OpenSSL.
- When setting up the HTTPS Certificate Installer from the DM 10 ISO, there is a popup that relays this message. DM 10 documentation has not reflected this as of now.
If you are running DM 10, you cannot use HTTPS for communication with the DM Management Studio
- If you are looking to lock down the ports on your DM Server after moving from DCOM to SSL protocol, keep in mind that the DM Management Studio can only use DCOM for communication at this time.
- An OpenText Enhancement Request is in the works to add communication with HTTP and HTTPS, according to KB Article 61823443.
- You can connect to the localhost in Management Studio from the DM Server itself, but you cannot connect to the DM Server from elsewhere on the network without opening ports for DCOM.
If you are utilizing load balancing between multiple DM Servers, you need DCOM.
- You can open port 137 for DM failover and propagate your server list manually, but you’ll need DCOM to take advantage of DM Server load balancing.
The Takeaway
This change provides high-level encryption of data transferred between DM Servers and eDOCS clients, and allows you to lock down your DM Servers and DM Web Servers by closing all ports except for HTTPS, SQL, and DM failover (if necessary). The option to configure HTTPS comes free with DM software and implementation requires essentially no downtime for users. Making HTTPS the default for all client communication is a great way to start securing your document management system. It’s a no-brainer.