Preparación para el examen 301 de LPI, Tema 303: Configuració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) en el Linux Professional Institute. En este tercer tutorial de una series of six tutorials, Sean lo guía en la configuración del servidor Lightweight Directory Access Protocol (LDAP), incluyendo el control de acceso, la seguridad y la performance. Al finalizar este tutorial, usted sabrá configurar el servidor LDAP.

Sean A. Walberg, Senior Network Engineer

Author photoSean Walberg ha trabajado con los sistemas Linux y UNIX desde 1994 en entornos académicos, corporativos, y de proveedores de servicios de Internet. Ha escrito bastante sobre la administración de sistemas en los últimos años. Usted puede contactarse con el en sean@ertw.com.



15-07-2011

Antes de comenzar

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

Sobre esta serie

El Linux Professional Institute (LPI) certifica administradores de sistemas Linux® en tres niveles: nivel junior (también denominado "certificación de nivel 1"), nivel avanzado (también denominado "certificación de nivel 2"), y nivel senior (también denominado "certificación de nivel 3"). Para alcanzar la certificación de nivel 1, debe aprobar los exámenes 101 y 102. Para alcanzar la certificación de nivel 2, debe aprobar los exámenes 201 y 202. Para lograr la certificación de nivel 3, debe tener una certificación de nivel avanzado activa y aprobar el examen 301 ("principal"). Quizá necesite también 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, avanzado y senior. Cada examen abarca varios temas, y cada tema tiene un tutorial de auto estudio correspondiente en developerWorks. La Tabla 1 muestra un listado de los seis temas y sus correspondientes tutorials en developWorks para el examen 301 de LPI.

Tabla 1. Examen 301 de LPI: Tutorials y temas
Tema del examen 301 de 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 cómo instalar, configurar y utilizar el software de OpenLDAP.
Tema 303 Preparación para el examen 301 de LPI:
Configuración
(Este tutorial) Aprenda cómo configurar el software de OpenLDAP en detalle. Vea los objetivos detallados.
Tema 304 Preparación para el examen 301 de LPI:
Uso
Pronto.
Tema 305 Preparación para el examen 301 de LPI:
integración y migración
Pronto.
Tema 306 Preparación para el examen 301 de LPI:
Planificación de la capacidad
Pronto.

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

  • Debería tener varios años de experiencia en la instalación y el mantenimiento de Linux en varias computadoras para diversos fines.
  • Debería tener experiencia en la integración con diversas tecnologías y sistemas operativos.
  • Debería tener experiencia profesional, o capacitación, como profesional Linux de nivel empresarial (incluso experiencia en otro rol).
  • Deberia conocer niveles de administración Linux avanzados y empresariales que incluyan la instalación, la administración, la seguridad, la localización de problemas, y el mantenimiento.
  • Debería poder utilizar herramientas de fuente abierta para medir problemas de planificación de capacidad y recursos para la localización de problemas.
  • Debería tener experiencia profesional en el uso de LDAP para la integración con servicios UNIX® y servicios 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).

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

Sobre este tutorial

Bienvenido a la "Configuración," el tercero de seis tutorials diseñados para prepararlo para el examen 301 de LPI. En este tutorial, aprenderá sobre la configuración del servidor LDAP, incluyendo los controles de acceso, la seguridad, la replicación y la performance de la base de datos.

Este tutorial está organizado de acuerdo a los objetivos de LPI para este tema. Muy a grandes rasgos, espere más preguntas del examen sobre los objetivos con valores más altos, como se muestra en la Tabla 2.

Objetivos

La Tabla 2 muestra una lista de los objetivos detallados de este tutorial.

Tabla 2. Configuración: objetivos del examen que abarca este tutorial
Objetivo del examen de LPIValor del objetivoResumen del objetivo
303.2
Listas de control de acceso en OpenLDAP
2Planificación e implementación de las listas de control de acceso.
303.3
Replicación de LDAP
5Configuración de OpenLDAP para la replicación de datos entre múltiples servidores.
303.4
Aseguramiento del directorio
4Configuración de acceso encriptado al servidor LDAP, y restricción del acceso al nivel firewall.
303.5
Ajuste de la performance del servidor LDAP
2Medida de la performance del servidor LDAP, y ajuste para la máxima performance.
303.6
Configuración del daemon de OpenLDAP
2Comprensión de las pautas básicas de configuración slapd.conf, y familiarización con las opciones básicas de la línea de comando slapd.

Prerequisitos

Para aprovechar al máximo este tutorial, debería tener conocimiento avanzado de Linux y un sistema Linux en funcionamiento en el cual practicar los comandos aprendidos.

Si sus capacidades Linux principales están muy oxidadas, quizá desee revisar primero los tutorials for the LPIC-1 and LPIC-2 exams.

Diferentes versiones de un programa pueden dan formato a los datos de salida de modo diferente, de modo que los resultados pueden no verse exactamente iguales a los de los listados y figuras en este tutorial.

Requisitos de sistema

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


Listas de control de acceso en LDAP

Esta sección abarca el material para el tema 303.2 del nivel senior del examen 301 del Linux Profesional Institute (LPIC-3). Este tema tiene un valor de 2.

En esta sección aprenda cómo:

  • Planificar listas de control de acceso de LDAP
  • Comprender la sintaxis del control de acceso
  • Garantizar y revocar permisos de acceso a LDAP

Una variedad de datos pueden almacenarse en un árbol LDAP, incluyendo números de teléfono, fechas de cumpleaños, e información de nómina de empleados. Algunos de estos pueden ser públicos, y otros pueden ser accesibles a cierta gente sólamente. La misma información puede tener restricciones diferentes basadas en el usuario. Por ejemplo, quizá sólo el dueño del registro y los administradores pueden cambiar un número de teléfono, pero todos pueden leer el número. Access control lists (ACLs) -las listas de control de acceso- administran la configuración de estas restricciones.

Planificación de listas de control de acceso LDAP

Antes de comenzar a escribir su configuración, debería determinar lo que desea lograr. ¿Qué partes de este árbol contienen información sensible? ¿Qué atributos deben protegerse, y de quién? ¿Cómo será utilizado el árbol?

Los componentes de un ACL

Una entrada ACL suministra tres piezas de información:

  1. ¿Qué entradas y atributos especifica el ACL
  2. ¿A quién aplica el ACL?
  3. El nivel de acceso que se garantiza

Expresiones regulares

Las expresiones regulares son utilizadas para hacer concordar el texto. Quizá posea una idea general de como se ve el texto, o conozca ciertos patrones, y pueda crear una expresión regular para encontrar lo que está buscando. Una expresión regular, o regex abreviado, consiste de coincidencias literales y caracteres meta que coinciden con varios patrones.

Un regex simple es hello, el cual coincide con cualquier cadena de caracteres que contiene el patrón hello.

Quizá no sepa si la cadena tiene mayúsculas, así que los meta caracteres, [], coinciden con cualquiera de los caracteres que se encuentran en el conjunto. Por lo tanto, [Hh]ello hace coincidir tanto hello como Hello.

El periodo coincide con cualquier caracter simple. .ello coincide con Hello y hello, pero también con fellow y cello. Este, sin embargo, no coincide con ello, porque el periodo tiene que coincidir con algo.

Los caracteres ?, *, y + coinciden con cero y uno de los caracteres precedentes, cero o más de los caracteres precedentes, y uno o más de los caracteres precedentes, respectivamente. Por lo tanto, hello+ coincide con hello y helloooooo, pero no conhell.

Las expresiones regulares tienen muchas opciones diferentes y le permiten traer eficazmente patrones de los archivos de texto. En el contexto de OpenLDAP, las expresiones regulares son utilizadas para hacer coincidir partes de un DN para evitar tener que codificar manualmente cientos de posibilidades diferentes.

Al especificar la clausula "what", usted puede elegir filtrar en el distinguished name (DN) del objeto, un filtro de consulta de estilo LDAP, una lista de atributos o una combinación de los tres. La clausula más simple permite todo, pero usted puede ser mucho más restrictivo. El filtrado del DN le permite especificar una coincidencia exacta, como ou=People,dc=ertw,dc=com, o una expresión regular (consulte "Regular expressions"). El filtro de la consulta puede hacer coincidir una determinada objectClass u otros atributos. La lista de atributos es una lista separada por comas de nombres de atributos. Un criterio de coincidencia más complejo podría ser "All password entries under ou=People,dc=ertw,dc=com who are administrators."

Usted tiene una gran flexibilidad al determinar a quién aplica el ACL. Los usuarios generalmente son identificados por el DN con el cual están enlazados al árbol, el cual se denomina bindDN. Cada entrada LDAP puede tener un atributo userPassword que es utilizado para autenticar a ese usuario en particular. En algunos contextos, usted puede referirse al usuario registrado actualmente como self, lo cual es útil para permitirle al usuario editar sus propios detalles.

Si un usuario no se valida, es considerado anónimo. Por omisión, los usuarios anónimos pueden leer el árbol, por lo cual deben decidir si necesitan modificar este comportamiento. Usted puede segmentar más sus usuarios anónimos (o cualquier usuario, para esa cuestión) via dirección IP o por medio del método usado para conectarse (como texto sin formato o encriptado).

