Preparación para el examen de LPI: Gestión de clientes de red

Tema 210 de Intermediate Level Administration (LPIC-2)

A través de este tutorial, el quinto de una serie de siete tutoriales que tratan la administración intermedia de redes en Linux, David Mertz lo sigue preparando para el examen 202 de Intermediate Level Administration (LPIC-2) de Linux Professional Institute. En este tutorial aprenderá a examinar la configuración centralizada de red de varios protocolos en clientes dentro de una red. DHCP se usa ampliamente para establecer un protocolo de enlace básico con las máquinas de los clientes (p. ej., asignar direcciones IP). En un nivel superior, NIS y (con más frecuencia) LDAP se usan con información compartida arbitraria entre las máquinas de una red. En este tutorial también se analiza PAM, un sistema de autenticación de usuarios flexible y en red.

David Mertz, Developer, Gnosis Software, Inc.

David Mertz cree que los lenguajes artificiales son perfectamente naturales pero los lenguajes naturales parecen un poco artificiales. Es posible contactar a David en mertz@gnosis.cx; podrá investigar todos los aspectos de su vida en su página Web personal. Vea su libro, Text Processing in Python (Procesamiento de Texto en Python). Las sugerencias y recomendaciones sobre las columnas pasadas o futuras son bienvenidas.



29-07-2011

Antes de comenzar

Aprenda todo lo que estos tutoriales pueden enseñarle y cómo aprovecharlos al máximo.

Acerca de esta serie

El Linux Professional Institute (LPI) otorga dos niveles de certificados para administradores del sistema Linux: nivel inicial (también denominado "certificado nivel 1") y nivel intermedio (también denominado "certificado nivel 2"). Para obtener el certificado nivel 1, es necesario aprobar los exámenes 101 y 102; para obtener el certificado nivel 2, es necesario aprobar los exámenes 201 y 202.

developerWorks ofrece tutoriales que lo ayudarán a prepararse para cada uno de los cuatro exámenes. Cada examen abarca diversos temas, y cada tema cuenta con su respectivo tutorial de autoestudio de developerWorks. A continuación se enumeran los siete temas y sus correspondientes tutoriales de developerWorks para el examen 202 de LPI:

Tabla 1. Examen 202 de LPI: tutoriales y temas
Tema del examen 202 de LPITutorial de developerWorksResumen del tutorial
Tema 205Preparación para el examen 202 de LPI (tema 205):
Configuración de redes
Aprenda a configurar una red TCP/IP básica, desde el nivel de hardware (generalmente Ethernet, módem, ISDN o 802.11) hasta el enrutamiento de direcciones de red.
Tema 206Preparación para el examen 202 de LPI (tema 206):
Correo y noticias
Aprenda a usar Linux como servidor de correo y servidor de noticias. Conozca el transporte de correo, el filtrado de correo local, el software de mantenimiento de listas de correo y el software de servidor del protocolo NNTP.
Tema 207Preparación para el examen 202 de LPI (tema 207):
DNS
Aprenda a usar Linux como servidor DNS, principalmente con BIND. Aprenda a realizar una configuración BIND básica, gestionar zonas DNS y asegurar un servidor DNS.
Tema 208Preparación para el examen 202 de LPI (tema 208):
servicios web
Aprenda a instalar y configurar el servidor Web Apache y a implementar el servidor proxy Squid.
Tema 210Preparación para el examen 202 de LPI (tema 210):
Gestión de clientes de red
(Este tutorial). Aprenda a configurar un servidor DHCP, un cliente y servidor NIS, un servidor LDAP y la compatibilidad con la autenticación PAM. Ver más abajo los objetivos detallados.
Tema 212Preparación para el examen 202 de LPI (tema 212):
Seguridad del sistema
Próximamente.
Tema 214Preparación para el examen 202 de LPI (tema 214):
Solución de problemas de red
Próximamente.

Si desea prepararse para el certificado nivel 1, consulte los tutoriales de developerWorks para el examen 101 de LPI. Si desea prepararse para el otro examen del certificado nivel 2, consulte el tutorial de developerWorks para el examen 201 de LPI. Lea el conjunto de tutoriales para LPI de developerWorks.

El Linux Professional Institute no respalda ningún material ni técnica de preparación para el examen en particular. Para obtener más información, escriba a info@lpi.org.

Acerca del presente tutorial

Bienvenido a "Gestión de clientes de red", el quinto de una serie de siete tutoriales que tratan la administración intermedia de redes en Linux. En este tutorial aprenderá la configuración centralizada de red de varios protocolos en clientes dentro de una red, verá cómo DHCP se usa ampliamente para establecer un protocolo de enlace básico con las máquinas de los clientes (p. ej., asignar direcciones IP) y comprenderá cómo, en un nivel superior, NIS y (con más frecuencia) LDAP se usan con información compartida arbitraria entre las máquinas de una red. En este tutorial también se analizará PAM (Pluggable Authentication Modules), un sistema de autenticación de usuarios flexible y en red.

Al igual que con los otros tutoriales de la serie 201 y 202 de developerWorks, este tutorial fue diseñado para servir de guía de estudio y punto de partida para la preparación de un examen, y no abarca toda la documentación de la materia. Se aconseja a los lectores consultar la lista de objetivos detallados de LPI y, si fuera necesario, complementar la información incluida en este tutorial con otros materiales.

