ClearOS LDAP configuration

Danger

Since version 8.1.12, the OpenLDAP integration has changed:

• The configuration parameters and login procedure remain the same.
• User data and roles are now managed in OpenKM administration and stored in the database.
• There is a cron job called “Sync LDAP users” which synchronizes user data from LDAP to the database.
• The current configuration can be found at Active Directory mixed configuration with LDAP synced.

You need to install the Certificate Manager and Directory Server modules.

• Create an okmAdmin user in ClearOS.
• Create ROLE_ADMIN, ROLE_USER groups in ClearOS and populate them.

LDAP Structure

dc=local
    dc=mydomain
      ou=Accounts
        ou=Groups
          cn=ROLE_ADMIN
            member=okmAdmin
            member=user1
            member=user2
            objectClass=posixGroup
          cn=ROLE_USER
            member=user3
            member=user4
            objectClass=posixGroup
          cn=ROLE_XXXX
            objectClass=posixGroup
          cn=ROLE_YYYY
            objectClass=posixGroup
          ...
                    ou=Users
          uid=okmAdmin
            memberOf=CN=ROLE_ADMIN,ou=Groups,ou=Accounts,dc=mydomain,dc=local
            mail=okmAdmin@mail.com
            cn=OpenKM Administrator
            objectClass=inetOrgPerson
          uid=user1
            memberOf=CN=ROLE_ADMIN,ou=Groups,ou=Accounts,dc=mydomain,dc=local
            mail=user1@mail.com
            cn=User Name 1
            objectClass=inetOrgPerson
          uid=user2
            memberOf=CN=ROLE_ADMIN,ou=Groups,ou=Accounts,dc=mydomain,dc=local
            mail=user2@mail.com
            cn=User Name 3
            objectClass=inetOrgPerson

Note

Any distinguished name includes by default dc=mydomain,dc=local

Caution

The OpenKM integration with LDAP has three steps. In the first step, configure OpenKM to retrieve the list of users and roles from LDAP. This list is cached for 30-45 minutes by OpenKM to prevent overloading the LDAP server. You can clear the cache from Administration > Tools > Cache stats. In the second step, create the certificate, and finally, in the third step, configure login; this last configuration always works in real time.

Step 1 - configuration parameters

Caution

We suggest logging in to OpenKM with the admin URL (for example http://localhost:8080/openkm/admin/index) because in the next steps it will be necessary to restart the OpenKM service and you do not want to lose administrative access.

The first action should be to modify the principal.adapter parameter value and restart the OpenKM service. Because the session ID is kept in the browser, you should not lose the login after the service is restarted and you can continue working in the administration. After this change, the users and roles lists will be empty in the administration. Until you successfully configure the next parameters, these lists will remain empty.

Go to Administration > Configuration parameters

Field / Property	Type	Description
principal.adapter	String	The parameter is deprecated since version 8.1.12 com.openkm.plugin.principal.LdapPrincipalAdapter
principal.database.filter.inactive.users	Boolean	The parameter is deprecated since version 8.1.12 true
principal.hide.connection.roles	Boolean	false
system.login.lowercase	String	true
principal.ldap.server	String	ldaps://ldap.mydomain.local:636
principal.ldap.security.principal	String	cn=Manager,ou=Internal,dc=mydomain,dc=local
principal.ldap.security.credentials	String	pass1234
principal.ldap.referral	String
principal.ldap.users.from.roles	Boolean	false
principal.ldap.user.attribute	String	uid
principal.ldap.user.search.base	List	ou=Users,ou=Accounts,dc=mydomain,dc=local
principal.ldap.user.search.filter	String	(objectClass=inetOrgPerson)
principal.ldap.username.attribute	String	cn
principal.ldap.username.search.base	String	ou=Users,ou=Accounts,dc=mydomain,dc=local
principal.ldap.username.search.filter	String	(&(objectclass=inetOrgPerson)(uid={0}))
principal.ldap.mail.attribute	String	mail
principal.ldap.mail.search.base	String	dc=company,dc=local
principal.ldap.mail.search.filter	String	(&(objectclass=inetOrgPerson)(uid={0}))
principal.ldap.role.attribute	String	cn
principal.ldap.role.search.base	List	ou=Groups,ou=Accounts,dc=mydomain,dc=local
principal.ldap.role.search.filter	String	objectClass=posixGroup
principal.ldap.roles.by.user.attribute	String	memberOf
principal.ldap.roles.by.user.search.base	String	ou=Users,ou=Accounts,dc=mydomain,dc=local
principal.ldap.roles.by.user.search.filter	String	(&(objectClass=person)(uid={0}))
principal.ldap.users.by.role.attribute	String	member
principal.ldap.users.by.role.search.base	String	ou=Groups,ou=Accounts,dc=mydomain,dc=local
principal.ldap.users.by.role.search.filter	String	(&(objectClass=posixGroup)(cn={0}))

Step 2 - create a Certificate

By default, ClearOS only allows LDAPS.

Note

You should create a certificate on ClearOS with the leftmost RDN of the Subject being the common name (FQDN) of your ClearOS server. An easy way is to specify only the common name, and when signing, use a policy that is permissive.

You can create an alias (CNAME) called ldap if you wish.

$ openssl req -out ldap.csr -key private/sys-0-key.pem -new
$ openssl ca -policy policy_anything -days 3650 -out /etc/pki/CA/certs/ldap.mydomain.local.crt -infiles ldap.csr

Add the CA cert to the nssdb:

$ certutil -A -d /etc/pki/nssdb/ -n "CA certificate" -t "CT,," -a -i /etc/pki/CA/ca-cert.pem

The LDAP server certificate needs to be saved in the nssdb with the name Server-Cert.

$ openssl pkcs12 -export -inkey /etc/pki/CA/private/sys-0-key.pem -in /etc/pki/CA/certs/ldap.mydomain.local.crt -out /root/Server-Cert.p12 -nodes -name 'Server-Cert'
$ pk12util -i /root/Server-Cert.p12 -d /etc/pki/nssdb/

Edit the file /etc/openldap/slapd.conf:

$ vim /etc/openldap/slapd.conf

TLSCACertificatePath    /etc/pki/nssdb
TLSCertificateFile      Server-Cert
TLSVerifyClient         never

Allow LDAP in ClearOS to be queried by OpenKM - edit the end of slapd.conf as follows:

access to *
    by self write
    by peername.ip=127.0.0.1 read
    ...
    by peername.ip=<OpenKM's IP address> read

Copy ClearOS’ public CA certificate to the OpenKM server and add it to OpenKM’s keystore:

$ keytool -import -trustcacerts -keystore /opt/openkm-6.2.3-community/java/jre/lib/security/cacerts -alias myca -file /etc/pki/tls/certs/myca.pem

Step 3 - configure login

Apply the changes in the openkm.properties file.

The parameter “okm.authentication.database” is used to disable database login.

The parameter “okm.authentication.ldap” is used to enable LDAP login.

#Authentication
okm.authentication.database=false
okm.authentication.ldap=true

#LDAP
ldap.server=ldaps://ldap.mydomain.local
ldap.manager.distinguished.name=cn=Manager,ou=Internal,dc=mydomain,dc=local
ldap.manager.password=*secret*
ldap.base=dc=mydomain,dc=local
ldap.role.attribute=cn
ldap.user.search.filter=uid={0}
ldap.role.search.filter=member={0}

Caution

After updating the openkm.properties file, you must restart the OpenKM service for the changes to take effect.

Another option to configure login

In some cases, you might be interested in setting the configuration in the file openkm.xml; please refer to Configuring openkm.xml documentation section for more information.

<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns:beans="http://www.springframework.org/schema/beans"
             xmlns:security="http://www.springframework.org/schema/security"
             xmlns:task="http://www.springframework.org/schema/task"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://www.springframework.org/schema/beans
                                 http://www.springframework.org/schema/beans/spring-beans.xsd
                                 http://www.springframework.org/schema/security
                                 http://www.springframework.org/schema/security/spring-security.xsd
                                 http://www.springframework.org/schema/task
                                 http://www.springframework.org/schema/task/spring-task.xsd">


  <!-- Security configuration -->
  <security:authentication-manager alias="authenticationManager">
    <security:authentication-provider ref="ldapAuthProvider" />
  </security:authentication-manager>

  <beans:bean id="contextSource" class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
      <beans:constructor-arg value="ldaps://ldap.mydomain.local:636/dc=mydomain,dc=local"/>
      <beans:property name="userDn" value="cn=Manager,ou=Internal,dc=mydomain,dc=local"/>
      <beans:property name="password" value="*secret*"/>
  </beans:bean>

  <beans:bean id="ldapAuthProvider" class="org.springframework.security.ldap.authentication.LdapAuthenticationProvider">
  <beans:constructor-arg>
    <beans:bean class="org.springframework.security.ldap.authentication.BindAuthenticator">
      <beans:constructor-arg ref="contextSource"/>
      <beans:property name="userSearch" ref="userSearch"></beans:property>
      </beans:bean>
  </beans:constructor-arg>
  <beans:constructor-arg name="authoritiesPopulator" ref="defaultLdapAuthoritiesPopulator"/>
  </beans:bean>

   <beans:bean id="userSearch" class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
       <beans:constructor-arg index="0" value="ou=Users,ou=Accounts" />
       <beans:constructor-arg index="1" value="uid={0}" />
       <beans:constructor-arg index="2" ref="contextSource" />
       <beans:property name="searchSubtree" value="true" />
   </beans:bean>

   <beans:bean id="defaultLdapAuthoritiesPopulator" class="org.springframework.security.ldap.userdetails.DefaultLdapAuthoritiesPopulator">
    <beans:constructor-arg ref="contextSource"/>
      <beans:constructor-arg value="ou=groups,ou=Accounts"/>
      <beans:property name="groupSearchFilter" value="member={0}"/>
      <beans:property name="groupRoleAttribute" value="cn"/>
      <beans:property name="searchSubtree" value="true" />
      <beans:property name="convertToUpperCase" value="true" />
      <beans:property name="rolePrefix" value="" />
  </beans:bean>


  <beans:bean id="userDetailService" class="org.springframework.security.ldap.userdetails.LdapUserDetailsService">
  </beans:bean>

</beans:beans>

For versions older than 8.1.12, use the following definition for the userDetailService:

<!--Needed for remember-me services -->
<beans:bean id="userDetailService" class="org.springframework.security.ldap.userdetails.LdapUserDetailsService">
  <beans:constructor-arg ref="userSearch"/>
  <beans:constructor-arg ref="defaultLdapAuthoritiesPopulator"/>
</beans:bean>