Una vez que ha determinado qué y quienes, debe determinar el nivel de acceso. El acceso puede ir desde ninguno hasta escritura. Usted puede también especificar que el usuario puede autenticarse contra la entrada pero no puede leer; o puede darle al usuario acceso de lectura, de búsqueda y de comparación.

Más allá de como configure sus ACLs, cualquier usuario rootDN configurado tiene control total sobre su base de datos. No puede cambiar esto, excepto moviendo la configuración derootDN desde slapd.conf.

Conprensión de la sintaxis del control de acceso

La forma básica de un ACL, expresada en Backus-Naur Form, es:
access to <what> [ by <who> [ <access> ] [ <control> ] ]+

Backus-Naur Form

Backus-Naur Form (BNF) es el modo de describir gramática como sintaxis ACL. Es a menudo utilizado en el desarrollo de protocolos de Internet porque BNF es conciso y muy preciso.

En notación BNF, usted tiene un elemento izquierdo y un elemento derecho separado por un símbolo ::=. Esto significa que el lado izquierdo puede ser substituido por elementos del lado derecho. Los elementos del lado derecho que se encuentran entre paréntesis (< and >) se refieren a otra línea de BNF, con el elemento entre paréntesis que aparecen en el lado izquierdo.

Los elementos entre paréntesis ([ and ]) son opcionales. Las barras verticales (|) indican "uno u otro"; y + y * significa "uno o más del anterior" y "cero o más del anterior," respectivamente. Quienes están familiarizados con expresiones regulares reconocerán muchos de estos elementos.

Si buscamos un ACL en el BNF, una entrada ACL consiste de la cadena literal "access to", seguida de un elemento denominado "what" que es definido en otro lugar. Le siguen uno o más líneas de la forma <who> [ <access> ] [ <control> ], donde who, access, y control son definidos en otro sitio, y tanto access como control son opcionales.

Exploraremos la gramática que falta en el resto de este tutorial.

Descripción del what

El what describe los atributos y entradas que serán respetados por el ACL. La notación BNF para hacer esto se muestra en el Listado 1.

