D2 4.6

Well, couple of weeks ago EMC bumped version of D2 and now they claim that this version has some security enhancements and these enhancements are so serious that all customers are recommended to upgrade their installations “at the earliest opportunity”:

Prior to EMC Documentum D2 4.6, many D2 Configuration object types were not properly protected with ACLs. As a result, an authenticated but unprivileged user could then modify or delete such objects.
Resolution

The following EMC Documentum D2 release contains resolutions to these vulnerabilities:

EMC Documentum D2 4.6

EMC recommends that all customers upgrade to D2 4.6 at the earliest opportunity

Yesterday Yuri Simione published a great post containing his thoughts about this vulnerability, unfortunately thoughts of Yuri Simione are just a half of the truth, and the real situation is much worse than you might expect. But before revealing all the cards let concentrate on EMC’s announce only. There are two main points:

The first point is really ridiculous because previously ECM claimed following about support policy for D2 4.5:

New D2 4.5 Support Windows:
Primary support extended to the April 30, 2019
Secondary support extended to April 30 of 2022

And as you can see D2 4.5 is not fully supported anymore. Doesn’t it look enticing to announce long support windows but every year forcibly move customers to new version?

The second point looks strange for me because security impact was either overestimated or underestimated. Take a look at EMC’s estimations:

and try to interpret values of CVSS vector:

  • AV:N – Attack Vector = Network – OK
  • AC:L – Access Complexity = Low – OK
  • PR:L – Privileges Required = Low – OK
  • UI:N – User Interaction = No – OK
  • S:U – Scope = Unchanged – see below
  • C:H – Confidentiality Impact = High – see below
  • I:H – Integrity Impact = High – OK
  • A:H – Availability Impact = High – OK

values of two metrics (Scope and Confidentiality Impact) look extremely doubtful: before D2 4.6 any authenticated user was able to read D2 configs stored in database and in D2 4.6 any authenticated user is able to read D2 configs stored in database, so, I do not see any “Confidentiality Impact” there, and this means that either “Confidentiality Impact” is not properly estimated or EMC tries to hide something. Fortunately, I was the original researcher of the most vulnerabilities in D2 and I do know the truth. Here you can find a list of unresolved vulnerabilities in Documentum product stack, this list was provided by CERT on February 2015, and there you can find following EMC’s comment:

Fixing PSRC-2105 will be a major undertaking and it has been decided by D2 Product Management that it will not be fixed in the next release of D2 (currently versioned as 4.2.1) scheduled GA in 2015 Q2 due to resource constraints. The remediation plan here then is to fix PSRC-2105 in 2015 after the upcoming D2 4.2.1 release.

It appears that the fixed releases communicated for this issue were incorrect. This has not been fixed because the vulnerability described in PSRC-2105 (D2 configuration objects not being protected with ACLs) on which it relies has not been fixed yet. However, fixing the latter will be a major undertaking and it has been decided by D2 Product Management that it will not be fixed in the next release of D2 (currently versioned as 4.2.1) scheduled GA in 2015 Q2 due to resource constraints. The remediation plan here then is to fix PSRC-2105 in 2015 after the upcoming D2 4.2.1 release.

this comment is related to the following blogpost: CVE-2015-0518. Was it really fixed?

So, the real situation is: if D2 is installed any authenticated user is able to gain superuser privileges, i.e. installation of D2 affects Content Server, so according to CVSS guide (“an exploited vulnerability can affect resources beyond the authorization privileges intended by the vulnerable component”) the value of Scope metric is “Changed” and the real CCVS vector is:

CVSS cheating

I had never touched on this topic before, but it was always interesting for me what causes EMC to mess with CVSS scores in their vulnerability reports, below are some examples based on ESA-2015-131:

EMC score:

Authenticated Content Server users with sysadmin privileges may potentially escalate their privileges to become a super-user due to improper authorization checks performed on subgroups that exists within the dm_superusers group and other privileged groups. This may potentially be exploited by a malicious attacker to gain unauthorized access to data or to perform unauthorized actions on Content Server. The previous fix for CVE-2014-4622 was incomplete.
CVE ID: CVE-2015-4531
CVSS v2 Base Score: 7.1 (AV:N/AC:H/Au:S/C:C/I:C/A:C)

NVD score:

CVSS v2 Base Score: 9.0 HIGH
Vector: (AV:N/AC:L/Au:S/C:C/I:C/A:C)
Impact Subscore: 10.0
Exploitability Subscore: 8.0

EMC score:

Authenticated non-privileged Content Server users are allowed to run save RPC commands with super user privileges on arbitrary objects. This is due to improper user authorization checks and object type checks being performed on these objects. This may potentially be exploited by a malicious, authenticated non-privileged user to perform unauthorized actions on Content Server including executing arbitrary code. The previous fix for CVE-2014-2514 was incomplete.
CVE ID: CVE-2015-4532
CVSS v2 Base Score: 8.2 (AV:N/AC:M/Au:S/C:C/I:C/A:P)

NVD score:

CVSS v2 Base Score: 9.0 HIGH
Vector: (AV:N/AC:L/Au:S/C:C/I:C/A:C)
Impact Subscore: 10.0
Exploitability Subscore: 8.0

EMC score:

Authenticated non-privileged Content Server users are allowed to execute arbitrary code with super user privileges via custom scripts. This is due to improper authorization checks being performed on the objects created. This may potentially be exploited to perform unauthorized actions on Content Server. The previous fix for CVE-2014-2513 was incomplete.
CVE ID: CVE-2015-4533
CVSS v2 Base Score: 8.2 (AV:N/AC:M/Au:S/C:C/I:C/A:P)

NVD score:

CVSS v2 Base Score: 9.0 HIGH
Vector: (AV:N/AC:L/Au:S/C:C/I:C/A:C)
Impact Subscore: 10.0
Exploitability Subscore: 8.0

EMC score:

Content Server delegates execution of business logic to an embedded java application server called “Java Method Server” (JMS). JMS fails to properly validate digital signatures, leading to the possibility of arbitrary code execution on the Content Server. An attacker capable of crafting a digital signature for a query string without the method_verb parameter may be able to execute arbitrary code in Content Server in JMS context, depending on Java classes present in the classloader.
CVE ID: CVE-2015-4534
CVSS v2 Base Score: 8.2 (AV:N/AC:M/Au:S/C:P/I:C/A:C)

NVD score:

CVSS v2 Base Score: 9.0 HIGH
Vector: (AV:N/AC:L/Au:S/C:C/I:C/A:C)
Impact Subscore: 10.0
Exploitability Subscore: 8.0

As you can see, EMC typically messes with “Access Complexity” and “* Impact” metrics, though these metrics either have an obvious nature (attacker gains superuser privileges, why was the “Availability Impact” estimated as “partial”?) or have a pretty straightforward clarification:

Access Complexity = Medium
The access conditions are somewhat specialized; the following are examples:

  • The attacking party is limited to a group of systems or users at some level of authorization, possibly untrusted.
  • Some information must be gathered before a successful attack can be launched.
  • The affected configuration is non-default, and is not commonly configured (e.g., a vulnerability present when a server performs user account authentication via a specific scheme, but not present for another authentication scheme).
  • The attack requires a small amount of social engineering that might occasionally fool cautious users (e.g., phishing attacks that modify a web browsers status bar to show a false link, having to be on someones buddy list before sending an IM exploit).

iapi replacement

On Friday I faced with a dumb, but expected, problem: there is no my favourite CLI tool (i.e. iapi) on OS X, moreover it is a challenge to get it working on Windows – you need to install CS on Windows and after that extract CLI tools from installation. Fortunately, using groovy it is not a big deal to create your own advanced CLI:

setFile API usage limitis

Today I received a comment for Ingestion rates blogpost:

object.setFile(“path to file”); ‘path to file’ is limited to 255 characters in 6.x, I am not sure in 7.x.
You might have already noticed it but thought of sharing with you.

Well, that is true that the problem exists, but that is not true that it is a some kind of internal limit – it is just a bug in DFC. The first time when I faced with such misbehaviour was a project, when I was helping customer to upgrade Documentum from 6.5 to 6.7 – I always “like” such projects because they always cause a lot of stress: customers always expect that higher version numbers mean more product stability and maturity, which is not true in case of Documentum, moreover, customers are always happy to treat you like a whipping-boy and pin old bugs on you. Anyway, that time the error was sounding like “webtop import does not work” and corresponding exception was looking like:

THREAD: Timer-8262; MSG: [DFC_OBJECT_BADATTRVALUE] value is too big for attribute 'set_file'. Value UTF-8 length is 388. Maximum length is 255.; ERRORCODE: ff; NEXT: null
 at com.documentum.fc.client.impl.typeddata.Attribute.validateValueLength(Attribute.java:285)
 at com.documentum.fc.client.impl.typeddata.AbstractTypedData.validateAndConvertIfNecessary(AbstractTypedData.java:325)
 at com.documentum.fc.client.impl.typeddata.AbstractTypedData.setRepeatingString(AbstractTypedData.java:419)
 at com.documentum.fc.client.DfTypedObject.setRepeatingStringInternal(DfTypedObject.java:1882)
 at com.documentum.fc.client.DfTypedObject.setRepeatingStringRaw(DfTypedObject.java:1867)
 at com.documentum.fc.client.DfTypedObject$AbstractAttributeFilterImpl.set(DfTypedObject.java:3446)
 at com.documentum.fc.client.content.impl.Content$SetFileHandler.set(Content.java:1515)
 at com.documentum.fc.client.DfTypedObject.doSetString(DfTypedObject.java:1441)
 at com.documentum.fc.client.DfTypedObject.setString(DfTypedObject.java:1418)
 at com.documentum.fc.client.content.impl.Content.setSetFile(Content.java:758)
 at com.documentum.fc.client.content.impl.Content.setContentSaver(Content.java:77)
 at com.documentum.fc.client.content.impl.Content___PROXY.setContentSaver(Content___PROXY.java)
 at com.documentum.fc.client.content.impl.ContentManager.newContent(ContentManager.java:352)
 at com.documentum.fc.client.content.impl.ContentManager.makeContentInternal(ContentManager.java:522)
 at com.documentum.fc.client.content.impl.ContentManager.addContentInternal(ContentManager.java:486)
 at com.documentum.fc.client.content.impl.ContentManager.setFile(ContentManager.java:480)
 at com.documentum.fc.client.DfSysObject.setContentSaverManager(DfSysObject.java:4343)
 at com.documentum.fc.client.DfDocument___PROXY.setContentSaverManager(DfDocument___PROXY.java)
 at com.documentum.operations.nodeactions.inbound.DfSetContentFile.setContentFile(DfSetContentFile.java:253)
 at com.documentum.operations.nodeactions.inbound.DfSetContentFile.execute(DfSetContentFile.java:37)
 at com.documentum.operations.steps.impl.OperationStep.executeStep(OperationStep.java:163)
 at com.documentum.operations.steps.impl.OperationStep.execute(OperationStep.java:41)
 at com.documentum.operations.impl.OperationExecutionEngine.execute(OperationExecutionEngine.java:51)
 at com.documentum.operations.DfOperation.execute(DfOperation.java:401)
 at com.documentum.operations.inbound.impl.InboundOperation.execute(InboundOperation.java:104)
 at com.documentum.operations.inbound.DfImportOperation.execute(DfImportOperation.java:96)
 at com.documentum.web.contentxfer.DFCOperationSupport.execute(DFCOperationSupport.java:61)
 at com.documentum.web.contentxfer.ContentTransferService.execute(ContentTransferService.java:377)
 at com.documentum.web.contentxfer.JobAdapter.execute(JobAdapter.java:108)
 at com.documentum.job.async.AsyncJobManager$AsyncTimerJob.executeJob(AsyncJobManager.java:236)
 at com.documentum.job.async.AsyncJobManager$AsyncTimerJob.run(AsyncJobManager.java:215)
 at java.util.TimerThread.mainLoop(Timer.java:512)
 at java.util.TimerThread.run(Timer.java:462)

If my memory server me right, I had spent about a day to investigate what was the root cause of the problem (“value is too big for attribute ‘set_file’. Value UTF-8 length is 388. Maximum length is 255.” message seems extremely useful, doesn’t it?) and the result of my investigation was:

  1. DFC validates length of attribute values using byte semantic, i.e. com.documentum.fc.client.impl.typeddata.Attribute.validateValueLength method looks like:
    public void validateValueLength(String value) {
    	int attrLength = getLength();
    	String attrName = getName();
    	if (attrLength == 0) {
    		return;
    	}
    	int allowedLength = getAllowedLength(value);
    	if (value.length() <= allowedLength) {
    		return;
    	}
    	throw new ValueLengthException(attrName, value.getBytes("UTF-8").length, attrLength);
    }
    
    public final int getAllowedLength(String value) {
    	int attrLength = getLength();
    	if (attrLength == 0) {
    		return Integer.MAX_VALUE;
    	}
    	return UTF8Util.calculateMaximumAllowedChars(value, attrLength);
    }
    
  2. com.documentum.fc.client.content.impl.Content.setContentSaver method does know about value length limits – it tries to truncate value but does that in wrong way – it has no idea about byte semantic:
    String clientPath = contentSaver.getClientPath();
    int maxLength = getMaxSetSetFileAttrLength();
    if (clientPath != null && clientPath.length() > maxLength) {
    	warn("set_file truncated for object" + getObjectId());
    	clientPath = clientPath.substring(0, maxLength);
    }
    setSetFile(clientPath);
    
  3. Disabling ACS write capabilities mitigated the problem

