Password policy in documentum

Imran_Yusubov
Imran_Yusubov Member
edited November 26, 2012 in Documentum #1

Hello Experts,

How to enforce users to change their password on login, and create a password policy, length chars etc. I have users with inline password and all have the same password. Now I want to force them to change their password on first login attempt. Is there any OOTB configuration available in Documentum, or does it require customization.

Thanks in advance

Tagged:

Best Answer

  • bacham2
    bacham2 Member
    edited November 21, 2012 #2 Answer ✓

    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.

Answers

  • bacham2
    bacham2 Member
    edited November 21, 2012 #3 Answer ✓

    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.

  • Imran_Yusubov
    Imran_Yusubov Member
    edited November 21, 2012 #4

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

  • bacham2
    bacham2 Member
    edited November 21, 2012 #5

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

  • Imran_Yusubov
    Imran_Yusubov Member
    edited November 21, 2012 #6

    You are tolking about America.

  • bacham2
    bacham2 Member
    edited November 21, 2012 #7

    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.

  • Imran_Yusubov
    Imran_Yusubov Member
    edited November 21, 2012 #8

    Thank you very much. The information is very helpful.

  • the_lord
    the_lord Member
    edited November 21, 2012 #9

    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

  • DCTM_Guru
    DCTM_Guru Member
    edited November 21, 2012 #10

    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.

  • Imran_Yusubov
    Imran_Yusubov Member
    edited November 21, 2012 #11

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

  • the_lord
    the_lord Member
    edited November 21, 2012 #12

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

    <component id="changepassword">

             <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>

  • PanfilovAB
    PanfilovAB Member
    edited November 24, 2012 #13 
    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.

  • DCTM_Guru
    DCTM_Guru Member
    edited November 24, 2012 #14

    PanfilovAB

    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.

  • PanfilovAB
    PanfilovAB Member
    edited November 25, 2012 #15 
    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:

    1. 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.
    2. 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
  • DCTM_Guru
    DCTM_Guru Member
    edited November 25, 2012 #16

    "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.

  • PanfilovAB
    PanfilovAB Member
    edited November 26, 2012 #17 
    - 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.

  • DCTM_Guru
    DCTM_Guru Member
    edited November 26, 2012 #18

    Good point.  I have also been told that sometimes I over think/over design for a simple problem

    This sounds like an enhancement request for BOCS.

Categories