Mostrando entradas con la etiqueta OpenLDAP. Mostrar todas las entradas
Mostrando entradas con la etiqueta OpenLDAP. Mostrar todas las entradas
Configurar slaves OpenLDAP para aplicar lock de usuarios por logins fallidos (ppolicy)
Quienes utilicen LDAP para autenticación de servidores/workstations, seguramente se han topado o se toparan con el overlay ppolicy, el cual permite configurar policies de password como largo mínimo, complegidad, history, lock por cantidad de intentos, etc. Cómo habilitar y configurar ppolicy está bastante bien explicado en diversos sites como este, por lo que no lo incluiré acá. El problema es que ninguno explica bien qué hacer si tenes servidores slave que se utilizan para autenticación.

Cuando tenés una configuración master -> slaves, los slaves son read-only, por lo que no guardarán ningún atributo por si mismos, sino que replican lo que tiene el master. Esto es, si por ejemplo están utilizando un slave como ldap server, varios intentos fallidos de login nunca bloquearán la cuenta, porque el tipo no guardará el atributo pwdAccountLockedTime en ningún lado. Esto es lo mismo que sucede cuando intentan hacer un change password y están usando un slave, el pass no se puede cambiar.

Para solucionar este problema, OpenLDAP provee la alternativa de que los slave redirijan los updates al master. Esto es, si alguien quiere actualizar un valor en el slave, el slave redirigirá el update al ldap master, y lo obtendrá por replicación. La solución comprende utilizar updateref, enconjunto con el overlay chain y la opción ppolicy_forward_updates, donde:
  • updateref "<master ldap server>" indica a qué servidor LDAP enviar los updates (se utiliza sólo en slaves). Esta opción por sí sola retorna al cliente la URL del master ldap, y es el cliente quien se debe encargar de tomar esa URL y hacer el update allí.
  • El overlay chain facilita lo anterior, haciendo que el update lo haga el mismo slave, en lugar de retornar la URL del master al cliente. Con chain podemos configurar que si alguna acción dispara un update, el slave se conecte al master y lo aplique. Para ello, hay que configurar un usuario de binding que en el master tenga permisos de escritura para los atributos que deberá actualizar. Este overlay también se usa para resolver DNs que no están replicados en el slave, ya que sin él, OpenLDAP retornará un redirect que el cliente final deberá seguir.
  • ppolicy_forward_updates es la opción del overlay ppolicy que le indica que debe forwardear los password failures, ya que sino asume que es un master y no dispara el hook de redirect.

Veamos todo junto en un ejemplo, donde el ldap master se llama masterserver.dvpem.org. Esta config es para el slave y va en slapd.conf. Incluí sólo las líneas relevantes de la configuración, no es una configuración slapd.conf completa.

IMPORTANTE:
  • La configuración del overlay chain debe ir lo más arriba posible, antes de la configuración de cualquier base de datos y de la configuración de replicación.
  • updateref debe ir luego de la configuración de replicación (syncrelp).
  • El usuario que utilicen para el overlay chain debe tener permiso manage sobre los atributos de password. Por ejemplo, este es el permiso necesario para un user SlaveUpdater:
    {0}to dn.subtree="ou=people,dc=dvpem,dc=org" attrs=pwdChangedTime,pwdAccountLockedTime,pwdFailureTime,pwdHistory,pwdGraceUseTime,pwdReset by dn.base="cn=SlaveUpdater,dc=dvpem,dc=org" manage by * +0 break
...
#importamos el módulo que contiene el overlay chain
moduleload back_ldap.la

#cargamos el overlay
overlay chain
#definimos cuál es la URL del master y con qué usuario bindear. Recuerden que el user debe tener permiso manage.
chain-uri "ldap://masterserver.dvpem.org"
chain-idassert-bind     bindmethod="simple"
                        binddn="cn=SlaveUpdater,dc=dvpem,dc=org"
                        credentials="elpassdeSlaveUpdater"
                        mode="self"
                        #starttls=yes        #necesario si usamos ldaps como protocolo
                        #tls_reqcert=allow   #necesario si usamos ldaps como protocolo
chain-return-error TRUE

...
...

#cargamos el overlay ppolicy
moduleload ppolicy.la
overlay ppolicy

#indicamos dónde está la pólicy default de password (largo, cantidad de intentos, etc). Misma config que en el master.
ppolicy_default "cn=default,ou=Policies,dc=dvpem,dc=org"

#indicamos que se deben forwardear los updates al master
ppolicy_forward_updates

...
...

#configuración estándar syncrelp
syncrelp rid=001
    provider=ldap://masterserver.dvpem.org
    type=refreshAndPersist
    interval=00:00:02:00
    retry="30 10 120 +"
    searchbase="dc=dvpem,dc=org"
    attrs="*,+"
    bindmethod=simple
    binddn="cn=replicator,dc=dvpem,dc=org"
    credentials=elpassdelreplicator
    tls_reqcert=allow

#especificamos a dónde redirigir los updates
updateref "ldap://masterserver.dvpem.org"

Si tienen configurado el slave para utilizar la base cn=config, deberán ejecutar el diguiente ldif (aquí lo llamo enable-ppolicy-forward.ldif):
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: back_ldap

dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {0}chain
olcChainCacheURI: FALSE
olcChainMaxReferralDepth: 1
olcChainReturnError: TRUE

dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
changetype: add
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: ldap
olcDbURI: "ldaps://masterserver.dvpem.org"
olcDbStartTLS: none  starttls=no
olcDbIDAssertBind: mode=self
  flags=prescriptive,proxy-authz-non-critical 
  bindmethod=simple
  timeout=0
  network-timeout=0
  binddn="cn=SlaveUpdater,dc=dvpem,dc=org"
  credentials="elpassdeSlaveUpdater"
  keepalive=0:0:0
  starttls=yes
  tls_cert="/etc/ldap/ssl/certificado.pem"
  tls_key="/etc/ldap/ssl/certificado.pem"
  tls_cacert="/etc/ldap/ssl/certificado.pem"
  tls_reqcert=allow
  tls_cipher_suite=NORMAL
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcUpdateRef
olcUpdateRef: ldaps://masterserver.dvpem.org

dn: olcOverlay={0}ppolicy,olcDatabase={1}hdb,cn=config
changetype: modify
replace: olcPPolicyForwardUpdates
olcPPolicyForwardUpdates: TRUE

