Preparación para el examen 301 de LPI, Tema 305: Integración y migración

Senior Level Linux Professional (LPIC-3)

En este tutorial, Sean Walberg lo ayuda a prepararse para realizar el examen ®Senior Level Linux Professional (LPIC-3) del Linux Professional Institute. En este quinto tutorial de una series of six tutorials, Sean lo guia en la integración de LDAP con las identificaciones y aplicaciones de su sistema. También detalla el procedimiento para integrar su servidor a un Microsoft® Active Directory externo.

Sean Walberg, Senior Network Engineer, P.Eng

Photo of Sean WalbergSean Walberg ha estado trabajando con Linux y UNIX desde 1994 en entornos de proveedores de servicios académicos, corporativos y de Internet. Ha escrito extensamente sobre la administración de los sistemas en los últimos años.



15-07-2011

Antes de comenzar

Conozca lo que pueden enseñarle estos tutorials y cómo aprovecharlos al máximo.

Sobre esta serie

El Linux Professional Institute (LPI) certifica a los administradores del sistema Linux en tres niveles: nivel junior (también denominado "nivel de certificación 1"), nivel avanzado (también denominado "nivel de certificación 2"), y nivel senior (también denominado "nivel de certificación 3"). Para alcanzar el nivel de certificación 1, debe aprobar los exámenes 101 y 102. Para alcanzar el nivel de certificación 2, debe aprobar los exámenes 201 y 202. Para alcanzar el nivel de certificación 3, debe tener una certificación activa de nivel avanzado y aprobar el examen 301 ("core"). También puede aprobar exámenes de especialidad adicionales en el nivel senior.

developerWorks ofrece tutorials para ayudarlo a prepararse para los cinco exámenes de certificación junior, avanzada y senior. Cada examen abarca varios temas, y cada tema tiene un tutorial de autoaprendizaje correspondiente en developerWorks. La Tabla 1 muestra una lista de los seis temas y sus correspondientes tutoriales en developerWorks para el examen 301 de LPI.

Tabla 1. Examen 301 de LPI: Tutorials y temas
Tema 301 del examen del LPItutorial de developerWorksResumen del Tutorial
Tema 301LPI exam 301 prep:
Concepts, architecture, and design
Aprenda sobre los conceptos y la arquitectura de LDAP, cómo diseñar e implementar un directorio LDAP, y sobre los esquemas.
Tema 302LPI exam 301 prep:
Installation and development
Aprenda a instalar, configurar y utilizar el software de OpenLDAP.
Tema 303LPI exam 301 prep:
Configuration
Aprenda cómo configurar el software de OpenLDAP en detalle.
Tema 304LPI exam 301 prep:
Usage
Aprenda cómo buscar en el directorio y usar las herramientas de OpenLDAP.
Tema 305 LPI exam 301 prep:
Integration and migration
(Este tutorial) Aprenda a utilizar LDAP como fuente de datos para sus sistemas y aplicaciones. Vea en detalle objectives.
Tema 306 LPI exam 301 prep:
Capacity planning
Pronto.

Para aprobar el examen 301 (y obtener el nivel de certificación 3):

  • Debería tener varios años de experiencia en la instalación y el manteniminto de varias computadoras por distintos motivos.
  • Debería tener experiencia de integración con diversas tecnologías y sistemas operativos.
  • Debería tener experiencia como profesional de Linux a nivel empresarial o estar capacitándose para ello (incluso tener experiencia en otro rol).
  • Debería tener niveles avanzado y empresarial de administración de Linux incluyendo la instalación, la administración, la seguridad, la localización de fallas y el manteniminto.
  • Debería poder usar las herramientas de fuente abierta para medir problemas de planificación de capacidad y de recursos para la resolución de problemas.
  • Debería tener experiencia profesional con el uso de LDAP para integrar con servicios de UNIX® y Microsoft® Windows®, incluyendo Samba, Pluggable Authentication Modules (PAM), correo electrónico y Active Directory.
  • Debería poder planificar, idear, diseñar, crear e implementar un entorno completo usando Samba y LDAP, así como medir la planificación de la capacidad y la seguridad de los servicios
  • Debería poder crear scripts en Bash o Perl, o tener conocimiento de al menos un lenguaje de programación de sistemas (como C).

Para continuar preparando el nivel de certificación 3, consulte los series developerWorks tutorials for LPI exam 301, así como el entire set of developerWorks LPI tutorials.

El Linux Professional Institute no avala el material o las técnicas para la preparación de exámenes de ninguna tercera parte en particular.

Sobre este tu tutorial

Bienvenido a "Integración y migración," el quinto de seis tutoriales diseñados para prepararlo para el examen 301 del LPI. En este, aprenderá todo sobre la integración de LDAP con la autenticación y otros servicios de UNIX.

Este tutorial está organizado según los objetivos del LPI para este tema. Muy a grandes razgos, espere más preguntas del examen sobre los objetivos con valores más altos.

Objectivos

La Tabla 2 proporciona los objetivos detallados para este tutorial.

Tabla 2. Integración y migración: Objetivos de examen que abarca este tutorial
Objetivo del examen del LPIValor del objetivoResumen del objetivo
305.1
Integración de LDAP con PAM y NSS
2Integración de la autenticación principal del sistema con LDAP.
305.2
NIS para la migración de LDAP
1Planificación e implementación de una estrategia de migración de NIS, incluyendo el despliegue de un NIS para el portal de enlace de LDAP.
305.3
Integración de LDAP con los servicios UNIX
1Uso del servidor LDAP como fuente de datos para SSH, FTP, HTTP, y otros servicios.
305.4
Integración de LDAP con Samba
1Uso del servidor LDAP como fuente de datos para Samba.
305.5
Integración de LDAP con Active Directory
2Uso de su servidor LDAP junto con un servicio de Active Directory.
305.6
Integración de LDAP con servicios de correo electrónico
1Integración de su servicio de correo electrónico con su directorio LDAP.

Prerrequisitos

Para aprovechar al máximo este tutorial, debería tener conocimientos avanzados sobre Linux y un sistema Linux en funcionamiento en el cual practicar los comandos aquí explicados.

Si sus capacidades básicas de Linux están un poco oxidadas, quizá desee primero revisar los tutorials for the LPIC-1 and LPIC-2 exams.

Diferentes versiones de un programa pueden dar formato distinto a los datos de salida, así que los resultados quizá no se vean exactamente igual a los de los listados y figuras en este tutorial.

Requisitos de sistema

Para seguir los ejemplos en este tutorial, necesitará una estación de trabajo de Linux con el paquete de OpenLDAP y soporte para PAM. La mayoría de las distribuciones modernas cumplen con estos requisitos.


Integración de LDAP con PAM y NSS

Esta sección ofrece material para el tema 305.1 del examen 301 Senior Level del Linux Professional (LPIC-3). Este tema tiene un valor de 2.

En esta sección aprenda como:

  • Configurar NSS para recuperar información de LDAP
  • Configurar PAM para usar LDAP para la autenticación
  • Configurar los módulos de PAM en diversos entornos UNIX

En la moda tradicional de UNIX, PAM y los dispositivos del Name Service Switch (NSS) extraen varios componentes de autenticación y búsqueda de su implementación, lo cual permite al administrador modificar los depósitos de datos backend sin recompilar ninguna aplicación. Por ejemplo, el paso de la autenticación tradicional basada en /etc/passwd al Network Information Service (NIS) es transparente porque NSS se implementa como parte de la biblioteca C. Las aplicaciones utilizan las llamadas a la biblioteca estandar como getpwent(3) para buscar usuarios, pero a través de alguna configuración mágica, los datos son dirigidos a otro depósito como NIS.

PAM es un animal un poco diferente, porque las aplicaciones deben escribirse específicamente teniendo en cuenta a PAM. Los administradores pueden usar un rico conjunto de bibliotecas para personalizar el comportamiento de una aplicación preparada para PAM, como por ejemplo la solicitud de una membresía específica para un grupo y del tiempo de conexión para autenticar exitosamente.

PAM y NSS pueden funcionar uno tras otro para la autenticación del usuario. Las aplicaciones preparadas para PAM le indican a PAM que verifique las credenciales del usuario. El administrador puede configurar PAM para verificar la contraseña a través del dispositivo NSS además de otras restricciones. PAM se utiliza solamente para la contraseña y bases de datos shadow, no para otros como los grupos o los hosts.

El soporte de LDAP para PAM y NSS es suministrado por un paquete de fuente abierta desde el software PADL.

Configuración de NSS para usar LDAP

El dispositivo de NSS se implementa en la biblioteca C como una conexión a las llamadas a la biblioteca tradicional para obtener información. La biblioteca C proporciona funciones como getpwent para obtener información de usuario y gethostbyname(3) para información de host, lo cual tradicionalmente era implementado como búsquedas a /etc/passwd y /etc/hosts, respectivamente. El administrador puede forzar las búsquedas del nombre del host para usar también el Domain Name Service (DNS) configurando NSS, lo que significa que la aplicación ignora el cambio.

Comprensión de NSS

En la Tabla 3 se describen las bases de datos que son administradas por NSS. La mayoría de las bases de datos tienen un archivo correspondiente en /etc, donde los datos se almacenan tradicionalmente.

Tabla 3. Bases de datos NSS
Nombre de la base de datosDescripción
aliasesLos aliases de correo electrónico para sendmail, utilizado para redireccionar (alias) una dirección local a otra dirección.
ethersCorrelaciona direcciones de ethernet con direcciones IP. Esto ya no es común debido a la disponibilidad del Address Resolution Protocol (ARP).
groupContiene una lista de grupos y los usuarios que pertenecen a ellos.
hostsCorrelaciona direcciones IP con nombres host.
netgroupSe utiliza para agrupar servidores. La mayoría a menudo se utiliza para la seguridad de NIS y Network File System (NFS).
networksUna correlación de nombres de redes con números. No se utiliza a menudo porque saber el nombre de la red proporciona poco valor.
passwdAlmacena información de cuenta de usuario como nombre, id de usuario, descripción, grupo primario, directorio principal, y a veces una contraseña.
protocolsCorrelaciona protocolos IP con sus nombres.
publickeySe utiliza para distribuir claves para NFS y NIS+.
rpcCorrelaciona nombres de funciones Remote Procedure Call (RPC) con números.
servicesCorrelaciona nombres de servicios TCP y UDP con el número de puerto.
shadowUn archivo de contraseña protegido, encriptado. Generalmente el campo password de /etc/passwd se almacena en este archivo para mantenerlo a salvo.

NSS se configura en /etc/nsswitchconf y contiene una línea por base de datos de la Tabla 3. El Listado 1 muestra un ejemplo de nsswitch.conf.

Listado 1. Muestra de nsswitch.conf
passwd:     files nis
shadow:     files nis
group:      files nis
hosts:      files nis dns

En el Listado 1 se configuran cuatro correlaciones: passwd, shadow, group, y hosts. El nombre de la correlación está seguida de dos puntos (:) y luego una lista ordenada de formas de acceso a los datos. Las primeras tres líneas en el Listado 1 son iguales: primero verifican en los archivos la información solicitada y luego el NIS, a veces conocido como las Yellow Pages. NIS se verifica sólo si no se encuentra nada en los archivos. La línea final del ejemplo verifica en los archivos (/etc/hosts), NIS, y luego DNS las solicitudes de los hosts.

El método disponible a utilizar en nsswitch.conf tiene una biblioteca correspondiente en /lib que comienza con libnss_. La funcionalidad para los archivos, por ejemplo, se encuentra en /lib/libnss_files-2.5.so (el número de versión no es importante porque lo resuelve un enlazador dinámico, ld-linux.so).

Incorporación de LDAP para NSS

Tras la discusión anterior sobre las bibliotecas dinámicas y el formato de nsswitch.conf, no debería sorprender que la integración de LDAP con NSS sea administrada a través de una biblioteca compartida denominada libnss_ldap y se haga referencia al mismo a través de la palabra clave ldap en /etc/nsswitch.conf. Esta biblioteca compartida toma la configuración de /etc/ldap.conf (no confundir con el archivo de configuración de OpenLDAP para los clientes de línea de comando, /etc/openldap/ldap.conf). En el Listado 2 se observa una muestra de ldap.conf.

