ClearOS LDAP configuration

Since version 8.1.12, the OpenLDAP integration has changed:

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

Need to install the Certificate Manager and Directory Server modules.

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

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

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

The OpenKM integration with LDAP has three steps. In the first step, configure OpenKM to retrieve the list of users and roles from the LDAP. This list is cached during 30-45 minutes by OpenKM to prevent overloading the LDAP server. You can clean 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 works always in real time.

Step 1 - configuration parameters

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

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

Go to Administration > Configuration parameters

Field / PropertyTypeDescription
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

ClearOS by default only allows LDAPS.

You should create a certificate on ClearOS with the leftmost RDN of the Subject being the common name (FQDN) of your ClearOS server. Easy way is to only specify 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 of 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 thusly:

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

After the update of the openkm.properties file must restart the openkm service to take effect.

Another option to configure login

In some cases might be interested to set configuration in 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 should use the next 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>