Listado 1. Descripción BNF de la parte what de un ACL
<what>        ::= * |
    [dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
    [filter=<ldapfilter>] [attrs=<attrlist>]
<basic-style> ::= regex | exact
<scope-style> ::= base | one | subtree | children
<attrlist>    ::= <attr> [val[.<basic-style>]=<regex>] 
    | <attr> , <attrlist>
<attr>        ::= <attrname> | entry | children

Algunos de los elementos en el Listado 1 no son definidos aquí, como DN y regex. La forma del distinguished name ya se conoce, y las expresiones regulares son mejor estudiadas fuera del BNF.

El Listado 1 muestra que una descripción de la porción what del ACL puede ser el caracter asterisco (*), el cual coincide todo, o una combinación de una descripción del DN, un filtro LDAP, y una lista de atributos. La última posibilidad puede usar uno o más de tres componentes, porque ellos están individualmente encerrados entre paréntesis.

El Listado 2 muestra tres cláusulas what que coinciden con el DN.

Listado 2. Tres cláusulas what de muestra
dn.exact="ou=people,dc=ertw,dc=com"
dn.regex="ou=people,dc=ertw,dc=com$"
dn.regex="^cn=Sean.*,dc=com$"

El primer ejemplo coincide sólo con la entrada de ou=people,dc=ertw,dc=com. Si este ACL es utilizado, este no coincide con ningún hijo como cn=Sean Walberg,ou=people,dc=ertw,dc=com, ni coincide con la entrada padre.

El segundo ejemplo es similar al primero, pero utiliza una expresión regular y ancla la cadena de búsqueda al caracter del signo de dolar ($). Un ancla coincide la posición de la cadena en lugar de la parte de la cadena. El signo de dolar coincide con el final de la cadena, así que el segundo ejemplo con coincide algo que termina en ou=people,dc=ertw,dc=com, lo cual incluye cn=Sean Walberg,ou=people,dc=ertw,dc=com. Tenga en cuenta que sin el ancla, la cadena de búsqueda podría ser algo en el destino, como ou=people,dc=ertw,dc=com,o=MegaCorp.

El tercer ejemplo del Listado 2 muestra otro ancla, ^, la cual coincide con el comienzo de la cadena. El tercer ejemplo también utiliza otra expresión regular, .*. El período coincide con cualquier caracter, y el asterisco coincide con cero o más del caracter precedente. Así, .* coincide con cualquier cadena de cero o más caracteres. Colocados juntos, el tercer ejemplo coincide con cualquier entrada que comienza con cn=Sean y termina con dc=com.

Usted puede también filtrar en base a consultas LDAP, lo más útil es una búsqueda en objectClass. Por ejemplo, una clausula what de filter=(objectClass=posixAccount) coincide sólo con entradas con un objectClass de posixAccount. Para una revisión de objectClass, vea el primer tutorial en esta serie, LPI exam 301 prep: Concepts, architecture, and design.

La opción final para la clausula what sirve para especificar atributos. El uso más común es para restringir quién puede ver atributos privados, especialmente contraseñas. Use attrs=userPassword para hacer coincidir el atributo password.

Una vez que ha determinado qué entradas y atributos van a hacerse coincidir, debe entonces describir a quien aplicará la regla.

Describa el who

El acceso aplica a un usuario, en base al DN que fue suministrado al momento en el que el cliente es vinculado al árbol. El DN generalmente se encuentra en el árbol, pero podría también ser suministrado rootDN en slapd.conf.

El Listado 3 muestra el BNF para la notación para la parte who del ACL.

Listado 3. Notación BNF para hacer coincidir la parte who de un ACL
<who> ::= * | [anonymous | users | self[.<selfstyle>]
                        | dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
                [dnattr=<attrname>]
                [group[/<objectclass>[/<attrname>][.<basic-style>]]=<regex>]
     		[peername[.<peernamestyle>]=<peername>]
		[sockname[.<style>]=<sockname>]
		[domain[.<domainstyle>[,<modifier>]]=<domain>]
		[ssf=<n>]
		[transport_ssf=<n>]
		[tls_ssf=<n>]
		[sasl_ssf=<n>]

<style> ::=	{exact|regex|expand}
<selfstyle> ::=	{level{<n>}}
<dnstyle> ::=	{{exact|base(object)}|regex
                 |one(level)|sub(tree)|children|level{<n>}}
<groupstyle> ::=	{exact|expand}
<peernamestyle> ::=	{<style>|ip|path}
<domainstyle> ::=	{exact|regex|sub(tree)}
<modifier> ::=	={expand}

Como en la parte what del ACL, un asterisco hace coincidir todo. Para ser más específico, tiene más opciones. OpenLDAP define tres atajos denominados anonymous, users, y self. Estos atajos hacen coincidir usuarios no registrados, usuarios autenticados, y el usuario actualmente registrado, respectivamente. Este último, self, es a menudo utilizado para permitir al usuario registrado editar componentes de su propio perfil. Esto se basa en una coincidencia exacta del DN; Si usted tiene la información de un usuario dividida en diferentes entradas, la palabra claveself aplica sólo a la entrada a la que está vinculado el usuario.

Algo interesante sobre la palabra clave self es que puede también hacer que el ACL aplique a padres o hijos de la entrada del usuario con la palabra clave level. Usando self.level{1} se hace coincidir la entrada del usuario y la entrada padre, mientras que self.level{-1} coincide con la entrada y cualquier hijo directamente conectado.

Todavía buscando en el DN, usted pueden realizar coincidencias de expresiones regulares o exactas con dn.exact="DN" y dn.regex="regex", respectivamente. Un último ejemplo mostrará cómo usar expresiones regulares para unir dinámicamente el what y el who.

Las entradas arbitrarias pueden protegerse usando la palabra clave dnattr, la cual requiere también el nombre de un atributo. Si el DN del solicitante aparece en el atributo específico del destino, el ACL se hace coincidir. Por ejemplo, si agrega dnattr=manager a su ACL y luego agrega manager: cn=Joe Blow,ou=people,dc=ertw,dc=com a la entrada de Fred Smith, el ACL coincidirá cuando Joe Blow acceda a la entrada de Fred Smith.

La palabra clave group es similar a dnattr, excepto que los parámetros se refieren a un grupo definido en algún otro lugar en el árbol en lugar de un atributo en la entrada. Por omisión, el grupo tiene una objectClass de groupOfNames, y se hace referencia a los miembros en el atributo member .

Use las palabras claves peername, sockname, y domain para hacer coincidir los atributos de la conexión del cliente. peername se refiere a la dirección IP del cliente, como peernameip=127.0.0.1. sockname es para conexiones sobre tuberías designadas, las cuales no son utilizadas por lo general. domain hace coincidir el nombre de host relacionado con la dirección IP, el cual puede ser fácilmente clonado.

El conjunto final de opciones se refiere al Security Strength Factor (SSF) de la conexión, el cual es un término de OpenLDAP para el nivel de seguridad de la conexión. Estas opciones serán aclaradas cuando le presentemos los mecanismos de seguridad utilizados para conectar a OpenLDAP, como Transport Layer Security (TLS), Simple Authentication y Security Layer (SASL).

Todos los elementos precedentes pueden ser utilizados juntos. Por ejemplo, usted podría permitir escribir acceso al campo de la palabra clave sólo a ciertos administradores que vienen de un cierto rango de dirección IP con cierto nivel de encriptamiento. Podría hacer también mucho menos, como requerir sólo un login válido, o hasta aceptar a cualquiera más allá de su autenticación.

Descripción del acceso

Una vez que determina quien accede a su árbol y a qué está tratando de acceder, debe especificar qué nivel de acceso tiene. El Listado 4 muestra la notación BNF para la parte de acceso al ACL.

Listado 4. Notación BNF que describe el formato de la cláusula de acceso
<access>  ::=  [[real]self]{<level>|<priv>} 
<level> ::= none|disclose|auth|compare|search|read|write
<priv> ::= {=|+|-}{w|r|s|c|x|d|0}+

Al especificar el acceso usando el formato level , cada nivel sucesivo incluye los que están antes que él. Es decir, read access brinda search, compare, auth, y disclose access. none y disclose niegan cualquier acceso, excepto que algún mensaje de error que pudiera mostrar información sobre los contenidos del árbol fuera eliminado por none y permitido por disclose.

Opcionalmente, usted puede especificar el nivel de acceso en términos de operaciones LDAP permitidas usando el formato priv . Las opciones se ejecutan de modo diferente al formato level , tanto que w se utiliza para escribir y 0 para ninguno. Al especificar acceso usando el formato priv no hay progresión implicada como en el caso de level. Si desea ofrecer aceso total, debe hacerlo con wrscx.

El símbolo =/+/- antes de las letras significa cómo el acceso especificado está asociado con el nivel de acceso actual si aplican múltiples reglas. Con =, todo el acceso previamente definido es ignorado, y el valor a utilizarse sigue el mismo signo. Con + y -, el acceso es agregado o substraido del nivel actual, respectivamente.

Comprensión del control

Por omisión, OpenLDAP toma un enfoque de primera coincidencia a las listas de acceso pertinentes. OpenLDAP encuentra la primera entrada ACL que coincide con la clausula what y, en esa entrada, encuentra la primera entrada que coincide con la parte who. Esto es como colocar la palabra clave stop después que el nivel de acceso es descripto. Las otras dos opciones son continue y break. Si usted utiliza continue, la entrada ACL actual es buscada para la siguiente línea que coincide con la parte who. Si utiliza break, el procesamiento de la entrada ACL actual se detiene, pero OpenLDAP busca la siguiente entrada ACL que coincide con la clausula who.

Uniendo los what, who, y access

Ahora que ha visto las tres partes del ACL (cuatro, si cuenta control), puede unirlas en una policy. El Listado 5 muestra una lista típica de ACLs que permite a los usuarios registrados leer el árbol y le permite a los usuarios actualizar sus propias palabras claves (pero no leerlas).

Listado 5. Una configuración ACL simple
access to attrs=userPassword
    by self =xw
    by anonymous auth

access to *
    by self write
    by users read

La primera clausula hace coincidir cualquiera que trata de acceder al campouserPassword . Al usuario se le da permiso de escritura y autenticación para su propia entrada, el cual se implementa a través de signos iguales. A los usuarios anónimos se les da permiso de autenticación. Un usuario es anónimo cuando está enlazado al árbol; por lo tanto, los usuarios anónimos requieren el permisoauth de modo que pueden registrarse como usuarios regulares, privilegiados.

Si la información solicitada no es la contraseña, la segunda entrada ACL es consultada. Nuevamente, el usuario tiene control total sobre su propia entrada (excepto el campouserPassword , debido a la primera entrada ACL), mientras que todos los usuarios autenticados tienen acceso de lectura al resto del árbol.

El Listado 6 muestra una entrada ACL que utiliza expresiones regulares para unir las clausulas what y who.

Listado 6. Crear con expresiones regulares
access to dn.regex="cn=([^,]+),ou=addressbook,dc=ertw,dc=com"
	by dn.regex="cn=$1,ou=People,dc=ertw,dc=com" write
	by users read

El Listado 6 le permite a los usuarios editar sus registros correspondientes en la parte del árbolou=addressbook,dc=ertw,dc=com . [^,]+ hace coincidir todo, pero no incluye, una coma, y el paréntesis guarda el texto coincidente en $1 para el primer conjunto de paréntesis, $2 para el siguiente, etc, incluyendo $9. La clausula who reutiliza el nombre del usuario para determinar quien puede acceder a la entrada. Si el nombre del usuario es el mismo que el de la entrada a la que se accede, entonces al usuario se le da acceso de escritura. Si esto fracasa, a los usuarios autenticados se les da acceso de lectura.

Consideraciones prácticas

Es inteligente mantener entradas ACL más específicas en la parte superior de la lista debido al comportamiento de la primera coincidencia; de otro modo, es más probable que el ACL anterior cause que se ignore el que está más abajo en la lista. Esta técnica puede utilizarse también para garantizar y revocar el acceso a un usuario determinado. Simplemente coloque su cláusula ACL específica en la parte superior de la lista.

Mantenga sus ACLs lo más simples posibles. Haciendo esto reducirá la posibilidad de error y también mejorará la performance. Los ACLs deben ser analizados gramaticalmente cada vez que una operación se realiza contra el árbol.


Replicación LDAP

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

En esta sección, usted aprenderá como hacer lo siguiente:

  • Comprender los conceptos de la replicación
  • Configurar la replicación de OpenLDAP
  • Ejecutar y administrar slurpd
  • Analizar los archivos de registro de la replicación
  • Comprender los hubs de réplica
  • Configurar las referencias de LDAP
  • Configurar la replicación de sincronización LDAP

En algún punto, sus necesidades pueden extenderse más allá del servidor. Su organización puede confiar en LDAP hasta el punto que la pérdida de su servidor LDAP es inaceptable, o el volumen de su consulta puede ser lo suficientemente grande que tiene que dividir sus consultas múltiples servidores. Podría ser incluso una combinación de ambos; pero en cualquier caso, usted necesita utilizar más de un servidor.

Con múltiples servidores, usted puede particionar su árbol en diferentes servidores, pero esto conduce a un aumento en la confiabilidad -- sin mencionar que puede ser difícil equilibrar de modo adecuado sus consultas. Idealmente, cada servidor tiene una copia idéntica del árbol. Cualquier escritura es propagada a otro servidor de modo oportuno, por lo que todos los servidores están actualizados. Esto se denomina replicación.

Este escenario, denominado multi-master, es complejo porque no es claro quién es el dueño de los datos. A menudo, ocurre una relación amo-esclavo, en la cual un servidor toma todas las escrituras y las enviar a los esclavos. Las consultas LDAP pueden realizarse contra cualquier servidor. Esto puede extenderse al escenario de réplica hub en el cual el servidor de esclavo único replica los datos del amo y, a su vez, replica los datos a otros esclavos.

OpenLDAP suministra dos métodos para realizar la replicación. El primero se realiza a través de slurpd, un daemon separado que observa los cambios en el amo y conduce los cambios en los esclavos. El segundo utiliza el motor de replicación de sincronicación de LDAP sincronicación de LDAP, de otro modo conocido como syncrepl. El método slurpd es ahora considerado obsoleto; la gente se apura a utilizar en su lugar syncrepl. Ambos métodos son analizados en esta sección.

Replicación slurpd-based

La replicación Slurpd-based es una replicación push en que el amo provoca cualquier cambio en los esclavos. Si un cliente trata de actualizar un esclavo, el esclavo se configura para enviar una referencia de regreso al cliente, indicando el cliente al amo. El cliente es responsable por la reutilización de la solicitud al amo. Slurpd es un daemon autosostenible que es configurado desde slapd.conf.

El flujo de los datos en el modelo de replicación slurpd

El servidor amo es el servidor que administra todas las escrituras desde los clientes y contiene la fuente autorizada de datos. Cualquier cambio al árbol del amo es ingresado en un registro de replicación, el cual es monitoreado por slurpd. slurpd impulsa los cambios a todos los esclavos tras notificación de un cambio en el registro de replicación.

La Figura 1 muestra el comportamiento típico de slurpd.

Figura 1. Flujo de datos en el modelo de replicación slurpd
Flujo de datos en el modelo de replicación slurpd

El proceso es el siguiente:

  1. El cliente envia una solicitud de actualización, la cual es recibida por un esclavo.
  2. El esclavo sabe que las escrituras pueden provenir sólo de su compañero de replicación, y por lo tanto envia una referencia de regreso al cliente, señalándolo al servidor amo.
  3. El cliente reemite la solicitud de actualización al amo.
  4. El amo realiza la actualización y escribe la modificación al registro de replicación
  5. slurpd, que también se ejecuta en el amo, observa el cambio en el registro de replicación.
  6. slurpd envía el cambio al esclavo.

De este modo, los esclavos pueden mantenerse actualizados con el amo en poco lapso de tiempo. Si ocurre alguna interrupción, o error en un esclavo, slurpd siempre sabe qué esclavos necesitan qué actualizaciones.

Configuración de slurpd

Para la configuración de la replicación basada en slurpd se deben seguir los siguientes pasos:

  1. Crear una cuenta de réplica que slurpd utilizará para autenticar contra la réplica esclava.
  2. Configurar el servidor amo con el nombre del esclavo.
  3. Configurar el esclavo para que sea una réplica, incluyendo cualquier ACLs necesaria.
  4. Copiar la base de datos desde la madre al esclavo.

La creación de la réplica es sencilla; el único requisito es que la cuenta tenga una contraseña en el atributo userPassword. Usted puede utilizar el inetOrgPersonobjectClass como la mayoría de las cuentas que pertenecen a la gente, o puede utilizar un objectClass más específico como account con el simpleSecurityObject auxiliar objectClass agregado. Recuerde del primer tutorial que losobjectClassestructurales defininen la entrada (y por lo tanto pueden utilizarse sólo uno por entrada), mientras que losobjectClasses auxiliares agregan atributos a cualquier entrada más allá del objectClassestructural. El Listado 7 muestra el código LDIF para agregar una cuenta de réplica.

Listado 7. Código LDIF para una cuenta de réplica
dn: uid=replica1,dc=ertw,dc=com
uid: replica1
userPassword: replica1
description: Account for replication to slave1
objectClass: simpleSecurityObject
objectClass: account

El Listado 7 muestra una entrada vacía -- sólo un nombre de usuario, contraseña y descripción, el cual es adecuado para la replicación. La descripción es opcional, pero se recomienda para la documentación. Recuerde la contraseña; ¡usted la necesitará en el próximo paso!

El amo debe ahora configurarse para almacenar todos los cambios en el registro de replicación, y una réplica debe configurarse para que slurpd funcione. Es importante recordar que slurpd lee su configuración de slapd.conf, y que slurpd impulsa las actualizaciones a los esclavos. Esto ayudará a recordar donde configurar la replicación y que las credenciales de autenticación pertenecen al amo. El esclavo puede validar las credenciales porque la cuenta es parte del árbol. El Listado 8 muestra la configuración del amo para permitir la replicación.

Listado 8. Configuración del amo para la replicación de slurpd
replica  uri=ldap://slaveserver.ertw.com
    suffix="dc=ertw,dc=com"
    binddn="uid=replica1,dc=ertw,dc=com"
    credentials="replica1"
    bindmethod=simple

replogfile /var/tmp/replicationlog

La configuración de la replicación sucede en el modo de la base de datos, así que asegúrese de que el comandoreplica esté en algún lugar después de su primera configuración de database. replica toma varios parámetros de la forma key=value. La clave uri especifica el nombre o la dirección IP del esclavo en el formato uniform resource identifier (URI), efectivamente el nombre del esclavo pretendido con ldap://.

Después de especificar el nombre del esclavo, puede opcionalmente configurar el nombre de la base de datos para replicar a través de la opción suffix. Por omisión, todas las bases de datos son replicadas. El requisito final es suministrar información de autenticación de modo que slurpd puede conectar al uri especificado. Para la autenticación simple, binddn, bindmethod, y credentials (la contraseña de usuario que asignó antes) es todo lo que necesita.

La pieza final del rompecabeza es indicarle a slapd donde almacenar su registro de replicación. Debe suministrar la ruta completa porque los nombres de archivos relativos no funcionan. No se preocupe sobre la creación del archivo, porque slapd lo creará por usted; pero la ruta que especifique debe poder ser editable por el usuario que está ejecutando slapd y slurpd.

En el servidor esclavo, debe configurar la cuenta de replicación y también decirle al esclavo que debería devolver a referencia al amo para escritura. El Listado 9 muestra esta configuración.

Listado 9. Configuración del esclavo
updatedn uid=replica1,dc=ertw,dc=com
updateref ldap://masterserver.ertw.com

El updatedn se refiere a la cuenta que creó anteriormente en el amo que slurpd utilizará para impulsar las actualizaciones a los esclavos. El updateref es otra LDAP URI, este es uno que señala al amo. El Listado 10 muestra un cliente tratando de actualizar el esclavo después de la carga de la configuración previa, y la recepción de una referencia.

Listado 10. Un cliente que recibe una referencia tras tratar de actualizar un esclavo
[root@slave openldap]# ldapadd -x -D cn=root,dc=ertw,dc=com -w mypass -f newaccount.ldif
adding new entry "cn=David Walberg,ou=people,dc=ertw,dc=com"
ldap_add: Referral (10)
        referrals:
                ldap://masterserver.ertw.com/cn=David%20Walberg,ou=People,dc=ertw,dc=com

Los clientes de línea de comando de OpenLDAP no siguen referencias, pero otras bibliotecas LDAP si. Si usted está usando LDAP en un entorno replicado, debería verificar que sus aplicaciones sigan las referencias correctamente.

La última pieza del rompecabezas es asegurarse de que el amo y el esclavo comiencen con bases de datos idénticas. Para hacer esto, siga estos pasos:

  1. Cierre el servidor amo.
  2. Cierre el servidor esclavo.
  3. Copie los archivos de la base de datos desde el amo al esclavo.
  4. Inicie el servidor amo y el esclavo.
  5. Inicie slurpd.

Ambos servidores deben cerrarse para copiar la base de datos, para asegurarse de que no se produzcan cambios y de que todos los datos sean copiados en el disco. Es vital que ambos servidores se inicien con el mismo conjunto de datos; de otro modo pueden desincronizarse más tarde. La replicación basada en slurpd esencialmente inicia todas las transacciones de nuevo en el esclavo que sucedieron en el amo, así que cualquier diferencia puede causar problemas.

slurpd puede iniciar automáticamente con slapd, dependiendo de su distribución y sus scripts de arranque. Si este no ha iniciado automáticamente, inícielo ejecutando slurpd en la línea de comando.

En este punto, la replicación debería estar ejecutándose. Cree una cuenta en su amo, y pruébelo. También pruebe que su esclavo envie las referencias si trata de actualizarlo.

Monitoreo de la replicación

Comprender como monitorear la replicación es importante porque pueden suceder errores que causen que los datos no estén sincronizados. Las mismas capacidades en el monitoreo ayudan también en la eliminación de fallas.

slurpd almacena sus propios archivos en /var/lib/ldap/replica (esto es separado del archivo de replicación producido por slapd). En este directorio están los archivos de replicación propios de slurpd y cualquier archivo rechazado. Si slurpd trata de enviar una actualización a un esclavo que falla, los datos son almacenados en un archivo denominado como el esclavo, con una extensión .rej. Dentro del archivo se encuentra el código LDIF que constituye la entrada junto con el error que devuelve el esclavo, como ERROR: Already exists. El Listado 11 muestra el contenido del archivo a .rej con un error diferente.

Listado 11. Un archivo de rechazo de replicación
ERROR: Invalid DN syntax: invalid DN
replica: slaveserver.ertw.com:389
time: 1203798375.0
dn: sendmailMTAKey=testing,ou=aliases,dc=ertw,dc=com
changetype: add
objectClass: sendmailMTAAliasObject
sendmailMTAAliasGrouping: aliases
sendmailMTACluster: external
sendmailMTAKey: testing
sendmailMTAAliasValue: testinglist@ertw.com
structuralObjectClass: sendmailMTAAliasObject
entryUUID: 5375b66c-7699-102c-822b-fbf5b7bc4860
creatorsName: cn=root,dc=ertw,dc=com
createTimestamp: 20080223202615Z
entryCSN: 20080223202615Z#000000#00#000000
modifiersName: cn=root,dc=ertw,dc=com
modifyTimestamp: 20080223202615Z

El archivo de rechazo en el Listado 11 comienza con un error de texto ("ERROR: Invalid DN syntax: invalid DN"), y el resto se ve como LDIF. Tenga en cuenta que el primer atributo es replica, el cual es el nombre de la réplica que no podía procesar la actualización, y el segundo atributo, time, es el momento en el que sucedió el error (en formato timestamp de UNIX). Los siguientes atributos provienen de la entrada que fue rechazada.

Los últimos 7 atributos se denominan atributos operacionales. Estos no formaron parte de los cambios originales, pero fueron agregados por el servidor LDAP por seguimiento interno. Un universally unique identifier (UUID) se dio a la entrada, junto con algo de información sobre cuando y quien cambió el registro.

En el Listado 11, el error probablemente proviene de un esquema faltante en el esclavo. El esclavo no comprende lo que es el atributo sendmailMTAKey, por lo tanto el DN de la entrada es inválido. El esclavo debe tener su esquema actualizado antes de que la replicación pueda continuar.

Para fijar una entrada rechazada, debe evaluar el error y fijar el problema subyacente con el árbol. Una vez que conoce la entrada rechazada aplicará limpiamente, use el modo one-shot de slurpd para aplicar la actualización con slurpd -r /path/to/rejection.rej -o. El parámetro-r le dice a slurpd que lea del registro de replicación dado, y -o provoca que slurpd utilice el modo one-shot, que significa que existe después del procesamiento del registro en lugar del comportamiento por omisión de esperar que se incorporen más entradas al registro.

Si la replicación no funciona en absoluto, el mejor enfoque es comenzar con el amo y seguir con el esclavo. Primero, elimine slurpd y realice un cambio al árbol. Luego, verifique si el registro de la replicación está aumentando; sino, el amo es configurado incorrectamente. Luego, inicie slurpd, y ejecute -d 255 en la línea de comando. Esto copia las acciones de slurpd mientras procesa los registros. Busque errores, especialmente aquellos relacionados con la apertura de archivos y controles de accesos.

Finalmente, en el esclavo, use loglevel auth sync para verificar cualquier error cuando ocurre la replicación (slapd registra a syslog con el dispositivo local4, de modo que quizá necesite agregar local4.* /var/log/slapd.log a /etc/syslog.conf).

Replicación de sincronización LDAP

slurpd es una solución sencilla para el problema de la replicación, pero tiene varios defectos. Cerrar su servidor amo de modo que pueda sincronizar un esclavo en el mejor de los casos poco práctico, y en el peor de los casos puede afectar el servicio. La arquitectura push de slurpd puede ser también limitante. slurpd dio buenos resultados en su momento, pero se creó algo mejor. RFC 4533 describe la operación de sincronización de contenido de LDAP, la cual se implementa en OpenLDAP pero el motor de replicacción de sincronización LDAP, también conocido como syncrepl.

syncrepl se crea como una capa insertada entre el núcleo de slapd y la base de datos backend. Todos los ingresos al árbol son rastreados por el motor syncrepl en lugar de requerir una instancia de servidor distinta. Aparte de los mecanismos de la replicación y los roles (descriptos luego), los conceptos son similares a slurpd. Los ingresos a una réplica son rechazados, con una referencia devuelta al servidor amo.

syncrepl es iniciado desde el esclavo, al cual ahora se le da el nombre de consumer. El rol del amo es denominado provider. En syncrepl, el consumidor conecta al proveedor para obtener actualizaciones al árbol. En el modo más básico, denominado refreshOnly, el consumidor recibe todas las entradas modificadas desde la última actualización, solicita una cookie que mantiene el rastro del último cambio sincronizado y luego se desconecta. En la siguiente conexión, la cookie se presenta al proveedor, el cual envía sólo las entradas que cambiaron desde la última sincronización.

Otro modo syncrepl, denominado refreshAndPersist, inicia como la operación refreshOnly; pero en lugar de desconectar, el consumidor permanece conectado para recibir cualquier actualización y cualquier cambio que sucede después de que la actualizacción inicial son enviados inmediatamente a la conexión al consumidor por el proveedor.

Configuración de syncrepl

El Listado 12 muestra la configuración del proveedor para ambos modos syncrepl (refreshOnly y refreshAndPersist).

Listado 12. Configuración del proveedor para syncrepl
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

La primera línea del Listado 12 permite la capa de syncprov. Las capas deben configurarse contra la base de datos; por lo tanto, esta configuración debe encontrarse después de la línea de configuración de subase de datos. Las siguientes dos líneas son opcionales, pero mejoran la confiabilidad. syncprov-checkpoint 100 10 le dice al servidor que almacene el valor de contextCSN al disco cada 100 operaciones de escritura o cada 10 minutos. contextCSN forma parte de la cookie mencionada anteriormente que ayuda a los consumidores a recoger el último ciclo de replicación de donde lo dejaron. syncprov-sessionlog 100 registra las operaciones de escritura al disco, el cual de nuevo ayuda en el ciclo de actualización.

Más detalles sobre la configuración del proveedor se encuentran en las páginas del manualslapo-syncprov(5).

El Listado 13 muestra el lado del consumidor del par de replicaciones.

Listado 13. Configuración del consumidor para syncrepl en modo refreshOnly
updateref ldap://masterserver.ertw.com
syncrepl rid=1
 provider=ldap://masterserver.ertw.com
 type=refreshOnly
 interval=00:01:00:00  
 searchbase="dc=ertw,dc=com"
 bindmethod=simple
 binddn="uid=replica1,dc=ertw,dc=com"
 credentials=replica1

Como el comando replica de la configuración de slurpd,el comandosyncrepl requiere un updateref, información sobre el árbol que está tratando de replicar y las credenciales de autenticación que utilizará. Esta vez, las credenciales corren por parte del consumidor y requieren suficiente acceso al proveedor para leer la parte del árbol que se replica. Las actualizaciones a las bases de datos en el consumidor son ejecutadas como el rootdn.

Los elementos en el Listado 13 específicos para syncrepl son rid, provider, type, y interval. rid identifica este consumidor al amo. El consumidor debe tener una ID única entre 1 y 999. El provider es un LDAP URI que indica nuevamente al proveedor. type especifica que usted solo desea sincronización periódica a través de refreshOnly, y el intervalo es por hora. El intervalo se especifica en el formatoDD:hh:mm:ss.

Inicie el consumidor con una base de datos vacía, y este replicará sus datos desde el proveedro y se actualizará cada una hora.

Realizar la transición al modo refreshAndPersist es sencillo. En el Listado 13, elimine el intervalo, y cambie el tipo a refreshAndPersist

syncrepl Filtering

Vale la pena no tener que replicar todo el árbol LDAP. Usted puede usar los siguientes comandos para filtrar los datos que son replicados.

Tabla 3. Comandos para el filtrado de tráfico de replicación
ComandoDescripción
searchbaseUn DN que señala el nodo en el árbol donde la replicación iniciará. OpenLDAP completará cualquier nodo padre necesario para completar el árbol.
AlcanceOne of sub, one, or base. Esto determina que tan abajo del árbol, comenzando en la base de búsqueda, esos datos son replicados. El valor por omisión es sub, el cual abarca la base de búsqueda y todos los hijos
FiltroUn filtro de búsqueda de LDAP, como (objectClass=inetOrgPerson) que controla que registros son replicados.
attrsUna lista de atributos que serán copiados de las entradas seleccionadas.

Como las otras opciones para syncrepl, estas opciones son ingresadas en la forma de key=value


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

En esta sección aprenderá a hacer lo siguiente:

  • Asegurar el directorio con SSL y TLS
  • Configurar y generar certificados cliente / servidor
  • Comprender consideraciones firewall
  • Configurar métodos de acceso no autenticados
  • Configurar métodos de autenticación de usuario / contraseña

Hasta este punto, todo el acceso a slapd ha sido sobre canales no encriptados usando contraseñas de texto sin formato. Esto se denomina autenticaciónsimple . Esta sección analiza la incorporación de encriptación a la conexión cliente-servidor.

Uso de SSL y TLS para asegurar las comunicaciones

Usted puede estar familiarizado con Secure Sockets Layer (SSL) y Transport Layer Security (TLS) como protocolos que aseguran las transacciones Web. Siempre que navega en una http de tipo URI, utiliza SSL o TLS. TLS es una mejora en SSLv3 y en algunos casos es compatible con versiones previas a SSL. Dado su herencia y compatibilidad compartida, a menudo se las conoce como SSL.

SSL utilizan certificados X.509, los cuales son datos en un formato estandar que ha sido firmado digitalmente por una tercera parte de confianza conocida como Certificate Authority (CA). Una firma digital válida significa que los datos que fueron firmados no han sido falsificados. Si los datos firmados fueran modificados, aunque sea un poco, entonces la firma no sería válida. Las partes independientes, como el cliente y el servidor, pueden validar las firmas porque ambos inician confiando en la CA.

En el certificado del servidor se encuentra la información sobre la propiedad del servidor, incluyendo su nombre en Internet. Por lo tanto usted puede estar seguro de que se está conectando al servidor correcto porque el nombre del servidor al que se conectó concuerda exactamente con el nombre que aparece en el certificado, y ha confiado en el CA para validar esto antes de firmar. El certificado también incluye la clave pública del servidor, la cual puede utilizarse para encriptar datos como los que sólo el portador de la clave secreta puede desencriptar.

Las claves públicas y secretas forman la base de la criptografía de las claves públicas o asimétricas. Es asimétrica porque los datos encriptados por la clave pública pueden ser descriptados sólo por la clave secreta, y los datos encriptados con la clave secreta pueden sólo ser desencriptados por la clave pública. De a cuerdo a lo que usted normalmente cree de un encriptamiento, como mantener un mensaje en secreto, el primer caso se utiliza. La clave pública se hace pública, y la clave secreta se hace secreta. Dado el comportamiento asimétrico de las claves, la clave secreta puede encriptar un mensaje, y cualquiera con la clave pública puede desencriptarlo. Así funcionan las firmas digitales.

Después de que el cliente se conecta al servidor y recibe el sertificado del servidor, el cliente puede validar que el nombre del servidor es correcto, lo cual evita un ataque man in the middle . La clave pública puede utilizarse para ejecutar a través de un protocolo que termina con el cliente y el servidor acordando un secreto compartido que nadie observa la conversación puede determinar. Este secreto es entonces utilizado para codificar el resto de la conversación entre el cliente y el servidor, denominada criptografíasimétrica porque la misma clave encripta y desencripta los datos. La división entre criptografía asimétrica y simétrica existe porque ela última es una orden de magnitud más rápida. La criptografía de clave pública es utilizada para autenticar y proponer un secreto compartido, y luego la criptografía de clave simétrica toma el control.

Para aplicar esto a OpenLDAP, debe crear un certificado para el servidor y luego configurar el servidor para que lo utilice. Este ejemplo usa un certificado autofirmado en lugar de crear una Certificate Authority (Autoridad de Certificado), lo cual significa que el certificado final ha sido firmado por si mismo. Este no suministra el nivel de confianza que si suministra un CA, pero es adecuado para realizar pruebas. El Listado 14 muestra la generación de la clave.

Listado 14. Generación del par de claves TLS
[root@bob ssl]# openssl genrsa -out ldap.key 1024
Generating RSA private key, 1024 bit long modulus
.................................++++++
.........................++++++
e is 65537 (0x10001)

El Listado 14 muestra la clave generada con el comando openssl genrsa. La clave tiene 1024 bits de largo, lo cual se considera adecuado actualmente para las claves públicas (tenga en cuenta que utilizar valores mucho más largos hace que las operaciones criptográficas sean mucho más lentas y puedan confundir a algunos clientes). Luego, openssl req toma la parte pública del par de claves recién generadas, agrega información local y empaqueta el resultado -- un Certificate Signing Request (CSR) -- para que sea firmado por un CA (ver el Listado 15).

Listado 15. Generación del Certificate Signing Request
[root@bob ssl]# openssl req -new -key ldap.key -out ldap.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:CA
State or Province Name (full name) [Berkshire]:Manitoba
Locality Name (eg, city) [Newbury]:Winnipeg
Organization Name (eg, company) [My Company Ltd]:ERTW
Organizational Unit Name (eg, section) []:Directory Services
Common Name (eg, your name or your server's hostname) []:masterserver.ertw.com
Email Address []:sean@ertw.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

El archivo generado, ldap.csr, puede ser enviado a un CA (junto con un buen pago) para ser firmado. Esto es también el procedimiento a seguir para generar un certificado para un servidor Web. Si usted envia esto para firmar, asegúrese de que toda la información suministrada sea ingresada correctamente, que las abreviaturas sean utilizadas sólo para el nombre del país, y que el nombre común coincida exactamente con el nombre del DNS que utilizará la gente para conectarse al servidor.

En lugar de hacer que un CA firme el CSR, en este ejemplo, usted lo firmará, como se muestra en el Listado 16.

Listado 16. Firma del CSR
[root@bob ssl]# openssl x509 -req -days 1095 -in ldap.csr -signkey ldap.key -out ldap.cert
Signature ok
subject=/C=CA/ST=Manitoba/L=Winnipeg/O=ERTW/OU=Directory Services/
  CN=masterserver.ertw.com/emailAddress=sean@ertw.com
Getting Private key

En el Listado 16 se firma la clave con el comando openssl x509. Usando -req se le dice a openssl que la entrada es un CSR. La validez del certificado es de 1095 días, o 3 años. Ahora que tiene ldap.key (la clave privada) y ldap.cert (el certificado y la clave pública).

Antes de continuar, agregue una línea a /etc/openldap/ldap.conf que contenga TLS_REQCERT allow. Esto le dice a las herramientas del cliente OpenLDAP que ignore el hecho de que están viendo un certificado autofirmado. De otro modo, las configuraciones por omisión rechazan el certificado por inválido.

Obtener OpenLDAP para usar la nueva clave y el certificado es sencillo. Asumiendo que almacenó las claves generadas en /etc/openldap/ssl/, las líneas en el Listado 17 configuran su servidor para conexiones TLS después de reiniciar slapd.

Listado 17. Configuración de slapd para SSL
TLSCertificateFile /etc/openldap/ssl/ldap.cert
TLSCertificateKeyFile /etc/openldap/ssl/ldap.key

Los comandos en el Listado 17 indican slapd para su certificado y clave privada. Para probar su nuevo servidor, emita el comando ldapwhoami -v -x -Z, el cual enlaza anónimamente a su puerto seguro. Si recibe un mensaje de "éxito" todo está funcionando correctamente. De otro modo la información de detección de fallas generada por -v indicará la causa o el error.

Usted puede generar un certificado de cliente, el cual es opcional, del mismo modo que el certificado del servidor. En lugar del Listado 17, use los comandosTLS_KEY y TLS_CERT en ldap.conf, que establecen su clave de cliente y certificado, respectivamente. Los certificados de cliente son necesarios sólo si necesita tener el certificado para identificar al cliente.

Consideraciones de Firewall

LDAP utiliza el puerto TCP 389, y LDAPS (LDAP over SSL) usa el puerto TCP 636. Si usted tiene un firewall entre los servidores y los clientes, estos puertos deben ser permitidos a través del firewall para que las conexiones tengan éxito. Los clientes siempre se conectan a los servidores, y, dependiendo de la estrategia de replicación, los servidores se conectan a otros servidores.

Tablas ip de Linux

Si tiene un firewall basado en tablas ip en su servidor LDAP, debe modificar su conjunto de reglas para permitir las conexiones entrantes. Generalmente, los comandos en el Listado 18 son suficientes.

Listado 18. Incorporación de reglas a tablas ip para permitir conexiones LDAP
iptables -A INPUT -p tcp --dport 389 -j ACCEPT
iptables -A INPUT -p tcp --dport 636 -j ACCEPT

El Listado 18 funciona si su política es simple. -A INPUT añade la regla a la tabla INPUT, donde todos los paquetes entrantes son verificados. Usted quizá tenga que insertar estas reglas en la parte superior (use -I INPUT en su lugar) o use las herramientas del firewall de su distribución para permitir puertos TCP 389 y opcionalmente 636 si necesita conectividad LDAPS.

Si está usando su firewall de Linux como un router, tal como el que los clientes adjuntaron a otra interfaz y el servidor LDAP está adjunto a otra interfaz, debe usar la cadena FORWARD en lugar de INPUT. Quizá desee también especificar la interfaz entrante con -i, como -i eth0 para indicar que sólo los paquetes entrantes que vienen en eth0 serán aceptados. Una vez que un paquete ha sido aceptado, los paquetes devueltos también serán aceptados.

Protección a través de TCP Wrappers

Una de las opciones de configuración disponibles al compilar OpenLDAP es --enable-wrappers, el cual enlaza los binarios resultantes contra las bibliotecas TCP Wrappers. Los wrappers usan dos archivos, /etc/hosts.allow y /etc/hosts.deny, para permitir o negar el acceso a clientes entrantes.

Primero verifique para ver si slapd usa TCP Wrappers con ldd /usr/sbin/slapd | grep libwrap. Si algo es devuelto, entonces su binario está utilizando TCP Wrappers. Sino, debe recompilar con --enable-wrappers o usar el método de las tablas ip que se mostró anteriormente.

Con el soporte de wrappers (envoltorios), usted puede negar que todos accedan agregando slapd: ALL a /etc/hosts.deny. Puede entonces permitir que aquellos con slapd: 192.168.1.,127.0.0.1, que permiten a cualquiera de la red 192.168.1.0/24 o del host local conectarse. Tenga en cuenta que las conexiones niegan a través de TCP Wrappers conectan al principio pero son luego desconectados automáticamente. Contraste esto a un firewall, donde el paquete es descartado antes de alcanzar slapd.

El formato de hosts.allow y hosts.deny permite muchas formas de permitir y negar conexiones; consulte todos los detalles en las páginas de manual hosts_access(5).

Más sobre autenticación

Hasta ahora, el análisis sobre la autenticación ha sido limitado a contraseñas de texto sin formato definido en slapd.conf y autenticación simple utilizada entre el cliente y el servidor. Las contraseñas de texto sin formato pueden resolverse con slappasswd. Ingrese slappasswd en el shell, y se le solicitará una contraseña y luego verificar esa contraseña. El resultado es un hash de la contraseña, como {SSHA}oxmMsm9Ff/xVQ6zv+bgmMQjCUFL5x22+. Este hash es garantizado matemáticamente para no ser reversible, aunque dado el hash, alguien podría adivinar repetidamente tratando varias contraseñas y viendo sie el hash es el mismo.

Ya ha experimentado el enlace anónimo, en el cual no se suministra nombre de usuario o contraseña, y el enlace autenticado, donde tanto el nombre de usuario como la contraseña son suministradas y válidas. OpenLDAP también soporta un enlace no autenticado, donde el nombre de usuario es suministrado sin contraseña. Un enlace no autenticado es generalmente desactivado al menos que tenga allow bind_anon_cred en su configuración. Si se permite, un enlace no autenticado es considerado anónimo.

La alternativa para la autenticación simple es Simple Authentication and Security Layer (SASL), un framework para suministrar una arquitectura plug-in para métodos de autenticación y encriptación. Una mirada detallada de SASL aparecerá en un próximo tutorial; mientras tanto, SASL permite diferentes métodos de autenticación para texto sin formato a Kerberos.

Anteriormente, cuando analizamos ACLs, este tutorial mencionó que el acceso puede ser influenciado por el método de conexión. Esto se denomina el Security Strength Factor (SSF). Una sección no encriptada tiene un SSF de 0, y una sección encriptada generalmente tiene un SSF correspondiente a la longitud de la clave. Por lo tanto, usted puede requerir una sección encriptada para un ACL particular agregando ssf=1 a la clausula who de su ACL.


Ajuste de performance de servicio LDAP

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

En esta sección, aprenderá cómo hacer lo siguiente:

  • Medir la performance de LDAP
  • Ajustar la configuración del software para aumentar la performance
  • Comprender los índices

OpenLDAP es una base de datos. Usted lo proporciona con una consulta o una tarea para ejecutar, y este encuentra los datos y se los proporciona a usted. Para hacer esto lo más rápido posible, debe asignar recursos a los lugares que serán mejor utilizados, como guardar en la memoria cache los datos a los que se accede con mayor frecuencia, e indexar las bases de datos.

Medir la performance

Antes de poder tratar de lograr que slapd se ejecute más rápidamente, debe poder medir el estado actual. Esto puede significar medir el tiempo de una determinada operación en su aplicación y buscar una mejora. Puede significar también la realización de varias consultas y el cálculo del promedio. La métrica quizá no esté basada en el tiempo; puede ser reducir la carga del disco en el servidor LDAP porque la configuración actual está causando demasiadas lecturas y escrituras.

De cualquier modo, es útil tomar varias medidas de diferentes métricas antes y después de cualquier modificación. Los comandos útiles son los siguientes:

  • vmstat para mostrar estadísticas de input /output (IO) y el uso de CPU, notablemente el tiempo del usuario y el tiempo de espera
  • iostat para mostrar más detalles sobre las lecturas y las escrituras al disco, junto con el uso del controlador del disco
  • ps para mostrar el uso de la memoria del proceso slapd (no es que el uso de más memoria sea malo, pero es importante asegurarse de que no quedarse sin RAM)
  • time para medir el tiempo de varias operaciones de línea de comando

Ajuste del daemon

El ajuste siempre involucra intercambios. A menudo, usted aumenta la cantidad de recursos (generalmente memoria o disco) a un proceso para obtener el proceso para responder más rápidamente. Esto disminuye los recursos que otros procesos pueden utilizar. De modo similar, si hace que el proceso se ejecute rápidamente, a menudo consume más recursos, como ciclos de CPU o IO de disco, que no están disponibles a otros procesos.

Los intercambios también pueden ocurrir en el nivel de la aplicación. Sacrificando algo de performance de escritura, usted a menudo puede mejorar drásticamente la performance de lectura, usted puede también hacer que su aplicación se ejecute más ráídamente apagando varios dispositivos de seguridad como el registro de la transacción. En caso de tener un colapso puede restaurar su base de datos del backup, pero sólo si sabe si es un intercambio aceptable.

La mayoría de la gente utiliza el Berkeley Database (BDB) backend. Este backend se basa en la Sleepycat Berkeley Database, ahora de Oracle, la cual es una base de datos de rápida incorporación. No soporta un lenguaje de consulta; en su lugar, esta basado en búsquedas basadas en tablas hash. El ajuste de este backend ocurre en dos lugares: uno en slapd.conf y otro en un archivo especial utilizado por el tiempo de ejecución de BDB.

Directivas de configuración de slapd.conf

La base de datos de BDB está conectada contra el binario que la utiliza, en lugar de ser un servidor autosostenible como la mayoría de los servidores SQL. Como tal, la aplicación que usa la base de datos BDB es responsable por algo del comportamiento de la base de datos. Las páginas del manual de slapd-bdb(5) describen todas las directivas que son controlables por slapd a través de slapd.conf; este tutorial abarca solo lo más importante.

Como la mayoría de los backends SQL, las bases de datos BDB escriba sus cambios en un registro de transacción para asegurar la confiabilidad en el caso de una falla; ellos también mantienen los datos en la memoria para guardar en las escrituras de disco. La operación que transmite todos los datos de la memoria al disco y escribe el registro de la transacción es denominado checkpoint. El comandocheckpoint le dice a slapd cual a menudo escribir los datos, en términos de kbytes de cambios almacenados y minutos desde el último punto de referencia. La incorporación de checkpoint 128 15 a slapd.conf significa que los datos serán transmitidos cada 128KB de cambios o al menos cada 15 minutos. Por omisión, no se realizan operaciones de punto de referencia que es lo mismo que checkpoint 0 0.

Las entradas a las que se ha accedido recientemente pueden almacenarse en la memoria cache en RAM para un acceso más rápido. Por omisión, se almacenan en la memoria cache 1000 entradas. Para modificar este número, use cachesize junto con la cantidad de entradas. Cuanto mayor el número de cachesize, más probable es que la entrada sea guardada en la memoria RAM, pero más RAM se consume por el proceso slapd. Su elección de valor aquí depende de cómo muchas entradas diferentes están en su árbol y el patrón de acceso. Asegúrese de tener suficiente espacio en la cache para guardar sus elementos a los que accede comunmente, como la lista de usuario.

Similar a cachesize es idlcachesize, el cual tiene que ver con qué tan grande es la memoria cache para los índices. Su configuración dependerá de cuantos índies haya configurado (se analiza más tarde), pero es inteligente comenzar realizando idlcachesize igual que cachesize.

Ajuste de las bases de datos BDB

Como hemos mencionado anteriormente, algunos de los parámetros de ajuste para las bases de datos BDB son administrados en un archivo distinto que se lee por el tiempo de ejecución de BDB y es ignorado por slapd. Este archivo se denomina DB_CONFIG, y vive en el mismo directorio que su base de datos. El parámetro más importante en ese archivo es set_cachesize, el cual establece el tamaño interno de BDB, no la cache de entrada de slapd. El formato es set_cachesize <GigaBytes> <Bytes> <Segments;>, en el cual GigaBytes y Bytes se refieren al tamaño de la cache (los dos son agregados juntos), y los segmentos le permiten dividir la cache en bloques de memoria separados para obtener alrededor de limitaciones de dirección de 32 bits (tanto 0 y 1 tienen el mismo efecto, permitiendo sólo un único segmento de memoria). Para una cache de 1GB, use set_cachesize 1 0 0.

Para determinar el mejor tamaño de cache BDB, a menudo es más fácil ver las estadísticas de la cache de un sistema en funcionamiento y aumentarlo según sea necesario. El comando para ver las estadísticas del uso de la memoria de una base de datos BDB es db_stat -h /path/to/database -m. Las primeras 20 líneas muestran detalles relevantes. Si se ha forzado la salida una gran cantidad de páginas de la cache, o la cantidad de páginas encontrada en la cache no es suficiente (< 95%), considere aumentar el tamaño de la cache BDB. En algunas distribuciones, db_stat puede llamarse slapd_db_stat para separarlo de las bibliotecas y herramientas del BDB del sistema.

Además de la cache, debe asegurarse de que los registros de las transacciones sean monitoreados. Establezca la ruta a los registros de las transacciones con set_lg_dir. Si puede colocar el registro de las transacciones en un conjunto diferente de ejes de disco al de la base de datos, logrará una performance mucho mejor.

Aunque BDB es una base de datos simple, necesita poder bloquear los archivos contra escritura. Las configuraciones por omisión para la cantidad de bloqueos en general es lo suficientemente grande, pero debería monitorear el resultado de db_stat -h /path/to/database -c por cualquier mención de alcance del número máximo de bloqueos. En BDB, los bloqueos están divididos en tres tipos (e informados por separado): lockers, locks, y lock objects. La diferencia entre ellos no es importante, pero la cantidad máxima de cada uno es controlada a través de set_lk_max_lockers, set_lk_max_locks, y set_lk_max_objects, respectivamente.

Siempre que usted realiza cambios a DB_CONFIG, debe reiniciar slapd. El Listado 19 muestra un ejemplo de un archivo DB_CONFIG basado en las directivas mencionadas anteriormente.

Listado 19. Archivo DB_CONFIG de muestra
# 256K cache
set_cachesize 0  268435456 0
set_lg_dir /var/log/openldap
set_lk_max_lockers 1000
set_lk_max_locks 1000
set_lk_max_objects 1000

Indexando la base de datos

La mayoría de las operaciones LDAP involucran algún tipo de búsqueda en un atributo, como un nombre de usuario, un número de teléfono, o una dirección de correo electrónico. Sin algo que lo ayude, slapd debe buscar en cada entrada al realizar una consulta. Al agregar un índice a un atributo se crea un archivo que permite a slapd buscar mucho más rápidamente porque los datos en un índice son almacenados de un modo que permite realizar búsquedas rápidas. Las desventajas de un índice son la velocidad de escritura más lenta y el mayor uso de disco y de memoria. Por lo tanto, es mejor indexar los atributos que son buscados con mayor frecuencia.

OpenLDAP soporta varios tipos de índices, dependiendo del tipo de búsqueda que se realice. Los tipos de índices aparecen en la Tabla 4.

Tabla 4. Tipos de índices de OpenLDAP
TipoPalabra claveDescripciónEjemplo de búsqueda
PresencepresUsada para búsquedas en las que se desea saber si existe un atributo.uid=*
EqualityeqUtilizada para búsquedas en las que se busca un valor específico.uid=42
SubstringsubUtilizada para búsquedas en las que se busca cadena en algún lugar de un valor. En este tipo, se puede especificar otros tres tipos optimizados o utilizar el sub tipo genérico. cn=Sean*
subiniitalUn índice de subcadena que busca una cadena en el comienzo de un valor.cn=Sean*
subanyUn índice de subcadena que busca una cadena en el medio de un valor.cn=*jone*
subfinalUn índice de subcadena que busca una cadena al final de un valor.cn=*Smith
ApproximateapproxUtilizada para búsquedas similares, en las cuales desea encontrar un valor que se parece a la cadena de búsqueda.cn~=Jason

Para aplicar un índice a un atributo, use la sintaxis index [attrlist] [indices], en la cual [attrlist] es una lista separada por comas de atributos y [indices] es una lista separada por comas de tipos de índices de la Tabla 4. Puede tener varias líneas index. Especificando default como los conjuntos de listas de atributos el tipo de índices que son utilizados cuando la lista de índices está vacía. Considere los índices definidos en el Listado 20.

Listado 20. Un conjunto de índices de muestra
index default eq,sub
index entryUUID,objectClass eq
index cn,sn,mail eq,sub,subinitial,subany,subfinal
index userid,telephonenumber
index ou eq

El Listado 20 primero define los índices por omisión como una coincidencia entre una equality y una substring. La segunda línea coloca un índice equality en el atributoentryUUID (bueno para la perforamance de syncrepl) y el atributo objectClass (una búsqueda común). La línea 3 coloca un índice equality y todos los índices de substring en los atributos cn, sn, y mail porque estos campos a menudo tienen diferentes caracteres comodín. Los atributos userid y telephonenumber reciben los índices por omisión porque no se ingresó nada más específico. Finalmente, el atributoou tiene un índice equality.

Después de cambiar las definicioens de su índice, debe reconstruir los índices deteniendo slapd y ejecutando slapindex como el usuario ldap (o, si está ejecutando como raíz, asegúrese de reasignar la propiedad de todos los archivos en el directorio de la base de datos al usuario ldap después de ejecutar slapindex). Inicie slapd, y sus índices serán utilizados.


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

En esta sección aprenderá a hacer lo siguiente:

  • Comprender las directivas de configuración de slapd.conf
  • Comprender las definiciones de la base de datos de slapd.conf
  • Administrar slapd y las opciones de su línea de comandos
  • Analizar los archivos de registro de slapd

Los contenidos de slapd.conf han sido cubiertos anteriormente en este tutorial y en el tutorial anterior. En esta sección resultan de particular interés las opciones de línea de comando y los comandos de registro disponibles para slapd.

Opciones de la línea de comando

La forma más sencilla de iniciar slapd es ejecutarlo sin argumentos. Slapd entonces lee el archivo de configuración por omisión, remueve el entorno, y lo desvincula de la terminal.

La Tabla 5 hace una lista de algunos de los argumentos útiles de la línea de comando.

Tabla 5. Los argumentos de la línea de comando slapd
ArgumentoValorDescripción
-dIntegerEjecuta slapd con eliminación extendida de fallas, y provoca que slapd se ejecute en el primer plano
-fFilenameEspecifica un archivo de configuración alternativo
-hURL listEspecifica las direcciones y puertos a los que escucha slapd
-sSysloglevelEspecifica la prioridad de syslog utilizada para los mensajes
-lIntegerEspecifica el dispositivo syslog local (como LOCAL4) usado para los mensajes
-uUsernameEjecuta slapd como el usuario determinado
-gGroupnameEjecuta slapd en un grupo determinado

La lista URL le permite enlazar slapd a diferentes interfaces. Por ejemplo, -h "ldap://127.0.0.1/ ldaps:///" provoca que slapd escuche al puerto TCP 389 (LDAP no encriptado) sólo en el bucle cerrado, y LDAP encriptado (puerto TCP 636) en todas las interfaces. Usted puede hasta modificar los números de puerto: por ejemplo, ldap://:5565/ provoca que LDAP no encriptado se ejecute en puerto 5565 de todas las interfaces.

Conprensión del registro

Slapd utiliza el Unix syslog daemon para el registro. Por omisión, todos los mensajes son enviados al dispositivo LOCAL4, de modo que necesita al menos local4.* /var/log/openldap.log en syslog.conf para capturar los mensajes a /var/log/openldap.log. El comandologlevel en slapd.conf entonces le dice a slapd que tipo de mensajes registrar. La Tabla 6 hace una lista de los posibles tipos de mensajes.

Tabla 6. Tipos de registros de mensajes de slapd
Palabra claveValor IntegerDescripción
trace1llamadas a función Trace
packet2Administración de paquetes para la resolución de problemas
args4Heavy trace debugging (argumentos de las funciones)
conns8Administración de la conexión
BER16Impresión de paquetes enviados y recibidos
filter32Búsqueda de filtro en proceso
config64Configuración de archivo en proceso
ACL128ACL en proceso
stats256Registro de estadísticas de conexiones/ operaciones/ resultados
stats2512Registro de estadísticas de entradas enviadas
shell1024Impresión de comunicación con backends de shell
parse2048Análisis gramatical de entradas
sync16384Replicación de LDAPSync

Usted puede usar una lista separada por espacios de palabras claves, valores integer, o la suma de los valores integer para la palabra clave loglevel. Por ejemplo, loglevel args ACL, loglevel 4 128, y loglevel 132 todos permiten la localización de problemas de argumentos de las funciones y ACLs.


Resumen

En este tutorial, aprendió sobre las listas de control de acceso, la replicación, la seguridad, el ajuste, y más detalles sobre la configuración general.

Las ACLs le indican quién obtiene acceso a qué conjunto de entradas y atributos. Usted debe configurar sus ACLs usando la forma access to <what> [ by <who> [ <access> ] [ <control> ] ]+. Puede usar una variedad de formas, incluyendo coincidencias directas y expresiones regulares para especificar el what. El who también puede utilizar coincidencias y expresiones regulares, pero puede también usar palabras claves como self, users, y anonymous. La cláusula who puede además buscar elementos como la fuerza de la conexión o la red de donde viene el usuario.

La replicación incluye mantener un servidor remoto actualizado con el servidor primario LDAP. Existen dos métodos para la replicación: slurpd y syncrepl. En el modelo slurpd, un daemon diferente se ejecuta en el servidor amo e impulsa todos los cambios a los esclavos. Los esclavos deben comenzar con una copia de los datos del amo; esto requiere período de inactividad en el amo. En syncrepl, el servidor proveedor (amo) ejecuta una capa para administrar las tareas de replicación. Los consumidores (esclavos) se conectan al amo y descargan las actualizaciones. Si un consumidor descarga actualizaciones periódicamente se dice que se encuentra en modo refreshOnly. Si el consumidor descarga las actualizaciones y permanece conectado, se encuentra en modo refreshAndPersist, y recibe actualizaciones a medida que tienen lugar en el proveedor.

TLS y SSL le permiten encriptar comunicaciones entre el cliente y el servidor, y hasta el tráfico de replicación. Debe generar claves y tenerlas firmadas por un CA para que TLS funcione. El tráfico LDAP regular se ejecuta sobre el puerto TCP 389, y el tráfico LDAP encriptado se ejecuta sobre el puerto TCP 636, de modo que debe tener sus firewalls configurados en consecuencia.

El ajuste de la performance involucra la asignación de recursos de sistemas a varias caches y buffers y la aplicación de índices a columnas en las que se busca frecuentemente. Los recursos de los sistemas están controlados en los archivos slapd.conf y DB_CONFIG. Los índices pueden ser equality, substring, presence, o approximate, dependiendo del tipo de búsqueda que se trate de optimizar.

La mayoría de los comportamientos de slapd son controlados en slapd.conf, de modo que hay sólo algunos parámetros de línea de comando para controlar las direcciones y puertos que escucha slapd, el usuario que ejecuta, y algunos parámetros sobre cómo se registra. Lo que slapd registra es controlado por la directica de loglevel en slapd.conf.

En este punto, usted tiene capacidades para instalar, configurar, y administar un servidor OpenLDAP funcional, incluyendo la seguridad, la replicación, y la el ajuste de la performance. Los dos tutorials siguientes se centrarán en aplicaciones de LDAP, como la integración de LDAP con sistemas de correo electrónico y autenticación, y búsqueda en su árbol desde su línea de comando.

Recursos

Aprender

Obtener los productos y tecnologías

  • La herramienta Firewall Builder realiza la tarea de ingresar reglas en tablas ip fácilmente; tiene un buen GUI y una suite de herramientas para desplegar actualizaciones en sus firewalls.
  • OpenLDAP es una buena opción para un servidor LDAP.
  • phpLDAPadmin es una herramienta de administración LDAP basada en la Web. Si GUI es más su estilo, Luma es una buena opción para tener en cuenta.
  • Con IBM trial software, que puede descargar directamente desde developerWorks, cree su próximo proyecto de desarrollo en 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=651068
ArticleTitle=Preparación para el examen 301 de LPI, Tema 303: Configuración
publish-date=07152011