Ejecutamos el ldif con ldapmodify (cambien el usuario admin por el que corresponda a ustedes):
ldapmodify -D "cn=admin,cn=config" -W -f enable-ppolicy-forward.ldif

Como siempre, espero que les haya resultado útil. Yo perdí un buen rato hasta entender cómo funciona esta lógica.
OpenLDAP kerberizado
Hasta ahora se mostró como utilizar OpenLDAP con autenticación anónima, es decir, sin autenticación (ver Instalar y configurar el directorio OpenLDAP  y Autenticar con kerberos y almacenar información de usuarios con LDAP en GNU/Linux). Si bien este modelo puede servir en algunos casos donde el servicio de directorio es público, en general se desea que la información sea accesible sólo para ciertos usuarios. De las autenticaciones soportadas en LDAP, la más segura es SASL-GSSAPI con kerberos y sobre conexión encriptada.
En este artículo veremos cómo utilizar GSSAPI, y cómo definir los accesos al directorio en base a los usuarios autenticados con kerberos para obtener una estructura de usuarios centralizada con autenticación segura, similar a Active Directory.
Con esto cierro la serie de artículos Autenticación y administración centralizada de usuarios en GNU/Linux, la cual comencé a publicar en julio del año pasado y contempla todos los pasos necesarios para armar dicha estructura. En el artículo principal pueden encontrar los links a todos los artículos de la serie.


Autenticar con SASL-GSSAPI kerberos

Para poder utilizar SASL-GSSAPI en LDAP, es necesario instalar el API Cyrus SASL compilado para el kerberos de MIT, tanto en el servidor como en clientes:
# apt-get install libsasl2-modules-gssapi-mit

Como vimos en la descripción de kerberos, cada servicio que desee kerberizarse deberá tener un principal en la base de datos. Entonces, para poder utilizar GSSAPI con kerberos necesitamos crear el principal correspondiente. Esto se logra utilizando kadmin o kadmin.local de la siguiente manera:
# kadmin.local
Authenticating as principal root/admin@DEMASIADOVIVO.ORG with password.
kadmin.local: addprinc -randkey ldap/ldap01.demasiadovivo.org@DEMASIADOVIVO.ORG
WARNING: no policy specified for ldap/ldap01.demasiadovivo.org@DEMASIADOVIVO.ORG; defaulting to no policy
Principal "ldap/ldap01.demasiadovivo.org@DEMASIADOVIVO.ORG" created.
donde ldap01.demasiadovivo.org es la dirección del servidor ldap y -randkey permite generar un password random.
El siguiente paso es guardar la clave del principal recién creado en un archivo (keytab), el cual luego se utilizará desde OpeLDAP para la autenticación:
kadmin.local: ktadd -k /root/ldap.keytab ldap/ldap01.demasiadovivo.org
Entry for principal ldap/ldap01.demasiadovivo.org with kvno 5, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/root/ldap.keytab.
Entry for principal ldap/ldap01.demasiadovivo.org with kvno 5, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/root/ldap.keytab.
Entry for principal ldap/ldap01.demasiadovivo.org with kvno 5, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/root/ldap.keytab.
Entry for principal ldap/ldap01.demasiadovivo.org with kvno 5, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/root/ldap.keytab.
Si no especifican el nombre del archivo (-k), la clave se escribe en /etc/krb5.keytab. Esto no es aconsejable porque este archivo será utilizado por OpenLDAP, para lo cual debemos darle permiso de lectura/escritura, y al hacerlo, le damos acceso a todas las claves que se encuentren en el. Por ello, es mejor separar la clave de OpenLDAP en un archivo propio.

Una vez creado el principal y exportado a un archivo, hay que copiar el mismo al servidor donde se encuentre OpenLDAP y darle permiso de lectura/escritura al usuario openldap, que es el usuario con el que se ejecuta el servicio. Un buen lugar para ubicar el archivo es dentro del mismo directorio de ldap.
/etc/ldap# chown openldap:openldap ldap.keytab
/etc/ldap# chmod 750 ldap.keytab
A continuación hay que editar el archivo /etc/default/slapd para indicar donde se encuentra el keytab para utilizar con SASL, ya que por default intentará usar /etc/krb5.keytab. Esto se hace editando o agregando la siguiente línea:
export KRB5_KTNAME=/etc/ldap/ldap.keytab

OpenLDAP mapea los principals de kerberos a DNs especiales, que tienen el siguiente formato:
uid=<nombre de="" usuario="">,cn=<realm>,cn=<mecanismo>,cn=auth
<nombre de="" usuario=""><realm><mecanismo>
<nombre de="" usuario=""><realm><mecanismo>
o
<nombre de="" usuario=""><realm><mecanismo> uid=<nombre de="" usuario="">,cn=<mecanismo>,cn=auth
<nombre de="" usuario=""><realm><mecanismo><nombre de="" usuario=""><mecanismo>
Por ejemplo, si el principal es demasiadovivo@DEMASIADOVIVO.ORG, éste se mapeará con el DN:
uid=demasiadovivo,cn=DEMASIADOVIVO.ORG,cn=gssapi,cn=auth
es decir, para poder utilizar autenticación kerberos en LDAP, debe existir una entrada en el directorio con el formato mostrado.

Si están utilizando LDAP como directorio de usuarios, el formato de los DN para estos usuarios (uid=demasiadovivo,ou=People,dc=demasiadovivo,dc=org) es muy diferente al recién mostrado (uid=demasiadovivo,cn=DEMASIADOVIVO.ORG,cn=gssapi,cn=auth). Esta diferencia se debe a que una entrada es para usuarios de LDAP y el otro es para usuarios almacenados en LDAP. Una entrada es para autenticar quién es el usuario y qué puede hacer en el directorio, y la otra es para almacenar datos de un usuario.
En el caso de utilizar autenticación kerberos y tomar los datos del usuario de LDAP con NSS, ambos usuarios son el mismo usuario, entonces se necesita una forma de mapearlos.
Para esto, OpenLDAP provee reemplazo de nombres de autenticación utilizando expresiones regulares. Esto es, en lugar de tener que definir dos entradas para el mismo usuario, es posible definir la entrada con los datos del usuario y mapear el DN de autenticación al DN real. La forma de hacerlo es ingresando una regla authz-regexp en el archivo slapd.conf (/usr/share/slapd/slapd.conf en debian). La directiva utiliza dos parámetros:
authz-regexp <patron buscado=""> <patron de="" reemplazo="">
Entonces, ingresando la siguiente regla, se tiene el reemplazo buscado:
authz-regexp
    uid=([^,]*),cn=DEMASIADOVIVO.ORG,cn=gssapi,cn=auth
    uid=$1,cn=People,dc=demasiadovivo,dc=org
