Configuración de openLDAP

Luego de instalado por primera vez openLDAP, este contendrá como BASE_DN una zona creada leyendo nuestra información FQDN de nuestro hostname, de no ser ese el nombre de dominio a ser utilizado por el LDAP (y casi nunca lo es), debemos reconfigurarlo:

Detenemos el servicio:

/etc/init.d/slapd stop

Y ejecutamos la re-configuración del paquete:

dpkg-reconfigure slapd

Al reconfigurar openLDAP hará una serie de preguntas:

  • Desea cambiar la configuración?: respuesta: Si
  • Cual es el nombre de dominio?: FQDN del dominio
  • Nombre de la empresa?: Para la descripción del arbol LDAP
  • Password del administrador: Para la zona creada
  • Repetir password de administrador
  • Utilizar LDAPv2?: por lo general esto no es necesario. NO
  • Qué backend desea utilizar?: acá cabe una descripción de los 2 backends de almacenamiento que soporta openLDAP:
BDB

Utiliza Berkeley DB para el almacenamiento de los datos, BDB es óptimo para DB que soporten una cantidad intensiva de consultas y muy pocas modificaciones y/o actualizaciones, no soporta entre otras cosas, mover, renombrar ni reemplazar sub-trees (sub-árboles) que tengan nodos hijos.

HDB

Modificación de BDB (Hierarquical Berkeley DB) que soporta entre otras cosas un mejor equilibrio entre consultas y modificaciones (para árboles con un intensivo proceso de modificación), entre otras cosas soporta “sub-tree rename”, esto es, permite que un sub-árbol (o rama) pueda ser renombrado y todos los nodos hijos son actualizados en paralelo.

La escogencia del backend es determinada por el nivel de uso y sus características; sin embargo y debido a cambios en Berkeley DB (ahora de Oracle), HDB es el backend de almacenamiento por defecto en GNU/Linux Debian y se prevee que BDB será en algún momento descartado.

Luego que hemos terminado de re-configurar, iniciamos el servicio.

/etc/init.d/slapd start

Asignándole password al usuario cn=admin,cn=config

Cuando openLDAP se instala en Debian, este “no le asigna” un password por defecto al usuario administrador del backend dinámico cn=config, por lo que debemos asignarle un password:

Editamos el backend originario del cn=config:

vim /etc/ldap/slapd.d/cn\=config/olcDatabase\=\{0\}config.ldif

Buscamos la entrada del DN:

olcRootDN: cn=admin,cn=config

Y le incorporamos un password:

olcRootDN: cn=admin,cn=config
olcRootPW: 123456

En este caso, el password es el seguro “123456” y está en modo “plano”, de querer el password “cifrado” debemos ejecutar:

slappasswd -h {ssha}

Donde ”-h” indica el tipo de cifrado, los cuales son:

  • {md5}
  • {sha1}
  • {ssha}
  • {crypt}

Tomamos el valor retornado por el comando y lo colocamos en el atributo olcRootPW:

olcRootPW: {SSHA}EJu5UMwAmsScZFj9IPzYZo0I37rITlgA

Cerramos y reiniciamos el servicio:

/etc/init.d/slapd restart

Podemos hacer una búsqueda de prueba:

ldapsearch -xLLL -b cn=config -D cn=admin,cn=config -W olcDatabase={0}hdb

Esto pedirá el password (en nuestro caso “123456”), y retornará:

Enter LDAP Password: 
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=jesuslara,dc=ve
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=jesuslara,dc=ve" write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by self write by dn="cn=admin,dc=jesuslara,dc=ve" write by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=jesuslara,dc=ve
olcRootPW: {SSHA}sLg1uSSe/rOp/lYq2b8DbPdVxlsSIipi
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq

Modificando el tamaño de la cache

El tamaño de la memoria cache es de gran importancia para el performance del servidor LDAP, esto es configurado en el archivo

DB_CONFIG

En la raiz de la DB de LDAP, ejemplo:

/var/lib/ldap/DB_CONFIG

El parámetro se escribe:

set_cachesize   0       52428800        0

de la forma: set_cachesize <gbytes> <bytes> <segments>

Donde gbytes es la cantidad de GigaBytes que asignaremos, bytes es la cantidad en bytes (gbytes y bytes se suman); el tamaño máximo de la caché de openLDAP (por DB) está limitada a 4Gb.

segments: representa la cantidad de segmentos en que dividiremos el cache, esto permite un uso paralelizado del mismo, “0” indica un único gran caché, mientras un numero mayor que 1, se dividirá la memoria en ese número de segmentos.

