Auto Logon Security Hotfix Considerations

If OpenText released patches P6 and P1 for DM 5.3.1 and DM 10, I hadn't seen them. That's fine, my playground has changed and I've been away from supporting OpenText products. However, I analyzed the Auto Logon hotfix and this is what I found.

Yes, if you had custom code that relied on the Auto Logon feature (sample one and two), the hotfix would cause your code to stop working. However, the hotfix doesn't seem re-design the insecure architecture of the Auto Logon feature. What it does is the 'friend from foe' distinguishing, where the friend is OpenText's DM clients and the foe is any custom code with DM API.  Said differently, DM Server still allows DM Extensions to log in a user without sending the user's password or any security token obtained from an identity provider server or anything.  It seems simply checking for specific parameters that the client application sends on the logon.  It appears very similar to how DM Server still allows SQL Passthrough for DM Extensions when Allow SQL Passthrough is disabled.  Needless to say that this type of 'protection' is not too hard to work around by simply mimicking the behavior of the 'trusted' application (DM Extensions in this case).

Ask OpenText Support: how would you utilize the DM Server's Auto Logon feature in a custom built application with DM API?  And if they refuse to give you a code sample or say it's not available for custom applications or only OpenText DM Extensions have this feature, then this is it - a back door to the server, for DM Extensions use the same API as all other developers who write custom code for eDOCS DM.

Disclaimer:
The information here is, to my best knowledge, believed to be true and provided as-is and without any warranty of any kind.

Plain Text Passwords in eDOCS PEOPLE Data Table

This is one among other security issues with OpenText eDOCS DM that requires attention. The explanation below is given to DM administrators along with my suggestion on how the issue can be addressed to prevent the exposure of your enterprise's documents.

If you look at the DOCSADM.PEOPLE table, you can notice the USER_PASSWORD column. Depending on for how long eDOCS DM was used in your company, you can find more or less records with passwords:

[SQL]
select  USER_ID, USER_PASSWORD, LAST_LOGIN_DATE from DOCSADM.PEOPLE where USER_PASSWORD is not null and ALLOW_LOGIN='Y'

These passwords are specific to DM, means that they have nothing to do with users' Windows account passwords, that is a good thing - Windows accounts are not compromised. However, the credentials still can be used to log into eDOCS server via eDOCS Extensions for Windows Explorer and Webtop (Cyberdocs). You can try.

At this point one may tell: 'Well, non-encrypted passwords in DB, who cares? Many old applications were written like this. Not so many people at our enterprise have direct access to eDOCS DB. Low risk. We shall be all right. '

The issue is actually worse than it may seem at the first glance. Here is why:

1. Potentially any person with read access to your DM database can find another user's password and then use it to act on that user's behalf, or may be just look at others documents. This intrusion is very difficult to detect if ever possible.

2. Anyone with write access to the database can set a password for another user, use it, wipe it out and no one would ever notice this was happening.

3. In fact, DM API has a 100% documented (read 'legal') method for reading these passwords in plain text as they are. Technically speaking, this grants read-only access to passwords to anyone with an existing login in DM. The method is a generic DM search service that is called with the following parameters:

SearchObject = "v_peoples",
Criteria = new Dictionary<string, object> { { "ALLOW_LOGIN", "Y" } },
ReturnProperties = new List<string> { "USER_ID", "USER_PASSWORD", "GROUP_ID", "NETWORK_ID", "LAST_LOGIN_DATE", "%FILTER_DISABLED_ROWS" }

It returns all people's accounts. The resultset can be easily filtered on the client side to find accounts with stored passwords.

4. DM API provides methods to anonymously write into the database! I have a separate post regarding this "feature" named SQL Pass-through. What it means for this breach is that DM API can be used to mock up passwords and then re-login with then on another user's behalf, same as item #2 above.

Items ##3 and 4 are very important to keep in mind. You should not forget them when thinking who has read-write access to your DM database. Potentially every DM user has.

