• Authentication with new LDAP server

  • OpenKM has many interesting features, but requires some configuration process to show its full potential.
OpenKM has many interesting features, but requires some configuration process to show its full potential.
Forum rules: Please, before asking something see the documentation wiki or use the search feature of the forum. And remember we don't have a crystal ball or mental readers, so if you post about an issue tell us which OpenKM are you using and also the browser and operating system version. For more info read How to Report Bugs Effectively.
 #43780  by icebox78
 
Hello,

I have recently joined an organization where OpenKM was in use upto 2 years ago. It was installed on a physical server which was later moved on to a virtual environment. Back then OpenLDAP was being used here which was later dropped. Recently we tried to turn openkm server back on but since it it was configured to authenticate via ldap we cannot login.
Here is what i have done yet from searching the forums:
Reset okmadmin password (21232f297a57a5a743894a0e4a801fc3) method No success
I have installed an openldap server, made only 1 user "okmadmin" changed login-config.xml and direct it towards our new ldap machine
our login-config.xml
Code: Select all
<application-policy name="OpenKM">
   <authentication>
      <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required" >
         <module-option name="java.naming.provider.url">ldap://172.16.0.20:389</module-option>
         <module-option name="java.naming.security.authentication">simple</module-option>
         <module-option name="bindDN">cn=admin,dc=domain,dc=org</module-option>
         <module-option name="bindCredential">manager</module-option>
         <module-option name="baseCtxDN">dc=domain,dc=org</module-option>
         <module-option name="baseFilter">(uid={0})</module-option>
         <module-option name="rolesCtxDN">ou=openkm,dc=domain,dc=org</module-option>
         <module-option name="roleFilter">(memberUid={1})</module-option>
         <module-option name="roleAttributeID">cn</module-option>
         <module-option name="roleAttributeIsDN">false</module-option>
         <module-option name="roleRecursion">-1</module-option>
         <module-option name="searchScope">SUBTREE_SCOPE</module-option>
         <module-option name="allowEmptyPasswords">false</module-option>
     <!--module-option name="defaultRole">AdminRole</module-option-->
Ldap schema is also attached
Attachments
okmadmin.png
okmadmin.png (2.69 KiB) Viewed 22062 times
 #43781  by icebox78
 
I would also like to know that without being able to authenticate, can we do a fresh install configure it and then copy all the data from old to new, Would it work.

Regards
 #43796  by jllort
 
1- Share the contents of your OpenKM.cfg here.
2- Comment into the OpenKM.xml the section of ldap authentication and switch to database autentication:
Code: Select all
  <!-- Security configuration -->
  <security:authentication-manager alias="authenticationManager">
    <security:authentication-provider>
      <security:password-encoder hash="md5"/>
      <security:jdbc-user-service 
        data-source-ref="dataSource"
        users-by-username-query="select usr_id, usr_password, 1 from OKM_USER where usr_id=? and usr_active='T'"
        authorities-by-username-query="select ur_user, ur_role from OKM_USER_ROLE where ur_user=?"/>
    </security:authentication-provider>
  </security:authentication-manager>
usually the password should be "admin" for the user "okmAdmin".

After login go to the administration or about menu option and tell us what openkm version are you using.
 #43810  by icebox78
 
1) 1- Share the contents of your OpenKM.cfg here.


hibernate.dialect=org.hibernate.dialect.MySQL5Dialect
hibernate.hbm2ddl=none

2- Comment into the OpenKM.xml the section of ldap authentication and switch to database autentication:

I already did try that and it didnt work. Also tried with the default copy of login-config.xml but it gives an error "java.lang.NullPointerException".

Regards
 #43817  by jllort
 
Follow my steps.
1- Stop OpenKM
2- Change OpenKM.xml to use database
3- Connect to database and update okmAdmin password value to admin ( check server.xml for the values )
Code: Select all
UPDATE OKM_USER SET USR_PASSWORD='21232f297a57a5a743894a0e4a801fc3' WHERE USR_ID='okmAdmin';
4- Start OpenKM

If you follow the steps sure must going right, if it fails, then you have changed something you should not change, revert the changes.
 #43827  by icebox78
 
jllort wrote: Mon May 15, 2017 7:46 pm Follow my steps.
1- Stop OpenKM
2- Change OpenKM.xml to use database
3- Connect to database and update okmAdmin password value to admin ( check server.xml for the values )
Code: Select all
UPDATE OKM_USER SET USR_PASSWORD='21232f297a57a5a743894a0e4a801fc3' WHERE USR_ID='okmAdmin';
4- Start OpenKM