Listado 2. Una muestra de ldap.conf para configurar libnss_ldap
# Server IP address (or space-separated addresses)
host 192.168.1.138
# Search base
base dc=ertw,dc=com
# optional: bind credentials
binddn: cn=nssldap,dc=ertw,dc=com
bindpw: letmein
# If root is making the request, use this dn instead
# The password is stored in /etc/ldap.secret and only readable by root
rootbinddn cn=root,dc=ertw,dc=com
# Point the passwd, shadow, and group databases at a DN
# the ?one defines the scope
nss_base_passwd ou=People,dc=ertw,dc=com?one
nss_base_shadow ou=People,dc=ertw,dc=com?one
nss_base_group          ou=Group,dc=ertw,dc=com?one
# Don't look for secondary groups for any of these users
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd

Además del contenido de /etc/ldap.conf que se observa en el Listado 2, también debe agregar la palabra clave ldap a la passwd, shadow, y grupos de líneas en /etc/nsswitch.conf. Siempre asegúrese de que files sea la primera entrada; de otro modo, podría encontrarse esperando desde servidores caídos hasta tiempo muerto — o hasta verse sin acceso a su propio sistema. (Si no tiene acceso debido a un problema con nsswitch.conf, inicie en modo de usuario único, reinicie nsswitch.conf nuevamente en los archivos, y luego reinicie.)

Es posible usar LDAP para todas las bases de datos, pero los tres que se enumeran aquí son los más útiles. Las otras correlacionens rara vez cambian y deberían ser administradas por separado. La excepción es la base de datos de los hosts, la cual puede utilizar LDAP, aunque DNS es una mejor opción.

Póngalo a prueba

Si nsswitch.conf y ldap.conf están configurados por separado, entonces debería poder conectarse con un usuario LDAP, mientras que los siguientes atributoes estén disponibles:

  • uid: el nombre de acceso
  • uidNumber: la id numérica de usuario
  • gidNumber: la id numérica de grupo primario
  • homeDirectory: el directorio principal del usuario
  • userPassword: la contraseña del usuario, encriptada con la rutina {crypt} (use slappasswd para generarla)

Estos atributos y más son agregados a través de la clase de objeto posixAccount.

Para probar, pruebe conectarse como usuario que se encuentra en su árbol LDAP pero no en los archivos de contraseña locales. También puede utilizar el comando getent passwd para mirar todas las entradas de usuario que conoce NSS. Si getent funciona pero el login no, su atributo userPassword es probablemente incorrecto.

Si ha verificado su configuración con el cliente, y NSS y LDAP todavía no funcionan juntos, habilite la conexión de nivel statsen el servidor OpenLDAP y vea si sus consultas son vistas por el servidor, y si se las permite.

Configuración de PAM para usar LDAP

PAM es muy parecido a NSS en el hecho de que extrae un conjunto de llamadas a la biblioteca de la implementación actual. A diferencia de NSS, PAM no reemplaza las llamadas UNIX existentes; en lugar de esto, suministra un conjunto de llamadas nuevas que pueden utilizar las aplicaciones.

Comprensión de PAM

PAM se implementa como biblioteca que utilizan las aplicaciones. Las aplicaciones llaman a esta biblioteca para usar las funciones de administración de PAM para verificar la autenticación, administrar la cuenta, administrar la sesión, y administrar la contraseña.

Verificar la autenticación es el objetivo principal de PAM. La aplicación le pregunta a la biblioteca PAM si el usuario está autenticado. La biblioteca PAM, a su vez, sigue las reglas establecidas por el administrador de los sistemas para alertar al usuario sobre una contraseña o realizar cualquier cantidad de verificaciones.

La administración de la cuenta se ejecuta después de que el usuario suministra credenciales válidas y es responsable de verificar si se permite el acceso. Una clave de acceso pueden no ser permitida en ciertos momentos o para ciertas aplicaciones.

La administración de sesión le brinda a la aplicación la oportunidad de configurar el entorno después de un acceso exitoso. A menudo es deseable dar al usuario conectado a la consola algunos permisos adicionales, como el uso del CDROM local u otros dispositivos; esto se hace en el nivel de administración de sesión.

Finalmente, la administración de contraseña suministra una forma flexible de cambiar contraseñas. Como pronto verá, esta funcionalidad le permite a los usuarios cambiar su contraseña LDAP a través del programa passwd(1) familiar. La administración de la contraseña PAM también le permite especificar políticas de validez de contraseñas que operan independientemente del backend de la contraseña.

Para configurar PAM para un servicio, debe crear un archivo denominado como el servicio en /etc/pam.d, como por ejemplo /etc/pam.d/sshd para el servicio sshd. Esta no es una regla fija, porque la aplicación especifica su propio nombre de servicio PAM. Cuando tenga dudas, utilice el nombre del binario, y verifique los registros en busca de errores.

Cada archivo de configuración en /etc/pam.d especifica una lista ordenada de instrucciones para cada una de las funciones de administración de PAM. Cada línea en el archivo tiene la forma de argumentos de módulo de control de función. La función es la función de administración, que usa las palabras claves auth, account, session, y password.

El control especifica cómo el valor de retorno de la instrucción evaluada se utilizará, y es una de las siguientes palabras claves:

  • required -- Esta verificación debe tener éxito para que la función tenga éxito. Si esta verificación falla, entonces PAM continuará verificando el resto de las instrucciones de la función, pero los resultados no tienen sentido.
  • requisite -- Esta verificación debe resultar exitosa para que la función tenga éxito. Si esta verificación falla, entonces PAM no continuará la verificación del resto de las instrucciones e indicará error.
  • sufficient -- Si esta verificación tiene éxito, el procesamiento se detiene y la función vuelve exitosamente, asumiendo que no han fallado elementos previos "solicitados". Si esta verificación falla, el error es ignorado y el procesamiento continua.
  • optional -- Los resultados de la verificación son ignorados.

El módulo y los argumentos implementan la verificación. El mismo módulo puede implementar una o más funciones descriptas, de modo que puede ver el mismo módulo listado varias veces. Un módulo que verá utilizado a menudo es pam_stack, el cual le permite llamar pilas de instrucciones de otros archivos. El Listado 3 muestra un archivo PAM que utiliza pam_stack.

Listado 3. Uso de pam_stack para llamar otras pilas de instrucciones
auth       required     pam_nologin.so
auth       required     pam_stack.so service=system-auth
account    required     pam_stack.so service=system-auth
session    required     pam_stack.so service=system-auth
password   required     pam_stack.so service=system-auth

En el Listado 3 se muestra el formato de un archivo PAM. La función auth tiene dos líneas, ambas son necesarias y por lo tanto deben tener éxito para que la autenticación resulte exitosa. La primera línea de autenticación llama a pam_nologin, cuya tarea es fallar si un usuario no raíz trata de conectarse cuando existe el archivo /etc/nologin. La siguiente línea de auth llama al módulo pam_stack y le pasa service=system-auth. pam_stack.so entonces lee los contenidos de /etc/pam.d/system-auth y verifica todas las instrucciones bajo la función auth. Si esto resulta bien, pam_stack devuelve un resultado exitoso al archivo que aparece en el Listado 3.

Las otras tres funciones—account, session, y password—sólo hacen referencia a pam_stack y el servicio system-auth. Si las funciones respectivas de system-auth tienen éxito, entonces el resultado se considera un éxito.

Muchos sistemas tienen un conjunto común de rutinas para autenticación, por lo cual pam_stack es utilizado en la mayoría de los archivos, y el system-auth (o equivalente) contiene todas las partes interesantes. Para el resto de esta sección, el archivo system-auth será el utilizado para insertar LDAP en el proceso de PAM.

Incorporación de LDAP a PAM

Tanto el módulo NSS como el módulo PAM utilizan /etc/ldap.conf para la configuración, así que si está siguiéndonos, está a medio camino de obtener un sistema PAM-LDAP en funcionamiento. Es posible usar NSS y PAM juntos de modo que las aplicaciones preparadas para PAM y las heredadas pueden autenticar para LDAP. PAM suministra algunas de las características más destacadas de NSS, incluyento las siguientes:

  • Modificación de contraseñas por parte del usuarios
  • Configuración más granular de requisitos de autenticación
  • Soporte para más tipos de encriptamientos de contraseñas
  • Administración centralizada de cuentas de usuarios

Asegúrese de que pam_password md5 esté en /etc/ldap.conf, y borre cualquier otra línea pam_password si las hubiera. Esto le indica a la biblioteca pam_ldap generar la contraseña con Message Digest 5 (MD5) localmente antes de enviarlo al servidor LDAP al cambiar contraseñas.

Edite su /etc/pam.d/system-auth (o equivalente) para agregar las referencias a pam_ldap, como se observa en el Listado 4. La línea debería colocarse después de cualquier referencia a pam_unix (de modo que las cuentas locales tienen prioridad sobre las cuentas LDAP) pero cualquier referencia a pam_allow y pam_deny (el cual proporciona una negación o permiso por omisión).

Listado 4. Nuevo system-auth que utiliza pam_ldap
auth        sufficient    pam_unix.so nullok try_first_pass
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadowaccount     sufficient    pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     required      pam_limits.so
session     required      pam_unix.so
session     optional      pam_ldap.so

Las líneas en negrita muestran incorporaciones al archivo de configuración PAM. Tenga en cuenta la incorporación de broken_shadow en la función account de pam_unix. Esto asegura que pam_unix.so no devuelva un error si el usuario no tiene una entrada shadow (la cual no tiene, porque la cuenta se encuentra en LDAP).

La opción use_first_pass al módulo auth de pam_ldap obliga a pam_ldap.so a utilizar la contraseña obtenida de pam_unix.so en vez de solicitar una nueva contraseña. use_authtok hace algo similar para la función password.

Para autorización, la nueva configuración hace que las contraseñas UNIX y LDAP sean suficientes para conectarse: es decir, la primera para tener éxito permite al usuario conectarse. Si ninguna tiene éxito (o si hay una falla, o "no existe el usuario"), entonces pam_deny provoca un error.

Pruébelo

Trate de cambiar la contraseña de usuario a través del comando passwd, y luego verifique que la contraseña fue modificada en el directorio LDAP. Finalmente, asegúrese de que el usuario pueda todavía conectarse.

Si logró que funcione NSS, PAM debería también funcionar. La mejor oportunidad de error es equivocarse al ingresar las entradas en la configuración de PAM, al colocar las entradas en el archivo equivocado, o colocarlas en la ubicación incorrecta del archivo.


NIS para la migración a LDAP

Esta sección contiene material para el tema 305.2 del examen 301 Senior Level Linux Professional (LPIC-3). Este tema tiene un valor de 1.

En esta sección aprenda cómo:

  • Analizar la estructura de NIS antes de la migración a LDAP
  • Analizar la estructura de NIS antes de la integración con LDAP
  • Automatizar la migración de NIS-a-LDAP
  • Crear una puerta de enlace NIS-a-LDAP

NIS es el método tradicional de autenticación central para máquinas UNIX. NIS es simple de configurar y funciona bien. A pesar de ser más compleja, la autenticación de LDAP es superior a NIS en varias formas:

  • LDAP es mucho más segura que NIS porque puede encriptar el tráfico y bloquear la base de datos.
  • LDAP puede almacenar más que simples datos de autenticación, mientras que NIS es limitado.
  • A LDAP pueden acceder más clientes que a NIS.

Usted puede elegir reemplazar NIS con LDAP o utilizar ambos de forma simultánea. Cuando los utiliza juntos, LDAP es una fuente de datos canónica, y el servidor de NIS utiliza datos de LDAP en lugar de archivos locales. Este es un buen enfoque para una migración a largo plazo o para soportar los sistemas operativos heredados que no funcionan con LDAP.

Enfoque 1: Migración a LDAP