Okay, what you, as administrator, can do to patch this breach.

• First, find the user account records with passwords and erase the passwords. 
• Second, ensure all your DM accounts are linked to user Windows accounts; never create or use DM-only accounts. 
• Next, create an INSERT and UPDATE triggers on the PEOPLE table to prevent passwords saving into the USER_PASSWORD column. 
• Last but not least, create alerts to notify yourself when there is an attempt to save a password into the PEOPLE table. It's up to you how you can accomplish it. This can be a tricky task.

Good luck.

Disclaimer:
The information here is provided as-is and without any responsibility of any kind. It is intended for eDOCS DM Administrators to help them understand the security issue and find ways of addressing it. The facts given are deemed true for eDOCS DM 5.3.1 P5 / DM 10 and earlier versions.

Memory Leaks in DM Service (DOCSFusion.exe)

It was the OpenText Technical Alert message sent out November 4, 2013 that drew my attention to memory leaks in DM Server:
In OpenText Document Management, eDOCS Edition (eDOCS DM) 5.3.1, with .NET Framework 4.0 installed on the client and server machines, the DM Server may stop responding. The tracking number for this issue is DM-31701.

The alert suggested installing .NET 4.5 as soon as possible to fix memory leaks.

I searched for known memory leaks in .NET 4.0, but couldn't find reports on any major issues. I then asked OpenText which specifically known issue in .NET 4.0 negatively impacts DM, but their answer was: "We tested with .NET 4.5 and couldn't detect memory leaks. You should install .NET 4.5 as recommended." Uh...

So I installed .NET Framework 4.5.1 on DM servers and started monitoring the memory of the DOCSFusion.exe process. It was soon noticed that memory consumption of DOCSFusion.exe is steadily increasing over time. Here is what I see now on a server:

This particular instance of DOCSFusion.exe was running for 20 days now and it climbed up to using 550 Mb of memory.

The issue was brought to OpenText Support Team's attention. After months of exchanging emails with OpenText Support and sending a ton of server and memory monitoring logs (OpenText has a special tool for this - WatchMemory.exe), I gave up on them admitting and fixing the issue.

This issue may be not critical in your environment, still you may want to keep your eye on it while monitoring your DM servers. The method I use for DOCSFusion.exe remote monitoring is checking the value of Process.WorkingSet64. Below is some C# code.

using System.Diagnostics;
...
public long MaxMemLimit = 800 * 1024 * 1024; // 800Mb
...
var procs = Process.GetProcessesByName(ProcessName, MachineName);
if(procs == null || procs.Length == 0)
    return new TestResult(false, null, subj,
        string.Format("Process {0} was not found on {1}.", ProcessName, MachineName), null);

var mem = procs.Max(p => p.WorkingSet64);
var isTestPassed = mem <= MaxMemLimit;

OpenText eDOCS DM Server Issues Every Administrator Must Be Aware Of

If everything seems to be going well, 

you have obviously overlooked something.

Basic Murphy's Laws

There are quite a few things an eDOCS DM administrator must be aware of and keep them under strict control to avoid the surprise of end-users calling and telling that DM isn't working for them. Here are my favorite.

Memory leaks in the DM service process
DOCSFusion.exe is leaking memory. The memory consumption steadily grows until it becomes critical, at which point you'd better restart the DM service than let your entire server to go down.

Database connection leaks
The DOCSFusion process manages a pool of database connections. Once in a while the pool manager goes mad and stops releasing database connections. Soon after that DM becomes extremely slow to end-users and can even crash.

Indexer sticks and stops progressing
As the subject says, the indexing appears to be working, but in fact it's not: all services are running and not reporting any errors, however, the index database files are not being updated. You have to restart the DM services on the server to give the indexer a kick to keep going.

These issues I observe with the most recent version of OpenText eDOCS DM: v5.3.1 Patch 5. I shall write separate blog posts on each of them to describe the "early-warning" detection methods I use in hope it would help other DM administrators...