If you follow the steps sure must going right, if it fails, then you have changed something you should not change, revert the changes.
2. There is no OpenKM.xml
3. I have already changed the okmAdmin password in OKM_USER
4. There is an OpenKM.cfg, login-config.xml and openkm-ds.xml and server.xml
I have reverted everything back to original settings in which i found the machine in. And these are the configs

OpenKM.cfg
Code: Select all
#
# Since OpenKM 5.1 this file is only used for Hibernate configuration.
# To change configuration parameters, use Administration -> Configuration
#
hibernate.dialect=org.hibernate.dialect.MySQL5Dialect
hibernate.hbm2ddl=none

login-config.xml
Code: Select all
<?xml version='1.0'?>
<!DOCTYPE policy PUBLIC
      "-//JBoss//DTD JBOSS Security Config 3.0//EN"
      "http://www.jboss.org/j2ee/dtd/security_config.dtd">

<!-- The XML based JAAS login configuration read by the
org.jboss.security.auth.login.XMLLoginConfig mbean. Add
an application-policy element for each security domain.

The outline of the application-policy is:
<application-policy name="security-domain-name">
  <authentication>
    <login-module code="login.module1.class.name" flag="control_flag">
      <module-option name = "option1-name">option1-value</module-option>
      <module-option name = "option2-name">option2-value</module-option>
      ...
    </login-module>

    <login-module code="login.module2.class.name" flag="control_flag">
      ...
    </login-module>
    ...
  </authentication>
</application-policy>

$Revision: 64598 $
-->

<policy>
    <!-- Used by clients within the application server VM such as
    mbeans and servlets that access EJBs.
    -->
    <application-policy name = "client-login">
       <authentication>
          <login-module code = "org.jboss.security.ClientLoginModule"
             flag = "required">
             <!-- Any existing security context will be restored on logout -->
             <module-option name="restore-login-identity">true</module-option>
          </login-module>
       </authentication>
    </application-policy>

    <!-- Security domain for JBossMQ -->
    <application-policy name = "jbossmq">
       <authentication>
          <login-module code = "org.jboss.security.auth.spi.DatabaseServerLoginModule"
             flag = "required">
             <module-option name = "unauthenticatedIdentity">guest</module-option>
             <module-option name = "dsJndiName">java:/DefaultDS</module-option>
             <module-option name = "principalsQuery">SELECT PASSWD FROM JMS_USERS WHERE USERID=?</module-option>
             <module-option name = "rolesQuery">SELECT ROLEID, 'Roles' FROM JMS_ROLES WHERE USERID=?</module-option>
          </login-module>
       </authentication>
    </application-policy>

    <!-- Security domain for JBossMQ when using file-state-service.xml
    <application-policy name = "jbossmq">
       <authentication>
          <login-module code = "org.jboss.mq.sm.file.DynamicLoginModule"
             flag = "required">
             <module-option name = "unauthenticatedIdentity">guest</module-option>
             <module-option name = "sm.objectname">jboss.mq:service=StateManager</module-option>
          </login-module>
       </authentication>
    </application-policy>
    -->

    <!-- Security domains for testing new jca framework -->
    <application-policy name = "HsqlDbRealm">
       <authentication>
          <login-module code = "org.jboss.resource.security.ConfiguredIdentityLoginModule"
             flag = "required">
             <module-option name = "principal">sa</module-option>
             <module-option name = "userName">sa</module-option>
             <module-option name = "password"></module-option>
             <module-option name = "managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=DefaultDS</module-option>
          </login-module>
       </authentication>
    </application-policy>

    <application-policy name = "JmsXARealm">
       <authentication>
          <login-module code = "org.jboss.resource.security.ConfiguredIdentityLoginModule"
             flag = "required">
             <module-option name = "principal">guest</module-option>
             <module-option name = "userName">guest</module-option>
             <module-option name = "password">guest</module-option>
             <module-option name = "managedConnectionFactoryName">jboss.jca:service=TxCM,name=JmsXA</module-option>
          </login-module>
       </authentication>
    </application-policy>

    <!-- A template configuration for the jmx-console web application. This
      defaults to the UsersRolesLoginModule the same as other and should be
      changed to a stronger authentication mechanism as required.
    -->
    <application-policy name = "jmx-console">
       <authentication>
          <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
             flag = "required">
           <module-option name="usersProperties">props/jmx-console-users.properties</module-option>
           <module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
          </login-module>
       </authentication>
    </application-policy>

    <!-- A template configuration for the web-console web application. This
      defaults to the UsersRolesLoginModule the same as other and should be
      changed to a stronger authentication mechanism as required.
    -->
    <application-policy name = "web-console">
       <authentication>
          <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
             flag = "required">
             <module-option name="usersProperties">web-console-users.properties</module-option>
             <module-option name="rolesProperties">web-console-roles.properties</module-option>
          </login-module>
       </authentication>
    </application-policy>

    <!--
      A template configuration for the JBossWS security domain.
      This defaults to the UsersRolesLoginModule the same as other and should be
      changed to a stronger authentication mechanism as required.
    -->
    <application-policy name="JBossWS">
      <authentication>
        <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
          flag="required">
          <module-option name="usersProperties">props/jbossws-users.properties</module-option>
          <module-option name="rolesProperties">props/jbossws-roles.properties</module-option>
          <module-option name="unauthenticatedIdentity">anonymous</module-option>
        </login-module>
      </authentication>
    </application-policy>

    <!-- OpenKM -->
    <!--application-policy name = "OpenKM">
       <authentication>
          <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag = "required">
            <module-option name="dsJndiName">java:/OpenKMDS</module-option>
            <module-option name="principalsQuery">select usr_password as PASSWD from OKM_USER where usr_id=? and usr_active='T'</module-option>
            <module-option name="rolesQuery">select ur_role as ROLEID, 'Roles' from OKM_USER_ROLE where ur_user=?</module-option>
            <module-option name="hashAlgorithm">md5</module-option>
            <module-option name="hashEncoding">hex</module-option>
          </login-module>
       </authentication>
    </application-policy-->