Finalmente hay que reiniciar el servicio slapd para que tome los cambios:
# /etc/init/slapd restart
Para probar que la autenticación funciona, adquirimos un token y ejecutamos un ldapwhoami:
$ kinit demasiadovivo
Password for demasiadovivo@DEMASIADOVIVO.ORG:
$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: demasiadovivo@DEMASIADOVIVO.ORG:
SASL SSF: 56
SASL data security layer installed.
dn:uid=demasiadovivo,cn=gssapi,cn=auth
CUIDADO: Asegúrense de que el servidor LDAP tiene resolución DNS inversa (registro PTR), caso contrario pueden encontrarse con un error como el siguiente:
Cannot determine realm for numeric host address
Para ver los mecanismos de autenticación habilitados, se puede ejecutar:
$ ldapsearch -s base -b "" supportedSASLMechanisms

Configurar permisos para acceder LDAP

Hasta ahora la configuración cuenta con autenticación GSSAPI-kerberos que es mucho mejor a tener autenticación simple, o no tener autenticación, pero todavía no se definió ningún rol de usuario que determine qué usuario puede hacer qué.
Por default OpenLDAP cuenta con el usuario admin que posee control total sobre el directorio, y se autentica utilizando autenticación simple con password. Además cuenta con un perfil público a través del cual cualquier persona, utilizando autenticación simple, puede leer los datos del directorio. Como se mostró en el artículo de instalación y configuración de LDAP, estos permisos se pueden observar ejecutando:

# slapcat -b cn=config -a olcDatabase={1}hdb
Como la autenticación la realizaremos a través de kerberos, una configuración interesante es permitir acceso de lectura de atributos no confidenciales a todo usuario autenticado mediante kerberos (en lugar de acceso anónimo), y acceso total a un grupo administrador, cuyos miembros sean usuarios autorizados y autenticados con kerberos.
Para lograr esta configuración, los pasos a realizar son los siguientes:

1. Eliminar al usuario admin y accesos default.
2. Crear un grupo administrador de dominio.
3. Otorgar control total al grupo del paso anterior (como suele ser el grupo Domain Admins en Active Directory).
4. Asignar acceso de lectura a usuarios autenticados.


1. Eliminar usuario admin y accesos default

Por defecto, OpenLDAP provee acceso de escritura para el usuario admin y de lectura sin autenticación. En la configuración de un servicio centralizado de usuarios con kerberos, estos accesos son poco flexibles e inseguros, por lo tanto hay que eliminarlos, y luego plantear nuevos accesos que utilicen usuarios autenticados con kerberos.
Al utilizar la estructura kerberos, los atributos userPassword y shadowLastChange no son necesarios, por lo que se puede eliminar dicho acceso.

Para lograr este objetivo, crear el siguiente LDIF llamado delete-default.ldif:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
#
# Eliminar acceso al usuario admin
delete: olcAccess
olcAccess: {2}to *
by self write
by dn="cn=admin,dc=dvpem,dc=org" write
by * read
-
# Eliminar acceso de lectura sin autenticacion
delete: olcAccess
olcAccess: {1}to dn.base=""
by * read
-
# Eliminar accesos a los atributos password de los usuarios
delete: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange
by self write
by anonymous auth
by dn="cn=admin,dc=dvpem,dc=org" write
by * none
-
# Prohibir acceso al atributo password
add: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange
by * none
-
# Eliminar el usuario admin
delete: olcRootPW
-
y ejecutar el comando:
$ ldapmodify -f delete-default.ldif -x -D cn=admin,cn=config -W
Se puede verificar que todo salió como se deseaba con el comando:
# slapcat -b cn=config -a olcDatabase={1}hdb

2. Crear grupo administrador del dominio

Como muchos sabrán, en Active Directory existe un grupo denominado Domain Admins, el cual tiene permiso de administración sobre todo el directorio y las máquinas unidas al dominio.
En el caso del dominio que se está configurando, es muy útil tener un grupo con las mismas características, que permita administrar el directorio. El siguiente LDIF denominado domain-root.ldif crea dicho grupo, cuyo único miembro (por ahora) es el usuario demasiadovivo:

dn: cn=domain_root,ou=Group,dc=demasiadovivo,dc=org
cn: domain_root
gidNumber: 1000
objectClass: top
objectClass: posixGroup
memberUid: demasiadovivo
Como todavía el único usuario con permiso de administración es admin, se debe utilizar el mismo con la herramienta ldapadd:
$ ldapadd -x -D cn=admin,cn=config -W -f domain-root.ldif
Enter LDAP Password:
adding new entry "cn=domain_root,ou=Group,dc=demasiadovivo,dc=org"

3. Otorgar control total al grupo domain_root sobre el directorio

Este punto es uno de los más complejos. Como vimos, OpenLDAP es muy flexible en cuanto a otorgar permisos y posee una facilidad para otorgar permisos por grupo (by group). El problema es que este se aplica a la clase groupOfNames y no sirve para posixGroup.
Se me ocurrieron varias alternativas para solucionar este problema:

1- Utilizar groupOfNames y mapear los request NSS_LDAP con una expresión regular que sustituya los pedidos, como se mostró en la sección anterior.
2- Editar el esquema de posixGroup para agregar el atributo member.
3- Utilizar la definición de posixGroup del RFC 2307bis, la cual expiró y nunca se aprobó. Esta RFC incluye el campo member en la definición.
4- Otorgar permisos basados en sets.
5- Cambiar el formato de las consultas LDAP de la librería NSS_LDAP para que utilice groupOfNames.
Como se puede observar, opciones hay, pero ninguna satisfactoria del todo. Yo opté por la 4ta, dado que encontré una buena definición del permiso por parte de Pierangelo Masarati. De todas, creo que es la que menos complicaciones trae, al menos para este setup inicial. Si bien el acceso que defino a continuación tiene la misma base que el de Pierangelo, tuve que cambiar el DN del conjunto, porque el original no me funcionó.

