Servicio de Directorio con LDAP [4]: OpenLDAP (I)

¡Hola Amigos!. Entremos en materia, y como siempre recomendamos lean los tres artículos anteriores de la serie:

El DNS, DHCP y NTP son los servicios mínimos indispensables para que nuestro sencillo directorio basado en OpenLDAP nativo, funcione adecuadamente en el Debian 6.0 “Squeeze”, o en el Ubuntu 12.04 LTS “Precise Pangolin”.

Red de ejemplo:

Lan: 10.10.10.0/24
Dominio: amigos.cu
Servidor: mildap.amigos.cu
Sistema Operativo Servidor: Debian 6 "Squeeze
Dirección IP del servidor: 10.10.10.15
Cliente 1: debian7.amigos.cu
Cliente 2: raring.amigos.cu
Cliente 3: suse13.amigos.cu
Cliente 4: seven.amigos.cu

En la Primera Parte veremos:

  • Instalación del OpenLDAP (slapd 2.4.23-7.3)
  • Comprobaciones después de la instalación
  • Indices a tener en cuenta
  • Reglas del Control de Acceso a los datos
  • Generación de Certificados TLS en Squeeze

mientras que en la Segunda Parte continuaremos con:

  • Autenticación local de usuarios
  • Poblar la base de datos
  • Administrar la base de datos mediante utilidades de consola
  • Resumen hasta aquí…

Instalación del OpenLDAP (slapd 2.4.23-7.3)

El servidor OpenLDAP se instala mediante el paquete slapd. También debemos instalar el paquete ldap-utils, el cual nos proporciona algunas herramientas del lado del cliente, así como utilidades propias del OpenLDAP.

:~# aptitude install slapd ldap-utils

Durante el proceso de instalación, el debconf nos preguntará por la contraseña del administrador o usuario “admin“. También se instalan una serie de dependencias; se crea el usuario openldap; se crea la configuración inicial del servidor, así como el directorio LDAP.

En las versiones anteriores del OpenLDAP, la configuración del demonio slapd se realizaba totalmente mediante el archivo /etc/ldap/slapd.conf. En la versión que estamos usando y posteriores, la configuración se realiza en el mismo slapd, y a tal propósito se le dedica un DITDirectory Information Tree” o Árbol de Información del Directorio, por separado.

El método de configuración conocido como RTCReal Time Configuration” Configuración en Tiempo Real, o como el Método cn=config, nos permite configurar de forma dinámica al slapd sin que sea necesario reiniciar el servicio.

La base de datos de la configuración consiste en una colección de archivos de texto en formato LDIFLDAP Data Interchange Format” Formato LDAP para el Intercambio de Datos, localizados en la carpeta /etc/ldap/slapd.d.

Para tener una idea de la organización de la carpeta slapd.d, ejecutemos:

:~# ls -lR /etc/ldap/slapd.d/
/etc/ldap/slapd.d/:
total 8
drwxr-x--- 3 openldap openldap 4096 feb 16 11:08 cn=config
-rw------- 1 openldap openldap  407 feb 16 11:08 cn=config.ldif

/etc/ldap/slapd.d/cn=config:
total 28
-rw------- 1 openldap openldap  383 feb 16 11:08 cn=module{0}.ldif
drwxr-x--- 2 openldap openldap 4096 feb 16 11:08 cn=schema
-rw------- 1 openldap openldap  325 feb 16 11:08 cn=schema.ldif
-rw------- 1 openldap openldap  343 feb 16 11:08 olcBackend={0}hdb.ldif
-rw------- 1 openldap openldap  472 feb 16 11:08 olcDatabase={0}config.ldif
-rw------- 1 openldap openldap  586 feb 16 11:08 olcDatabase={-1}frontend.ldif
-rw------- 1 openldap openldap 1012 feb 16 11:08 olcDatabase={1}hdb.ldif

