OpenKM / DBScripts / Admin Account / LDAP?

[neomlsra]

OpenKM uses the \'admin\' / \'admin\' combination for username and password by default but by using it with our LDAP we have rules against using names such as admin and we need to use strong password protection.

Question: If I am installing a new instance of OpenKM can I change the scripts in particular auth.ddl to a different username and password for admin and still have it work correctly once the install is done? Please advise us on the right approach to resolve this issue. We already have the LDAP working except I can\'t have the admin account in its current form.

[pavila]

If you configure OpenKM to authenticate with your LDAP, the embeded user database is not used. You have to create an user called \"admin\" in your LDAP. The password can be as strong as you want. The deafult \"admin\"/\"admin\" user is used when default authentication is condigured (by default, it authenticates agains an embeded database)

[neomlsra]

I understand that the \'admin\' / \'admin\' account is only for the default but somehow you are determining what username is identified as the admin that initially has rights to the admin tab to administer the system. If I create a different user in my LDAP such as okmMgr with a strong password how do I assign that user the admin rights to allow administration of the OpenKM. I have played with the system before and even if I assign myself the admin role I still can\'t get access to the administrator tab.

Is the admin name hard coded to be the one and only account that has access to the administrator tab?

[pavila]

The administrator name is hard-coded and must be \"admin\".

[neomlsra]

Comments: In many companies the name \'admin\' cannot be used as an LDAP account name so hard coding the \'admin\' name to the functional ability to display the Administrator Tab will never fly in many companies. I am not sure why this is needed as I\'ve never seen any other systems do this before but it may kill this as a potential solution for us at the company I currently work for.

Question: Is there a way to have both a local (default) security schema setup where the admin account is stored locally without requiring a LDAP version and have the rest of the users authenticate through LDAP?

If we wanted to change the source so that the hardcoded \'admin\' account matched our internal naming requirements how hard of an undertaking would that be. In other words is this just referenced in some very specific areas that you could point us to or is it located in hundreds of places in the code. I know that you recently changed it from system to admin so the requirement has been there before.

If not, are there any plans to change the handling for the \'admin\'account to something that is not hardcoded?

[jtrog]

neomlsra,

It would appear that there is a way to authenticate from both the local, default, database as well as an AD or LDAP database. The change is made in the server/default/conf/login-config.xml to the authentication section. I\'ve added the LDAP configuration as a second <login-module/> section and then changed the flag from \"required\" to \"sufficient\". Once this change is made, restart OpenKM, and you should be able to log in as admin/admin or any LDAP user. Check out my login-config.xml file below.

server/default/conf/login-config.xml

Code: Select all

    <!-- OpenKM default -->
    <application-policy name = \"OpenKM\">
      <authentication>
        <login-module code=\"org.jboss.security.auth.spi.DatabaseServerLoginModule\" flag = \"sufficient\">
          <module-option name=\"dsJndiName\">java:/OKMAuthDS</module-option>
          <module-option name=\"principalsQuery\">select usr_pass as PASSWD from users where usr_id=? and usr_active=\'true\'</module-option>
          <module-option name=\"rolesQuery\">select ur_role as ROLEID, \'Roles\' from user_role where ur_user=?</module-option>
        </login-module>
    <login-module code=\"org.jboss.security.auth.spi.LdapExtLoginModule\" flag=\"sufficient\" >
      <module-option name=\"java.naming.provider.url\">ldap://localhost:389</module-option>
      <module-option name=\"bindDN\">cn=Administrator,dc=localhost</module-option>
      <module-option name=\"java.naming.security.authentication\">none</module-option>
      <module-option name=\"bindCredential\">password</module-option>
      <module-option name=\"baseCtxDN\">ou=people,dc=localhost</module-option>
      <module-option name=\"baseFilter\">(uid={0})</module-option>
      <module-option name=\"rolesCtxDN\">ou=groups,dc=localhost</module-option>
      <module-option name=\"roleFilter\">(memberUid={0})</module-option>
      <module-option name=\"roleAttributeID\">memberOf</module-option>
      <module-option name=\"roleAttributeIsDN\">true</module-option>
      <module-option name=\"roleNameAttributeID\">ou</module-option>
      <module-option name=\"roleRecursion\">-1</module-option>
      <module-option name=\"searchScope\">SUBTREE_SCOPE</module-option>
      <!-- <module-option name=\"defaultRole\">UserRol</module-option> -->
    </login-module>
      </authentication>
    </application-policy>