El enfoque general para la migración de NIS a LDAP es el siguiente:

  1. Determinar qué base de datos NIS debe reemplazarse.
  2. Cargar los datos de NIS end LDAP.
  3. Reconfigurar los clientes para usar LDAP en lugar de NIS.

Al finalizar el momento transcurrido entre el inicio del paso 2 y el final del paso 3, usted tiene dos bases de datos activas sin conexiones. Cualquier cambio, como la incorporación de un usuario o el cambio de la contraseña de un usuario, debe realizarse en ambas bases de datos; de otro modo, sus datos pueden no ser válidos. Puede escoger detener todos los cambios u optar por una estrategia de integración como se observa en la siguiente sección.

Análisis de su estructura NIS actual

Antes de realizar cualquier migración, debe determinar qué bases de datos serán hospedadas por NIS. Conéctese al servidor amo de NIS, y vea en el directorio de la base de datos. En la mayoría de los sistemas, los archivos se almacenan en /var/yp/, en un directorio denominado según el nombre de dominio. En el Listado 5 se muestra los archivos en un típico directorio de la base de datos del servidor NIS.

Listado 5. Determinación de qué bases de datos son abastecidas por NIS
# ls /var/yp/`domainname` 
group.bygid
group.byname
hosts.byaddr
hosts.byname
mail.aliases
netid.byname
passwd.byname
passwdbyuid
protocols.byname
protocols.bynumber
rpc.byname
rpc.bynumber
services.byname
services.byservicename
ypservers

