Configuración de LDAP en ClearOS

Peligro

Desde la versión 8.1.12, la integración con OpenLDAP ha cambiado:

• Los parámetros de configuración y el procedimiento de inicio de sesión permanecen igual.
• Los datos y roles de usuario ahora se gestionan en la administración de OpenKM y se almacenan en la base de datos.
• Existe una tarea cron llamada “Sync LDAP users” que sincroniza los datos de usuario desde LDAP hacia la base de datos.
• La configuración actual puede consultarse en Active Directory mixed configuration with LDAP synced.

Necesita instalar los módulos Certificate Manager y Directory Server.

• Cree un usuario okmAdmin en ClearOS.
• Cree los grupos ROLE_ADMIN, ROLE_USER en ClearOS y rellénelos.

Estructura LDAP

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

Nota

Cualquier nombre distinguido incluye por defecto dc=mydomain,dc=local

Precaución

La integración de OpenKM con LDAP tiene tres pasos. En el primer paso, se configura OpenKM para obtener la lista de usuarios y roles desde LDAP. Esta lista se cachea durante 30-45 minutos en OpenKM para evitar sobrecargar el servidor LDAP. Puede limpiar la caché desde Administration > Tools > Cache stats. En el segundo paso, se crea el certificado, y finalmente, en el tercer paso, se configura el inicio de sesión; esta última configuración siempre funciona en tiempo real.

Paso 1 - parámetros de configuración

Precaución

Le sugerimos iniciar sesión en OpenKM con la URL de administración (por ejemplo http://localhost:8080/openkm/admin/index) porque en los siguientes pasos será necesario reiniciar el servicio de OpenKM y no querrá perder el acceso administrativo.

La primera acción debe ser modificar el valor del parámetro principal.adapter y reiniciar el servicio de OpenKM. Como el ID de sesión se mantiene en el navegador, no debería perder el inicio de sesión tras reiniciar el servicio, y puede seguir trabajando en la administración. Tras este cambio, las listas de usuarios y roles quedarán vacías en la administración. Hasta que configure correctamente los siguientes parámetros, estas listas permanecerán vacías.

Vaya a Administration > Configuration parameters

Campo / Propiedad	Tipo	Descripción
principal.adapter	String	El parámetro está obsoleto desde la versión 8.1.12 com.openkm.plugin.principal.LdapPrincipalAdapter
principal.database.filter.inactive.users	Boolean	El parámetro está obsoleto desde la versión 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}))

Paso 2 - crear un certificado

Por defecto, ClearOS solo permite LDAPS.

Nota

Debe crear un certificado en ClearOS donde el RDN más a la izquierda del Subject sea el nombre común (FQDN) de su servidor ClearOS. Una forma sencilla es especificar solo el nombre común y, al firmar, usar una política permisiva.

Puede crear un alias (CNAME) llamado ldap si lo desea.

$ 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

Añada el certificado de la CA a la nssdb:

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

El certificado del servidor LDAP debe guardarse en la nssdb con el nombre 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/

Edite el fichero /etc/openldap/slapd.conf:

$ vim /etc/openldap/slapd.conf

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

Permita que OpenKM pueda consultar LDAP en ClearOS - edite el final de slapd.conf de la siguiente forma:

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

Copie el certificado CA público de ClearOS al servidor de OpenKM y añádalo al keystore de OpenKM:

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

Paso 3 - configurar el inicio de sesión

Aplique los cambios en el fichero openkm.properties.

El parámetro “okm.authentication.database” se usa para deshabilitar el inicio de sesión por base de datos.

El parámetro “okm.authentication.ldap” se usa para habilitar el inicio de sesión por LDAP.

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

Precaución

Tras actualizar el fichero openkm.properties, debe reiniciar el servicio de OpenKM para que los cambios surtan efecto.

Otra opción para configurar el inicio de sesión

En algunos casos, puede interesarle establecer la configuración en el fichero openkm.xml; consulte la sección de documentación Configuring openkm.xml para más información.

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

Para versiones anteriores a la 8.1.12, use la siguiente definición para 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>