/etc/ldap/slapd.d/cn=config/cn=schema:
total 40
-rw------- 1 openldap openldap 15474 feb 16 11:08 cn={0}core.ldif
-rw------- 1 openldap openldap 11308 feb 16 11:08 cn={1}cosine.ldif
-rw------- 1 openldap openldap  6438 feb 16 11:08 cn={2}nis.ldif
-rw------- 1 openldap openldap  2802 feb 16 11:08 cn={3}inetorgperson.ldif

Si observamos un poco la salida anterior, vemos que el Backend utilizado en Squeeze es la base de datos tipo hdb, la cual es una variante de bdb “Berkeley Database”, y que es totalmente jerárquica y soporta el renombrado de sub-árboles. Para conocer más sobre los posibles Backends que soporta OpenLDAP, visite http://es.wikipedia.org/wiki/OpenLDAP.

También vemos que se utilizan tres bases de datos separadas, o sea, una dedicada a la configuración, otra al Frontend, y la última que es la base de datos hdb en si.

Por otra parte, slapd se instala por defecto con los esquemas Core, Cosine, Nis e Inetorgperson.

Comprobaciones después de la instalación

En una terminal ejecutamos y leemos con calma las salidas. Comprobaremos, sobre todo con el segundo comando, la configuración deducida de listar la carpeta slapd.d.

:~# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config | more
:~# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn
dn: cn=config
dn: cn=module{0},cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
dn: olcBackend={0}hdb,cn=config
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}hdb,cn=config

Explicación de cada salida:

  • cn=config: Parámetros globales.
  • cn=module{0},cn=config: Módulo cargado de forma dinámica.
  • cn=schema,cn=config: Contiene el hard-coded al nivel de los esquemas del sistema.
  • cn={0}core,cn=schema,cn=config: El hard-coded del esquema del núcleo.
  • cn={1}cosine,cn=schema,cn=config: El esquema Cosine.
  • cn={2}nis,cn=schema,cn=config: El esquema Nis.
  • cn={3}inetorgperson,cn=schema,cn=config: El esquema Inetorgperson.
  • olcBackend={0}hdb,cn=config: Backend de almacenamiento de datos tipo hdb.
  • olcDatabase={-1}frontend,cn=config: Frontend de la base de datos y parámetros por defecto para las otras bases de datos.
  • olcDatabase={0}config,cn=config: Base de datos de la configuración del slapd (cn=config).
  • olcDatabase={1}hdb,cn=config: Nuestra instancia de la base de datos (dc=amigos,dc=cu)
:~# ldapsearch -x -LLL -H ldap:/// -b dc=example,dc=com dn
dn: dc=amigos,dc=cu
dn: cn=admin,dc=amigos,dc=cu
  • dc=amigos,dc=cu: Base del DIT Árbol de Información del Directory
  • cn=admin,dc=amigos,dc=cu: Administrador (rootDN) del DIT declarado durante la instalación.

Nota: El sufijo base dc=amigos, dc=cu, lo tomó el debconf durante la instalación a partir del FQDN del servidor mildap.amigos.cu.

Indices a tener en cuenta

El indexado de las entradas se realiza para mejorar el rendimiento de las búsquedas sobre el DIT, con criterios de filtrado. Los índices que consideraremos son los mínimos recomendados acorde a los atributos declarados en los esquemas por defecto.

Para modificar dinámicamente los índices en la base de datos, creamos un archivo de texto en formato LDIF, y posteriormente lo agregamos a la base de datos. Creamos el archivo olcDbIndex.ldif y lo dejamos con el siguiente contenido:

:~# nano olcDbIndex.ldif
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: uidNumber eq
-
add: olcDbIndex
olcDbIndex: gidNumber eq
-
add: olcDbIndex
olcDbIndex: memberUid eq,pres,sub
-
add: olcDbIndex
olcDbIndex: loginShell eq
-
add: olcDbIndex
olcDbIndex: uid pres,sub,eq
-
add: olcDbIndex
olcDbIndex: cn pres,sub,eq
-
add: olcDbIndex
olcDbIndex: sn pres,sub,eq
-
add: olcDbIndex
olcDbIndex: givenName,ou pres,eq,sub
-
add: olcDbIndex
olcDbIndex: displayName pres,sub,eq
-
add: olcDbIndex
olcDbIndex: default sub
-
add: olcDbIndex
olcDbIndex: mail eq,subinitial
-
add: olcDbIndex
olcDbIndex: dc eq