En el Listado 5 se utiliza el comando domainname para visualizar el nombre de dominio. Cuando se coloca dentro de comillas de ejecución (`), el resultado de este comando es ingresado en la línea de comando. Con la excepción del archivo ypservers, todos los demás archivos en este directorio representan una base de datos NIS. Haga una lista de nombres de bases de datos únicos para determinar cuales son las bases de datos que se deben mover a LDAP. NIS almacena los mismos datos con diferentes claves de búsqueda, como el nombre y la UID en el caso del archivo de contraseña; en este caso, ambos representan la base de datos de la contraseña. Algunas no son tan obvias: por ejemplo, mail.aliases es la tabla de aliases. Si está en duda, vea /var/yp/Makefile para determinar la fuente de la base de datos.

Después de ver en el servidor, quizá desee examinar algunos de sus clientes NIS para determinar cuales son las correlaciones que están usando. Para esto, busque la contraseña nis en /etc/nsswitch.conf. Probablemente descubrirá que su servidor está almacenando más correlaciones que las que se utiliza.

Uso de las herramientas de migración

Las herramientas más populares para migrar los datos de NIS a LDAP son suministrados por el software PADL, los fabricantes de pam_ldap, nss_ldap, y la puerta de enlace NIS-LDAP de la que hablaremos más adelante. Hay posibilidades de que su distribución incluya los archivos; de otro modo, puede encontrar enlaces a las herramientas en la sección Resources. Las herramientas de migración PADL pueden tomar datos de los archivos locales, NIS, o NIS+ y arrojarlos a su servidor LDAP.

Antes de usar las herramientas de PADL, debe tener su servidor LDAP listo y funcionando sin datos. Las herramientas generarán todas las entradas necesarias, y usted desea evitar la duplicación.

Las herramientas de migración consisten de un conjunto de scrips shell y perl. En los sistemas RedHat, los scripts forman parte del paquete de openldap-servers y se encuentran en el directorio /usr/share/openldap/migration. Los usuarios de Debian querrán el paquete de migrationtools. Busque un archivo denominado migrate_base.pl, o descargue la última versión de PADL.

Estos scripts toman los datos de diversos recursos, los convierten en LDIF, y luego los agregan al servidor. Los datos son agregados con el comando ldapadd en el modo en línea y a través de slapadd en el modo fuera de línea, de modo que necesitará creadenciales administrativas para el primero en la lista, y su proceso LDAP tendrá que detenido para el último.

Antes de comenzar, le será útil establecer algunas variables de entorno para configurar el domain name (DN) de base del árbol y su DN raíz. En el Listado 6 se observan los comandos bash para prepararse para la migración del dominio ertw.com.

Listado 6. Determinación de las variables de entorno en preparación para una migración LDAP
export LDAP_BASEDN="dc=ertw,dc=com"
export LDAP_BINDDN="cn=root,dc=ertw,dc=com"
export LDAP_DEFAULT_MAIL_DOMAIN=ertw.com

La primera línea el el Listado 6 es el DN base del árbol LDAP, el cual será utilizado para generar todos los DNs luego. La segunda línea es su DN raíz. Usted necesita la contraseña sólo si está utilizando el modo en línea. La línea final del Listado 6 establece el nombre de dominio por omisión para las direcciones de correo electrónico. Algunas de las herramientas no le darán esta información, así que establecerlo ahora prevenirá la agravación luego.

Las herramientas están divididas en dos categorías. Los archivos en la primera categoría tienen nombres que comienzan con migrate_all_. La segunda categoría incluye los archivos restantes, los cuales tienen nombres que comienzan con migrate_ seguido del nombre de un archivo o una base de datos. Los scripts en la primera categoría se utilizan para reunir datos; la segunda categoría se utiliza para convertir el formato nativo en LDIF.

Usted tiene dos opciones. Puede utilizar uno de los scripts migrate_all_, el cual automáticamente capturará todas las bases de datos comunes de la ubicación deseada (NIS, archivos, NIS+m, etc); o puede capturar sólo los datos relevantes usted mismo y usar los scripts individuales de migración para convertir los datos en LDIF. El primer enfoque, cuando funciona, es más fácil. El Listado 7 muestra el uso de migrate_all_nis_online.sh para migrar todos los datos de NIS a LDAP en modo en línea.

Listado 7. Migración de datos desde NIS hasta LDAP usando el script migrate_all_nis_online.sh
[root@server1 migration]# ./migrate_all_nis_online.sh 
Enter the NIS domain to import from (optional):  
No such map networks.byaddr. Reason: Internal NIS error
Enter the hostname of your LDAP server [ldap]: localhost
Enter the credentials to bind with: mypassword
Do you wish to generate a DUAConfigProfile [yes|no]? no

Importing into dc=ertw,dc=com...

Creating naming context entries...
Migrating groups...
Migrating hosts...
Migrating networks...
Migrating users...
Migrating protocols...
Migrating rpcs...
Migrating services...
Migrating netgroups...
Migrating netgroups (by user)...
sh: /etc/netgroup: No such file or directory
Migrating netgroups (by host)...
sh: /etc/netgroup: No such file or directory
adding new entry "dc=ertw,dc=com"

Importing into LDAP...
adding new entry "ou=Hosts,dc=ertw,dc=com"
..... output omitted ...
adding new entry "cn=rquotad,ou=Rpc,dc=ertw,dc=com"

adding new entry "cn=rquotad,ou=Rpc,dc=ertw,dc=com"
ldap_add: Already exists (68)

/usr/bin/ldapadd: returned non-zero exit status: saving failed LDIF to
 /tmp/nis.ldif.X17515

El Listado 7 comienza con la ejecución de migrate_all_nis_onlinesh script, el cual captura datos de NIS, los convierte a LDIF, y luego utiliza ldapadd para importar los datos. La primera consulta desde el script es el dominio NIS; usted puede presionar Enter para seleccionar el dominio NIS por omisión en el sistema. El script entonces importa los datos de NIS (en este sistema, un error no fatal es impreso porque la correlación de las redes no se utiliza). El script anuncia información sobre el servidor LDAP, como el nombre de host y la contraseña (el DN de enlace y el DN de base fueron aprendidos a través de las variables de entorno que ingresó en el Listado 6). Debería elegir no importar un DUAConfigProfile al menos que tenga un esquema que los soporte, los cual es poco probable.

Si, en este punto, comienza obtener errores sobre sintaxis de DN inválida, asegúrese de haber importado el archivo nis.schema a slapd.conf.

Si su esquema es correcto, el script importará los datos a su árbol LDPA. Es improbable que el script pueda morir con un error como el que se vio al final del Listado 7. Por la forma en la cual se almacenaron los datos en NIS, puede haber duplicado entradas en algunas bases de datos. Esto está bien en NIS pero no en LDAP. Hay pocas soluciones a este problema, dependiendo de sus necesidades:

  • Edite el archivo LDIF (/tmp/nis.ldif.X17515 en este caso) para borrar los duplicados, y luego elimine la base de datos de LDAP e importe el archivo.
  • Indíquele a ldapadd que ignore los errores con la opción -c. export LDAPADD="/usr/bin/ldapadd -c" hará esto. (Tenga en cuenta que el script todavía informará error, pero los datos habrán sido importados.)
  • Edite migrate_all_nis_online.sh para establecer el valor de ETC_SERVICES, ETC_PROTOCOLS, y ETC_RPC para /dev/null en lugar de un archivo temporal. Esto evita el procesamiento de la base de datos. (Tenga en cuenta que algunos de los scritps migrate_all_ pueden ser anulados por variables de entorno, pero no la variante NIS.)
  • Saltee migrate_all_nis_online.sh, y migre manualmente.

Las primeras tres opciones se explican por si mismas y son efectivas mientras esté cómodo con los resultados (como no tener protocolos, RPC, y servicios en LDAP para la tercera opción). La cuarta opción necesita algo de explicación.

Si lo único que desea es mover grupos y usuarios a LDAP, puede simplemente copiar los archivos usted mismo y generar el LDIF usando los otros scripts suministrados, y usando ypcat para obtener datos de NIS. El Listado 8 muestra el proceso.

Listado 8. Migración de grupos y usuarios manual
[root@server1 migration]# ypcat passwd > /tmp/passwd.tmp
[root@server1 migration]# ypcat group > /tmp/group.tmp
[root@server1 migration]# ./migrate_base.pl > /tmp/ldif
[root@server1 migration]# ./migrate_passwd.pl /tmp/passwd.tmp >> /tmp/ldif
[root@server1 migration]# ./migrate_group.pl /tmp/group.tmp >> /tmp/ldif
[root@server1 migration]# ldapadd -x -D "cn=root,dc=ertw,dc=com" \
  -w "mypassword" -f /tmp/ldif
adding new entry "dc=ertw,dc=com"
adding new entry "ou=Hosts,dc=ertw,dc=com"
..... output omitted ...

Las primeras dos líneas del Listado 8 usan ypcat para obtener los datos de NIS y colocarlos en un archivo en /tmp. Las siguientes tres líneas generan LDIF. migrate_base genera algunas entradas básicas en el árbol, y las siguientes dos líneas abarcan los archivos de contraseña y grupo a LDIF. Tenga en cuenta que el usuario del operador adjunto (>>), por lo cual el archivo resultante contendrá el resultado de los tres scripts de migración. Finalmente, llama ldapadd para importar los datos.

Sea cual sea su decisión, realice algunas búsquedas básicas para asegurarse de que puede ver los datos. Asegúrese de que puede ver las password hashes (use el DN raíz para esto, porque es posible que haya listas de control de acceso evitando que se vean las contraseñas).

En este punto, tiene sus datos NIS en LDAP. Hasta que todos sus clientes NIS se hayan movido, todos los cambios a NIS deben replicarse a LDAP y biseversa.

Movimiento de clientes y verificación de resultados

Mover los clientes es sólo cuestión de configurar NSS y PAM en el cliente. La sección anterior abarcaba esto en detalle. En resumen, usted puebla /etc/ldap.conf con la información de su servidor y edita /etc/nsswitch.conf para reemplazar nis con ldap. Si está configurando PAM, entonces necesita editar los datos relevantes en /etc/pam.d para agregar referencias a pam_ldap.so.

Pruebe sus clientes conectándose a ellos como usuario regular y ejecutando los comandos getent en las bases de datos que movió a LDAP.

Enfoque 2: Integración con LDAP

El segundo enfoque habla de la coexistencia de NIS y LDAP. Esto puede ser útil si tiene clientes que no hablan LDAP (ya sea porque no tiene un módulo LDAP nativo o porque no soporta PAM), o si desea extender su transición durante un período de tiempo mayor. El enfoque para la coexistencia de NIS/LDAP es similar a la primera estrategia:

  1. Determinar qué bases de datos están en uso.
  2. Cargar los datos de NIS en LDAP.
  3. Reemplazar los servidores de NIS con ypldapd.
  4. Reconfigurar los clientes que utilizarán LDAP.

Los clientes que continuen utilizando NIS no deben realizar cambios porque ypldapd es un servidor NIS completamente funcional. La única diferencia entre este y el estándar ypserv que tiene que ver con su sistema operativo es que ypldapd obtiene sus datos de LDAP en lugar de los archivos locales.

Los primeros dos pasos son los mismos que en el primer enfoque, de modo que comience en el paso 3.

Reemplace sus servidores NIS por ypldapd

ypldapd es un daemon servidor NIS que obtiene su información de LDAP en lugar de los archivos de la base de datos en /var/yp. Se trata de un software comercial de PADL, pero usted puede obtener una licencia gratuita por 30 días enviando un correo electrónico a PADL (consulte la sección Resources). La instalación de ypldapd es un proceso simple:

  1. Descomprima el software en /opt/ypldapd.
  2. Copie la licencia en /opt/ypldapd/etc/padlock.ldif.
  3. Edite el archivo de configuración, /opt/ypldapd/etc/ypldapd.conf
  4. Detenga el servidor NIS actual.
  5. Inicie ypldapd.

Primero, ejecute mkdir -p /opt/ypldapd como raíz para conformar el directorio ypldapd (y /opt, si es que no existe). Muévase a este directorio (cd /opt/ypldapd), y descomprima la distribuciónypldapd con tar -xzf /tmp/ypldapd_linux-i386.tar.gz. Esto coloca los archivos ypldapd en el directorio correspondiente.

Se le otorgará un archivo de licencia, que usted colocará en /opt/ypldapd/etc/padlock.ldif. Si lo copia desde un correo electrónico, entonces asegúrese de que su cliente de correo electrónico no involucre lineas largas: la clave debería contener cuatro líneas de largo con una serie de pares attribute:value.

El archivo de configuración ypldapd se encuentra en /opt/ypldapd/etc/ypldapd.conf. Allí hay un archivo denominado ypldapd.conf.sample que puede copiar para empezar. Al igual que con las otras herramientas que hemos visto hasta ahora, necesita suministrar información sobre el servidor LDAP. En el Listado 9 se observa un ypldapd.conf de muestra.

Listado 9. Muestra de ypldapd.conf
# The NIS domain name
ypdomain ertw
# The LDAP server and base DN
ldaphost localhost
basedn dc=ertw,dc=com
# Credentials... The user must be able to read the userPassword attribute
binddn cn=ypldapd,dc=ertw,dc=com
bindcred mypassword
# The map of NIS databases to DNs (relative to basedn)
# If you used the migration tools then you shouldn't have to change anything
namingcontexts namingcontexts.conf
# Should ypldapd cache data?
caching on
# Cache lifetime, in minutes
cache_dump_interval 15
# Should passwords be hidden?
hide_passwords off
# How many ypldapd servers can be running at a given time?
maxchildren 5

Con ypldapd.conf en su lugar, puede cerrar todas las instancias de ypserv y luego ejecutar sbin/ypldapd, que inicia ypldapd en el entorno.

Traslado de los clientes y verificación de resultados

Para probar el nuevo servidor NIS, ejecute ypwhich, el cual le dice qué servidor NIS está destinado. Si obtiene un error, asegúrese de que no haya otras circunstancias de ypserv ejecutándose y de que sólo una ypldapd esté ejecutándose. Luego, trate de alcanzar una correlación ingresando ypcat passwd (esto supone que su servidor estaba ejecutando también un cliente).

Los clientes que se quedarán con NIS deberían poder también ejecutar ypwhich y ypcat contra el nuevo servidor. En los casos de los clientes que se muevan a LDAP, ver el conjunto anterior de instrucciones para la migración.


Integración de LDAP con servicios UNIX

Esta secciónn contiene material para el tema 305.3 del examen 301 del Senior Level Linux Professional (LPIC-3). Este tema tiene un valor de 1.

En esta sección aprenderá a:

  • Integrar SSH con LDAP
  • Integrar FTP con LDAP
  • Integrar HTTP con LDAP
  • Integrar FreeRADIUS con LDAP
  • Integrar los servicios de impresión con LDAP

La mayoría de las aplicaciones funcionan correctamente con LDAP si ha configurado NSS y PAM. A algunas aplicaciones se les recomienda el uso de PAM, o el suministro de funcionalidad adicional accediendo correctamente a LDAP. Esta sección se centra en los daemos UNIX comunes y en cómo ellos soportan la integración de LDAP

Integración de SSH con LDAP

La distribución de OpenSSH se integra con LDAP a través de PAM, junto con la funcionalidad que fue compilada. Para verificar, ejecute ldd /usr/sbin/sshd | grep pam para ver si las biblioteca compartida de PAM están conectadas. Si no, debe recompilar sshd con --with-pam.

Para usar PAM, asegúrese de tener un archivo de configuración de PAM denominado /etc/pam.d/sshd si uno no existe ya. En el Listado 10 se muestra un archivo de muestra que utiliza la pila system-auth.

Listado 10. Un /etc/pam.d/system-auth de muestra
auth       required       pam_stack.so service=system-auth
account    required       pam_stack.so service=system-auth
password   required       pam_stack.so service=system-auth
session    required       pam_stack.so service=system-auth

Con el archivo de configuración de en su lugar, puede configurar sshd para trabajar con PAM. En /etc/ssh/sshd_config, agregue UsePAM yes, e inicie sshd.

Integración de FTP con LDAP

Hay muchos daemons FTP disponibles, y no está claro cuales aplican al examen LPIC 3 .

El método más sencillo de integración es confiar en la integración NSS. Cuando el servidor FTP realiza una búsqueda de contraseña, el dispositivo NSS utiliza LDAP.

En tiempos modernos, sin embargo, es más probable que los servidores FTP sean creados con soporte de PAM. en estos casos, puede crear su archivo de configuración PAM en /etc/pam.d. Este archivo generalmente se denomina ftp, pero puede ser anulado dependiendo del software y la distribución. Por ejemplo, RedHat empaqueta el daemon vsftpd para utilizar /etc/pam.d/vsftpd en lugar del /etc/pam.d/ftp por omisión.

Una vez que el daemon ftp ha encontrado su archivo de configuación PAM, este lo procesa como cualquier otro cliente PAM. La configuración en el Listado 10 es suficiente para comenzar. Puede también considerar el uso de pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed y pam_shells en la fase auth para limitar a los usuarios que pueden conectarse y las shells válidas, como lo hicieron los servidores de FTP heredados.

Integración de HTTP con LDAP

El servidor Apache Web tiene módulos que administran autenticación básica HTTP con un backend LDAP en lugar del tradicional backend htpasswd basado en archivos. Este es suministrado a través de los módulos mod_authnz_ldap y mod_ldap . El primer módulo suminstra los mecanismos para usar información de LDAP para autenticar un usuario Web, mientras que mod_ldap proporciona una interfaz para mod_authnz_ldap (o cualquier módulo futuro basado en LDAP) para acceder a LDAP, incluyendo conectar y guardar en cache agrupamiento de conexiones.

Las instrucciones en esta sección se refieren a 2.2. Si está usando Apache 2.0, el módulo mod_auth_ldap se utiliza a para mod_authnz_ldap. La configuración de estos dos módulos es similar.

Ambos mod_ldap y mod_authnz_ldap forman parte de la distribución de Apache. Si compila su servidor Web manualmente, necesita agreagar --enable-authnz-ldap --enable-ldap a su comando configure . Si usa la versión de su distribución de Apache, entonces instale el módulo apropiado (para distribuciones de Red Hat, los módulos forman parte del paquete httpd principal).

Cuando un usuario realiza una solicitud a una fuente protegida, las devoluciones de error de Apache código 401 (no autorizado). En este punto, el navegador Web debería solicitar al usuario nombre de usuario y contraseña. El navegador Web entonces reemite la solicitud con la información decodificada en un encabezado de Autorización. Si el nombre de usuario y la contraseña son aceptados por el servidor Web, la página es suministrada al cliente; de otro modo, el servidor devuelve otro 401.

Apache, cuando está configurado para verificar contraseñas contra LDAP, primero enlaza al servidor como usuario predefinido y realiza una búsqueda en el usuario para encontrar el DN. El servidor luego reenlaza como el usuario con la contraseña suministrada. Si el servidor puede conectar con éxito como este usuario, la autenticación es considerada un éxito.

Después de una autenticación exitosa, el servidor puede configurarse para realizar tareas adicionales de autorización, como la verificación contra el DN o atributo, o la verificación para ver si el usuario pasa un filtro de búsqueda. Si alguna de estas pruebas está configurada, entonces se debe aprobar la verificación para aprobar la autorización.

La configuración de mod_authnz_ldap es similar al método estándar de autenticación usando archivos de texto. El Listado 11 muestra el caso más simple de autenticación LDAP sin autorización.

Listado 11. Configuración de Apache para la autenticación LDAP
LoadModule ldap_module modules/mod_ldap.so
LoadModule authnz_ldap_module modules/mod_authnz_ldap.so

<Location /protected>
  AuthType basic
  AuthName ProtectedByLDAP
  AuthBasicProvider ldap

  AuthLDAPUrl ldap://192.168.1138/ou=People,dc=ertw,dc=com?uid
  # Anon bind for first phase
  #AuthLDAPBindDN
  #AuthLDAPBindPassword

  AuthzLDAPAuthoritative off
  require valid-user
</Location>

Las primeras dos líneas del Listado 11 cargan los módulos requeridos en el servidor Web. El resto de la configuración se coloca en un contenedor Location container, lo cual significa que aplica sólo a solicitudes que comienzan con /protected. La configuración primero declara la autenticación básica y un nombre de ProtectedByLDAP. El navegador Web muestra el nombre al usuario. La línea AuthBasicProvider le dice a Apache que la autenticación es suministrada a través de LDAP.

En el Listado 11 se continua con AuthLDAPUrl, el cual señala Apache al servidor LDAP. La forma del parámetro es ldap://host:port/basedn?attribute?scope?filter. host y port define el servidor LDAP, y basedn es el DN base desde el cual la búsqueda inicl se realizad. attribute se refiere al atributo que será buscado junto con el nombre de usuario junto con el nombre de usuario durante la búsqueda inicial (por omisión es uid). scope es one o sub para corresponder cun un nivel o con todos los hijos. filter es un filtro opcional que logicamente será ANDed con al búsqueda para la combinación correspondiente user/attribute.

El ejemplo en el Listado 11 tiene AuthLDAPBindDN y AuthLDAPBindPassword entre comentarios, lo cual ocasiona un enlace anónimo. Si desea especificar un usuario aquí, puede. De cualquier modo, el usuario que realiza el enlace inicial debe poder buscar en el atributo suministrado en el comando AuthLDAPUrl.

Las últimas dos líneas desactivan la autorización permitiendo cualquier usuario valido. AuthzLDAPAuthoritative off significa que a un módulo atrasado se le puede permitir el permiso aún si LDAP niega la autorización (pero no la autenticación). require valid-user proviene de otro módulo, de modo que este atraso es necesario. En lugar de estas dos líneas, puede usar LDAP relacionados, como la verificación de la membresía de grupo o un atributo LDAP. El Listado 12 muestra parte de la configuración del Listado 11, pero restringe el acceso a las personas con el atributo y el valor ou=Engineering.

Listado 12. Restricción de acceso a una OU particular
AuthzLDAPAuthoritative  on
require ldap-filter ou=engineering

Hay que destacar dos cosas del Listado 12. Primero, AuthzLDAPAuthoritative está ahora activo (este es el valor por omisión) porque su requisito puede ser administrado por el módulo LDAP. Segundo, el ldap-filter no incluye paréntesis. Apache utiliza el filtro LDAP determinado y también realiza una AND lógica con la uid (o con el atributo que especifique usted en el comando AuthLDAPUrl) y crea el filtro de búsqueda simplemente con la inserción de una cadena. Si tiene comillas o paréntesis adicionales en su filtro, la consulta resultante será inválida. La autenticación falla, y aparece un mensaje de registro en el error_log del servidor.

Integración de FreeRADIUS con LDAP

FreeRADIUS es un servidor Remote Authentication Dial In User Service (RADIUS) de fuente abierta que a menudo se utiliza para la autenticación de dial-up u otros servicios de redes. Los clientes usan RADIUS para autenticar usuarios, y el servidor RADIUS a su vez utiliza LDAP para encontrar su información.

Usted puede integrar PAM y FreeRADIUS de dos formas: usando PAM, o activando el soporte LDAP nativo a través del módulo rlm_ldap. La elección depende de cómo planee usar RADIUS. Si sólo necesita la autenticación, o no desea modificar su esquema LDAP, entonces use PAM. Si necesita usar atributos de RADIUS es más sencillo configurar el módulo LDAP y almacenar los atributos en LDAP (RADIUS permite al servidor enviar detalles de configuración al dispositivo que solicita autenticación, lo cual le permite suministrar diferentes servicios a distintos usuarios).

En el modo PAM, asegúrese de que PAM esté configurado para LDAP como los otros sistemas. La configuración del archivo de PAM para FreeRADIUS es /etc/pam.d/radiusd. Partiendo de los archivos de configuración por omisión que vienen con FreeRADIUS, quite las barras de comentario de la palabra clave pam en la sección authenticate de radiusd.conf. Luego, edite el archivo de los usuarios y busque DEFAULT Auth-Type = System. Cambie la palabra clave System por PAM. Reinicie radiusd, y listo.

El módulo LDAP nativo, rlm_ldap, es más complejo. Primero, debe tener FreeRADIUS instalado en su sistema, cree con el módulo rlm_ldap (--enable-ldap). FreeRADIUS es creado como la mayoría de los paquetes así que no lo explicaremos aquí. Si su distribución Linux incluye FreeRADIUS, probablemente incluya el módulo LDAP.

FreeRADIUS incluye un esquema LDAP en un archivo denominado openldap.schema. Copie este a /etc/openldap/schema/freeradius.schema, e impórtelo a OpenLDAP a través de la directiva include en slapd.conf. El esquema proporciona varios atributos y dos objectClasses. Una de las clases de objetos es radiusprofile; este se utiliza para cualquier usuario que sea autenticado con RADIUS. radiusprofile es un objectClass auxiliar y por lo tanto puede incluirse en cualquier entrada. radiusObjectProfile es un objectClass estructural utilizado para crear contenedores de perfiles radius; no es necesario para la operación.

Luego, edite el archivo de usuarios por omisión como en el ejemplo de PAM, pero en lugar de cambiar el método por omisión por PAM, coloque entre comentarios toda la sección. Este archivo controla el modo en el que los usuarios se autentican y autorizan. Eliminar el método por omisión es suficiente para permitir que el módulo LDAP asuma el control y administre la autenticación y autorización de usuarios.

radiusd.conf necesita más trabajo. En ambas secciones, authenticate y authorize quite las barras de comentario de la palabra clave ldap que permite la autenticación y autorización de LDAP. Debe además encontrar una sección que se parezca a Auth-Type LDAP { ldap } y quitar las barras de comentario también de allí. Finalmente, quite las barras de la sección ldap { ... } e ingrese la dirección de su servidor, el DN base, e información de autenticación opcional. Al igual que otros softwares, el enlace inicial realiza la búsqueda del DN de usuario; luego, un segundo enlace se realiza cuando el usuario confirma la contraseña y recupera los atributos. Por lo tanto, el usuario como el que inicialmente estaba enlazado (o anónimo si no ha configurado el usuario) debe poder realizar búsquedase en el atributo uid, y los usuarios deben poder leer sus propios atributos.

Los usuarios que necesitan ser autenticados por LDAP deben usar la objectClass radiusProfile y tener un atributo dialupAccess con algún valor en él, como "yes". Con configuraciones más avanzadas, puede usar el valor para aplicar diferentes configuraciones, pero para fines básicos, el atributo puede tomar cualquier valor.

FreeRADIUS es un servidor RADIUS extremadamente sólido, y gran parte de la configuración puede ser necesaria para hacer lo que necesita. Las dos configuraciones que se muestran aquí se centran en lo que es necesario para tener LDAP funcionando.

Integración de CUPS con LDAP

El Common UNIX Printing System (CUPS) es el daemon de impresión favorito actualmente porque es fácil de configurar, soporta el Internet Printing Protocol (IPP), y es compatible con las herramientas lpr tradicionales. CUPS soporta PAM, pero debe indicársele cómo y cuándo autenticar.

Primero edite /etc/pam.d/cups de modo que soporte LDAP. Luego, en /etc/cups/cupsd.conf, cree para sus impresoras un contenedor que requiera autenticación, como se observa en el Listado 13.

Listado 13. Contenedor de impresora que requiere autenticación
<Location /printers>
        AuthType Basic
</Location>

En el Listado 13 se muestra una configuración que requiere autenticación básica para cualquier URL que comienza con /printers. La configuración CUPS es casi idéntica a la de Apache, así que esta configuración le recordará la del Listado 11. Sin embargo, CUPS está usando PAM en lugar de un módulo LDAP nativo, de modo que no es necesaria la configuración de LDAP. CUPS usa PAM para la autenticación porque así está configurado. Pero, cuando usted trata de navegar en una URL /printers, la cual incluye la impresión a una impresora, se le solicita una contraseña. El Listado 14 muestra dicha solicitud.

Listado 14. Verificación de que CUPS está funcionando con LDAP
[sean@bob LPIC-III_5]$ lpr index.xml 
Password for sean on localhost? mypassword
[sean@bob LPIC-III_5]$

Si la contraseña fuese incorrecta o PAM no estuviera funcionando, entonces en el Listado 14 habría aparecido otra solicitud de contraseña. PAM resultó exitoso, así que el documento se imprimió y el usuario volvió al prompt del shell.


Integración de LDAP con Samba

Esta sección contiene material para el tema 305.4 del examen Senior Level Linux Professional (LPIC-3). Este tema tiene un valor de 1.

En esta sección, aprenda cómo:

  • Migrar de smbpasswd a LDAP
  • Comprender el esquema OpenLDAP Samba
  • Comprender LDAP como backend de contraseña de Samba

Samba es la forma en que la comunidad UNIX se integra con las redes de Microsoft Windows. Con este software, puede compartir archivos con redes de Microsoft (tanto cliente como servidor) y hacer que su computadora UNIX aparezca como una computadora Windows para los otros clientes de Windows.

Comprensión de la autenticación de Samba

El objetivo de Samba es la integración con redes de Windows, así que debe utilizar los mecanismos de autenticación que usa Windows. Si está autenticando contra un servidor de Windows, está bien, pero a menudo el servidor de Samba funciona como depósito de las credenciales. Por lo tanto, dos copias de las hashes de contraseñas son necesarias — una para las contraseñas UNIX tradicionales y otra para las hashes de Microsoft.

Las contraseñas de Microsoft son similares a las contraseñas de UNIX en que son hashes de la contraseña verdadera. Una función hash es una función unidireccional que acepta una entrada de longitud variable (como una contraseña) y devuelve una hash de longitud fija (cadena). Es imposible tomar la hash y recuperar la clave original, aunque podría tratar millones de entradas diferentes con la esperanza de que la hash obtenida coincida.

Las dos hashes de contraseña diferentes son almacenadas como contraseñas de Microsoft: la hash LANManager y la hash Windows NT. La primera no es tan segura como la segunda porque se hicieron varias cosas a la contraseña original antes del hashing que reduce la cantidad de datos de salida posibles. La hash Windows NT ha sido diseñada para superar estas limitaciones. Aunque ambas hashes sean almacenadas, usted puede elegir desactivar el soporte LANManager si todos sus clientes soportan hashes NT (disponible en Windows NT SP 3 y versiones superiores).

Samba ha almacenado tradicionalmente las hashes de contrasaña en el archivo smbpasswd y usa herramientas como smbpasswd para administrar el archivo de contraseña por el mismo nombre. Esto puede moverse fácilmente a LDAP de modo que múltiples servidores Samba pueden autenticarse sin necesidad de usar Primary Domain Controllers u otra infraestructura de Microsoft. Almacenar datos en LDAP también reduce la duplicaicón de información en la red.

Comprensión del esquema de Samba

Las contraseñas NT son diferentes a las contraseñas UNIX y no pueden almacenarse en el atributo userPassword. Por lo tanto, el esquema LDAP debe ampliarse para almacenar las hashes de contraseña y otras piezas de información que un dispositivo de Microsoft espera que estén disponibles.

El archivo de esquema se distribuye con la suite de Samba como samba.schema. Copie este archivo a /etc/openldap/schema, y use la directiva include en slapd.conf para integrarlo al esquema de su servidor.

samba.schema incorporta varias clases de objetos nuevas, las cuales son explicadas en la Tabla 4.

Tabla 4. Clases de objetos en samba.schema
clase de objetoDescripción
sambaSamAccountSuministra la información necesaria para una cuenta (computadora, usuario, etc.) en un entorno.
sambaGroupMappingCorrelaciona un grupo UNIX a un grupo Windows.
sambaTrustPasswordSuministra información de autenticación sobre las relaciones entre los dominios.
sambaDomainAlmacena información sobre el dominio en el árbol LDAP. Encontrará que uno de estos es agregado automáticamente a su árbol LDAP después de configurar Samba/LDAP.

Configuración de Samba para LDAP

Configurar Samba para LDAP implica editar smb.conf para configurar la fuente de datos LDAP y luego administrar las entradas LDAP de los usuarios para que se enteren de los nuevos atributos de Samba.

En smb.conf, encontrará una línea como passdb backend = tdbsam, la cual representa el mecanismo de almacenamiento de archivos smbpasswd. Reemplácela con el código que aparece en el Listado 15, modificado según su entorno.

Listado 15. Uso del almacenamiento de contraseñas ldapsam
# ldapsam requires the uri to the LDAP server
passdb backend = ldapsam:ldap://192.168.1.138/
# A user in your LDAP server that can read and write the new attributes
# The password will be entered later
ldap admin dn = cn=root,dc=ertw,dc=com
# Same as search base
ldap suffix = dc=ertw,dc=com
# OUs for users/computers/groups
ldap user suffix = ou=People
ldap machine suffix = ou=Computers
ldap group suffix = ou=Group

Una vez que ha configurado smb.conf, reinicie Samba y ejecute smbpasswd -W. Se le pedirá la contraseña para el DN admin de LDAP que ingresó en smb.conf. En este punto, Samba usará datos de LDAP para autenticar usuarios.

Administración de usuarios Samba en LDAP

Los usuarios deben configurar con la clase de objeto sambaSamAccount antes de usar Samba, lo cual implica la configuración de las hashes de contraseña y la asignación de un security identifier (SID) al usuario. Esto es fácil de hacer con la herramienta smbpasswd, la cual tradicionalmente agregaba usuarios al archivo smbpasswd. smbpasswd administrará un usuario LDAP si smb.conf está configurado para utilizar LDAP, como se observa en el Listado 15.

Para configurar un nuevo usuario, primero asegúrese de que la cuenta del usuario esté configurada con la clase de objeto posixAccount y un atributo uid, el cual debería estar allí si los el usuario se conecta a través de LDAP y PAM o NSS. Luego, ejecute smbpasswd -a username para modificar la entrada LDAP del usuario, la cual incluye la configuración de la contraseña de Samba. El Listado 16 muestra una típica entrada de usuario después de realizar la configuración para Samba.

Listado 16. Entrada de usuario Samba
dn: cn=Jim Joe,ou=people,dc=ertw,dc=com
givenName: Jim
sn: Joe
cn: Jim Joe
uid: jjoe
uidNumber: 1000
sambaSID: S-1-5-21-2287037134-1443008385-640796334-
userPassword:: e01ENX1yTDBZMjB6QytGenQ3MlZQek1TazJBPT0=
sambaLMPassword: 5BFAFBEBFB6A0942AAD3B435B51404EEsambaNTPassword: AC8E657F83DF82BEEA5D43BDAF7800CC
loginShell: /bin/bash
gidNumber: 4
homeDirectory: /home/a
sambaAcctFlags: [U]
objectClass: inetOrgPerson
objectClass: sambaSamAccount
objectClass: posixAccount
objectClass: top

Las líneas en negrita del Listado 16 fueron agregadas por smbpasswd. Partiendo de arriba, un SID es agregado a la cuenta. El uso de smbpasswd lo libera de la necesidad de para calcular esto, porque smbpasswd descifra que SID utilizar. Luego, las hashes de contraseña LanManager y NT son almacenadas. La sambaAcctFlags se utiliza para almacenar algunos atributos de la entrada. Estos son algunos de los valores que puede contener este indicador:

  • N: no se requiere contraseña
  • D: cuenta desactivada
  • H: se requiere directorio principal
  • T: duplicación temporal de otra cuenta
  • U: cuenta de usuario regular
  • M: MNS (Majority Node Set cluster) logon user account
  • W: Workstation Trust Account
  • S: Server Trust Account
  • L: bloqueo automático
  • X: la contraseña no ha expirado
  • I: Domain Trust Account

Finalmente, la clase de objeto sambaSamAccount habilita todos estos atributos.

Además de aquellos aquí descriptos, puede establecer muchas otras opciones para llevar más información específica de Windows. Constulte la página del manual pdbedit para aprender sobre la lectura y la modificación de información de usuario de Samba desde la línea de comando. Samba puede actuar como Primary Domain Controller (PDC) de Windows, y la información adicional es necesaria para que los clientes de Windows funcionen correctamente.

Sincronización de la contraseña

Ahora que hay dos conjuntos de contraseñas (userPassword y las dos hashes de Samba), debe encontrar la forma de mantener las contraseñas sincronizadas. Si un usuario cambia su contraseña de Samba, o desde la línea de comando o desde un cliente de Windows, la contraseña UNIX debería modificarse. Asimismo, si un usuario modifica la contraseña UNIX, la contraseña de Samba debería cambiar.

El primer caso es más sencillo. Agregue ldap password sync = yes a la sección [global] de smb.conf, y reinicie Samba. Cualquier otro cambio a la contraseña modificará las hashes de Samba y userPassword .

Cambiar las contraseñas de Samba cuando un usuario modifica su contraseña a través del comando de UNIX passwd requiere de PAM. Samba viene con mod_smbpasswd, el cual se utiliza para autenticar y cambiar contraseñas a través del sistema Samba. Por ahora, no hay necesidad de autenticar contraseñas, de modo que sólo la función password será utilizada. El Listado 17 muestra parte de un archivo de configuración de PAM que, cuando se utiliza, modifica las contraseñas de UNIX y Samba en LDAP.

Listado 17. Pila de contraseñas PAM para modificar contraseñas UNIX y Samba
password    requisite     pam_cracklib.so try_first_pass retry=3
password    optional      pam_smbpass.so use_authtok use_first_pass
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

En el Listado 17, la línea agregada se muestra en negrita. El módulo pam_smbpass se menciona como opcional de modo que si un usuario no está configurado como usuario de Samba, ese paso fracasará. La modificación de la contraseña de Samba se realiza antes de que cambien las contraseñas de UNIX y LDAP, porque estas dos se marcan como suficientes, lo que significa que para que la primera para tener éxito detiene el proceso.

Con el Listado 17 en su lugar, un usuario que cambia su contraseña desde la línea de comandos también cambiará la contraseña de Samba.

Migración de usuarios existentes a LDAP

Cuando se traslada a un backend LDAP, probablemente tenga usuarios existentes en un mecanismo de contraseña basado en archivos que debe migrar. La herramienta pdbedit puede copiar cuentas de un lugar a otro para facilitar esta tarea.

En el Listado 18 se muestra el uso de pdbedit para migrar usuarios. El parámetro -i establece la fuente de los datos, y el parámetro -e determina el destino. Antes de ejecutar el comando pdbedit, debería tener la base de datos ldapsam configurada en smb.conf.

Listado 18. Migración de usuarios de tdbsam a ldapsam
[root@server1 ~]# pdbedit -e ldapsam -i tdbsam
Importing account for fred...ok
Importing account for jsmith...ok

Si está utilizando en antiguo backend de contraseña smbpasswd, utilice smbpasswd en lugar de tdbsam.


Esta sección contiene material para el tema 305.5 del examen Senior Level Linux Professional (LPIC-3). Este tema tiene valor de 2.

En esta sección aprenderá sobre:

  • La integración de Kerberos con LDAP
  • La autenticación multiplataforma
  • Conceptos de conexión simple
  • Limitaciones de la integración y la compatibilidad entre OpenLDAP y Active Directory

Microsoft Windows pueden encontrarse en casi todas las compañías; hay grandes posibilidades de que su entorno ya utilice Active Directory, el servicio de directorio empresarial de Microsoft. Active Directory está basado en dos protocolos abiertos: LDAP y Kerberos. Si comprende estos protocolos y configura el sistema Linux adecuadamente, su caja Linux puede autenticar contra el directorio de la empresa y facilitar single sign on (SSO). Esto significa que usted se conecta a su máquina una vez y sus credenciales son válidas en toda la red.

Comprensión de Kerberos

Kerberos, denominado según el perro de tres cabezas de Hades en la mitología griega, es un protocolo que permite a usuarios y servidores suministrarse mutuamente la identidad a través de una red de confianza. Se desarrolló en el Massachusetts Institute of Technology (MIT) para ser utilizado en su red y desde entonces encontró su lugar en muchas otras redes. Microsoft eligió utilizarlo a partir de Active Directory de Windows 2000.

Kerberos V es la corriente desarrollada actualmente, aunque puede encontrarse con Kerberos IV de vez en cuando. Kerberos V es compatible con versiones anteriores para sistemas que todavía utilizan Kerberos IV.

El protocolo de Kerberos

Kerberos es un protocolo que permite a un servicio autenticar la identidad de un usuario sin necesidad de ver la contraseña. Esto se logra teniendo un servidor de confianza compartido, denominado Authentication Service (AS). El AS comparte un secreto con cada usuario y servicio. El secreto se utiliza para proteger información entre el AS y el otro extremo de la conversación; hasta permite al AS dar al usuario un mensaje (denominado ticket) destinado a otra persona. En este último caso, los usuarios no pueden leer el ticket porque no tienen el secreto compartido.

todos los clientes y servidores forman el reino de Kerberos, el cual es muy parecido a un dominio NIS o en algunos aspectos al DN de base de un árbol LDAP. El reino define todos los dispositivos y personas que autentican a un conjunto común de servidores de Kerberos. Generalmente, el reino es la zona DNS de la organización escrita en mayúsculas, como ERTW.COM. Para los fines de Kerberos, los clientes son las computadoras que obtienen tickets de un servidor de Kerberos. Los servidores son dispositivos que suministran el servicio de entrega de tickets de Kerberos.

Todo lo que es autenticado en el reino de Kerberos tiene un correspondiente principal de Kerberos que lo identifica y está relacionado con la contraseña o el secreto compartido. Cuando un usuario se conecta a un servidor, se está conectando en realidad a un servicio que se ejecuta en el servidor. Cada servicio se trata por separado y debe registrarse como principal con el servidor de Kerberos. Un principal de servicio tiene la forma de servicename/servername@REALM, mientras que un principal de usuario tiene la forma de user@REALM.

El protocolo de Kerberos se observa en la Figura 1.

Figura 1. El protocolo de Kerberos
El protocolo de Kerberos

Podemos decir que el protocolo de Kerberos tiene dos fases distintas: la conexión inicial del usuario al reino, y la autenticación del usuario al servicio. Lo magico de Kerberos es que la conexión inicial sucede sólo una vez; la autenticación de servicio subsecuente puede suceder muchas veces en muchos servidores.

La primera fase de Kerberos comienza cuando el usuario solicita al servidor de Kerberos (específicamente, un componente denominado el Key Distribution Center [KDC]) un Ticket Granting Ticket (TGT), el cual se utilizará más tarde para solicitar el servicio. El KDC genera un TGT, lo encripta con la contraseña del usuario, y lo envia de nuevo al usuario.

El TGT ha sido enlazado al pase de visitante en una compañía. Usted debería mostrar su identificación al guardia de seguridad (KDC) y se le otorgará un pase de visitante válido por un día. Este proceso le permite mantener su propia ID a salvo y también limita la exposición de la compañía a pases de visitantes robados. El TGT expira en un corto período de tiempo, gereralmente de 8 horas.

En la segunda fase, el usuario decide si necesita acceder a un servicio. El usuario envía una solicitud al componente Ticket Granting Service (TGS)del servidor Kerberos, el cual incluye el TGT y el nombre del servicio (el principal). El TGS verifica para ver si el TGT todavía es válido y luego emite un ticket que ha sido encriptado con el secreto compartidodel servicio. Finalmente, el usuario presenta este ticket al servicio. Si el serviciopuede desencriptar con éxito el ticket, entonces el servicio sabe que el sistema Kerberos aprobó la solicitud. No hay contraseñas que hayan atravesado la red.

Kerberos previene ataques de replay, en el que un atacante captura un ticket y lo utiliza de nuevo, imponiendo tiempos de vida limitados en los tickets e incluyendo marcas de tiempo en el ticket encriptado. Un ticket para un servicio puede ser válido por 5 minutes, de modo que el servicio tiene que recordar el valor del ticket sólo por 5 minutes si un ticket ha sido replayed. Todos los relojes deben sincronizarse para que esto funcione.

¿Qué relación tiene LDAP con todo esto?

Kerberos suministra sólo el marco de la autenticación, muy parecido a lo que hace el sistema PAM. La información de usuario no es almacenada en la base de datos de Kerberos.

Los secretos de Kerberos pueden ser almacenados en la base de datos de LDAP o pueden dejarse por separado. La elección depende de la implementación de Kerberos. En cualquier caso, LDAP se utiliza para almacenar la información de usuario como el directorio principal y la información personal.

Debe mantener su base de datos de Kerberos segura más allá de donde la almacene. Las claves de Kerberos son como contraseñas: pueden ser robadas y utilizadas para generar TGTs y tickets. La mayoría de las guías recomiendan mucho mantener su servidor Kerberos en su propio dispositivo y protegerlo tanto como sea posible.

Configuración de Microsoft Active Directory para invitados de Linux

Active Directory utiliza implementaciones de Kerberos y LDAP que son compatibles con estas que incluye Linux. Microsoft ha extendido Kerberos para soportar atributos específicos de Windows, pero esto no impide que usuarios de UNIX lo utilicen (consulte la sección Resources para ver la documentació de Microsoft sobre el tema).

El esquema de Active Directory debe ampliarse para soportar algunos de los atributos de UNIX, lo cual es fácil en el servidor de Windows 2003. Diríjase al panel de control de su controlador de dominio, y elija Add or Remove Programs > Add/Remove Windows Components. Desde el componente Active Directory Services, elija el subcomponente Identity Management for UNIX. (si tiene una versión anterior de Windows, este componente a veces se denomina Server for NIS). Instale este software, y el esquema de LDAP se ampliará; los diálogos de usuario también incluirán una etiqueta UNIX Attributes (atributos Unix), que utilizará pronto.

desde la aplicación Active Directory Users and Computers, edite el grupo de seguridad de usuarios de dominio. Tenga en cuenta la etiqueta, UNIX Attributes. Asigne un grupo y un dominio NIS a su grupo de usuarios de dominio, como se observa en la Figura 2. Así permitirá que el grupo sea visto por los sistemas UNIX. Este grupo será el grupo primario del usuario.

Figura 2. Asignación de atributos UNIX a un grupo
Asignación de atributos UNIX a un grupo

Todavía en el contenedor Users, encuentre un usuario que desee utilizar en sus servidores UNIX. Encuentre la etiqueta UNIX Attributes para este usuario, y asigneles los atributos UNIX estándares. En la Figura 3 se observa un usuario de muestra.

Figura 3. Los atributos UNIX de un usuario
Los atributos UNIX de un usuario

El usuario en la Figura 3 ha sido asignado a un grupo primario, un directorio principal, un shell, y una id de usuario.

Luego, debe crear una cuenta de servicio que permita el acceso a su árbol LDAP, porque el acceso anónimo está desactivado por omisión. Use la siguiente configuración para este usuario:

  • Name: cuenta de servicio LDAP (o la que elija)
  • User logon name: ldap (o la que elija)
  • Password: a su elección
  • User can't change password: seleccionado
  • Password never expires: seleccionado
  • Primary group: invitados de dominio

Los miembros de la cuenta de servicio deberían ser ser sólo invitados de dominio. Desde la etiquetaMember Of , agregue el grupo invitados de dominio (Domain Guests) a la cuenta, destáquelo en la lista de grupos, luego haga clic en el botón Set Primary Group. Una vez cambiado el grupo, puede quitar el grupo Domain Users (usuarios de dominio) del perfil.

Si la políticas de seguridad prohiben las opciones de contraseña, tendrá que ajustar la configuración de Linux (descripto luego) cada vez que cambia la contraseña. Tenga en cuenta que LDAP se utiliza aquí sólo para información de directorio y no para contraseñas, de modo que el requisito para cambiar contraseñas está disminuida.

Configuración de Linux

El lado Linux de la ecuación involucra tres pasos. Primero, configurar el acceso al directorio a través de /etc/ldap.conf. Luego, configurar PAM para autenticación de Kerberos. Finalmente, configurar Samba para usar la informació de Active Directory para la autenticación, y unir esto al dominio.

Antes de comenzar, debe asegurarse de que la máquina Linux esté usando su servidor Microsoft para DNS y tiempo de red. Su servidor Linux debe además tener un registro de host en la zona DNS de Microsoft para su dominio.

Configuración de LDAP

LDAP se configura igual que antes, salvo por el hecho de que se requiere alguna correlación de atributos UNIX con atributos Microsoft. En el Listado 19 se muestra /etc/ldap.conf configurado para acceder a un directorio LDAP de Microsoft usando la cuenta del usuario configurada anteriormente.

Listado 19. Configuración de ldap.conf para usar un directorio de Microsoft
# Information about the directory
uri ldap://192.168.1.151
binddn ldap@ertw.com
bindpw ldap
ssl no
base dc=ertw,dc=com

# Map attributes
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
nss_map_objectclass posixGroup group
nss_map_attribute uniqueMember member
pam_login_attribute sAMAccountName
pam_filter objectclass=User
pam_password ad

La configuración que se muestra en el Listado 19 primero indica el módulo al servidor LDAP de Microsoft usando las credenciales configuradas anteriormente. Los atributos son correlacionados desde el nombre UNIX hasta el nombre Microsoft, como el uso de sAMAccountName para la id de usuario.

Finalmente, agregue ldap winbind a las secciones passwd, group, y files allí). Esto le permite al sistema obtener información del directorio desde LDAP y Samba (el último será configurado más tarde).

Luego, puede ejecutar getent passwd para ver los usuarios de LDAP. Tenga en cuenta que debe establecer los atributos de UNIX para el usuario en Active Directory para que el usuario aparezca en la lista.

Configuración de Kerberos

Kerberos se configura a través de PAM y el archivo /etc/krb5.conf. Si está utilizando su servidor DNS de Microsoft para su DNS, entonces sólo debe especificar su reino, porque el servidor será aprendido automáticamente de DNS. El Listado 20 muestra los contenidos de /etc/krb5.conf

Listado 20. /etc/krb5.conf para el reino ERTW.COM
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = ERTW.COM
 dns_lookup_realm = false
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 forwardable = yes

[realms]
 ERTW.COM = {
  default_domain = ertw.com
 }

[domain_realm]
 .ertw.com = ERTW.COM
 ertw.com = ERTW.COM

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }

krb5.conf está dividido en secciones, con el nombre de la sección entre corchetes. Las ección de conexión especifica las rutas de diversos archivos de registro. Las secciones libdefaults configuran las bibliotecas de Kerberos: en particular, dns_lookup_kdc le indica a la biblioteca buscar en el servidor regristros de servidor (SRV) en DNS para encontrar el KDC. El registro se parece a _kerberos._tcp.ERTWCOM., y la respuesta es el nombre del servidor y el puerto de contacto.

La sección de los reinos define los reinos y las zonas DNS relacionadas. La sección domain_realm hace lo contrario: permite a un host determinar su reino en base a su fully qualified domain name (FQDN). Finalmente, la sección appdefaults es para aplicaciones que usan Kerberos; en este caso, PAM ha sido configurado con algunas opciones por omisión.

En la práctica, hay poco para configurar en krb5.conf porque el archivo de configuración por omisión tiene todos los elementos necesarios. Todo lo que tiene que hacer es sustituir su reino y nombre de dominio donde sea apropiado. Usted puede además usar la herramienta de configuración de Kerberos del sistema, como authconfig.

La configuración de PAM es como las configuraciones anteriores de LDAP y smbpasswd. Agregue una llamada a la biblioteca PAM de Kerberos donde sea apropiado. El Listado 21 muestra parte del archivo system-auth de Fedora después de la configuración de Kerberos.

Listado 21. Archivo system-auth después de la configuración de Kerberos
auth        sufficient    pam_unix.so nullok try_first_pass
auth        sufficient    pam_krb5.so use_first_pass
auth        required      pam_deny.so

account     required      pam_unixso broken_shadow
account     [default=bad success=ok user_unknown=ignore] pam_krb5.so
account     required      pam_permit.so

password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_krb5.so use_authtok
password    required      pam_deny.so

session     required      pam_unix.so
session     optional      pam_krb5.so

Kerberos ha sido agregado directamente después de la verficación de la contraseña UNIX en la fase de autorización como elemento suficiente. Esto significa que si una contraseña UNIX se encuentra, Kerberos no es consultado. Si no se encuentran contraseñas UNIX, entonces Kerberos es consultado. Si Kerberos falla, la pila falla. Si no se encuentra un usuario, el control pases al módulo pam_deny, el cual provoca un error.

La fase de cuenta utiliza una sintaxis alternativa a la que ha visto hasta ahora. cada módulo PAM puede devolver distintas opciones, como "success" o "no such user". Los corchetes permiten al administrador tomar una acción diferente en base a cada código que puede obtenerse. El Listado 21 implementa una política que dice que si pam_krb5 devuelve un resultado exitoso, entonces continue el procesamiento. Si el usuario es desconocido, entonces ignora el módulo por completo. Cualquier otra cosa se considera una falla. Este comportamiento es cerrado a la palabra clave solicitada, con la excepción de que un usuario desconocido no causa una falla. Consulte la página del manual pam.conf(5) para obtener más detalles sobre esta sintaxis, incluyendo las opciones.

La fase de contraseña y sesión incluye el módulo en la pila sin opciones especiales.

En este punto, debería poder conectarse a su servidor Linux usando las credenciales de Active Directory. El próximo paso configura Samba y asegura además la conexión creando una cuenta de computadora para el servidor.

Configuración de Samba y unión del dominio

Para la configuración de Samba, debe primero borrar el backend de contraseñas existente de smb.conf, y cualquier archivo tdb de in /etc/samba y /var/cache/samba. El Listado 22 muestra las directivas que debe agregar a la sección [global] de smb.conf para permitir a Samba utilizar AD.

Listado 22. Configuración de Samba para la integración de AD
# Active directory security
security = ads
realm = ERTW.COM
use kerberos keytab = yes

# Identity mapping
idmap backend = ad
ldap idmap suffix = dc=ertw,dc=com

# LDAP configuration
ldap admindn = cn=ldap,cn=users,dc=ertw,dc=com
ldap suffix = dc=ertw,dc=com

# Winbind
winbind use default domain = yes
winbind nested groups = yes

El Listado 22 comienza especificando que el modo de seguridad de ADS se utiliza (servidor Active Directory remoto), junto con el reino de Kerberos. La segunda sección configura idmapping, el cual es un dispositivo que correlaciona SIDs remotos de Microsoft con ids locales de UNIX. Esta configuración especifica que Active Directory es la fuente de la información. La correlación corre por cuenta de Microsoft, porque ya ha ingresado las IDs en la etiqueta UNIX Attributes de los usuarios y grupos. Su servidor sólo tiene que obtener esta información de LDAP.

La configuración de LDAP es familiar; esta establece el DN para la conexión de LDAP para el usuario ldap creado anteriormente. Tenga en cuenta que el contenedor es cn=users en lugar de ou=people que ha visto hasta ahora. La contraseña es ingresada a través de smbpasswd.

Las últimas dos líneas habilitan Winbind, que es una implementación de algunas de las llamadas de procedimiento remoto de Microsoft (consulte Resources si desea más información sobre Winbind). esto le permite obtener más información de su servidor Active Directory, y no sólo de los grupos y usuarios par alos cuales ha agregado los atributos UNIX.

Después de la configuración de smb.conf, inicie los servidios de Samba y winbind.

Los pasos finales en la configuración de Samba son establecer la contraseña admindn y unir su dominio. El Listado 23 muestra a la computadora uniendo el dominio.

Listado 23. Configuración de la contraseña admindn y unión del dominio
[root@server1 ~]# smbpasswd -W
Setting stored password for "cn=ldap,cn=users,dc=ertw,dc=com" in secrets.tdb
New SMB password: ldap
Retype new SMB password: ldap

[root@server1 ~]# net ads join -U administrator
administrator's password: mypassword
Using short domain name -- ERTW0
Joined 'SERVER1' to realm 'ERTW.COM'

Pruébelo

Debería poder conectarse a su servidor con las credenciales de Active Directory y navegar en los archivos compartidos de una computadora remota sin tener que conectarse. Algunos de los comandos útiles para probar son:

  • net ads testjoin: prueba la cuenta de la computadora
  • wbinfo -u: muestra una lista de usuarios de Active Directory y prueba winbind
  • klist: después de conectarse a través de Kerberos, le muestra su TGT y cualquier otro ticket de servicio que ha sido emitido
  • smbclient -k -L '\\SERVERNAME': muestra una lista de los archivos compartidos desde SERVERNAME, usando una conexión de Kerberos

Integración de LDAP con los servicios de correo electrónico

Esta sección contiene material para el tema 305.6 del examen Senior Level Linux Professional (LPIC-3). Este tema tiene valor de 1.

En esta secció aprenderá a:

  • Planificar la estructura del esquema LDAP para servicios de correo electrónico
  • Crear atributos de correo electrónico en LDAP
  • Integrar Postfix con LDAP
  • Integrar sendmail con LDAP

sendmail y Postfix son dos de los more popular mail transport agents (MTAs) en uso. La tarea de MTA es recibir mensajes de los sistemas y enviarlos para entregarlos al usuario final o al próximo hop MTA. MTAs también toma mensajes de usuarios y encuentra el MTA remoto que es capaz de entregar el mensaje.

Tanto sendmail como Postfix confian en varias correlaciones — pares key/value que normalmente se encuentran en archivos flat o en bases de datos hash como BDB. Este tipo de búsqueda es también buena para LDAP. Las ventajas de LDAP son que muchos hosts pueden compartir la misma información, y que es más sencillo desarrollar herramientas para administrar los datos en LDAP en lugar de hacer lo en archivos flat que deben luego ser reconstruidos en tablas hash. El costo de LDAP versus las lecturas al disco no debería ser importante, especialmente si el árbol LDAP está correctamente indexado.

Configuración de sendmail

El sendmail MTA es una criatura más compleja, y agrega LDAP a la mezcla sólo aumentos de complejidad. Usted no puede hacer nada con sendmail porque es casi infinitamente configurable. El inconveniente es que las cosas que deberían ser simples tienden a ser más complicadas de lo necesario.

Comprenda que sendmail es un programa que interpreta un lenguaje a menudo denominado cf para procesar el correo electrónico. Cf es un lenguaje para el análisis framatical sencillo por sendmail, no por humanos. Afortunadamente, los humanos pueden usar un lenguaje denominado M4, el cual tiene una sintaxis mucho más simple, para generar el resultado del código cf.

Correlaciones de sendmail

Muchas de las operaciones de cf involucran la búsqueda de información en las correlaciones, las cuales son series de pares key-value. Cada correlación tiene un fin particular, como la correlación aliases para todos los aliases de correo electrónido y la correlación mailertable para el enrutamiento estático de correo electrónico. La correlación es una entidad de dos columnas; las búsquedas son realizadas en el left-hand side (LHS), y se devuelve el valor correspondiente del right-hand side (RHS).

El concepto de una correlación no se traduce directamente al LDAP. Una búsqueda de clave única en una correlación de sendmail puede devolver sólo una entrada RHS (la RHS puede tener múltiple valores, pero sólo una instancia de la clave existe). sendmail funciona con esto definiendo un esquema que permite partes key-value para almacenar en LDAP. Además, sendmail traduce la solicitud de cada correlación a un filtro de consulta LDAP que está diseñado para devolver un conjunto de atributos de entrada única. Puede elegir usar el esquema de sendmail, o puede modificar los filtros para trabajar con los datos en su árbol.

Para comenzar, agregue un esquema de misc.schema (viene con OpenLDAP) al esquema de su servidor. Este impleementa el enrutamiento de correo electrónico basado en LDAP. Luego, agregue sendmail.schema de la distribución de sendmail, la cual le permite almacenar correlaciones en LDAP.

Configuración del enrutamiento de correo electrónico de LDAP

Algunas organizaciones tienen múltiples servidores de correo electrónico para administrar todos los usuarios, ya sea debido a las restricciones geográficas o para administrar la capacidad de los servidores. En este caso, el buzón de voz de un usuario podría ser un servidor denominado wpgertw.com pero el la dirección de correo electrónico del usuario podría ser sean@ertw.com. El enrutamiento de correo electrónico de LDAP permite a cualquier servidor de sendmail recibir el mensaje, realizar la búsqueda en LDAP, y reescribir la dirección en la versión interna. Entonces es más sencillo cambiar el servidor destino modificando LDAP. De cualquier modo, la dirección de correo electrónico del usuario queda igual.

misc.schema implementa un bosquejo de Internet para el enrutamiento de LDAP. Este esquema suministra la clase de objeto inetLocalMailRecipient con los siguientes atributos:

  • mailLocalAddress: atributo que define la dirección de correo electrónica de alguien como lo ve alquien fuera de la organización
  • mailRoutingAddress: atributo que define la dirección interna de un usuario, el cual generalmente incluye el servidor que contiene el buzón de entrada del usuario
  • mailHost: atributo que define el servidor que administra el correo electrónico de este usuario

La información del host para el usuario puede encontrarse en mailRoutingAddress o mailHost. Por ejemplo, una mailRoutingAddress de sean@wpg.ertw.com con un mailHost de mx.ertw.com parece una contradicción. Si el host está activo, el correo será entregado allí más allá de la dirección de enrutamiento. La dirección será reingresada todavía en la dirección de enrutamiento si este atributo existe. En el ejemplo de sean@wpg.ertw.com, la dirección en el sobre será reingresada en sean@wpg.ertw.com, pero el mensaje será entregado en mx.ertw.com.

El Listado 24 muestra el código M4 que habilita el enrutamiento de LDAP. Esto debería ir a /etc/mail/sendmail.mc; luego, debe recrear su sendmail.cf. Generalmente esto significa ir a /etc/mail/ y ejecutar make; o puede significar la ejecución de m4 sendmail.mc > sendmail.cf.

Listado 24. Habilitación del enrutamiento de LDAP en sendmail.mc
define(`confLDAP_DEFAULT_SPEC', `-h localhost -b dc=ertw,dc=com')
FEATURE(`ldap_routing')
LDAPROUTE_DOMAIN(`ertw.com')

La primera línea establece los argumentos por omisión para el cliente LDAP interno: el host y la base de la búsqueda. La segunda línea permite al dispositivo de enrutamiento de LDAP, y el tercero habilita el dominio ertw.com para el enrutamiento de LDAP.

La duplicación del atributo mailLocalAddress desde inetLocalMailRecipient y el atributo mail desde inetOrgPerson es algo que vale la pena ver. sendmail le permite ignorar las búsquedas que utiliza internamente ingresando argumentos adicionales al dispositivo ldap_routing. El primer argumento es el filtro utilizado para encontrar el atributo mailHost, y el segundo se utiliza para encontrar mailRoutingAddress. Por lo tanto, FEATURE(`ldap_routing', `ldap -1 -T<TMPF> -v mailHost -k (&(objectClass=inetLocalMailRecipient)(mail=%0))', `ldap -1 -T<TMPF> -v mailRoutingAddress -k (&(objectClass=inetLocalMailRecipient)(mail=%0))') le permite a sendmail utilizar el atributo mail en lugar de mailLocalAddress. El filtro de búsqueda se especifica con el switch -k, y el atributo para regresar con -v. El resto de los argumentos son estándares para sendmail.

Configuración de aliases

sendmail implementa los aliases de LDAP como una serie de entradas en el árbol LDAP, indexado a un atributo denominado sendmailMTAKey usando una clase de objeto de sendmailMTAAliasObject. Usted quizá desee mantener los aliases en su propio contenedor. El Listado 25 muestra el LDIF para un alias de sendmail que toma el correo electrónico para exec@ertw.com y lo envia a hair@ertwcom y teeth@ertw.com.

Listado 25. Alias para exec@ertw.com
dn: sendmailMTAKey=execs,ou=aliases,dc=ertw,dc=com
objectClass: sendmailMTAAliasObject
sendmailMTACluster: external
sendmailMTAAliasGrouping: aliases
sendmailMTAKey: execs
sendmailMTAAliasValue: hair@ertwcom
sendmailMTAAliasValue: teeth@ertw.com

El primer atributo, sendmailMTACluster, define los servidores que pueden utilizar este alias. Usted debe definir el nombre del cluster en el archivo sendmail.mc, como define(`confLDAP_CLUSTER', `external'). Este cluster se utiliza como parte del filtro de búsqueda, de modo que si olvida de definirlo, sus aliases nunca serán utilizados. La alternativa para definir un cluster es establecer sendmailMTAHost, lo cual hace que la entrada aplique sólo a un host en particular.

sendmailMTAAliasGrouping debe ser aliases; este es parte del filtro de búsqueda. La clave se refiere al nombre del alias; finalmente, usted tiene uno o más valores que son los objetivos.

El último paso es configurar sendmail para usar LDAP para el archivo de los aliases con la directiva M4 define(`ALIAS_FILE', `ldap:'). En general, en cualquier lado que se le pida un archivo en sendmail.mc, puede colocar ldap:, y se hará referencia a la correlación en LDAP. sendmailMTAAliasGrouping luego se convierte en el nombre de la correlación.

Configuración de Postfix

Postfix está diseñado para ser más simple que sendmail pero para seguir siendo compatible con sendmail. El concepto de correlaciones todavía sigue presente, pero en lugar de ajustar las correlaciones al esquema, debe definir sus propios filtros de consulta que utilizan sus propios atributos.

Para la mayoría de las correlaciones, especifica el destino como ldap:/path/to/config.cf, siendo config.cf el archivo de configuración que define el servidor LDAP, la consulta, y los atributos que forman la respuesta. Por ejemplo, la directiva local_recipient_maps especifica cómo Postfix correlacionará las direcciones de correo electrónico con las cuentas locales. Especifique local_recipient_maps = $aliases, ldap:/etc/postfix/localrecipients.cf para verificar primero la base de datos de los aliases (más adelante) y luego la dirección regular adjunta a la entrada del usuario. El Listado 26 muestra los contenidos de localrecipients.cf.

Listado 26. La búsqueda de depósitos locales de LDAP
# LDAP server info
server_host = ldap://localhost
search_base = ou=people,dc=ertw,dc=com

# %s is the e-mail address...
query_filter = mail=%s

# the uid tells the account that gets the delivery
result_attribute = uid

El Listado 26 especifica el servidor local LDAP y la People OU. Postfix consulta el filtro de búsqueda y reemplaza la %s con la dirección de correo electrónico. Así, un correo electrónico para fred@ertw.com causará la búsqueda de (mail=fred@ertw.com) en el People OU. El atributo uid se utiliza para determinar el buzón de correo electrónico. Para probar, puede ejecutar postmap -q fred@ertw.com ldap:/etc/postfix/localrecipients.cf, que ejecuta la dirección de correo electrónico determinada a través del archivo de configuración localrecipients.cf (tenga en cuenta que NSS debe configurarse para devolver detalles sobre la cuenta de fred).


Resumen

En este turorial, aprendió a integrar LDAP con sus sistemas actuales. NSS suministra un modo sencillo para que las herramientas principales de UNIX utilicen LDAP redireccionando las llamadas a la biblioteca estándar C al backend de su elección. PAM es todavía otra abstracción; le permite cambiar la forma de autenticar las aplicaciones en una forma granular mientras que la aplicación esté preparada para PAM. PAM también relaciona restricciones de cuentas y modificaciones de contraseñas. Los archivos PAM se encuentran en /etc/pam.d.

La migración de NIS a LDAP involucra la planificación de cuales son las bases de datos que deben moverse y luego la ejecución de algunas herramientas para extraer los datos y convertirlos a LDIF. Si todavía debe soportar NIS en su entorno, PADL ha escrito un servidor NIS denominado ypldapd que traduce entre NIS y LDAP presentando una interfaz de NIS para aplicaciones, y lee los datos de LDAP.

Muchas aplicaciones están preparadas para PAM, lo cual significa que la migración a LDAP es tan simple como modificar algunos archivos en /etc/pam.d. Algunas aplicaciones, como Apache, hablan directamente LDAP. La configuración de Apache para LDAP involucra el uso del módulo mod_authnz_ldap y la especificación de los filtros de búsqueda que ayudan a Apache a encontrar a los usuarios en el árbol.

Samba proporciona servicios de Windows en una plataforma UNIX. Usted puede configurar Samba para usar los datos de LDAP o incluso usar los datos de Kerberos para hablar directamente con Windows. En el último caso, LDAP todavía se utiliza para la información de directorio, y Kerberos se utiliza para la autenticación.

El correo electrónico es un uso natural para LDAP dada su similitud a la de una agenda telefónica. Tanto sendmail como Postfix permiten que las correlaciones sean obtenidas de LDAP.

Esto concluye la mirada a los servicios del directorio para el examen LPIC 3. El siguiente y último tutorial de esta serie se centrará en el monitoreo y la predicción de la performance ode sus servidores Linux.

Recursos

Aprender

Obtener los productos y tecnologías

  • Firewall Builder simplifica la tarea de ingreso de reglas en las tablas ip con una buena GUI y una serie de herramientas para desplegar herramientas en sus firewalls.
  • Descargue pam_ldap y nss_ldapsi su distribución no incluye las bibliotecas PADL PAM y NSS LDAP.
  • Descargue ypldapd si piensa continuar con la prueba del portal de enlace NIS-LDAP. La licencia dura 30 días.
  • Descargue las LDAP migration tools del sitio de PADL.
  • Microsoft ha desarrollado gssMonger para verificar la interoperabilidad de la autenticación de Kerberos entre Windows y otras plataformas.
  • OpenLDAP es una buena opción para un servidor LDAP.
  • phpLDAPadmin es una herramienta de administración de LDAP basada en la Web. Si prefiere la GUI, Luma es una buena opción.
  • Con IBM trial software, que puede descargar directamente desde developerWorks, cree su próximo proyecto de desarrollo con Linux.

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Linux
ArticleID=651084
ArticleTitle=Preparación para el examen 301 de LPI, Tema 305: Integración y migración
publish-date=07152011