<application-policy name="OpenKM">
   <authentication>
      <login-module code="org.jboss.security.auth.spi.LdapExtLoginModule" flag="required" >
         <module-option name="java.naming.provider.url">ldap://172.16.0.202:389</module-option>
         <module-option name="java.naming.security.authentication">simple</module-option>
         <module-option name="bindDN">cn=admin,dc=domain,dc=org</module-option>
         <module-option name="bindCredential">manager</module-option>
         <module-option name="baseCtxDN">dc=domain,dc=org</module-option>
         <module-option name="baseFilter">(uid={0})</module-option>
         <module-option name="rolesCtxDN">ou=groups,ou=openkm,dc=domain,dc=org</module-option>
         <module-option name="roleFilter">(memberUid={0})</module-option>
         <module-option name="roleAttributeID">cn</module-option>
         <module-option name="roleAttributeIsDN">false</module-option>
         <module-option name="roleRecursion">-1</module-option>
         <module-option name="searchScope">SUBTREE_SCOPE</module-option>
         <module-option name="allowEmptyPasswords">false</module-option>
     <!--module-option name="defaultRole">AdminRole</module-option--> 
    </login-module>
    </authentication>
</application-policy>

    <!-- The default login configuration used by any security domain that
    does not have a application-policy entry with a matching name
    -->
    <application-policy name = "other">
       <!-- A simple server login module, which can be used when the number
       of users is relatively small. It uses two properties files:
       users.properties, which holds users (key) and their password (value).
       roles.properties, which holds users (key) and a comma-separated list of
       their roles (value).
       The unauthenticatedIdentity property defines the name of the principal
       that will be used when a null username and password are presented as is
       the case for an unuathenticated web client or MDB. If you want to
       allow such users to be authenticated add the property, e.g.,
       unauthenticatedIdentity="nobody"
       -->
       <authentication>
          <login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule"
             flag = "required" />
       </authentication>
    </application-policy>

</policy>


openkm-dc.xml
Code: Select all
<?xml version="1.0" encoding="UTF-8"?>
<datasources>
<local-tx-datasource> 
	<jndi-name>OpenKMDS</jndi-name> 
	<connection-url>jdbc:mysql://localhost:3306/okm_app_eobi?autoReconnect=true</connection-url> 
	<driver-class>com.mysql.jdbc.Driver</driver-class> 
	<user-name>openkm</user-name> 
	<password>workstation</password> 
	<min-pool-size>5</min-pool-size> 
	<max-pool-size>20</max-pool-size> 
	<idle-timeout-minutes>28680</idle-timeout-minutes> 
	<exception-sorter-class-name>com.mysql.jdbc.integration.jboss.ExtendedMysqlExceptionSorter</exception-sorter-class-name>
	<valid-connection-checker-class-name>com.mysql.jdbc.integration.jboss.MysqlValidConnectionChecker</valid-connection-checker-class-name>
	<metadata> <type-mapping>mySQL</type-mapping></metadata> 
</local-tx-datasource>
</datasources>