Adicionamos los índices a la base de datos y comprobamos la modificación:

:~# ldapmodify -Y EXTERNAL -H ldapi:/// -f ./olcDbIndex.ldif

:~# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \
cn=config '(olcDatabase={1}hdb)' olcDbIndex

dn: olcDatabase={1}hdb,cn=config
olcDbIndex: objectClass eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: memberUid eq,pres,sub
olcDbIndex: loginShell eq
olcDbIndex: uid pres,sub,eq
olcDbIndex: cn pres,sub,eq
olcDbIndex: sn pres,sub,eq
olcDbIndex: givenName,ou pres,eq,sub
olcDbIndex: displayName pres,sub,eq
olcDbIndex: default sub
olcDbIndex: mail eq,subinitial
olcDbIndex: dc eq

Reglas del Control de Acceso a los datos

Se denomina Control de Acceso a las reglas que se establecen para que los usuarios puedan leer, modificar, agregar y borrar datos en la base de datos del Directorio, mientras que denominaremos Listas de Control de Acceso o “ACL Access Control List” a las directivas que configuran a las reglas.

Para conocer cuales ACLs se declararon por defecto durante el proceso de instalación del slapd, ejecutamos:

:~# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \
cn=config '(olcDatabase={1}hdb)' olcAccess

:~# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \
cn=config '(olcDatabase={-1}frontend)' olcAccess

:~# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \
cn=config '(olcDatabase={0}config)' olcAccess

:~# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \
cn=config '(olcAccess=*)' olcAccess olcSuffix

Cada uno de los comandos anteriores nos mostrarán las ACLs que hasta ahora tenemos declaradas en nuestro Directorio. Específicamente, el último comando las muestra todas, mientras que los tres primeros nos dan las reglas de control de acceso a los tres DIT involucrados en nuestro slapd.

Sobre el tema de las ACLs y para no hacer un artículo mucho más largo, recomendamos la lectura de las páginas del manual man slapd.access.

Para garantizar el acceso de los usuarios y administradores a actualizar su entradas de loginShell y Gecos, adicionaremos la siguiente ACL:

## Creamos el archivo olcAccess.ldif y lo dejamos con el siguiente contenido
:~# nano olcAccess.ldif
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {1}to attrs=loginShell,gecos
  by dn="cn=admin,dc=amigos,dc=cu" write
  by self write
  by * read

## Adicionamos la ACL
:~# ldapmodify -Y EXTERNAL -H ldapi:/// -f ./olcAccess.ldif

# Comprobamos los cambios
ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \
cn=config '(olcAccess=*)' olcAccess olcSuffix

Generación de Certificados TLS en Squeeze

Para tener una autenticación segura con el servidor OpenLDAP, debemos hacerla mediante una sesión encriptada la cual podemos lograrla mediante el uso del TLS “Transport Layer Security” o Capa de Transporte Segura.

El servidor OpenLDAP y sus clientes son capaces de utilizar el framework TLS para proveer la protección referente a la integridad y la confidencialidad, así como dar el soporte para una autenticación LDAP segura mediante el mecanismo SASLSimple Authentication and Security Layer Externo.