Para el permiso definimos el siguiente LDIF denominado domain_root-access.ldif:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {0}to dn.subtree="dc=demasiadovivo,dc=org"
by set="([uid=] + ([cn=domain_root,ou=Group,dc=demasiadovivo,dc=org])/memberUid + [,cn=gssapi,cn=auth])/entryDN & user" write
Al principio puede resultar confuso, pero analicemos un poco qué es lo que se está haciendo.
En la primer línea se indica que se está otorgando permiso a todo el dominio demasiadovivo.org. dn.subtree es el scope, e indica que se aplique a todo lo que contiene el dominio.
En la segunda línea se indica a quién se otorga el permiso y qué tipo de permiso (write). Esta es la parte más confusa.
Primero hay que entender qué es lo que se desea otorgar. Lo que debemos hacer es otorgar permiso de escritura a todos los miembros del grupo domain_root. Los miembros se obtienen del atributo memberUid, pero este atributo no es un DN, sino sólo el nombre del usuario. Como el permiso debe otorgarse a un DN, primero hay que armarlo.
El DN de un usuario consta de uid=,cn=gssapi,cn=auth. Lo único que tenemos es el nombre de usuario, por lo tanto, hay que armar el resto del string (los strings se concatenan con el signo +). Para hacerlo se utilizan los siguientes valores:

  • [uid=], para agregar el string uid=
  • ([cn=domain_root,ou=Groups,dc=demasiadovivo,dc=org])/memberUid para agregar el nombre de usuario de los miembros del grupo. Se utilizan los parentesis porque los mismos indican precedencia, de esta forma se evalúa primero el grupo y luego se obtienen los miembros.
  • [,cn=gssapi,cn=auth] para agregar la parte restante del DN
Para obtener el DN definitivo, se encierra todo entre paréntesis y se obtiene el atributo entryDN. El resultado es la lista de todos los usuarios que integran el grupo domain_root. Este conjunto se intersecta (operador &) con la base "user" que referencia al usuario autenticado actualmente. La intersección retornará el DN del usuario, si el usuario está en el grupo, o vacío si no lo está, otorgando o negando el permiso.

Para agregar este nuevo acceso, utilizar ldapmodify con el usuario administrador de la base de datos de configuración (cn=admin,cn=config):

$ ldapmodify -f domain_root-access.ldif -x -D cn=admin,cn=config -W

4. Asignar acceso de lectura a usuarios autenticados

Llegado este punto, ya tenemos el grupo de administración del dominio, pero no los accesos de lectura para que los usuarios lean las entradas. Esto se logra definiendo el siguiente LDIF denominado read-access.ldif:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {1}to *
by users read
by * none
que se agrega con:
$ ldapmodify -f read-access.ldif -x -D cn=admin,cn=config -W

Configurar las máquinas cliente para usar GSSAPI

De la configuración anterior tenemos que ahora sólo se puede consultar al servidor LDAP si el cliente se autenticó previamente ante kerberos. Debido a esto, hay que configurar NSS-LDAP de forma especial, para que el servicio pueda consultar el directorio y obtener los datos del usuario que se está autenticando.
Hasta ahora, cuando un usuario se autentica ante el sistema, primero PAM valida las credenciales con kerberos, y luego NSS se conecta de forma anónima al servidor LDAP para traer los datos del usuario. Como ahora no es posible obtener datos de forma anónima, es necesario que NSS utilice GSSAPI con un ticket kerberos. El problema es qué ticket utilizar? dado que no podemos utilizar el ticket que se obtiene al validar al usuario.

Para solucionar este problema, es necesario realizar los siguientes pasos:

1. crear un principal por cada host,
2. exportar la clave de cada principal a keytabs,
3. mover cada keytab al host correspondiente,
4. configurar NSS de cada host para utilizar kerberos y realizar la autenticación con el keytab correspondiente.

Crear principal para host y exportar clave en keytab

Para crear el principal del host maquina01 y exportarlo en el keytab maquina01.keytab, nuevamente hacemos uso de la herramienta kadmin.local (o kadmin si se conectan remoto), y ejecutamos lo siguiente:

kadmin.local: addprinc -randkey host/maquina01.dvpem.org@DVPEM.ORG
WARNING: no policy specified for host/maquina01.dvpem.org@DVPEM.ORG; defaulting to no policy
Principal "host/maquina01.dvpem.org@DVPEM.ORG" created.
kadmin.local: ktadd -k /root/maquina01.keytab host/maquina01.dvpem.org
Entry for principal host/maquina01.dvpem.org with kvno 2, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/root/maquina01.keytab.
Entry for principal host/maquina01.dvpem.org with kvno 2, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/root/maquina01.keytab.
Entry for principal host/maquina01.dvpem.org with kvno 2, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/root/maquina01.keytab.
Entry for principal host/maquina01.dvpem.org with kvno 2, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/root/maquina01.keytab.
Se utiliza -randkey para generar una clave aleatoria, dado que se utilizará directamente desde el archivo maquina01.keytab.

El paso anterior podría haberse realizado directamente desde el host maquina01, utilizando el comando kadmin y descargando la clave a un keytab local (/etc/krb5.keytab). En resultado es el mismo.


Configurar NSS-LDAP para utilizar kerberos en los clientes

Una vez generado el principal del host maquina01, hay que mover el keytab recién creado al host correspondiente. Un buen lugar para colocar el keytab es en /etc/krb5.keytab, que es el archivo default de kerberos. Por seguridad, el archivo debe poseer permisos 640:

# chmod 640 /etc/krb5.keytab
Con la clave en su lugar, procedemos a configurar NSS-LDAP. En debian el archivo de configuración se encuentra en /etc/nslcd.conf. En dicho archivo se deben agregar las siguientes líneas:
sasl_mech gssapi
krb5_ccname FILE:/tmp/krb5cc_0

donde:

- sasl_mech indica el mecanismo SASL a utilizar (GSSAPI)
- krb5_ccname informa donde se encuentra el ticket kerberos
Una vez especificados los parámetros anteriores, nslcd comenzará a utilizar k5start para obtener el ticket del host antes de acceder a LDAP. Este demonio permite configurar algunos aspectos de cómo utilizar k5start a través del archivo /etc/default/nslcd. En el mismo se puede forzar la ejecución de k5start, como configurar la ubicación de la clave, el nombre del principal, y cada cuánto refrescar el ticket. La configuración por default es buena para la mayoría de los casos, aunque recomiendo agregar las siguientes líneas:
K5START_START="yes"
K5START_PRINCIPAL="host/maquina01.dvpem.org"
donde K5START_START="yes" fuerza el uso de k5start, y K5START_PRINCIPAL="host/maquina01.dvpem.org" indica cuál es el nombre del principal.
Si todavía no tienen instalado kstart, pueden hacerlo con:

# apt-get install kstart
Al finalizar la configuración, reiniciar el demonio nslcd para que tome los cambios:
# /etc/init.d/nslcd restart
Para probar, simplemente realizar un login con una cuenta que esté definida en LDAP. También pueden ver que se consulta LDAP al utilizar el comando:
$ getent passwd
En caso de que no esté funcionando y debamos revisar la configuración, primero detener el demonio nscd, dado que este cachea los resultados de las consultas, y por lo tanto, el resultado que se obtiene puede no ser el real:
# /etc/init.d/nscd stop
Luego revisar los siguientes logs:
- en el cliente:
/var/log/auth.log
- en el servidor:
/var/log/debug
Otra ayuda es observar en el cliente si el proceso login se conecta al servidor LDAP al momento de autenticar, con el siguiente comando:
# lsof -r 2 -i
donde:
-r 2 pone lsof en modo repetición. De esta forma lsof lista lo seleccionado por otros argumentos, espera 2 segundos y vuelve a listar.
-i lista los procesos que estan escuchando en sockets tcp o udp.

Referencias

- OpenLDAP - 15. Using SASL 

- LDAP, Kerberos 5, SASL and Passwords 
- Debian OpenLDAP with Kerberos Authentication
- Red Hat Documentation - 10.2.6. Setting Up Kerberos Authentication
- OpenLDAP - 5. Configuring slapd
- LDAP Administration Guide
- OpenLDAP FAQ - Sets in Access Controls
- Integrated Kerberos-OpenLDAP client on Debian lenny
- Configuring LDAP Authentication

- FreeBSD Forum - nss_ldap sasl gssapi authentication?
- RedHat mailing list - nss_ldap using sasl with gssapi. Kerberos credentials cache problem[Scanned]
Instalar y configurar el directorio OpenLDAP
Existe una interesante variedad de directorios LDAP disponibles en GNU/Linux, siendo algunos de los más importantes OpenLDAP, 389 Directory Server, OpenDS y Apache Directory. Si bien todos presentan características similares, elegí utilizar OpenLDAP por ser el más antiguo, existe mucha información al respecto, es muy flexible, y está disponible en los repositorios de las distribuciones más importantes.
A continuación describiré cómo instalar y configurar OpenLDAP. Si bien mi trabajo fue realizado en debian, no debería variar demasiado en otras distribuciones.


Instalación

En debian y derivados, instalar OpenLDAP es tan simple como ejecutar:
# apt-get install slapd ldap-utils
donde slapd es el demonio que provee la funcionalidad ldap, y ldap-utils contiene un set de herramientas para administrar y testear el server.

Durante el proceso de instalación, el configurador del paquete (debconf) requerirá los siguientes datos básicos:
  • Nombre DNS de nuestro dominio (ej: demasiadovivo.org).
  • Nombre de la organización a utilizar en el DN base. En general utilizarán el mismo que el nombre DNS (ej: demasiadovivo.org).
  • Contraseña del administrador.
  • Base de datos de fondo para almacenar los datos LDAP. Si bien openLDAP acepta distintas bases de datos, es recomendable utilizar la de Berkeley (BDB) que no es una BD relacional, sino una que permite almacenar varios items por cada clave y logra mejor performance en casos de muchas lecturas y pocas escrituras. Todo esto encaja perfecto con LDAP, porque son justamente estos los atributos de un directorio.
  • Remover la base de datos cuando el paquete slapd se purgue? es buena idea setear que no, así no borramos accidentalmente la base de datos LDAP.
  • Permitir el protocolo LDAPv2? esto dependerá de los clientes que estemos utilizando. Dado que LDAPv3 ya esta muy maduro e implementado en la mayoría de los sistemas, lo mejor es decir no a esta pregunta.
En debian 6 (squeeze) el archivo de configuración del demonio OpenLDAP se encuentra en /usr/share/slapd/slapd.conf. En otras distribuciones puede encontrarse en /etc/ldap/slapd.conf, /etc/openldap/slapd.conf o /usr/local/etc/openldap/slapd.conf. En dicho archivo podrán ver que se importan archivos que contienen los esquemas básicos, así como configuración de permisos para escribir y leer registros, tipo de base de datos, ubicación de la base de datos (/var/lib/ldap en debian), el nivel de logging, y varias cosas más.

Una vez instalado el paquete, podemos probar si el servidor se instaló y configuró correctamente, utilizando ldapsearch. ldapsearch es una herramienta que nos servirá mucho para testear la configuración del servidor y, como su nombre lo indica, sirve para hacer búsquedas dentro de directorio.
Para realizar la prueba, pediremos todos los objetos que se encuentren en el servidor:
ldapsearch -b dc=demasiadovivo,dc=org -H ldap://localhost -x
donde:
  -b indica el DN base done iniciar la búsqueda
  -H es para ingresar la URI del server
  -x indica que utilice autenticación simple
Como no utilizamos ningún fitro y no indicamos qué atributos traer, ldapsearch traerá todo.


ldap.conf

Para evitar tener que ingresar los datos referentes al DN base y la URI o dirección de servidor en cada conexión con el servidor ldap, podemos almacenar esta información en el archivo /etc/ldap.conf
ldap.conf se utiliza para configuraciones default concernientes a los clientes ldap. Los dos valores más utilizados son URI y BASE, que sirven justamente para lo explicado en el párrafo anterior. Un ejemplo de este archivo es el siguiente:
URI    ldap://demasiadovivo.org ldaps://demasiadovivo.org
BASE    dc=demasiadovivo,dc=org
Con esto nos evitamos, por ejemplo, los parámetros -b y -H en ldapsearch =)


Agregar, modificar, y eliminar entradas del directorio

Los datos LDAP son intercambiados utilizando un formato de texto plano denominado LDIF (LDAP Data Interchange Format). Utilizando archivos LDIF podemos agregar, modificar, elminar y renombrar entradas del directorio.
Cada entrada (registro) continee un conjunto de atributos y están separadas por líneas en blanco. Ya vimos ejemplos de este formato cuando utilizamos ldapsearch para testear el servicio.
Para editar la información del directorio, simplemente creamos un archivo ldif y utilizamos la herramienta ldapadd o ldapmodify. Para eliminar entradas, se utiliza ldapdelete.

En secciones anteriores vimos que la estructura del árbol del directorio se puede armar en base a unidades organizativas (organizational units - OU), algo muy común en sistemas de usuarios centralizado (Active Directory, y GNU/Linux con NSS-LDAP y PAM). Las OU básicas de un sistema de usuarios centralizado son People y Group. Podemos crear estas OUs utilizando un archivo ou.ldif que contenga:
dn: ou=People,dc=demasiadovivo,dc=org
ou: People
objectClass: organizationalUnit

dn: ou=Group,dc=demasiadovivo,dc=org
ou: Group
objectClass: organizationalUnit
y luego ejecutando ldapadd de la siguiente forma:
$ ldapadd -c -x -D cn=admin,dc=dvpem,dc=org -W -f ou.ldif
donde:
-c indica que continúe procesando si encuentra errores
-x indica que utilice autenticación simple
-D setea el DN con el cual realizar el bind (usuario de autenticación)
-W pide el password
-f permite importar los datos del archivo
Como se observa, con -x -D cn=admin,dc=dvpem,dc=org -W realizamos la autenticación con el usuario admin, dado que con acceso anónimo no es posible modificar registros de la base de datos. Más adelante veremos cómo autenticar utilizando SASL en lugar de autenticación simple.

Podemos ver el resultado ejecutando la siguiente búsqueda:
$ ldapsearch -x ou=People
$ ldapsearch -x ou=Group

Modificar la configuración

La configuración del servicio LDAP se almacena en el archivo slapd.conf, pero si se desea hacer cambios en en la misma, una vez que se actualiza dicho archivo, es necesario reiniciar el demonio slapd, algo que es muy contraproducente en un sistema que está en producción atendiendo cientos o miles de consultas. Por suerte, desde la versión 2.3 de OpenLDAP, es posible editar la configuración online. A partir de dicha versión, la configuración se almacena una base de datos separada, con un esquema y DIT predefinidos (cuyo base DN es cn=config), y la cual se encuentra en el directorio slapd.d (en debian /etc/ldap/slapd.d/). Esta base de datos posee administración en tiempo de ejecución a través de operaciones LDAP con datos en formato LDIF y se puede acceder y editar a través del conjunto de herramientas slapacl, slapadd, slapauth, slapcat, slapdn y slaptest.
Para ver las entradas de configuración, se puede utilizar slapcat de la misma manera que se utiliza ldapsearch. Por ejemplo, para ver la configuración de la base de datos, se debe ejecutar:
# slapcat -b cn=config -a olcDatabase=*
donde -b indica el sufijo o DN base, y -a permite utilizar filtros.

De esta forma tenemos que la configuración del directorio se realiza a través de atributos en entradas del directorio, y la mayoría de estos comienzan con el prefijo "olc" (OpenLDAP configuration). Además, algunas de las entradas tienen nombres con números entre llaves ({}). Esto se debe a que ni las entradas, ni los atributos de un directorio tienen un orden específico, pero el orden es necesario para la configuración, porque existen dependencias. Los números en los nombres aseguran que la configuración se ejecute en el orden correspondiente, asegurando la consistencia. En general estos números se generan automáticamente a medida que se crean las entradas.


Control de acceso

En la configuración default de un OpenLDAP recién instalado existen dos permisos para acceder al directorio:
  • utilizando el usuario admin que tiene control total. Este usuario está declarado en el DN base con cn=admin (por ej: cn=admin,dc=demasiadovivo,dc=org). La contraseña de este usuario se setea durante la instalación del directorio.
  • acceso de lectura de cualquier entrada de forma anónima, es decir, sin ningún tipo de autenticación.
Este todo o nada no suele alcanzar para ninguna organización, por lo tanto es necesario conocer cómo se administran los permisos.
El acceso a las entradas del directorio se configura a través del atributo olcAccess, cuyo formato es:
olcAccess: <directiva acceso="" de="">
olcAccess: <directiva acceso="" de="">
<access directive=""> ::= to <what>
    [by <who> <access> <control>]+
<what> ::= * |
    [dn[.<basic-style>]=<regex> | dn.<scope-style>=<dn>]
    [filter=<ldapfilter>] [attrs=<attrlist>]
<basic-style> ::= regex | exact
<scope-style> ::= base | one | subtree | children
<attrlist> ::= <attr> [val[.<basic-style>]=<regex>] | <attr> , <attrlist>
<attr> ::= <attrname> | entry | children
<who> ::= * | [anonymous | users | self
    | dn[.<basic-style>]=<regex> | dn.<scope-style>=<dn>]
    [dnattr=<attrname>]
    [group[/<objectclass>[/<attrname>][.<basic-style>]]=<regex>]
    [peername[.<basic-style>]=<regex>]
    [sockname[.<basic-style>]=<regex>]
    [domain[.<basic-style>]=<regex>]
    [sockurl[.<basic-style>]=<regex>]
    [set=<setspec>]
    [aci=<attrname>]
<access> ::= [self]{<level>|<priv>}
<level> ::= none | auth | compare | search | read | write
<priv> ::= {=|+|-}{w|r|s|c|x|0}+
<control> ::= [stop | continue | break]
donde la parte <what> selecciona las entradas y/o atributos a los cuales se aplica el acceso, <who> especifica que entidades tienen acceso, y <access> especifica el tipo de acceso otorgado. Se soportan múltiples tripletas <who> <access> <control>, permitiendo otorgar distinto tipo de acceso a distintas entidades.
Para observar los accesos default de todas las bases de datos, basta con ejecutar:
# slapcat -b cn=config -a olcAccess=*
Por ejemplo, ejecutando slapcat con el siguiente filtro es posible observar los accesos default a la base de datos principal:
# slapcat -b cn=config -a olcDatabase={1}hdb
  ...
  olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=demasiadovivo,dc=org" write by * none
  olcAccess: {1}to dn.base="" by * read
  olcAccess: {2}to * by self write by dn="cn=admin,dc=demasiadovivo,dc=org" write by * read
  ...
Con esta información se ve que los atributos userPassword (el password del usuario) y shadowLastChange (última fecha de modificación del password) tienen:
  • acceso de escritura para el propio usuario (self) y para el administrador (dn="cn=admin,dc=demasiadovivo,dc=org")
  • tiene acceso de lectura de forma anonima en caso de que se este realizando una autenticación (anonymous auth)
  • ningún acceso para el resto de los usuarios (* none).
Un punto a tener en cuenta es que en debian squeeze (al menos en mi caso) sólo el usuario root tiene permiso para modificar la configuración, utilizando el modo de autenticación externa de LDAP. Es decir, LDAP valida el usuario del sistema operativo.
El problema es que este modo de autenticación NO viene habilitado por defecto y requiere activación de TLS/SSL en el servidor LDAP. Esta tarea no resultó tan trivial como pensaba y no pude habilitarlo.
Para poder acceder a la configuración, existe un mecanismo alternativo. En la base de datos config, existe el usuario admin, pero por default no tiene password asignado. Para habilitar el uso de este usuario con autenticación simple, primero hay que crear la contraseña con slappasswd:
# slappasswd -h {SSHA}
y luego editar el archivo /etc/ldap/slapd.d/cn\=config/olcDatabase\=\{0\}config.ldif para agregar la siguiente línea debajo del nombre de usuario:
olcRootDN: cn=admin,cn=config   //esta línea ya existe en el archivo
olcRootPW: {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Finalmente, reiniciar el servicio:
# /etc/init.d/slapd restart
y testear que funciona:
$ ldapsearch -x -D cn=admin,cn=config -W -b cn=config
Cómo armar los permisos y otorgarlos está excelentemente explicado en la sección 5.3. Access Control del manual de OpenLDAP, por lo tanto no tiene sentido que lo repita aquí.


Clientes gráficos

Si bien podemos administrar todo el directorio a través de archivos LDIF, esto puede resultar engorroso y contraproducente en el día a día. Por suerte existen herramientas gráficas que nos ayudan a administrar el directorio de manera más simple.
Algunas de estas herramientas son:

Referencias

- OpenLDAP provider on Debian squeeze
- OpenLDAP installation on Debian
- OpenLDAP - 2. A Quick-Start Guide
- Debian 5.0 y OpenLDAP con TLS
- OpenLDAP - 5. Configuring slapd
- LDAP Administration Guide
- Zarafa LDAP cn config How To
- HowTo:LDAP Debian 6 (squeeze)
LDAP: Un directorio liviano
Un protocolo que se ha popularizado muchísimo en los últimos años es LDAP. El mismo es utilizado en la mayoría de las empresas, ya sea con Active Directory o con alguna de las múltiples soluciones para GNU/Linux como OpenLDAP, o 389 Directory Server.
Existen librerías para la mayoría de los lenguajes de programación que soportan LDAP, por lo cual existen muchos programas que lo utilizan.
Este protocolo es la base de cualquier sistema de directorio actual (Active Directory entre ellos), y es muy importante que todo administrador y/o programador conozca acerca de el.
Este artículo los introducirá en el mundo LDAP, explicando de qué trata, cómo funciona, la terminología, cómo es la autenticación y el formato de las búsquedas. El mismo forma parte del proyecto Autenticación y administración centralizada de usuarios en GNU/Linux.


Qué es?

Lightweight Directory Access Protocol (LDAP) es una base de datos especial (no relacional) que provee servicios de directorio basado en el estándar X.500, diseñada para almacenar información basada en atributos y soportar filtros sofisticados en búsquedas. A diferencia de una base de datos relacional, LDAP está optimizado para realizar búsquedas y organiza de forma distinta los datos.
Piensen en un directorio como una guía telefónica. En la guía encontramos personas con sus atributos (nompre, apellido, dirección y teléfono) organizadas en base a la letra de su apellido.
Un directorio informático que estamos acostumbrados a utilizar es la lista de direcciones de email. En la lista de emails encontramos las direcciones de email de nustros contactos, así como el nombre, teléfono, dirección física, etc. Podemos filtrar esta lista para buscar compañeros de trabajo, de universidad, por nombre, etc.
El "Light" en el nombre de LDAP se debe a que es una implementación más liviana que el anterior estandar X.500 denominado Directory Access Protocol, el cual estaba diseñado para trabajar sobre el stack OSI.

El modelo de información en LDAP está basado en entradas. Una entrada es un conjunto de atributos que tiene un nombre único (Distinguished Name - DN). El DN es utilizado para distinguir la entrada unequívocamente y se arma a partir de su RDN (Relative Distinguished Name), construido a partir de algún/os atributo/s de la entrada, y el DN de la entrada padre. Cada atributo de la entrada tiene un tipo y uno o varios valores. Los tipos suelen representarse con un string nemotécnico como 'cn' (common name), 'c' (country), 'ou' (organization unit), etc.
La información del directorio se organiza en forma de árbol y a este se lo denomina directory information tree (DIT). La jerarquía del árbol se arma a partir de información geográfica tomando como base del árbol o bien el nombre DNS. Dentro de esta jerarquía se pueden definir varias unidades organizativas, personas, dispositivos, etc.
Un ejemplo de entrada LDAP es:
dn: cn=demasiadovivo,dc=itfreekzone,dc=blogspot,dc=com
cn: demasiadovivo
givenName: demasiadovivo
mail: espameasiqueres@gmail.com
manager: cn=Javiz,dc=je-photography,dc=blogspot,dc=com
objectClass: person
En el ejemplo, el DN es "cn=demasiadovivo,dc=itfreekzone,dc=blogspot,dc=com" que está formado por el atributo common name, y los atributos domain component (dc) de las entradas padre. El resto son los atributos de la entrada. Como pueden observar, una entrada puede contener referencias a otras entradas, como es el caso del atributo manager que referencia a la entrada "cn=Javiz,dc=je-photography,dc=blogspot,dc=com".

El protocolo utiliza el port TCP 389 por defecto, en caso de no utilizar ssl, y 636 en caso de hacerlo.


Esquemas, Clases de objeto, Atributos y entradas

Como vimos, el directorio está formado por entradas, las que a su vez están formadas por un conjunto de atributos. Estos atributos se agrupan en clases de objetos (objectClass), las que a su vez se empaquetan en esquemas (schemes). Todas las objectClass y los atributos se definen dentro de esquemas. En OpenLDAP pueden encontrar la definición de los atributos y clases de objetos en el directorio /etc/ldap/schema/.

Los atributos se definen por separado y se pueden utilizar en una o varias objectClass. Para poder utilizar un atributo en una entrada, ésta debe contener alguna objectClass que contenga el atributo, y a su vez, la objectClass debe estar incluida en algún esquema reconocido por el servidor LDAP.

Las objectClass se pueden organizar jerárquicamente, en cuyo caso heredan todas las propiedades de sus padres o SUPerior. Estas objectClass pueden ser STRUCTURAL, en cuyo caso se usan para crear entradas, AUXILIARY en cuyo caso se pueden agregar en cualquier entrada, o ABSTRACT. El ejemplo más común de objectClass ABSTRACT es top, que forma el mayor nivel de cualquier jerarquía objectClass. Cada una de estas definiciones pueden tener atributos obligatorios y otros opcionales.

Las entradas agrupan conjuntos de objectClass, donde cada una debe contener obligatoriamente (y sólo puede contener una) STRUCTURAL. Además, puede contener una ABSTRACT y un número arbitrario de AUXILIARY.


Autenticación

LDAP soporta varios métodos de autenticación para acceder al directorio, existiendo dos principales que deben ser soportados (según el estándar):
  • Método de Autenticación Simple (Simple Authentication Method). Provee tres mecanismos de autenticación:
    • Autenticación anónima de enlace simple. Conexión LDAP sin usuario ni contraseña.
    • Autenticación sin autenticación de enlace simple. Se debe utilizar el nombre de usuario de un usuario válido, pero no es necesario proveer contraseña.
    • Autenticación de Usuario/Contraseña de enlace simple. En este caso se utiliza usuario y password para la autenticación, pero el password se transmite de forma plana.
  • Autenticación Simple y Capa de Seguridad (Simple Authentication and Security Layer - SASL). SASL es un framework para proveer autenticación y servicios seguros de datos a través de mecanismos reemplazables. El estándar de SASL sólo define uno de estos mecanismos (denominado EXTERNAL) pero las implementaciones más utilizadas soportan los siguientes:
    • DIGEST-MD5: provee un mecanismo para utilizar la autenticación HTTP Digest dentro del framework SASL. Este mecanismo envía un MD5 del password en lugar del password en texto plano, sobre una conexión sin encripción.
    • EXTERNAL: permite al cliente requerir que el servidor use credenciales provistas por un mecanismo externo al mecanismo de autenticación del cliente. La autenticación externa puede ser a través de la información de login del sistema operativo, IPSec, TLS o algún otro medio.
    • GSSAPI: permite al cliente utilizar tokens GSSAPI como credenciales para la autenticación. El token GSSAPI pueden ser Kerberos TGT o token NTLM.
    • GSSAPI-SPNEGO (Active Directory): es un mecanismo GSSAPI pero que contiene una negociación cliente-servidor para elegir el mecanismo de seguridad preferido según lo soportado por el cliente y el servidor.
En todos los casos, por cuestiones de seguridad, lo mejor es utilizar una capa de encripción por debajo del proceso de autenticación, como puede ser TLS (SSL) o IPSec. El método y mécanismo de autenticación más seguro es SASL usando GSSAPI con kerberos y sobre conexión encriptada. En orden de mejor a peor, las opciones son las siguientes:
  • SASL usando GSSAPI con kerberos y sobre conexión encriptada.
  • SASL usando GSSAPI con NTLMv2 y sobre conexión encriptada (sólo en Active Directory).
  • SASL usando GSSAPI con kerberos.
  • SASL usando GSSAPI con NTLMv2 (sólo en AD).
  • SASL usando GSSAPI con NTLM y sobre conexión encriptada (sólo en Active Directory).
  • Autenticación Simple, usuando usuario/contraseña sobre conexión encriptada.
  • SASL usando GSSAPI con NTLM (sólo en AD).


Búsquedas en el directorio

La sintaxis para realizar búsquedas no es muy intuitiva y muy distinta a la forma en que consultamos bases de datos relacionales a través de SQL, pero con el tiempo (como todo) uno se acostumbra.
Los parámetros son los siguientes:

  • baseObject: el DN de la entrada donde deseamos comenzar la búsqueda (ej: dc=demasiadovivo,dc=org)
  • scope: qué elementos bajo el baseObject buscar.
  • filer: criterio para seleccionar elementos dentro del scope. Los fitros se construyen utilizando operadores de igualdad y se pueden concatenar utilizando operadores booleanos en notación prefija. Pueden encontrar una buena explicación sobre construcción de filtros en Red Hat - LDAP Search Filters, Appendix A - LDAP: Text Search Filter y MS LDAP Query Basics.
  • derefAliases: cuando y cómo seguir entradas que son alias.
  • atributos: que atributos retornar en el resultado (ej: cn mail).
  • sizeLimit, timeLimit: máxima cantidad de entradas a retornar y el tiempo máximo permitido para ejecutar la búsqueda.
  • typesOnly: retornar sólo el tipo de los atributos, sin los valores.

Una excelente herramienta para realizar búsquedas en LDAP es ldapsearch, la cual viene en el paquete ldap-utils. Un ejemplo es el siguiente:
ldapsearch -b dc=itfreekzone,dc=blogspot,dc=com "(cn=demasiadovivo)" mail
donde usamos como baseObject "dc=itfreekzone,dc=blogspot,dc=com", como filtro (cn=demasiadovivo), y el atributo que deseamos traer es "mail".


Lo que viene...

Próximamente publicaré un artículo sobre cómo instalar y configurar el servicio de directorio más utilizando en entornos *nix (principalmente GNU/Linux), denominado OpenLDAP.


Referencias

- OpenLDAP - 1. Introduction to OpenLDAP Directory Services
- LDAP Wiki
- Chapter 3. LDAP Schemas, objectClasses and Attributes
- 6. LDAP Lightweight Directory Access Protocol
- LDAP for Rocket Scientists