server.xml
Code: Select all
<Server>

  <!--APR library loader. Documentation at /docs/apr.html -->
  <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
  <!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -->
  <Listener className="org.apache.catalina.core.JasperListener" />

   <!-- Use a custom version of StandardService that allows the
   connectors to be started independent of the normal lifecycle
   start to allow web apps to be deployed before starting the
   connectors.
   -->
   <Service name="jboss.web">

    <!-- A "Connector" represents an endpoint by which requests are received
         and responses are returned. Documentation at :
         Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
         Java AJP  Connector: /docs/config/ajp.html
         APR (HTTP/AJP) Connector: /docs/apr.html
         Define a non-SSL HTTP/1.1 Connector on port 8080
    -->
    <Connector port="80" address="${jboss.bind.address}"    
         maxThreads="250" maxHttpHeaderSize="8192"
         emptySessionPath="true" protocol="HTTP/1.1"
         enableLookups="false" redirectPort="8443" acceptCount="100"
         connectionTimeout="20000" disableUploadTimeout="true" />

    <!-- Define a SSL HTTP/1.1 Connector on port 8443
         This connector uses the JSSE configuration, when using APR, the 
         connector should be using the OpenSSL style configuration
         described in the APR documentation -->
    <!--
    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS" />
    -->

    <!-- Define an AJP 1.3 Connector on port 8009 -->
    <Connector port="8009" address="${jboss.bind.address}" protocol="AJP/1.3"
         emptySessionPath="true" enableLookups="false" redirectPort="8443" />

      <Engine name="jboss.web" defaultHost="localhost">

         <!-- The JAAS based authentication and authorization realm implementation
         that is compatible with the jboss 3.2.x realm implementation.
         - certificatePrincipal : the class name of the
         org.jboss.security.auth.certs.CertificatePrincipal impl
         used for mapping X509[] cert chains to a Princpal.
         - allRolesMode : how to handle an auth-constraint with a role-name=*,
         one of strict, authOnly, strictAuthOnly
           + strict = Use the strict servlet spec interpretation which requires
           that the user have one of the web-app/security-role/role-name
           + authOnly = Allow any authenticated user
           + strictAuthOnly = Allow any authenticated user only if there are no
           web-app/security-roles
         -->
         <Realm className="org.jboss.web.tomcat.security.JBossSecurityMgrRealm"
            certificatePrincipal="org.jboss.security.auth.certs.SubjectDNMapping"
            allRolesMode="authOnly"
            />
         <!-- A subclass of JBossSecurityMgrRealm that uses the authentication
         behavior of JBossSecurityMgrRealm, but overrides the authorization
         checks to use JACC permissions with the current java.security.Policy
         to determine authorized access.
         - allRolesMode : how to handle an auth-constraint with a role-name=*,
         one of strict, authOnly, strictAuthOnly
           + strict = Use the strict servlet spec interpretation which requires
           that the user have one of the web-app/security-role/role-name
           + authOnly = Allow any authenticated user
           + strictAuthOnly = Allow any authenticated user only if there are no
           web-app/security-roles
         <Realm className="org.jboss.web.tomcat.security.JaccAuthorizationRealm"
            certificatePrincipal="org.jboss.security.auth.certs.SubjectDNMapping"
            allRolesMode="authOnly"
            />
         -->

        <Host name="localhost"
           autoDeploy="false" deployOnStartup="false" deployXML="false"
           configClass="org.jboss.web.tomcat.security.config.JBossContextConfig"
           >

            <!-- Uncomment to enable request dumper. This Valve "logs interesting 
                 contents from the specified Request (before processing) and the 
                 corresponding Response (after processing). It is especially useful 
                 in debugging problems related to headers and cookies."
            -->
            <!--
            <Valve className="org.apache.catalina.valves.RequestDumperValve" />
            -->
 
            <!-- Access logger -->
            <!--
            <Valve className="org.apache.catalina.valves.AccessLogValve"
                prefix="localhost_access_log." suffix=".log"
                pattern="common" directory="${jboss.server.log.dir}" 
                resolveHosts="false" />
            -->

            <!-- Uncomment to enable single sign-on across web apps
                deployed to this host. Does not provide SSO across a cluster.     
            
                If this valve is used, do not use the JBoss ClusteredSingleSignOn 
                valve shown below. 
                
                A new configuration attribute is available beginning with
                release 4.0.4:
                
                cookieDomain  configures the domain to which the SSO cookie
                              will be scoped (i.e. the set of hosts to
                              which the cookie will be presented).  By default
                              the cookie is scoped to "/", meaning the host
                              that presented it.  Set cookieDomain to a
                              wider domain (e.g. "xyz.com") to allow an SSO
                              to span more than one hostname.
             -->
            <!--
            <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
            -->

            <!-- Uncomment to enable single sign-on across web apps
               deployed to this host AND to all other hosts in the cluster.
            
               If this valve is used, do not use the standard Tomcat SingleSignOn
               valve shown above.
            
               Valve uses a JBossCache instance to support SSO credential 
               caching and replication across the cluster.  The JBossCache 
               instance must be configured separately.  By default, the valve 
               shares a JBossCache with the service that supports HttpSession 
               replication.  See the "jboss-web-cluster-service.xml" file in the 
               server/all/deploy directory for cache configuration details.
            
               Besides the attributes supported by the standard Tomcat
               SingleSignOn valve (see the Tomcat docs), this version also 
               supports the following attributes:
            
               cookieDomain   see above
            
               treeCacheName  JMX ObjectName of the JBossCache MBean used to 
                              support credential caching and replication across
                              the cluster. If not set, the default value is 
                              "jboss.cache:service=TomcatClusteringCache", the 
                              standard ObjectName of the JBossCache MBean used 
                              to support session replication.
            -->
            <!--
            <Valve className="org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn" />
            -->
         
            <!-- Check for unclosed connections and transaction terminated checks
                 in servlets/jsps.
                 
                 Important: The dependency on the CachedConnectionManager
                 in META-INF/jboss-service.xml must be uncommented, too
            -->
            <Valve className="org.jboss.web.tomcat.service.jca.CachedConnectionValve"
                cachedConnectionManagerObjectName="jboss.jca:service=CachedConnectionManager"
                transactionManagerObjectName="jboss:service=TransactionManager" />

         </Host>

      </Engine>

   </Service>