Este tutorial está organizado en función de los objetivos de LPI para este tema. En líneas generales, prepárese para responder más preguntas sobre aquellos objetivos con mayor valor de ponderación.

Tabla 2. servicios web: objetivos de examen comprendidos en este tutorial
Objetivo del examen de LPIValor de ponderación del objetivoResumen del objetivo
2.210.1
Configuración DHCP
Valor: 2Configure un servidor DHCP. Este objetivo incluye establecer opciones predeterminadas y del cliente, agregar hosts estáticos y hosts BOOTP. También incluye configurar un agente de retransmisión DHCP y mantener el servidor DHCP.
2.210.2
Configuración NIS
Valor: 1Configure un servidor NIS. Este objetivo incluye configurar un sistema como cliente NIS.
2.210.3
Configuración LDAP
Valor: 1Configure un servidor LDAP. Este objetivo incluye trabajar con jerarquía de directorio, grupos, hosts y servicios y agregar otros datos a la jerarquía. También incluye importar y agregar elementos, así como agregar y gestionar usuarios.
2.210.4
Autenticación PAM
Valor: 2Configure PAM de manera que admita autenticación usando diversos métodos disponibles.

Requisitos previos

Para aprovechar este tutorial al máximo, es necesario tener un conocimiento básico de Linux y un sistema Linux en funcionamiento para practicar los comandos incluidos en este tutorial.


Introducción

Acerca de DHCP

El Protocolo de configuración dinámica de host (DHCP) es el sucesor del protocolo BOOTP. La función principal de un servidor DHCP consiste en asignar direcciones IP a máquinas clientes que pueden conectarse a una red o desconectarse de ella. La mayoría de las redes IP, incluso aquellas con topologías y listas de clientes estables, usan DHCP para evitar conflictos en la asignación de direcciones in IP.

Además, el servidor DHCP proporciona a los clientes información de enrutamiento y de subredes, direcciones DNS y, en algunos casos, otro tipo de información. Las asignaciones DHCP pueden tener diversas duraciones (de cortas a infinitas), dependiendo de la configuración del servidor y de los detalles de la solicitud del cliente. De hecho, DHCP es coherente con la asignación de direcciones IP fijas a máquinas específicas (a través de sus direcciones de hardware para MAC), pero, en todo caso, evita conflictos entre máquinas.

La especificación formal de DHCP es RFC 2131 (en Recursos encontrará el vínculo).

Acerca de NIS

El Servicio de información de red (NIS) es el protocolo de servicios de directorio cliente-servidor "Yellow Pages" (YP) desarrollado por Sun Microsystems para la distribución de datos de configuración de sistema, como nombres de usuario y de host, en una red informática.

NIS/YP se usa para almacenar un directorio central de usuarios, nombres de host y muchas otras cosas útiles en una red informática. Por ejemplo, en un entorno UNIX común, la lista de usuarios (para su autenticación) está ubicada en /etc/passwd. El uso de NIS agrega otra lista de usuarios "global" que sirve para autenticar usuarios en cualquier host.

En su mayor parte, NIS ha sido reemplazado por el más general y seguro LDAP en el uso general.

"The Linux NIS(YP)/NYS/NIS+ HOWTO" es un buen punto de partida para obtener más información sobre NIS (en Recursos encontrará el vínculo).

Acerca de LDAP

El Protocolo ligero de acceso a directorios (LDAP) es un protocolo cliente-servidor para acceder a servicios de directorio, específicamente servicios de directorio basados en X.500.

Un directorio LDAP es similar a una base de datos, pero suele contener información más descriptiva y basada en atributos. Como tal, LDAP proporciona la flexibilidad suficiente para almacenar cualquier tipo de información compartida en red. Como la lectura de información de un directorio es mucho más frecuente que su escritura, LDAP está adaptado para dar una respuesta rápida a las operaciones de búsqueda de gran volumen.

LDAP tiene la capacidad de replicar la información en gran medida para aumentar la disponibilidad y la confiabilidad mientras se reduce el tiempo de respuesta. Cuando se replica la información del directorio, cualquier inconsistencia temporaria entre las réplicas será sincronizada con el tiempo.

La especificación formal de LDAP es RFC 2251 (en Recursos encontrará el vínculo).

Acerca de PAM

Linux-PAM (Pluggable Authentication Modules para Linux) es una suite de bibliotecas compartidas que permite al administrador del sistema local elegir la manera en que las aplicaciones autentican a los usuarios.

Una aplicación compatible con PAM puede cambiar los mecanismos de autenticación en tiempo de ejecución. De hacho, es posible actualizar el sistema de autenticación local por completo sin recompilar las aplicaciones. Esta biblioteca PAM está configurada localmente con un archivo de sistema, /etc/pam.conf (o una serie de archivos de configuración ubicados en /etc/pam.d/), para autenticar la solicitud de usuario a través de los módulos de autenticación disponibles localmente. Por lo general, los módulos están ubicados en el directorio /lib/security y toman la forma de archivos de objeto de carga dinámica.

The Linux-PAM System Administrators' Guide es un buen punto de partida para obtener más información (enRecursosencontrará el vínculo).