I have no idea why, but customer preferred to disable ACS write capabilities in webtop over filing a CR to EMC support (Actually, I’m kidding – I do know why).

In your case the minimal reproducible test case is:

/**
 * @author Andrey B. Panfilov <andrey@panfilov.tel>
 */
public class SetFileTest {

	public static final int MAX_LENGTH = 100;

	public static void main(String[] args) throws DfException, IOException {
		IDfSession session = new DfClientX().getLocalClient().newSession("DCTM_DEV",
				new DfLoginInfo("dmadmin", "dmadmin"));
		for (char c : new char[] { 'c', '愛', }) {
			IDfDocument document = (IDfDocument) session.newObject("dm_document");
			document.setFileEx(buildPath(c, 512), "crtext", 0, null);
			document.save();
			IDfContent content = (IDfContent) session.getObject(document.getContentsId());
			System.out.println(content.getString("set_file"));
		}
	}

	private static String buildPath(char c, int length) throws IOException {
		StringBuilder result = new StringBuilder(length);
		int cLen = utfLen(Character.valueOf(c).toString());
		while (utfLen(result) < length) {
			if (MAX_LENGTH - (utfLen(result) % MAX_LENGTH) <= cLen && result.charAt(result.length() - 1) != '/') {
				String path = result.toString();
				new File(path).mkdirs();
				result.append(File.separatorChar);
			}
			result.append(c);
		}
		String path = result.toString();
		File f = new File(path);
		f.createNewFile();
		System.out.println("Path: " + path);
		return path;
	}

	private static int utfLen(CharSequence str) throws IOException {
		return str.toString().getBytes("UTF-8").length;
	}

}
Path: ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc/ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc/ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc/ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc/ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc/cccccccccccc
[main] WARN com.documentum.fc.client.content.impl.Content  - set_file truncated for object06024be980005afb
ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc/ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc/ccccccccccccccccccccccccccccccccccccccccccccccccccccccc
Path: 愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛/愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛/愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛/愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛/愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛愛/愛愛愛愛
Exception in thread "main" DfAttributeValueException:: THREAD: main; MSG: [DFC_OBJECT_BADATTRVALUE] value is too big for attribute 'set_file'. Value UTF-8 length is 512. Maximum length is 255.; ERRORCODE: ff; NEXT: null
	at com.documentum.fc.client.impl.typeddata.Attribute.validateValueLength(Attribute.java:285)
	at com.documentum.fc.client.impl.typeddata.AbstractTypedData.validateAndConvertIfNecessary(AbstractTypedData.java:325)
	at com.documentum.fc.client.impl.typeddata.AbstractTypedData.setRepeatingString(AbstractTypedData.java:419)
	at com.documentum.fc.client.DfTypedObject.setRepeatingStringInternal(DfTypedObject.java:1882)
	at com.documentum.fc.client.DfTypedObject.setRepeatingStringRaw(DfTypedObject.java:1867)
	at com.documentum.fc.client.DfTypedObject$AbstractAttributeFilterImpl.set(DfTypedObject.java:3446)
	at com.documentum.fc.client.content.impl.Content$SetFileHandler.set(Content.java:1516)
	at com.documentum.fc.client.DfTypedObject.doSetString(DfTypedObject.java:1441)
	at com.documentum.fc.client.DfTypedObject.setString(DfTypedObject.java:1418)
	at com.documentum.fc.client.content.impl.Content.setSetFile(Content.java:759)
	at com.documentum.fc.client.content.impl.Content.setContentSaver(Content.java:77)

Encryption madness. Part II

Do you remember a story about dfc.crypto.repository parameter? Below is a continuation.

Case: I want to perform upgrade from 6.7SP2 to 7.2. What should I expect? Upgrade procedure will fail because AES became a standard in 2001, but it seems that EMC got to know about that only in 2013 and decided to break upgrade procedure:

- We happy?
- Vincent! We happy?
- Yeah, we happy.

Don’t you see anything strange? I do not understand what “crypto_mode = AES128_RSA1024_SHA256” and “crypto_mode = 3DES_RSA1024_SHA256” parameters do mean, actually, I do know what the abbreviations “AES”, “RSA”, “DES” and “SHA” do mean, but I have no idea what do they mean combined together. So, let’s check documentation:

Cool, now I know even less than I knew 5 minutes ago 😦 What is my problem? I’m too smartcurious, and I do know that 3DES and AES are symmetric ciphers, RSA is a asymmetric encryption algorithm which is primarily used for key exchange, and SHA is a MAC algorithm (message authentication code). And being brought together all these abbreviations make sense only for SSL/TLS, let me demonstrate:

Andreys-MacBook-Pro:~ apanfilov$ openssl ciphers -v
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
DES-CBC3-MD5            SSLv2 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=MD5 
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
RC2-CBC-MD5             SSLv2 Kx=RSA      Au=RSA  Enc=RC2(128)  Mac=MD5 
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5 
RC4-MD5                 SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5 
EDH-RSA-DES-CBC-SHA     SSLv3 Kx=DH       Au=RSA  Enc=DES(56)   Mac=SHA1
EDH-DSS-DES-CBC-SHA     SSLv3 Kx=DH       Au=DSS  Enc=DES(56)   Mac=SHA1
DES-CBC-SHA             SSLv3 Kx=RSA      Au=RSA  Enc=DES(56)   Mac=SHA1
DES-CBC-MD5             SSLv2 Kx=RSA      Au=RSA  Enc=DES(56)   Mac=MD5 
EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=RSA  Enc=DES(40)   Mac=SHA1 export
EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=DSS  Enc=DES(40)   Mac=SHA1 export
EXP-DES-CBC-SHA         SSLv3 Kx=RSA(512) Au=RSA  Enc=DES(40)   Mac=SHA1 export
EXP-RC2-CBC-MD5         SSLv3 Kx=RSA(512) Au=RSA  Enc=RC2(40)   Mac=MD5  export
EXP-RC2-CBC-MD5         SSLv2 Kx=RSA(512) Au=RSA  Enc=RC2(40)   Mac=MD5  export
EXP-RC4-MD5             SSLv3 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export
EXP-RC4-MD5             SSLv2 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export

Doesn’t it look familiar? So, how does the crypto_mode parameter relate to “mode based on the algorithm used to generate the AEK key”? Nohow, documentation and implementation are misleading. So, what is stored in aek.key file? Nothing but a sequence of bytes which represent either 3DES or AES secret key.

No about the problem.

I have not idea why, but in D7, when fallback settings take place, encrypttext API commands got an extremely weird behaviour:

Session id is s0
API> encrypttext,c,xxx
...
DM_ENCR_TEXT_V2=AAAACHYQW2Ab8FTGW8gul3tK6Q8M+9RKuRSGgxypEcVmqaJLt2JE0+7tuKzVQzh78QTCxS6gcWAq7sOx
API> encrypttext,c,xxx
...
DM_ENCR_TEXT=W8gul3tK6Q8M+9RKuRSGgzw1veDUWIeDnWK6wT7gFEaVCVEGGORiHu/uzJNPhsAh

moreover:

~]$ iapi -X -Sapi
Running with non-standard init level: api
API> encrypttext,a,xxx
...
DM_ENCR_TEXT_V2=AAAACHYQW2Ab8FTGW8gul3tK6Q8M+9RKuRSGg63EjkDYL8tY2+Ox0El+nLbK+UgeDk0lAKELAnUx2Rnu
API> encrypttext,a,xxx
...
DM_ENCR_TEXT=W8gul3tK6Q8M+9RKuRSGg5J4DiemgxHojpL7UY6GbwClg7osvnn1GTnEmC672QgY
API> 

What does such behaviour mean? Now, you are unable to set ldap password from DA: when setting ldap password from DA, it executes replicate_setup_methods docbase method (something like “execute do_method with method=’replicate_setup_methods’,arguments=’mkfile_encrypt_text password /u01/documentum/dba/config/DCMT_DEV/ldap_08002b8f801ccabb.cnt'”), this method executes encrypttext API command and gets wrong password.

:)

Yesterday my skypemate found below CS behaviour extremely weird and asked to publish it:

API> retrieve,c,dm_user where user_source='inline password'
...
11024be980000159
API> get,c,l,user_password
...
****************
API> ?,c,select user_password from dm_user where r_object_id='11024be980000159' 
user_password   
----------------
****************
(1 row affected)

API> ?,c,select * from (select user_password from dm_user where r_object_id='11024be980000159')
user_password                                                                                                                                                                                                                                                   
-------------------------------------------------....
AAAAEFFuv1nNL7GwOdtSMsULtqfm6IAgEbbOScTIrQo8lbCei....
(1 row affected)