</Server>

 #43835  by jllort
 
I think you are using OpenKM what comes with jboss ? is that ?
In this case the file to be modified is login-config.xml
Enable database:
Code: Select all
<!--application-policy name = "OpenKM"> -->
       <authentication>
          <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag = "required">
            <module-option name="dsJndiName">java:/OpenKMDS</module-option>
            <module-option name="principalsQuery">select usr_password as PASSWD from OKM_USER where usr_id=? and usr_active='T'</module-option>
            <module-option name="rolesQuery">select ur_role as ROLEID, 'Roles' from OKM_USER_ROLE where ur_user=?</module-option>
            <module-option name="hashAlgorithm">md5</module-option>
            <module-option name="hashEncoding">hex</module-option>
          </login-module>
       </authentication>
    </application-policy>
And disable ldap.

If you want to check ldap configuration, chedk:
Distinguised name of the user is correct
Base dc=domain,dc=org is right
this is very strange (uid={0}) ( you are using active directory or another , seems open ldap ? )

i suggest uncomment this line to be sure you do not have get roles from user problem
Code: Select all
<module-option name="defaultRole">AdminRole</module-option/>
This url has samples for Active directory ( https://www.openkm.com/wiki/index.php/A ... OpenKM_5.1 ) might take a look into. And here some sample for open ldap https://www.openkm.com/wiki/index.php/Ldap-example1
 #43838  by icebox78
 
The version we are using is older with jboss and I'm told that they used to have Openldap authentication. There was an Openldap server which had GoSa installed on it. There is no sign of that Ldap server now, hence the problem.
 #43841  by icebox78
 
This is the error appearing in the logs when i try logging in through Ldap
Code: Select all
DEBUG [org.jboss.security.auth.spi.LdapExtLoginModule] Bad password for username=okmadmin
javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name 'ou=groups,ou=openkm,dc=domain,dc=org'
A tcpdump on ldap server reveals that the Ldap server is getting requests when i login from openkm

Regards
 #43844  by icebox78
 
Hi
We have resolved the problem for now and can login openkm successfully. The problem was in ""rolesCtxDN"" of login-config.xml.
What i would like to do now is to install openkm latest version on a new server and transfer everything on that server. Is it possible that we can do it without using ldap in the future

Regards
 #43858  by jllort
 
- About ldap check if your users have an attribute named memberUid with value AdminRole or UserRole. The attribute must be set in the user.
- About export and import into new OpenKM version is possible, but before starting, tell me what is your OpenKM version ? do you use metadata or categories ?

About Us

OpenKM is part of the management software. A management software is a program that facilitates the accomplishment of administrative tasks. OpenKM is a document management system that allows you to manage business content and workflow in a more efficient way. Document managers guarantee data protection by establishing information security for business content.