Otros recursos

Como con la mayoría de las herramientas Linux, siempre es conveniente examinar las páginas man de las utilidades que se analizan. Las versiones y los conmutadores pueden cambiar en las diferentes versiones de la utilidad o del kernel o en las diferentes distribuciones de Linux. Si desea obtener información más detallada, el proyecto Linux Documentation Project tiene una gran variedad de documentos útiles, entre los que se destacan sus instructivos. Se han publicado diversos libros sobre redes Linux; personalmente, considero muy útil TCP/IP Network Administration de O'Reilly, escrito por Craig Hunt. (En Recursos encontrará los vínculos).


Configuración DHCP

Aspectos generales del protocolo

Como muchos protocolos de red, el Protocolo de configuraciónn dinámica de host (DHCP) es una interfaz cliente/servidor. El cliente DHCP es un programa mucho más fácil, tanto en su estructura interna como en su configuración, que el servidor DHCP. Esencialmente, la función de un cliente DHCP es difundir un mensaje DHCPDISCOVER en su subred física local y luego esperar una respuesta.

El mensaje DHCPDISCOVER PUEDE incluir opciones con sugerencias de valores para la dirección de red y la duración de la concesión. Los servidores que reciben un mensaje DHCPDISCOVER deberían responder a la dirección MAC solicitante con un mensaje DHCPOFFER. El cliente, a su vez, responde con un mensaje DHCPREQUEST a uno de los servidores oferentes, por lo general el primer (y único) servidor que responde.

Los parámetros de configuración de un cliente son recibidos en un mensaje DHCPACK. En ese punto, el cliente ya ha recibido una dirección IP asignada, y sus comunicaciones pasarán, por decirlo de alguna manera, del nivel de enlace de datos (Ethernet) al nivel de red (IP).

Proceso cliente

Por lo general, un cliente DHCP se debe configurar únicamente con la información que se desea obtener. Por ejemplo, las distribuciones basadas en Debian suelen usar el cliente DHCP, dhclient, que se configura con el archivo /etc/dhcp3/dhclient.conf. El archivo de muestra incluido en el paquete del cliente dhcp3 tiene todas las opciones de configuración deshabilitadas con comentarios, excepto una. La única opción habilitada podría tener el siguiente aspecto:

Listado 1. Opción de dhclient.conf
request subnet-mask, broadcast-address,
time-offset, routers, domain-name, domain-name-servers, host-name,
netbios-name-servers, netbios-scope;

En este ejemplo, con la configuración predeterminada, el cliente básicamente dice: "pido todo lo que se pueda". En los mensajes de negociación, el mensaje DHCPACK del servidor contiene información de todos estos valores solicitados que el cliente usará una vez recibidos. La dirección IP del cliente está implícita en la lista ya que esa configuración siempre es objeto de negociación.

Además de especificar las opciones de tiempo de espera y de tiempo de concesión (y algunas otras), el cliente puede (en la mayoría de los casos no está obligado a hacerlo) imponer ciertas restricciones a las direcciones IP que desea usar. Para excluir una dirección en particular, es posible usar reject 192.33.137.209;. Para especificar de manera expresa la dirección que desea utilizar el cliente, usefixed-address 192.5.5.213;.

Es posible que el cliente rechace una oferta de concesión con el mensaje DHCPDECLINE; sin embargo, los servidores intentarán cumplir las solicitudes cuando fuera posible. Un servidor DHCP también puede realizar la asignación fija de una dirección IP específica a una dirección MAC; es más frecuente que la configuración de una dirección IP por máquina se lleve a cabo con la configuración del servidor que con la configuración del cliente.

Para tener un registro de las concesiones adquiridas, dhclient mantiene una lista con las concesiones que se le asignaron en el archivo /var/lib/dhcp3/dhclient.leases (la ruta de acceso puede variar según la distro); así, una concesión DHCP vigente no se perderá si un sistema se desconecta de la red física o se reinicia.

Proceso servidor

El servidor DHCP necesita conocer un poco más sus opciones ya que proporciona diversa información a los clientes en las concesiones CDP; además, debe asegurarse de que las direcciones IP se asignen de manera única exclusiva a cada cliente. Por lo general, el servidor DHCP se ejecuta como daemon, dhcpd, y obtiene la información de su configuración de /etc/dhcpd.conf (la ruta de acceso puede variar según la distro). Es posible que un solo daemon dhcpd gestione múltiples subredes, generalmente cuando existen múltiples redes físicas que se conectan a un servidor; sin embargo, es más frecuente que un servidor gestione una subred. El listado 2 es un ejemplo bastante completo de la configuración de un servidor.

