Password policy in documentum

No there isn't. Documentum is not the right place to do this. Inline passwords are mostly for development or technical accounts such as dm_bof_registry.

All comments

No there isn't. Documentum is not the right place to do this. Inline passwords are mostly for development or technical accounts such as dm_bof_registry.

So you mean we need to use a third party user management system? Such as active directory?

That's exactly what I'm saying. Every company should have one nowadays. Welcome to the 21st century

You are tolking about America.

Personally I'm in Europe

You can try to setup an OpenLDAP directory server (http://www.openldap.org/). It's free in case your customer is sensitive to that kind of argument... Only problem is that it's not certified to work with Content Server but I know for a fact that it does.

Thank you very much. The information is very helpful.

the_lord

Hi Imran,

Create you own custom component and redirect user to that at first login modifying login component and then below code can be used to force the user to change the pass :

IDfUser user = (IDfUser) getDfSession().getUser("User Name");user.setUserPassword("New password");user.save();

This may help you if you have session after user logs in.

Have not tried yet but just try this as luck.

Thanks,

Amit

I agree with bacham2. Content Server was never designed to be user authentication source - inline user password was only introduced in 6.x. Instead of building custom code to handle password policies, algorithms, and everything related to that, you should use various LDAP servers that are supported by Content Server. The only reason I am pushing for "certified" LDAP server is that the LDAP sync job that creates users/groups has only been tested against the supported LDAP servers. Anything else may require you to customize the LDAP sync job.

The security department has tons of requirements, so it is the best to use LDAP.

the_lord

There is an WDK component also which can be used to change passwords..

<desc>

The component provides a user interface and functionality that

allow users to change their repository passwords. The login and

changepassword components are the only two Documentum components

that do not require a Documentum connection.

</desc>

Johnny Gee wrote:I agree with bacham2.   Content Server was never designed to be user authentication source - inline user password was only introduced in 6.x.  Instead of building custom code to handle password policies, algorithms, and everything related to that, you should use various LDAP servers that are supported by Content Server.  The only reason I am pushing for "certified" LDAP server is that the LDAP sync job that creates users/groups has only been tested against the supported LDAP servers.  Anything else may require you to customize the LDAP sync job.

I agree, but I know at least two cases when ldap does not work:

1. documentum uses simple binding to AD, so authentication for AD accounts with DN length longer than 255 chars(bytes?) does not work

2. documentum does know anything about fingerprint readers/smart cards/etc - one my customer's branch office uses only smart cards (users do not know their passwords), so we are using inline passwords for such users.

1. Did you submit a ticket to EMC about this? I would be curious on their response.

2. In your described scenario, I would create custom authentication scheme. What you describe is similar to using RSA token ID, which CS does not support natively, but I have seen customers who have implemented this. To me, using inline is just workaround, since there is no synchronization of the user password (for network) and the inline password stored in repository.

1. Did you submit a ticket to EMC about this?  I would be curious on their response.

I think such behaviour is by design: user_ldap_dn attr has 255 bytes length

I would create custom authentication scheme.

It's webtop-only solution.

 To me, using inline is just workaround, since there is no synchronization of the user password (for network) and the inline password stored in repository.

Some facts about authentication implemented by WDK and CS:

IDfSessionManager stores in memory all user passwords using plaintext, so anyone who has access to application server can make heap dump and steal passwords - it is a security issue, if customer support requests a heap dump to diagnose your problem such behaviour is an issue too.
CS does not cache successful authentication attempts, that leads to the next problems:
- additional peformance impact on ldap servers
- when ldap server becomes unavaliable WDK-users got weird errors

"when ldap server becomes unavaliable WDK-users got weird errors"

- I believe you can multiple ldap servers from a failover perspective. This is not really different from having database or CS not available. It should be treated as integral part of the entire system.

- I believe you can multiple ldap servers from a failover perspective.  This is not really different from having database or CS not available.  It should be treated as integral part of the entire system.

You should think more globally The distance between CS and brach office is about 8500 km.