Los servidores OpenLDAP modernos perfieren el uso de */StartTLS/* o Iniciar una Capa Segura de Transporte al protocolo /LDAPS:///, el cual está obsoleto. Cualquier duda, visite *Start TLS v. ldaps://* en http://www.openldap.org/faq/data/cache/605.html

Basta con dejar como se instala por defecto el archivo /etc/default/slapd con la declaración SLAPD_SERVICES=”ldap:/// ldapi:///”, con el objetivo de emplear un canal encriptado entre el cliente y el servidor, y las propias aplicaciones auxiliares para administrar el OpenLDAP que se instalen localmente.

El método aquí descrito, basado en los paquetes gnutls-bin y ssl-cert es válido para el Debian 6 “Squeeze” y también para el Ubuntu Server 12.04. Para el Debian 7 “Wheezy” se emplea otro método basado en OpenSSL.

La generación de los certificados en Squeeze se realiza de la siguiente forma:

1.- Instalamos los paquetes necesarios
:~# aptitude install gnutls-bin ssl-cert

2.- Creamos la Clave Primaria para la Autoridad del Certificado
:~# sh -c "certtool --generate-privkey > /etc/ssl/private/cakey.pem"

3.- Creamos una plantilla para definir el CA (Certificate Authority)
:~# nano /etc/ssl/ca.info
cn = Amigos Cubanos
ca
cert_signing_key

4.- Creamos el Certificado CA Self Signed o Auto-Firmado para los clientes
:~# certtool --generate-self-signed \
--load-privkey /etc/ssl/private/cakey.pem \
--template /etc/ssl/ca.info \
--outfile /etc/ssl/certs/cacert.pem

5.- Generamos una Clave Privada para el Servidor
:~# certtool --generate-privkey \
--bits 1024 \
--outfile /etc/ssl/private/mildap-key.pem

Nota: Sustituya "mildap" en el nombre del archivo anterior por el de su
propio servidor. Nombrar el Certificado y la Clave, tanto para el servidor
como para el servicio que la utiliza, nos ayuda a mantener las cosas claras.

6.- Creamos el archivo /etc/ssl/mildap.info con el siguiente contenido:
:~# nano /etc/ssl/mildap.info
organization = Amigos Cubanos
cn = mildap.amigos.cu
tls_www_server
encryption_key
signing_key
expiration_days = 3650

Nota: En el contenido anterior declaramos que el certificado es válido
para un período de tiempo de 10 años. El parámetro debemos ajustarlo a
nuestras conveniencias.

7.- Creamos el Certificado del Servidor
:~# certtool --generate-certificate \
--load-privkey /etc/ssl/private/mildap-key.pem \
--load-ca-certificate /etc/ssl/certs/cacert.pem \
--load-ca-privkey /etc/ssl/private/cakey.pem \
--template /etc/ssl/mildap.info \
--outfile /etc/ssl/certs/mildap-cert.pem

Hasta aquí tenemos generados los archivos necesarios.Sólo nos resta adicionar al Directorio la ubicación del Certificado Auto Firmado cacert.pem; la del Certificado del Servidor mildap-cert.pem; y la de la Clave Privada del Servidor mildap-key.pem. También debemos ajustar los permisos y el propietario de los archivos generados.

:~# nano /etc/ssl/certinfo.ldif
dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/mildap-cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/mildap-key.pem

8.- Adicionamos
:~# ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/ssl/certinfo.ldif

9.- Ajustamos propietario y permisos
:~# adduser openldap ssl-cert
:~# chgrp ssl-cert /etc/ssl/private/mildap-key.pem
:~# chmod g+r /etc/ssl/private/mildap-key.pem
:~# chmod o-r /etc/ssl/private/mildap-key.pem

El certificado cacert.pem es el que debemos copiar en cada cliente. Para que en el propio servidor se utilice éste certificado, debemos declararlo en el archivo /etc/ldap/ldap.conf. Para ello, modificamos el archivo y lo dejamos con el siguiente contenido:

:~# nano /etc/ldap/ldap.conf
BASE            dc=amigos,dc=cu  
URI             ldap://mildap.amigos.cu
TLS_CACERT      /etc/ssl/certs/cacert.pem

Finalmente y también como comprobación, reiniciamos el servicio slapd y revisamos la salida del syslog del servidor, para conocer si el servicio se reinició adecuadamente utilizando el certificado recién declarado.

:~# service slapd restart
:~# tail /var/log/syslog

Si el servicio no se reinicia correctamente u observamos algún error grave en el syslog, no nos desalentemos. Podemos intentar reparar el daño o comenzar de nuevo. Si decidimos empezar desde cero la instalación del slapd, no es necesario formatear nuestro servidor.

Para borrar todo lo que hasta ahora hemos hecho por una u otra causa, debemos des-instalar el paquete slapd, y a continuación borrar la carpeta /var/lib/ldap. También debemos dejar en su versión original al archivo /etc/ldap/ldap.conf.

Es raro que en un primer intento todo funcione correctamente. 🙂

Recuerden que en la próxima entrega veremos:

  • Autenticación local de usuarios
  • Poblar la base de datos
  • Administrar la base de datos mediante utilidades de consola
  • Resumen hasta aquí…

¡Hasta pronto, amigos!.

Comparte para difundir

Si te ha gustado nuestro contenido ahora puedes ayudar a difundirlo en las redes sociales de manera sencilla usando los siguientes botones:

Envía
Pinea
Print

Categorías

Redes/Servidores

Ingeniero Termo Energético de profesión. Administrador de Redes desde hace ya varios años. Programador en Visual FoxPro. Debianero de Corazón, y "OldFashion Man". Contacto: federicotoujague@gmail.com / +53 5 5005735

19 comentarios

  1.   Hugo dijo

    Maestro!!!
    SE PASO CON EL TUTO!
    es Exelente
    todos los LIKES DEL MUNDO PARA Ud.
    😀

    1.    federico dijo

      Muchas Gracias, Hugo !!!. Espera los próximos artículos sobre el tema.

  2.   thisnameisfalse dijo

    Hola:

    interesante tu seríe de artículos.

    me ha extrañado leer esta afirmación: “Los servidores OpenLDAP modernos perfieren el uso de StartTLS o Iniciar una Capa Segura de Transporte al antiguo protocolo TLS/SSL, el cual está obsoleto.”

    ¿Afirmas que, en todos los casos incluso fuera del ámbito LDAP, STARTTLS es un mecanismo de protección superior a TSL/SSL?.

    1.    federico dijo

      Gracias por comentar. Observa que me refiero al OpenLDAP. No me extralimito. En http://www.openldap.org/faq/data/cache/185.html, puedes leer lo siguiente:

      Transport Layer Security (TLS) is the standard name for the Secure Socket Layer (SSL). The terms (unless qualified with specific version numbers) are generally interchangable.

      StartTLS is the name of the standard LDAP operation for initiating TLS/SSL. TLS/SSL is initiated upon successful completion of this LDAP operation. No alternative port is necessary. It is sometimes referred to as the TLS upgrade operation, as it upgrades a normal LDAP connection to one protected by TLS/SSL.

      ldaps:// and LDAPS refers to “LDAP over TLS/SSL” or “LDAP Secured”. TLS/SSL is initated upon connection to an alternative port (normally 636). Though the LDAPS port (636) is registered for this use, the particulars of the TLS/SSL initiation mechanism are not standardized.

      Once initiated, there is no difference between ldaps:// and StartTLS. They share the same configuration options (excepting ldaps:// requires configuration of a separate listener, see slapd(8)’s -h option) and result in like security services being established.
      Note:
      1) ldap:// + StartTLS should be directed to a normal LDAP port (normally 389), not the ldaps:// port.
      2) ldaps:// should be directed to an LDAPS port (normally 636), not the LDAP port.

      1.    thisnameisfalse dijo

        Disculpa, pero sigo sin ver claro por qué afirmas que: 1) los servidores modernos prefieren STARTTLS a SSL/TLS; 2) que STARTTLS es moderno, frente a SSL/TLS que es obsoleto.

        Llevo medio mes peleándome con la configuración de distintos clientes de correo que acceden al servidor por SSL (usando las librerías de openssl, como hace la mayoría del software libre), con certificados de CAs en /etc/ssl/certs/ y demás parafernalia. Y lo que he aprendido es que: 1) STARTTLS únicamente cifra la autenticación de la sesión, y todo lo demás lo envía sin cifrar; 2) SSL cifra absolutamente toda el contenido de la sesión. Por tanto, en ningún caso STARTTLS es superior técnicamente a SSL; yo más bien me inclinaría a pensar lo contrario, ya que el contenido de tu sesión viaja sin cifrar por la red.

        Otra cosa distinta es que se recomiende STARTTLS por otros motivos que yo desconozco: por compatibilidad con MSWindows, porque la implementación sea más estable o esté mejor probada… no lo sé. Por eso te pregunto.

        Por la cita del manual que me has adjuntado en tu respuesta, veo que la diferencia entre ldap:// y ldaps:// es equivalente a la diferencia entre imap:// e imaps://, ó entre smtp:// y smtps://: se usa un puerto distinto, se añade alguna entrada adicional en el fichero de configuración, pero el resto de parámetros se mantienen. Pero eso no indica nada acerca de preferir STARTTLS o no.

        Un saludo, y perdón por la réplica. Sólo intento aprender un poco más.

        1.    federico dijo

          Mira, es muy raro que en mis artículos haga afirmaciones de ese calibre sin que estén respaldadas por alguna publicación seria. Al final de la serie voy a incluir todos los enlaces a documentación que considero seria, y que he consultado para escribir el post. Te adelanto los siguientes enlaces:

          https://wiki.debian.org/LDAP/OpenLDAPSetup
          Ubuntu ServerGuide https://code.launchpad.net/serverguide
          OpenLDAP-Oficial http://www.openldap.org/doc/admin24/index.html
          LDAP over SSL/TLS and StartTLS http://tt4cs.wordpress.com/2014/01/18/ldap-over-ssltls-and-starttls/

          Y además, consulté la documentación acompañante que se instala con cada paquete.

          El tema de la seguridad en general y de las diferencias entre StartTLS y TLS/SSL, son muy técnicos y de una profundidad tal que no me considero con los conocimientos necesarios para dar ese tipo de explicaciones. Pienso que podemos seguir conversando vía e-mail.

          Por otra parte, en ningún lugar afirmo que NO pueda usarse LDAPS://. Si lo consideras más seguro, pues adelante !!!.

          Más no puedo ayudarte y agradezco mucho tus comentarios.

        2.    federico dijo

          Un poco más de claridad puedes obtener -siempre sobre OpenLDAP- en:
          http://www.openldap.org/faq/data/cache/605.html

          The StartTLS extended operation [RFC 2830] is LDAPv3’s standard mechanism for enabling TLS (SSL) data confidentiality protection. The mechanism uses an LDAPv3 extended operation to establish an encrypted SSL/TLS connection within an already established LDAP connection. While the mechanism is designed for use with TLSv1, most implementations will fallback to SSLv3 (and SSLv2) if necessary.

          ldaps:// is a mechanism for establishing an encrypted SSL/TLS connection for LDAP. It requires use of separate port, commonly 636. Though originally designed for use with LDAPv2 and SSLv2, many implementations support its use with LDAPv3 and TLSv1. Although there is no technical specification for ldaps:// it is widely used.

          ldaps:// is deprecated in favor of Start TLS [RFC2830]. OpenLDAP 2.0 supports both.
          For security reasons the server should be configured not to accept SSLv2.

  3.   freebsddick dijo

    Este sera uno de esos articulos en los cuales los usuarios no comentaran porque como solo ven porno en sus estaciones Linux simplemente no les interesa.. A proposito de ldap tengo varios servicios relacionados dentro de la red heterogenea para la empresa en la que trabajo. Buen articulo!!

    1.    federico dijo

      Gracias por comentar !!!. Y muy cierta tu afirmación en cuanto a los pocos comentarios en muchos de mis artículos. Sin embargo, recibo correspondencia de lectores interesados, o de otros que descargan el artículo para su posterior lectura y aplicación.

      Siempre es muy útil tener retroalimentación mediante los comentarios, aunque sean: lo guardé para una posterior lectura, interesante, u otro parecer.

      Saludos

  4.   federico dijo

    El Freeke !!! Gracias por comentar. Recibí tu comentario por correo pero no lo veo aunque refresque la página varias veces. Amigo, puede probar éste y los anteriores artículos sin problemas en Squeeze o en Ubuntu Server 12.04. En Wheezy los certificados se generan de forma diferente, mediante el OpenSSL. Más nada. Saludos hermano !!!.

  5.   federico dijo

    @thisnameisfalse: AL mejor escribano se le va un borrón. Gracias a tus comentarios, creo que el párrafo de marras, debe quedar de la siguiente forma:

    Los servidores OpenLDAP modernos perfieren el uso de StartTLS o Iniciar una Capa Segura de Transporte, al protocolo LDAPS://, el cual está obsoleto. Cualquier duda, visite Start TLS v. ldaps:// en http://www.openldap.org/faq/data/cache/605.html

    Saludos

  6.   jose monge dijo

    Perfecto, justo en este momento tengo tarea sobre ldap

  7.   walter dijo

    no se puede meter todo en un solo archivo asi se puede bajar el tuto completo

  8.   eVeR dijo

    Soy técnico en Informática con amplia experiencia en Linux y aun así me perdí por la mitad del artículo. Después lo voy a releer con mas detenimiento. Muchas gracias por el tuto.
    Aunque es verdad que nos permite comprender mucho mas por que se suele elegir ActiveDirectory para estas cosas. Hay un universo de diferencia en cuando a simplicidad de configuración e implementación.
    Saludos

  9.   federico dijo

    Gracias a todos por comentar !!!
    @jose monge, espero te sirva de utilidad
    @walter al final de todos los posts, veré si puedo hacer un compendio en formato html o pdf
    @eVeR al revés, es más sencillo -aunque parezca que no- un OpenLDAP que un Active Directory. espera los próximos artículos y verás.

  10.   Marcelo dijo

    Una consulta, hago paso a paso la instalacion pero al reiniciar el servicio slapd, me tira el siguiente error>

    Jul 30 15:27:37 xxxx slapd[1219]: @(#) $OpenLDAP: slapd (Ubuntu) (Mar 17 2014 21:20:08) $#012#011buildd@aatxe:/build/buildd/openldap-2.4.31/debian/build/servers/slapd
    Jul 30 15:27:37 xxxxx slapd[1219]: UNKNOWN attributeDescription “CHANGETYPE” inserted.
    Jul 30 15:27:37 xxxxx slapd[1219]: UNKNOWN attributeDescription “ADD” inserted.
    Jul 30 15:27:37 xxxxx[1219]: <= str2entry: slap_str2undef_ad(-): empty AttributeDescription
    Jul 30 15:27:37 xxxxx slapd[1219]: slapd stopped.
    Jul 30 15:27:37 xxxxx [1219]: connections_destroy: nothing to destroy.

    1.    x11tete11x dijo

      podes preguntar en el foro 😀 http://foro.desdelinux.net/

  11.   pedrop dijo

    Para todo el que vea este excelente y bien explicado post y le suceda este problema a la hora de crear las ACLs:
    ldapmodify: invalid format (line 5) entry: “olcDatabase={1}hdb,dc=config”

    Luego de rajarme la cabeza buscando en internet, resulta que ldapmodify es el tipo m’as exacto que hay sobre la faz de la web. Es histérico con los caracteres fuera de lugar así como los espacios al final (trailing space). Sin más dilación, el consejo es escribir la condición by una al lado de la otra o sea by X write by self write by * read. Si aún no funciona instalar el Notepad++ > Vista > Mostrar símbolo y por fin muerte a los caracteres invisibles. Espero que a alguien le sirva de ayuda.

  12.   pedrop dijo

    Generar los certificados para Debian Wheezy basado en OpenSSL esto puede servir:
    http://blog.phenobarbital.info/2014/10/openldap-tlsssl-configuracion-basica-y-aseguramiento/

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.