¿Cómo se computa la cache efectiva?

Nota: requerimos instalar db4-utils

aptitude install db4-utils

Si observamos las estadísticas de un archivo de índice:

db4.8_stat -d /var/lib/ldap/objectClass.bdb 
Wed Oct 20 21:59:40 2010	Local time
53162	Btree magic number
9	Btree version number
Little-endian	Byte order
duplicates, sorted duplicates	Flags
2	Minimum keys per-page
4096	Underlying database page size
1007	Overflow key/data size
1	Number of levels in the tree
5	Number of unique keys in the tree 
6	Number of data items in the tree
0	Number of tree internal pages
0	Number of bytes free in tree internal pages (0% ff)
1	Number of tree leaf pages
3934	Number of bytes free in tree leaf pages (3% ff)
0	Number of tree duplicate pages
0	Number of bytes free in tree duplicate pages (0% ff)
0	Number of tree overflow pages
0	Number of bytes free in tree overflow pages (0% ff)
0	Number of empty pages
0	Number of pages on the free list

La opción “4096 Underlying database page size” indica que el tamaño de página es de 4Kb (por lo general los tamaños de página serán 4Kb, 8Kb ó 16 Kb). Otro valor a tomar en cuenta es “0 Number of tree internal pages” según la fórmula:

(keys per page + overflow pages + duplicate pages + internal pages) * page size / 2

La caché efectiva puede ser computada de la siguiente manera:

Ejemplo:

Si tenemos un archivo ya lleno de objectClasses, con 3 keys por pagina, 656 paginas duplicadas y una página de 4Kb, esto da:

(3 + 656) * 4Kb / 2 =~ 1.3MB.

Debemos repetir esta fórmula por cada índice generado y sumarlos para obtener el total de la caché efectiva.

Incorporando Schemas

Los schemas son archivos donde se definen cada una de las estructuras (clases) y sus atributos (attributes) para la construcción de entradas LDAP; cada archivo con extensión .schema define dentro de él uno o más objectClasses y sus respectivos atributos.

Los schemas más conocidos son:

  • NIS: define las entradas de tipo PosixAccount, ShadowAccount y PosixGroup
  • core: define las entradas básicas de LDAP como person, organization, etc
  • inetorgperson: entradas dedicadas a usuarios de organización Internet

Detenemos el servicio:

/etc/init.d/slapd stop

Copiamos los archivos que necesitamos (schemas) en /etc/ldap/schema

Y listamos los schemas y guardamos en una lista:

ls -w1 /etc/ldap/schema/*.schema > schemas.conf

Nos movemos al directorio:

cd /etc/ldap/schema

Eliminar los esquemas ya definidos ahi:

/etc/ldap/slapd.d/cn\=config/cn\=schema/

(se volverán a cargar, no hay problema)

Editamos la lista en schemas.conf para que queden solamente los archivos que deseamos e incorporamos la palabra “include” al inicio de cada esquema:

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/collective.schema
include /etc/ldap/schema/corba.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/duaconf.schema
include /etc/ldap/schema/dyngroup.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/java.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/amavis.schema
include /etc/ldap/schema/asterisk.schema
include /etc/ldap/schema/dhcp.schema
include /etc/ldap/schema/mod_vhost_ldap.schema
include /etc/ldap/schema/openca.schema
include /etc/ldap/schema/ppolicy.schema
include /etc/ldap/schema/puppet.schema
include /etc/ldap/schema/qmail.schema
include /etc/ldap/schema/radius.schema
include /etc/ldap/schema/samba.schema
include /etc/ldap/schema/sudo.schema
include /etc/ldap/schema/dnszone.schema

ADVERTENCIA: Muchos esquemas dependen de otros esquemas para ser interpretados, por lo que el orden en esta lista es extremadamente importante, por ejemplo: cosine.schema depende de core, pero nis.schema e inetorgperson.schema dependen de cosine, a su vez, dnszone.schema depende de core, cosine, misc y nic.schema.

Luego, generamos los LDIF de cada esquema:

slapcat -f /etc/ldap/schema/schemas.conf -F /etc/ldap/slapd.d -n0 -s "cn={8}misc,cn=schema,cn=config" > /etc/ldap/slapd.d/cn\=config/cn\=schema/cn=misc.ldif

Esto generará una serie de schemas.ldif en el directorio:

/etc/ldap/slapd.d/cn=config/cn=schema# ls -la
total 204
drwxr-x--- 2 openldap openldap  4096 oct 20 16:58 .
drwxr-x--- 3 openldap openldap  4096 oct 20 16:54 ..
-rw------- 1 openldap openldap 15474 oct 20 15:30 cn={0}core.ldif
-rw------- 1 openldap openldap  1254 oct 20 16:47 cn={10}openldap.ldif
-rw------- 1 openldap openldap  8273 oct 20 16:47 cn={11}amavis.ldif
-rw------- 1 openldap openldap 26316 oct 20 16:47 cn={12}asterisk.ldif
-rw------- 1 openldap openldap 15878 oct 20 16:47 cn={13}dhcp.ldif
-rw------- 1 openldap openldap  2257 oct 20 16:47 cn={14}mod_vhost_ldap.ldif
-rw------- 1 openldap openldap   983 oct 20 16:47 cn={15}openca.ldif
-rw------- 1 openldap openldap  3236 oct 20 16:47 cn={16}ppolicy.ldif
-rw------- 1 openldap openldap  1081 oct 20 16:47 cn={17}puppet.ldif
-rw------- 1 openldap openldap  9222 oct 20 16:47 cn={18}qmail.ldif
-rw------- 1 openldap openldap 13293 oct 20 16:47 cn={19}radius.ldif
-rw------- 1 openldap openldap  1450 oct 20 16:47 cn={1}collective.ldif
-rw------- 1 openldap openldap 11308 oct 20 15:30 cn={1}cosine.ldif
-rw------- 1 openldap openldap 12021 oct 20 16:47 cn={20}samba.ldif
-rw------- 1 openldap openldap  1528 oct 20 16:47 cn={21}sudo.ldif
-rw------- 1 openldap openldap  5790 oct 20 16:47 cn={22}dnszone.ldif
-rw------- 1 openldap openldap  1212 oct 20 16:47 cn={2}corba.ldif
-rw------- 1 openldap openldap  4414 oct 20 16:47 cn={4}duaconf.ldif
-rw------- 1 openldap openldap  1622 oct 20 16:47 cn={5}dyngroup.ldif
-rw------- 1 openldap openldap  2784 oct 20 16:47 cn={6}inetorgperson.ldif
-rw------- 1 openldap openldap  2518 oct 20 16:47 cn={7}java.ldif
-rw------- 1 openldap openldap  1448 oct 20 16:47 cn={8}misc.ldif
-rw------- 1 openldap openldap  6420 oct 20 16:47 cn={9}nis.ldif

Retornamos el directorio al usuario y grupo openldap:

chown openldap.openldap /etc/ldap -R

e iniciamos el servicio: /etc/init.d/slapd start

Carga de Módulos

Los módulos y backends son una serie de extensiones que permiten extender las capacidades de openLDAP, desde el tipo de almacenamiento de datos hasta backends utilitarios para ejecutar scripts; para aprender a usar los overlays y los backends hay una sección acá.

Modo slapd.conf

Para incorporar módulos utilizando un archivo de configuración en /etc/ldap/slapd.conf agregamos el la sección de configuración general del servidor (antes que la incorporación de cualquier database):

moduleload      back_hdb
moduleload      back_bdb
moduleload      back_dnssrv
moduleload      back_ldap 
moduleload      syncprov
moduleload      ppolicy
moduleload      unique
moduleload      refint
moduleload      constraint
moduleload      back_monitor
moduleload      back_perl
moduleload      back_shell

De lo que hace cada uno, hay una sección específica en overlays y backends.

Al terminar de editar, reiniciamos el servicio.

Modo dinámico (cn=config)

En el archivo:

/etc/ldap/slapd.d/cn=config/cn\=module\{0\}.ldif

Podemos incorporar todos los módulos que necesitemos, en este caso, tenemos el siguiente LDIF:

dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb

E incorporamos los módulos que necesitamos así:

dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleload: {1}back_bdb
olcModuleload: {2}back_dnssrv
olcModuleload: {3}back_ldap
olcModuleload: {4}syncprov
olcModuleload: {5}ppolicy
olcModuleload: {6}unique
olcModuleload: {7}refint
olcModuleload: {8}constraint
olcModuleload: {9}back_monitor
olcModuleload: {10}back_perl
olcModuleload: {11}back_shell

Guardamos, cerramos y reiniciamos el servicio.

En los logs, veremos que al menos el modulo monitor se ha activado con la siguiente línea:

Oct 21 00:10:54 lexotanil slapd[17762]: hdb_monitor_db_open: monitoring disabled; configure monitor database to enable
 
weyu/openldap/config.txt · Última modificación: 2012/08/09 10:02 (editor externo)
 
Excepto donde se indique lo contrario, el contenido de esta wiki se autoriza bajo la siguiente licencia:CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki