Autenticacin LDAP

Toby Burress
kurin@causa-sui.net

Copyright 2007, 2008 The FreeBSD Documentation Project $FreeBSD$

FreeBSD is a registered trademark of the FreeBSD Foundation. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the or the symbol.

Este documento pretende servir como un punto de partida de la conguracin de un servidor LDAP (principalmente un servidor OpenLDAP) para la autenticacin en FreeBSD. Esto es muy til en situaciones cuando muchos servidores necesitan las mismas cuentas de usuario, por ejemplo cuando uno quiere reemplazar NIS.

Tabla de contenidos
1. Prefcio ......................................................................................................................................................................1 2. Conguracin de LDAP ...........................................................................................................................................2 3. Conguracin del cliente..........................................................................................................................................6 4. Consideraciones de seguridad................................................................................................................................10 A. Herramientas tiles................................................................................................................................................12 B. Certicados OpenSSL para LDAP .......................................................................................................................12

1. Prefcio
Este documento intentar exponer los conocimientos necesarios para congurar un servidor LDAP. Tratar de proveer una explicacin de net/nss_ldap para usar con los servicios clientes y con el servidor LDAP. Cuando haya terminado, el lector ser capaz de congurar y montar un servidor FreeBSD que pueda gestionar un directorio LDAP y otro servidor FreeBSD que pueda autenticarse a travs del directorio LDAP. Este artculo no pretende ser una gua exhaustiva de seguridad, robustez, o las mejores condiseraciones y prticas de la conguracin de LDAP o los otros servicios mencionados aqu. A pesar del mayor esfuerzo del autor para hacer todo correctamente, no trataremos de los temas de seguridad ms all de un alcance general. Este artculo debe

Autenticacin LDAP considerarse slo un fondo terico. Una implementacin verdadera debe realizarse con un profundo anlisis de requerimientos.

2. Conguracin de LDAP
LDAP signica Lightweight Directory Access Protocol (Protcolo Simple de Acceso de Directorios) y es un derivado del protcolo X.500 Directory Access Protocol. Su especicacin ms reciente est disponible en RFC4510 (http://www.ietf.org/rfc/rfc4510.txt) y sus derivados. Escencialmente, esto es una base de datos que est optimizada ms para la lectura que para la escritura. En los ejemplos de este documento se usar el servidor LDAP OpenLDAP (http://www.openldap.org/). No obstante, los principios aqu expuestos generalmente funcionarn con distintos servidores pero la mayora de la administracin concreta es especca de OpenLDAP. Existen varias versiones del servidor en el Ports Collection, por ejemplo net/openldap23-server. Los servidores necesitarn las correspondientes bibliotecas de net/openldap23-client. Bsicamente, existen dos partes del servicio LDAP que tienen que congurarse. La primera es la conguracin del servidor para que acepte conexiones apropiadamente, y la segunda es agregar entradas en el directorio del servidor para que las herramientas de FreeBSD sepan cmo interactuar con l.

2.1. Conguracin de las conexiones del servidor

Nota: Esta seccin es especca para OpenLDAP. Si usa otro servidor, debe consultar la documentacin adecuada.

2.1.1. Instalacin de OpenLDAP Primero, instale OpenLDAP: Ejemplo 1. Instalacin de OpenLDAP

# cd /usr/ports/net/openldap24-server # make install clean

Esto instala los binarios slapd y slurpd, adems de todas las bibliotecas requeridas por OpenLDAP.

2.1.2. Conguracin de OpenLDAP A continuacin tendremos que congurar OpenLDAP. Probablemente querr que las conexiones de su servidor LDAP requieran cifrado para que las contraseas de sus usuarios no se transeran en texto plano, lo cual se considera inseguro. Las herramientas que usaremos disponen de dos tipos muy similares de cifrado: SSL y TLS. TLS signica Transportation Layer Security (Seguridad de la capa de transportacin). Los servicios que emplean TSL tienden a conectarse a travs de los mismos puertos que los que no tienen cifrado alguno. As que un

Autenticacin LDAP servidor SMTP, el cual emplea TLS escuchar las conexiones a travs del puerto convencional que es el 25, al igual que un servidor LDAP escuchar a travs del 389. SSL signica Secure Sockets Layer (Capa de conexin segura), y los servicios que implementan SSL no escuchan a travs de los mismos puertos como su contraparte sin implementar SSL. Por esta razn SMTPS escucha a travs del puerto 465 (en vez del 45), HTTPS escucha a travs del 443, y LDAPS a travs del 636. La razn por la que SSL usa otro puerto diferente que TLS es porque la conexin TLS comienza en texto plano y cambia al trco cifrado despus de la directiva STARTTLS. Las conexiones SSL se cifran desde el comienzo. Aparte de esto, no hay mucha diferencia entre ambos.
Nota: Ajustaremos OpenLDAP con TLS, debido a que SSL se considera obsoleto.

Una vez que OpenLDAP est instalado desde el Ports Collection, se podr habilitar TLS con los siguientes parmetros de conguracin en el chero /usr/local/etc/openldap/slapd.conf:
security ssf=128 TLSCertificateFile /path/to/your/cert.crt TLSCertificateKeyFile /path/to/your/cert.key TLSCACertificateFile /path/to/your/cacert.crt

Aqu, la directiva ssf=128 especica que OpenLDAP requerir un cifrado de 128 bit para todas las conexiones, es decir, para la bsqueda y para la actualizacin. Este parmetro puede emplearse segn las necesidades de seguridad que tenga su infraestructura pero rara vez tendr que reducirlo debido a que la mayora de las bibliotecas cliente de LDAP soportan cifrado fuerte. Los cheros cert.crt, cert.key, y cacert.crt son necesarios para que los clientes lo identiquen como el servidor vlido LDAP. Si simplemente quiere un servidor que funcione, puede crear un certicado propiamente rmado con OpenSSL: Ejemplo 2. Generacin de una clave RSA
% openssl genrsa -out cert.key 1024

Generating RSA private key, 1024 bit long modulus ....................++++++ ...++++++ e is 65537 (0x10001)
% openssl req -new -key cert.key -out cert.csr

En este punto tiene que introducir varios valores. Puede introducir cualquier valores segn sus preferencias pero es importante que el valor Common Name sea el nombre de dominio completamente calicado del servidor OpenLDAP. En nuestro caso, y en los ejemplos aqu expuestos, el servidor se llama server.example.org . Introducir incorrectamente este valor causar que los clientes fallarn cuando pretenden establecer las conexiones. Esto puede causar una gran frustacin, as que asegrese de seguir estos pasos al pie de la letra. Finalmente, el pedido de rmado del certicado necesita rmarse:

Autenticacin LDAP Ejemplo 3. Firmar propiamente el certicado

% openssl x509 -req -in cert.csr -days 365 -signkey cert.key -out cert.crt

Signaustedre ok subject=/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd Getting Private key

Esto crear un certicado propiamente rmado que puede usarse a travs de las directivas en slapd.conf, donde cert.crt y cacert.crt son el mismo chero. Si usa varios servidores OpenLDAP (con replicacin por slurpd) deber ver en Apndice B cmo generar una clave CA y usarla para rmar los certicados de los servidores. Una vez que esto est hecho, ponga lo siguiente en el chero /etc/rc.conf:
slapd_enable="YES"

Luego ejecute /usr/local/etc/rc.d/slapd start. Esto arrancar el servicio OpenLDAP. Conrme que el servicio escuche a travs del puerto 389:
% sockstat -4 -p 389

ldap

slapd

3261

tcp4

*:389

*:*

2.1.3. Conguracin del cliente Instale las bibliotecas de OpenLDAP a travs del port net/openldap23-client. Los clientes siempre tendrn las bibliotecas OpenLDAP ya que son necesarias para los port security/pam_ldap y net/nss_ldap. El chero de conguracin de las bibliotecas OpenLDAP es /usr/local/etc/openldap/ldap.conf. Edite este chero que contenga los siguientes valores:
base dc=example,dc=org uri ldap://server.example.org/ ssl start_tls tls_cacert /path/to/your/cacert.crt

Nota: Es importante que sus clientes tengan acceso al chero cacert.crt ya que sin ste, no sern capaces de conectarse.

Nota: Hay dos cheros llamados ldap.conf. ste es el primero del que se trata ahora. ste pertenece a las bibliotecas de OpenLDAP y dene la comunicacin con el servidor. El segundo es el chero /usr/local/etc/ldap.conf y pertenece a pam_ldap.

En este punto ya ser capaz de ejecutar ldapsearch -Z en el cliente. La opcin -Z habilita el uso de TLS. Si encuentra un error algo estar mal congurado. En la mayora de los casos es algo relacionado a sus certicados. Use s_client y s_server de openssl(1) para asegurarse de que los tiene congurados y rmados apropiadamente.

Autenticacin LDAP

2.2. Entradas en la base de datos

La autenticacin con un directorio LDAP normalmente ocurre al conectarse el usuario al directorio. Esto se hace estableciendo una conexin simple en el directorio con el nombre de usuario dado. Si existe una entrada que concuerda tanto en el nombre de usuario especicado con el atributo uid (identicador del usuario) como en la contrasea introducida con el atributo userPassword, entonces se permitir el acceso. El primer paso que tenemos que hacer es identicar el directorio donde se almacenan nuestros usuarios. La entrada base para nuestra base de datos es dc=example,dc=org. La ubicacin por defecto que la mayora de los clientes supone es algo como ou=people,base, as que usaremos esto aqu tambin. Sin embargo, tenga en cuenta que esto se puede congurar. Por tanto, la entrada ldif para la unidad organizacional people quedar en algo como esto:
dn: ou=people,dc=example,dc=org objectClass: top objectClass: organizationalUnit ou: people

Todos los usuarios se crearn como subentradas de esta unidad organizacional. En cuanto el objeto al que pertenecen sus usuarios, hay algunas otras consideraciones que aadir. La mayora de las herramientas por defecto usarn people, lo cual es conveniente si simplemente quiere tener entradas para autenticarse. Sin embargo, si desea almacenar informaciones de los usuarios en la base de datos LDAP, probablemente querr usar inetOrgPerson el cual tiene muchos ms atributos tiles. En cualquier caso, tiene que incluir los esquemas relevantes en slapd.conf. Para este ejemplo usaremos el objeto person. Si usa inetOrgPerson, los pasos son bsicamente idnticos, excepto que se requiere el atributo sn. Para agregar un usuario fulano, el ldif sera:
dn: uid=fulano,ou=people,dc=example,dc=org objectClass: person objectClass: posixAccount objectClass: shadowAccount objectClass: top uidNumber: 10000 gidNumber: 10000 homeDirectory: /home/ustedser loginShell: /bin/csh uid: ustedser cn: ustedser

Yo comienzo los UID de mis usuarios de LDAP desde 10000 para evitar interferencias con las cuentas del sistema. Usted puede congurar otro nmero segn preere pero tenga en cuenta que debe ser menor de 65536. Tambin necesitamos las entradas de los grupos. stos pueden congurarse como las entradas de los usuarios pero por defecto usaremos lo siguiente:
dn: ou=groups,dc=example,dc=org objectClass: top objectClass: organizationalUnit ou: groups

Autenticacin LDAP
dn: cn=ustedser,ou=groups,dc=example,dc=org objectClass: posixGroup objectClass: top gidNumber: 10000 cn: ustedser

Para proceder este cambio en su base de datos puede ejecutar slapadd o ldapadd con un chero que contenga estas entradas. Alternativamente, puede usar sysutils/ldapvi. La utilidad ldapsearch en el cliente ya debe reconocer estas entradas. Si es as, su base de datos est debidamente congurada para ser un servidor de autenticacin LDAP.

3. Conguracin del cliente

El cliente debe ya tener las bibliotecas OpenLDAP como se describe en la Seccin 2.1.3 pero si tiene varios clientes tiene que instalar net/openldap23-client en cada uno de ellos. FreeBSD requiere dos port instalados para autenticarse a travs de un servidor LDAP: security/pam_ldap y net/nss_ldap.

3.1. Autenticacin
El port security/pam_ldap se congura en /usr/local/etc/ldap.conf.
Nota: ste es un chero diferente del chero de conguracin de la biblioteca OpenLDAP, /usr/local/etc/openldap/ldap.conf. Sin embargo, ste emplea muchas de las mismas opciones, de hecho, no es ms que una subparte de ese chero. En las referencias a ldap.conf en el resto de esta seccin se entienden por el chero /usr/local/etc/ldap.conf.

As de este modo, tenemos que copiar todos nuestros originales parmetros de conguracin de openldap/ldap.conf al nuevo chero ldap.conf. Una vez que est hecho, tenemos que comunicarle a security/pam_ldap lo que tiene que comprobar en el servidor del directorio. Identicamos nuestros usuarios con el atributo uid. Para congurar esto (aunque ste es el comportamiento por defecto), cambie la directiva pam_login_attribute en ldap.conf: Ejemplo 4. Cambiar pam_login_attribute
pam_login_attribute uid

Con este cambio, security/pam_ldap buscar el ditectorio LDAP entero bajo base por el valor uid=username. Si encuentra una y slo una entrada intentar conectarse con ese usuario y la contrasea introducida. Si puede conectarse correctamente, entonces permitir el acceso. En caso de que no sea as fallar.

Autenticacin LDAP 3.1.1. PAM PAM, el cual signica Pluggable Authentication Modules, (mdulos extensibles de autenticacin) es el mtodo por el cual FreeBSD autentica la mayora de sus sesiones. Para comunicarle a FreeBSD que nosotros deseamos usar un servidor LDAP tendremos que agregar una lnea apropiada en el chero de PAM. La mayora del tiempo el chero apropiado de PAM es /etc/pam.d/sshd. Si quiere usar SSH (recuerde ajustar las opciones revelantes en /etc/ssh/sshd_config o en caso contrario SSH no usar PAM). Para usar PAM para la autenciacin, agregue la siguiente lnea:
auth sufficient /usr/local/lib/pam_ldap.so no_warn

La ubicacin exacta de esta lnea en el chero y las opciones de la cuarta columna determinan el mecanismo exacto de autenticacin. Vase pam.d(5). Con esta conguracin ser capaz de autenticar un usuario a travs de un directorio LDAP. PAM conectar con sus credenciales y si tiene xito le comunicar a SSH que permita el acceso. Sin embargo, no es una buena idea permitir acceso a cada usuario en el directorio a cada cliente. Con la conguracin actual todo lo que uno necesita para conectarse a una mquina es una entrada en el directorio LDAP. Afortunadamente, existen unas cuantas maneras de restringir el acceso de un usuario. El chero ldap.conf dispone de una directiva pam_groupdn. Cada usuario que se conecta a esta mquina tiene que ser un miembro del grupo especicado aqu. Por ejemplo, si tiene
pam_groupdn cn=servername,ou=accessgroups,dc=example,dc=org

en ldap.conf, entonces slo los miembros de ese grupo sern capaces de ingresarse. Sin embargo, hay unas cuantas consideraciones para tener en cuenta. Los miembros de este grupo se especican en uno o ms atributos memberUid, y cada atributo tiene que tener el nombre distintivo completo del miembro. As que memberUid: menganito no funcionar sino que tiene que ser:
memberUid: uid=menganito,ou=people,dc=example,dc=org

Adems, esta directiva no se verica durante la autenticacin de PAM sino que durante la gestin de la cuenta, as que necesitar una segunda lnea en sus cheros PAM bajo account. Esto requerir que cada usuario est incluido en el grupo, lo cual no necesariamente es conveniente. Para no bloquear usuarios que no estn en el directorio LDAP tiene que habilitar el atributo ignore_unknown_user. Finalmente, debe habilitar la opcin ignore_authinfo_unavail para que no est bloqueado en cada cliente cuando el servidor LDAP est fuera de servicio. Su pam.d/sshd debera parecer a algo como esto: Ejemplo 5. Muestra de pam.d/sshd
auth auth auth auth auth account account required sufficient requisite sufficient required required required pam_nologin.so no_warn pam_opie.so no_warn pam_opieaccess.so no_warn /usr/local/lib/pam_ldap.so pam_unix.so no_warn pam_login_access.so /usr/local/lib/pam_ldap.so

no_fake_prompts allow_local no_warn try_first_pass

no_warn ignore_authinfo_unavail igno

Autenticacin LDAP
Nota: Ya que agreguemos estas lneas especcamente a pam.d/sshd, esto tendr slo un efecto en las sesiones SSH. Los usuarios de LDAP no sern capaces de ingresarse por la consola. Para cambiar este comportamiento examine los otros cheros en /etc/pam.d y modifquelos apropiadamente.

3.2. Name Service Switch

NSS es el servicio que mapea los atributos a nombres. As que, por ejemplo, si un chero es del usuario 1001, una aplicacin consultar a NSS por el nombre de 1001 y ste tiene que obtener fulano o menganito o el nombre del usuario que sea. La informacin de nuestro usuario ya se mantiene en el directorio LDAP pero todav tenemos que comunicarle a NSS que busque ah cuando sea necesario. El port net/nss_ldap se encarga de esto. ste usa el mismo chero de conguracin que security/pam_ldap y no necesita ningunos parmetros extra una vez que est instalado. Por tanto, lo que se queda es simplemente editar /etc/nsswitch.conf para que utilice el directorio. Simplemente reemplace las siguientes lneas:
group: compat passwd: compat

con
group: files ldap passwd: files ldap

Esto le permitir a mapear los nombres de usuario a los UID y los UID a los nombres de usuario. Felicitaciones! En este punto ya tendr la autenticacin funcionando con LDAP.

3.3. Advertencias
Desgraciadamente, al mismo tiempo que esto era escrito, FreeBSD no soportaba el cambio de contraseas de usuario con passwd(1). Por eso la mayora de los administradores implementa una solucin propia. Enumeramos algunos ejemplos aqu. Recuerde que si escribe su propio script de cambio de contraseas, hay algunos asuntos de seguridad que debe tener en cuenta. Vase Seccin 4.3. Ejemplo 6. Shell script para el cambio de contraseas
#!/bin/sh stty read read read stty -echo -p "Old Password: " oldp; echo -p "New Password: " np1; echo -p "Retype New Password: " np2; echo echo

if [ "$np1" != "$np2" ]; then echo "Passwords do not match." exit 1

Autenticacin LDAP
fi ldappasswd -D uid="$USER",ou=people,dc=example,dc=org \ -w "$oldp" \ -a "$oldp" \ -s "$np1"

AtencinEste script casi no verica los errores pero lo importante es que sea muy cuidadoso con el almacenamiento de las contraseas. Si escribe un script como ste, al menos ajuste el valor sysctl security.bsd.see_other_uids:
# sysctl security.bsd.see_other_uids=0.

Una solucin ms exible (y probablemente ms segura) puede ser escribir un programa customizado, o incluso una interfaz web. Lo siguiente es parte de una biblioteca Ruby que puede cambiar contraseas de LDAP. ste maneja tanto con la lnea de comandos como con la web. Ejemplo 7. Script en Ruby para cambiar contrasea
require require require require ldap base64 digest password # ruby-password

ldap_server = "ldap.example.org" luser = "uid=#{ENV[USER]},ou=people,dc=example,dc=org" # get the new password, check it, and create a salted hash from it def get_password pwd1 = Password.get("New Password: ") pwd2 = Password.get("Retype New Password: ") raise if pwd1 != pwd2 pwd1.check # check password strength salt = rand.to_s.gsub(/0\./, ) pass = pwd1.to_s hash = "{SSHA}"+Base64.encode64(Digest::SHA1.digest("#{pass}#{salt}")+salt).chomp! reustedrn hash end oldp = Password.get("Old Password: ") newp = get_password # Well just replace it. That we can bind proves that we either know # the old password or are an admin. replace = LDAP::Mod.new(LDAP::LDAP_MOD_REPLACE | LDAP::LDAP_MOD_BVALUES, "userPassword", [newp])

Autenticacin LDAP

conn = LDAP::SSLConn.new(ldap_server, 389, true) conn.set_option(LDAP::LDAP_OPT_PROTOCOL_VERSION, 3) conn.bind(luser, oldp) conn.modify(luser, [replace])

Aunque no garantiza que est libre de huecos de seguridad (por ejemplo, la contrasea se almacena en la memoria) esto es ms limpio y ms exible que un simple script sh.

4. Consideraciones de seguridad
Ahora que sus mquinas (y posiblemente otros servicios) se autentican a travs de su servidor LDAP, este servidor necesita una proteccin por lo menos tan fuerte que el chero /etc/master.passwd tendra en un servidor regular y posiblemente incluso ms as que un servidor LDAP crackeado o roto rompera el servicio en cada cliente. Recuerde que esta seccin no es exhaustiva. Debe continuamente revisar su conguracin y sus procedimientos para mejorar el servicio.

4.1. Cambiar los atributos a slo-lectura

Varios atributos en el directorio LDAP deben ser de slo-lectura. Si se deja modicar por el usuario, por ejemplo, un usuario podra cambiar su atributo uidNumber a 0 y obtener acceso de root. Para empezar, el atributo userPassword no debe dejarse modicar. Por defecto, cualquiera que pueda conectarse al servidor LDAP puede leer este atributo. Para deshabilitar esto, ponga lo siguiente en el chero slapd.conf: Ejemplo 8. Proteger las contraseas
access to dn.subtree="ou=people,dc=example,dc=org" attrs=userPassword by self write by anonymous auth by * none access to * by self write by * read

Esto no permitir la lectura del atributo userPassword, mientras que todava est permitido que los usuarios cambien sus propias contraseas. Adems, tambin querr evitar que los usuarios puedan cambiar algunos de sus propios atributos. Por defecto, los usuarios pueden cambiar cualquier atributo (excepto aquellos cuyos propios esquemas del directorio LDAP denieguen cambios) incluso su uidNumber. Para evitar este riesgo, modique lo de encima por: Ejemplo 9. Atributos de slo-lectura
access to dn.subtree="ou=people,dc=example,dc=org" attrs=userPassword by self write

10

Autenticacin LDAP
by anonymous auth by * none access to attrs=homeDirectory,uidNumber,gidNumber by * read access to * by self write by * read

Esto parar a los usuarios de ser capaces de enmascararse como otros usuarios.

4.2. Denicin de la cuenta de root

Frecuentemente el root o cuenta de administracin para el servicio de LDAP se dene en el chero de conguracin. OpenLDAP soporta esto entre otros mtodos y esto funciona pero puede generar problemas si slapd.conf se compromete. Esto puede ser til para arrancar el servicio de LDAP y luego denir una cuenta root all. Es incluso mejor denir cuentas que tengan permisos limitados, y omitir una cuenta root enteramente. Por ejemplo, usuarios que pueden agregar o borrar cuentas de usuario a un grupo pero no pueden cambiarse ellos mismos la pertenencia de dicho grupo. Tal poltica de seguridad ayudara a mitigar los efectos de contraseas crackeadas. 4.2.1. Crear un grupo de administracin Digamos que su departemento IT quiere ser capaz de cambiar los directorios home de los usuarios pero usted no quiere que todos ellos sean capaces de agregar o borrar usuarios. La manera de ajustar esto es agregar un grupo para estos administradores: Ejemplo 10. Crear un grupo de administracin
dn: cn=homemanagement,dc=example,dc=org objectClass: top objectClass: posixGroup cn: homemanagement gidNumber: 121 # required for posixGroup memberUid: uid=fulano,ou=people,dc=example,dc=org memberUid: uid=menganito,ou=people,dc=example,dc=org

Y entonces cambie los atributos de permisos en slapd.conf: Ejemplo 11. Listas de control de acceso (ACL) para un grupo de administracin del directorio home
access to dn.subtree="ou=people,dc=example,dc=org" attr=homeDirectory by dn="cn=homemanagement,dc=example,dc=org" dnattr=memberUid write

Ahora fulano y menganito pueden cambiar los directorios home de otros usuarios.

11

Autenticacin LDAP En este ejemplo les hemos dado una componente de poder administrativo a ciertos usuarios sin darles poder en otros dominios. La idea es que una cuenta de usuario no tenga simplemente todo el poder de una cuenta root pero cada poder de root tiene que tenerlo al menos un usuario. La cuenta root entonces llega a ser innecesaria y puede borrarse.

4.3. Almacenamiento de la contrasea

Por defecto, OpenLDAP almacenar el valor del atributo userPassword tal y como almacena otro dato: en texto plano. La mayora del tiempo esto es un texto codicado en base64, el cual provee suciente proteccin para mantener a un administrador honesto del conocimiento de su contrasea pero nada ms. De ah que sea una buena idea almacenar las contraseas en un formato ms seguro, como por ejemplo SSHA (SHA salteado). Esto se hace con cualquier programa que use para cambiar las contraseas de los usuarios.

A. Herramientas tiles
Existen unos cuantos programas que pueden ser tiles, particularmente si tiene muchos usuarios y no quiere congurar nada a mano. El port security/pam_mkhomedir es un mdulo de PAM que siempre triunfa. Su propsito es crear directorios home para los usuarios que no lo tengan. Si tiene una docena de servidores y clientes y cientos de usuarios, esto es mucho ms fcil de usar y construir el esqueleto de directorios que preparar cada directorio de home independientemente. El port sysutils/cpu es una utilidad parecida a pw(8) que puede usarse para administrar los usuarios en el directorio LDAP. Puede ejecutarlo directamente, o utilizarlo en un script. ste puede manejar ambos TLS (con la opcin -x) y SSL (directamente). El port sysutils/ldapvi es una excelente herramienta para la edicin de valores en el directorio LDAP con una sintxis del tipo LDIF. El directorio (o subseccin del directorio) se presenta en el editor escogido por la variable de entorno EDITOR. Esto facilita mucho realizar cambios a gran escala en el directorio sin tener que crear una solucin propia. El port security/openssh-portable tiene la habilidad de conectarse a un servidor LDAP para vericar las claves SSH. Esto es extremadamente til si tiene muchos servidores y no quiere copiar sus claves pblicas a todos ellos.

B. Certicados OpenSSL para LDAP

Si gestiona dos o ms servidores LDAP, probablemente no quiere usar certicados propiamente rmados, debido a que cada cliente tendr que congurarse para que funcione con cada certicado. Esto es posible pero no es tan simple como crear su propia autoridad de certicado, y rmar los certicados de sus servidores con ella. Los pasos aqu presentados carecen de explicaciones detalladas. Explicaciones adicionales pueden encontrarse en openssl(1) y otros manuales.

12

Autenticacin LDAP Para crear una autoridad certicadora, slo hace falta un certicado propiamente rmado y la clave. Los pasos para crearlos son: Ejemplo B-1. Crear un certicado
% openssl genrsa -out root.key 1024 % openssl req -new -key root.key -out root.csr % openssl x509 -req -days 1024 -in root.csr -signkey root.key -out root.crt

ste ser su certicado y clave root CA. Problemente querr cifrar la clave y almacenarla en un lugar seguro. Cualquiera con acceso a stos puede enmascararse como uno de sus servidores LDAP. A continuacin, usando el primero de los dos pasos encima creamos una clave ldap-server-one.key y un pedido de rmado de un certicado ldap-server-one.csr. Una vez que rme el pedido de rmado con root.key, ser capaz de usar ldap-server-one.* en sus servidores LDAP.
Nota: No olvide usar el nombre de dominio completamente calicado para el atributo common name cuando se genera el pedido de rmado del certicado ya que si no hace as los clientes rechazarn la conexin y esto puede ser bastante difcil de diagnosticar.

Para rmar la clave, use -CA y -CAkey en vez de -signkey: Ejemplo B-2. Firmar como una autoridad de certicado
% openssl x509 -req -days 1024 \ -in ldap-server-one.csr -CA root.crt -CAkey root.key \ -out ldap-server-one.crt

El chero de salida ser el certicado que puede usarse en sus servidores LDAP. Finalmente, para que los clientes confen en todos sus servidores, distribuya root.crt (el certicado, no la clave!) en cada cliente y especifquelo en la directiva TLSCACertificateFile en ldap.conf.

13