Listado 2. Opciones de configuración de dhcpd.conf
# default/max lease in
seconds: day/week default-lease-time 86400; max-lease-time 604800; option
subnet-mask 255.255.255.0; option broadcast-address 192.168.2.255; option
routers 192.168.2.1; # DNS locally, fallback to outside local domain option
domain-name-servers 192.168.2.1, 151.203.0.84; option domain-name "example.com";
# Set the subnet in which IP address are pooled subnet 192.168.2.0 netmask
255.255.255.0 { range 192.168.2.100 192.168.2.199; } # Assign a fixed IP to a
couple machines by MAC address group { use-host-decl-names true; host
first.example.com { hardware ethernet 00:00:c1:a2:de:10; fixed-address
192.168.2.200; } host second.example.com { hardware ethernet 00:dd:cc:a1:78:34;
fixed-address 192.168.2.201; }

Cuando un cliente envía un mensaje de difusión a un servidor que se ejecuta con esta configuración, este recibirá una concesión en 192.168.2.200 ó 192.168.2.201, si tiene la dirección MAC especificada, o recibirá una concesión en una dirección disponible dentro del grupo 192.168.2.100-192.168.2.199.

El cliente también puede usar el mensaje DHCPINFORM para indicarle al servidor que ya tiene una dirección IP asignada (por configuración manual), pero que desea obtener otro tipo de información de configuración. Tenga presente que informar a un servidor que un cliente está usando una dirección IP específica no es lo mismo que solicitar una dirección IP específica. En el último caso, el servidor puede conceder o no la solicitud dependiendo de las concesiones existentes. En el primer caso, el servidor no tiene voz en la decisión, y no se puede otorgar una concesión per se (sin embargo, los servidores intentarán evitar la asignación de direcciones IP que estén en uso a nuevos clientes solicitantes).

Cuando expira la concesión, los clientes y los servidores deben negociar nuevas concesiones para que los parámetros de configuración sigan siendo válidos. Se pueden usar concesiones más cortas cuando haya grandes posibilidades de que cambie la información de configuración de un servidor (por ejemplo, DNS dinámico a través de una WAN externa). Un cliente puede extinguir una concesión enviando el mensaje DHCPRELEASE, pero esto no es suficiente para lograr un correcto funcionamiento (después de todo, los clientes a veces se bloquean, se reinician o se desconectan sin tener la oportunidad de enviar el mensaje).

En ausencia de un mensaje de liberación, la concesión es mantenida por el servidor según los términos de duración en que se otorgó la concesión, por lo que una máquina reiniciada generalmente seguirá usando la concesión anterior (que se almacenará en dhclient.leases tanto en el servidor como en el cliente).


Configuración NIS

Cuándo usar NIS

La mayoría de las utilidades asociadas con NIS siguen llevando el prefijo yp debido al nombre anterior del protocolo, "Sun Yellow Pages". Por cuestiones legales relativas a la marca, el servicio pasó a llamarse NIS. NIS permite que una red de máquinas comparta información como usuarios y grupos (el contenido de /etc/passwd y /etc/group, respectivamente), dando a los usuarios derechos en cualquier máquina dentro de un dominio NIS.

NIS funciona de manera similar a DNS al definir dominios donde se distribuye información y permitir que los servidores maestros y esclavos distribuyan información jerárquicamente dentro de un dominio. De hecho, NIS se podría usar en lugar de DNS distribuyendo la información de nombres de dominio encontrada en /etc/hosts, aunque esto rara vez suceda en la práctica. NIS tiene cierta flexibilidad: en principio, cualquier tipo de información puede colocarse en una base de datos NIS (que está en formato DBM, pese a que la herramienta makedbm del paquete de servidor NIS convierte los archivos planos en este formato, generalmente "tras bambalinas ").

También existe un servicio llamado NIS+ con el que se buscó reemplazar a NIS y que incluye el cifrado y la autenticación de datos; sin embargo, NIS+ no es compatible con versiones anteriores de NIS y su uso no es muy extendido.

Antes de comenzar

Para ejecutar cualquiera de las utilidades NIS, es necesario ejecutar el daemon /sbin/portmap, que convierte los números del programa RPC en números de puerto del protocolo TCP/IP (o UDP/IP), debido a que los clientes NIS hacen llamadas RPC. Si bien la mayoría de las distribuciones de Linux inician /sbin/portmap en sus scripts de inicio, se recomienda verificar si este daemon se está ejecutando con % ps -ax | grep portmap.

Si no está en ejecución, instale /sbin/portmap e inclúyalo en los scripts de inicio de su sistema.

Utilidades del cliente NIS (daemon ypbind)

Un cliente NIS incluye las herramientas ypbind, ypwhich, ypcat, yppoll y ypmatch. El daemon ypbind se debe ejecutar como raíz y, por lo general, es iniciado como parte de los scripts de inicio del sistema (si bien esto no es obligatorio).

Las otras herramientas están basadas en los servicios de ypbind, pero se ejecutan a nivel de usuario. La versión anterior de ypbind difundía una solicitud de enlace en la red local; sin embargo, esto permite que un servidor NIS malicioso responda la solicitud y proporcione a los clientes información de usuario y de grupo errónea. Es preferible configurar servidores específicos para que ypbind se conecte antes que usar el archivo /etc/yp.conf. Si se configuran múltiples servidores (o si se usa la difusión a pesar del peligro), ypbind puede cambiar los servidores enlazados cada 15 minutos según cuál de ellos puede responder más rápidamente. Estos servidores deberían estar organizados en una configuración maestro/esclavo, pero el cliente no tiene que conocer este dato ni preocuparse por él. Por ejemplo, la configuración ypbind puede tener el siguiente aspecto:

Listado 3. /etc/yp.conf
ypserver 192.168.2.1 ypserver 192.168.2.2 ypserver
192.168.1.100 ypserver 192.168.2.200

Antes que se ejecute /usr/sbin/ypbind, es necesario establecer el nombre de dominio NIS de la red, que puede ser cualquier nombre que se elija para el servidor NIS y que, por lo general, debería ser diferente del nombre de dominio DNS. Establezca el nombre de dominio NIS usando (incluya el nombre real): % ypdomainname my.nis.domain.

Utilidades del cliente NIS (otra configuración)

Si desea usar NIS como parte de la búsqueda del nombre de dominio, debe modificar /etc/host.conf de manera que incluya NIS en el orden de búsqueda; por ejemplo, buscar un nombre en primer lugar en /etc/hosts, luego en NIS y, por último, en DNS:

Listado 4. Modificación del orden de búsqueda
% cat /etc/host.conf order
hosts,nis,bind

Para habilitar usuarios distribuidos NIS, modifique el archivo /etc/passwd del cliente de manera que incluya +::::::.

La información de base de datos NIS actúa como una plantilla para los intentos de inicio de sesión con este patrón "sin rellenar". Es posible ajustar la información de usuario si así lo desea; por ejemplo:

Listado 5. /etc/passwd detallado
+user1:::::::+user2:::::::+user3:::::::+@sysadmins:::::::-ftp+:*::::::/etc/NoShell

De esta manera, solo se permite el acceso a user1, user2 y user3, así como a todos los miembros del netgroup sysadmin, pero se proporcionan los datos de cuenta de todos los otros usuarios de la base de datos NIS.

Las fuentes NIS se configuran en /etc/nsswitch.conf. El nombre podría indicar que se hace referencia estricta a una búsqueda de servidor de nombres cuando, en realidad, se describen diversos tipos de información. Básicamente, esta configuración describe el orden en que se busca en las fuentes de información. El nombre nis significa información obtenida en un servidor NIS; el nombre files implica usar un archivo de configuración local apropiado. El nombre dns se usa para la opción hosts.

Además, es posible especificar qué hacer si una fuente inicial no contiene la información deseada: return implica abandonar (y a menos que NIS no responda en absoluto, continue implica buscar el dato en la siguiente fuente). Por ejemplo:

Listado 6. /etc/nsswitch.conf
passwd: compat group: compat shadow: compat
hosts: dns [!UNAVAIL=return] files networks: nis [NOTFOUND=return] files ethers:
nis [NOTFOUND=continue] files protocols: nis [NOTFOUND=return] files rpc: nis
[NOTFOUND=return] files services: nis [NOTFOUND=return] files

Utilidades de usuario del cliente NIS

Las utilidades ypwhich, ypcat, yppoll y ypmatch se usan a nivel de usuario para consultar información sobre NIS:

  • ypwhich imprime el nombre de un servidor NIS.
  • ypcat imprime los valores de todas las claves de una base de datos NIS.
  • yppoll imprime la versión y el servidor maestro de un mapa NIS.
  • ypmatch imprime los valores de una o más claves de un mapa NIS.

Consulte las páginas man correspondientes a la utilidad en cuestión para obtener más información acerca de su uso.

Utilidades del servidor NIS (ypinit, ypserv)

El servidor NIS usa el daemon ypserv para proporcionar bases de datos NIS a los clientes y se configura en el archivo /etc/ypserv.conf. Como se mencionó anteriormente, es posible ejecutar los servidores NIS maestro y esclavo dentro de un dominio. El conjunto de bases de datos NIS se inicializa en un servidor maestro usando (solo la primera vez que se ejecuta; luego use make -C /var/yp): % /usr/lib/yp/ypinit -m.

Un servidor esclavo no es sino un cliente NIS que obtiene sus bases de datos del servidor maestro (y ejecuta ypserv). Para copiar la información del servidor maestro en el servidor esclavo que se ejecuta localmente, use % /usr/lib/yp/ypinit -s my.nist.domain.

En el servidor maestro, las bases de datos NIS se generan a partir de información incluida en (algunos de) los siguientes archivos de configuración:

  • /etc/passwd,
  • /etc/group,
  • /etc/hosts,
  • /etc/networks,
  • /etc/services,
  • /etc/protocols,
  • /etc/netgroup,
  • /etc/rpc.

Las bases de datos que se exportan son configuradas en /var/yp/Makefile, que también propaga los cambios al momento de su regeneración.

Los servidores esclavos recibirán una notificación de cualquier cambio que se produzca en los mapas NIS al momento de su regeneración (a través del programa yppush) y automáticamente recuperarán los cambios necesarios para poder sincronizar sus bases de datos. Los clientes NIS no necesitan hacer esto ya que se comunican continuamente con el servidor NIS para leer la información almacenada en sus bases de datos DBM.


Configuración LDAP

Cuándo usar LDAP

En principio, el Protocolo ligero de acceso a directorios es similar en cuanto a su objetivo a NIS. Ambos distribuyen cierta información estructurada desde el cliente hasta el servidor; sin embargo, LDAP va más allá estructurando de forma jerárquica qué información se distribuye entre qué clientes, redirigiendo solicitudes a otros servidores LDAP si fuera necesario e incorporando mecanismos de seguridad. Además, LDAP proporciona mecanismos y herramientas para que los clientes actualicen la información almacenada en los servidores LDAP y, a su vez, la distribuyan entre otros clientes que la soliciten (conforme a los permisos correspondientes).

Instalación

Antes de ejecutar OpenLDAP, la implementación de software libre generalmente usada en Linux (si bien existen implementaciones comerciales), es necesario instalar varias bibliotecas necesarias (o verificar su existencia):

  • Es posible obtener los servicios de Seguridad del nivel de transporte (TLS) desde el proyecto OpenSSL Project (o a través de los mecanismos de instalación de su distribución de Linux).
  • Los servicios de autenticación Kerberos son opcionales, pero muy recomendables. Es posible usar MIT Kerberos o Heimdal Kerberos.
  • El nivel de seguridad y autenticación simple se puede instalar como parte de la distro básica, pero también se puede obtener desde Cyrus SASL.
  • Se recomienda usar Sleepycat Software Berkeley DB, aunque probablemente existan otras implementaciones DBM compatibles.
  • Es deseable, por no decir obligatorio, usar Posix threads y TCP wrappers.

Una vez satisfechos estos requisitos previos, descargue la biblioteca OpenLDAP y realice el baile más o menos habitual:

Listado 7. Danza de instalación de OpenLDAP habitual
% ./configure % make
depend % make % make test # make sure things went OK % su root -c 'make
install'

Después de la instalación básica, es necesario configurar la configuración slapd, que suele estar en /usr/local/etc/openldap/slapd.conf. La configuración debe incluir los componentes del dominio:

Listado 8. Componentes de dominio a incluir en slapd.conf
database bdb suffix
"dc=eng,dc=uni,dc=edu,dc=eu" rootdn "cn=Manager,dc=eng,dc=uni,dc=edu,dc=eu"
rootpw <secret> directory /usr/local/var/openldap-data

Para encontrar un valor para <secret>, use la utilidad slappasswd con la siguiente cadena codificada en base64 cifrada para su "<secret>":

Listado 9. Descubrimiento del "secreto"
% slappasswd New password: *******
Re-enter new password: ******** {SSHA}YzPqL5Jio2+17NFIy/pAz8pqS5Ko13fH

Para obtener más información acerca de los permisos, la replicación y otras opciones de slapd.conf, observe con atención las páginas man detalladas.

La iniciación del daemon slapd es similar a la iniciación de cualquier otro daemon; para comprobar su funcionamiento, use ldapsearch:

Listado 10. Prueba de funcionamiento de slapd
su root -c
/usr/local/libexec/slapd ldapsearch -x -b '' -s base '(objectclass=*)'
namingContexts

Si todo salió bien, debería aparecer un código similar al del listado 11:

Listado 11. Respuesta de slapd en funcionamiento
dn:namingContexts:
dc=eng,dc=uni,dc=edu,dc=eu

Agregado de datos con un archivo LDIF

El formato de datos usado en LDAP es un formato binario; sin embargo, para exportar e importar datos en una base de datos LDAP, se usa una serialización ASCII llamada Formato de intercambio de datos LDAP (LDIF). En LDIF, los datos binarios se representan como codificación base64. OpenLDAP incluye herramientas para exportar datos desde los servidores LDAP a LDIF (ldapsearch), para importar datos desde LDIF a los servidores LDAP (ldapadd) y para aplicar un conjunto de cambios descriptos en LDIF a los servidores LDAP (ldapmodify y ldapdelete).

Además, LDIF es uno de los formatos que se usan para importar y exportar datos de la libreta de direcciones de Mozilla Application Suite y otras herramientas de usuario de nivel de aplicación. Incluso Microsoft Windows 2000 Server y Windows Server 2003 incluyen una herramienta LDIF, LDIFDE, para transferir datos desde y hasta Active Directory (Directorio activo).

Para agregar información manualmente a un servidor LDAP, primero es necesario crear un archivo LDIF:

Listado 12. Creación del archivo LDIF de muestra, example.ldif
dn:
dc=example,dc=com objectclass: dcObject objectclass: organization o: Example
Company dc: example dn: cn=Manager,dc=example,dc=com objectclass:
organizationalRole cn: Manager

Luego agréguelo usando% ldapadd -x -D "cn=Manager,dc=example,dc=com" -W -f example.ldif.

Por supuesto que el dominio example.com se debe reemplazar por un dominio adecuado para su sitio. Normalmente, las jerarquías y los nombres de dominio LDAP coinciden con aquellos usados por los nombres DNS familiares. Se le pedirá que ingrese el valor rootpw especificado en slapd.conf.

Consulta de bases de datos LDAP

Existe una herramienta, slurpd (Standalone LDAP Update Replication Daemon), que se utiliza para replicar una base de datos de información completa; sin embargo, para el caso de valores de datos individuales, se usa una herramienta como ldapsearch o bien (más probablemente) se incorpora la compatibilidad con LDAP en alguna aplicación que se ejecute. La herramientaslapcatsirve para volcar una base de datos LDAP en LDIF. Por ejemplo, muchos Mail User Agents (MUA) pueden usar LDAP para buscar información de dirección y de contacto.

Dentro de algunas aplicaciones, incluso aquellas que se pueden programar usando lenguajes de scripting o de aplicación, es posible acceder a los recursos LDAP con URL LDAP, que toman la siguiente forma: ldap://host:port/dn?attributes?scope?filter?extensions.

La mayoría de estos campos son opcionales. El nombre de host predeterminado es localhost; el puerto predeterminado es 389. El nombre distintivo raíz predeterminado es la cadena vacía. Si necesita información de autenticación, especifíquela en la porción extensions de la URL.

Además de las URL LDAP, muchos servidores y clientes LDAP son compatibles con las URL LDAPS, no estándar pero ampliamente usadas. Las URL LDAPS usan conexiones SSL en lugar de conexiones de texto simple y usan un puerto predeterminado 636: ldaps://host:port/dn?attributes?scope?filter?extensions.


Autenticación PAM

Cuándo usar PAM

Lo primero que hay que tener en cuenta de Pluggable Authentication Modules (Módulos de autenticación conectables – PAM) es que no es en sí una aplicación o protocolo, sino una colección de bibliotecas que pueden utilizar aplicaciones compiladas. Si una aplicación está habilitada para PAM, la directiva de seguridad de esa aplicación puede ser configurada por un administrador de sistema sin modificar ni actualizar la aplicación. Muchas herramientas Linux, especialmente los daemons y servidores, están habilitados para PAM.

Una manera rápida de verificar si una herramienta determinada está probablemente habilitada para PAM consiste en usar ldd para comprobar qué bibliotecas usa. Por ejemplo, un usuario se puede preguntar si su utilidad de inicio de sesión está habilitada para PAM:

Listado 13. ¿El inicio de sesión está habilitado para PAM?
% ldd /bin/login
| grep libpam libpam.so.0 => /lib/libpam.so.0 (0xb7fa8000)
libpam_misc.so.0 => /lib/libpam_misc.so.0 (0xb7fa5000)

El uso de libpam.so y libpam_misc.so por parte de login no garantiza que las facilidades PAM sean usadas y usadas correctamente por esta herramienta, pero es un buen indicio. Asimismo, el usuario se puede preguntar si los servidores Apache y FTP están habilitados para PAM:

Listado 14. ¿Y los servidores Apache y FTP?
% ldd /usr/sbin/apache2 | grep
libpam % ldd /bin/login | grep libpam libpam.so.0 => /lib/libpam.so.0
(0xb7fa8000) libpam_misc.so.0 => /lib/libpam_misc.so.0
(0xb7fa5000)

Ahora el usuario sabe que su instalación Apache no está habilitada para PAM (si bien existen versiones disponibles que incluyen esta característica).

Para comprobar de una manera más exhaustiva si PAM funciona completamente con una determinada herramienta, es posible crear un archivo de configuración PAM para el programa. Por ejemplo, para comprobar la utilidad de inicio de sesión, se podría crear un archivo /etc/pam.d/login (tenga presente que probablemente ya exista en el sistema con una configuración más significativa, así que no elimine la copia existente):

Listado 15. Comprobación de PAM en el inicio de sesión con etc/pam.d/login
auth required pam_permit.so auth required
pam_warn.so

La ejecución de un login correctamente habilitado para PAM permitirá que cualquiera pueda iniciar sesión, pero registrará la acción en el registro del sistema. Si syslog muestra una entrada, esto significa que PAM está habilitado para esta aplicación. Observe que esta es una de las peores configuraciones que se podrían inventar para login ya que le da a cualquiera acceso al shell. Por eso, tenga presente que PAM se debe configurar con cierto cuidado.

Configuración PAM

PAM funciona con dos tipos diferentes de archivos de configuración. La mayoría de las bibliotecas libpam.so están compiladas en el modo "use el mejor si está disponible, pero confórmese con el peor". Sin embargo, una biblioteca PAM también podría estar compilada en el modo "use el mejor, pero verifique el peor". A continuación se explica el funcionamiento de este modo.

Actualmente, la forma preferida de configurar PAM es a través de archivos ubicados en el directorio /etc/pam.d/ que tienen el mismo nombre que el servicio cuya seguridad describen. Un estilo más antiguo y menos preferido consiste en usar un único archivo, /etc/pam.conf, para establecer la directiva de seguridad de todas las aplicaciones. Desde el punto de vista del mantenimiento, los archivos de configuración por aplicación son más fáciles de manejar y además pueden vincularse simbólicamente para "duplicar" una directiva de seguridad de una aplicación en otra. Ambos estilos de configuración tienen básicamente el mismo aspecto. El archivo único /etc/pam.conf contiene líneas de la forma:

Listado 16. Ambos archivos de configuración contienen
<service><module-type><control-flag><module-path><args>

En los archivos de configuración por aplicación, se omite el primer campo, ya que es el mismo que el nombre del archivo. Con el estilo más antiguo, la configuración de inicio de sesión de solo prueba tendría el siguiente aspecto:

Listado 17. /etc/pam.conf
login auth required pam_permit.so login auth
required pam_warn.so

El campo <module-type> puede tener uno de los siguientes cuatro valores:

  • auth(autenticación),
  • account(permisos de no autenticación basados en el sistema de estado de usuario),
  • session(realizar acciones antes/después de usar el servicio) y
  • password(actualizar tokens de autenticación de usuarios).

El campo <control-flag> se usa para "apilar" módulos, lo cual permite un control bastante sutil de las siguientes cuestiones: cuándo se requiere un método, si se realiza o no y cuándo es aceptable alguna otra reserva. Las opciones son:

  • required,
  • requisite,
  • sufficient,
  • optionale
  • include.

Estas opciones se analizarán en el siguiente panel.

El campo <module-path> incluido en los ejemplos: nombra una biblioteca compartida en la ubicación de módulo esperada, si no se especificó una ruta de acceso, o en una ubicación explícita, si comienza con una "/". Por ejemplo, en el listado 17, se podría haber especificado /lib/security/pam_warn.so. El campo <args> podría hacer referencia a cualquier cosa, dependiendo de dónde debe configurar su operación un módulo específico, si bien algunos argumentos genéricos deberían ser compatibles con la mayoría de los módulos PAM. Tenga presente que los módulos PAM son extensibles. Si se escribiera un nuevo módulo PAM, se podría colocar en /lib/security, y todas las aplicaciones lo podrían usar una vez que se actualice su archivo de configuración.

Ejemplo de permiso PAM

Para comprender el funcionamiento de <control-flag>, desarrollemos un ejemplo medianamente complejo. Lo primero que deberíamos hacer es crear un servicio OTHER especial. Si ya existe y no hay ninguna directiva PAM definida para un servicio, se usará la directiva de OTHER. Un valor predeterminado seguro podría tener el aspecto del listado 18:

Listado 18. /etc/pam.d/other
auth required pam_warn.so auth required
pam_deny.so @include safe-account @include safe-password @include
safe-session

En este ejemplo, primero se registra un intento de autenticación en syslog y luego se deniega. Las instrucciones @include incluyen contenidos de cualquier otro lugar, como /etc/pam.d/safe-account y amigos, donde estas definiciones "seguras" podrían contener similares instrucciones de advertencia y posterior denegación para los otros <module-type>.

Ahora configuremos el acceso para nuestra aplicación hipotética classified-db. Como nos preocupa el tema del acceso, para que un usuario pueda usar esta aplicación, deberá proporcionar una huella retinal o digital coincidente y también ingresar una contraseña. Sin embargo, la contraseña podría estar almacenada en las configuraciones locales /etc/passwd y /etc/shadow o disponible mediante uno o dos servidores de bases de datos externos.

Ninguno de los módulos de seguridad usados en el ejemplo existe en la realidad (a mi leal saber y entender), salvo pam_unix.so, que es el antiguo acceso con contraseñas de estilo UNIX.

Listado 19. /etc/pam.d/classified-db
auth optional pam_unix.so auth
optional pam_database1.so try_first_pass auth optional pam_database2.so
use_first_pass auth requisite pam_somepasswd.so auth sufficient
pam_fingerprint.so master=file1 7points auth required pam_retinaprint.so

El flujo de esta configuración es moderadamente complejo. Primero intentamos autenticar la contraseña con tres tipos de módulo optional (opcionales). Como son optional, la falta de uno de ellos no detiene el proceso de autenticación ni lo satisface. Primero se intenta ingresar la contraseña de autenticación UNIX estándar (se le pide al usuario que ingrese una contraseña). Luego, comprobamos las contraseñas en database1, pero primero usamos el argumento de módulo genérico try_first_pass para ver si la contraseña UNIX es la misma que la de la base de datos; si no coinciden, solicitamos una contraseña adicional. Sin embargo, con database2, solamente intentamos autenticar usando la contraseña UNIX que ingresó el usuario (argumento genérico use_first_pass).

Una vez comprobados algunos sistemas de contraseñas optional, usamos un hipotético pam_somepasswd.so que debe determinar si alguna de las comprobaciones de contraseña tuvo éxito (quizás usando un semáforo, pero queda abierto para módulos hipotéticos). El punto es que como la comprobación es requisite (obligatoria), si falta, la autenticación se detendrá y el error se informará.

Las últimas dos comprobaciones de autenticación (si se alcanzan) son sufficient (suficientes). Es decir, la satisfacción de una de ellas devuelve un estado de éxito general a la aplicación llamante. Por eso, primero intentamos utilizar la comprobación de huellas digitales usando pam_fingerprint.so (observe que algunos argumentos hipotéticos se trasladan al módulo). Solo si esta comprobación falla – quizás por la ausencia de un escáner de huellas digitales–, se intentará usar el examen retinal. Asimismo, si el escaneo retinal tiene éxito, esto será sufficient. Sin embargo, para demostrar todos los indicadores, también usamos required (necesario), que significa que incluso si el examen retinal es exitoso, seguiríamos usando otros métodos (pero como no hay más métodos en el ejemplo, sufficient desempeñará la misma función).

También existe una forma de especificar indicadores compuestos más ajustados para el campo <control-flag>: usando conjuntos [value1=action1 ...] entre corchetes; sin embargo, las palabras clave básicas suelen ser suficientes.

Recursos

Aprender

Obtener los productos y tecnologías

  • Genere su próximo proyecto de desarrollo en Linux con el software de prueba de IBM, disponible para su descarga directa desde developerWorks.

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=502534
ArticleTitle=Preparación para el examen de LPI: Gestión de clientes de red
publish-date=07292011