This project is read-only.
El servidor ya contiene la información básica para que el árbol pueda funcionar, y a partir de la cual ya se pueden ir añadiendo elementos en el árbol.

En una situación ideal el árbol partirá de un estado vacío y conforme se vaya requiriendo en la red en la que esté instalado el servidor, se va a ir añadiendo la información necesaria de usuarios.
Por desgracia para los administradores, esta situación se sucede en pocas ocasiones. Resulta más normal que el deseo del administrador sea la migración de usuarios y grupos de una o varias máquinas con usuarios en Linux o en cualquier otro servicio de directorios.
Dependiendo del ámbito de este servidor, esta tarea puede ser realmente pesada, ya que implicaría o la creación de ficheros ldif de gran tamaño o la inserción de usuarios con alguna de las herramientas gráficas descritas en el apéndice de este mismo handbook.
Para ello existen unos scripts desarrollados en perl, que pueden servir de gran ayuda para este propósito.
Los scripts conforman un paquete llamado MigrationTools que se puede encontrar en http://www.padl.com/OSS/MigrationTools.html.
Se pueden descargar desde esa misma URL o bien desde alguno de los binarios instalables adaptados a distintas distribuciones de Linux.

Como indica en el paquete disponible en la web, antes de poder empezar a usar las herramientas de migración hay que configurarlas, editando el fichero migrate_common.php. Este fichero de configuración es cargado por cada script en el momento de su ejecución.
Por lo general solo es imprescindible modificar dos parámetros que son:
$DEFAULT_BASE, que indica el dn raiz del árbol LDAP en el que se desea introducir toda la información migrada.
$EXTENDED_SCHEMA, que permite que se puedan añadir en el fichero importado una serie de atributos adicionales como el inetOrgPerson o el organizationalPerson.

No obstante, a parte de estos parámetros, resulta bastante interesante estudiar bien la documentación adjunta en el paquete y el fichero de configuración comentado, ya que hay opciones que incluso van a aceptar a el valor real de ciertos atributos del árbol, lo cual, en caso de no estar bien configurados, en un futuro puede ocasionar más de un problema según el uso que se quiera dar al servidor.

Existen diversos scripts que se pueden utilizar para muchos prósitos distintos. En realidad, para una atenticación simple de usuarios de Linux contra LDAP, solo es necesario almacenar en el árbol la información de los grupos y de los usuarios POSIX, con sus respectivos valores. Por el momento solo se va a hacer referencia a el migratebase.pl, migrategroup.pl y migrate_passwd.pl.
Como indica en el propio fichero de configuración, hay que tener cuidad, de que cada fichero este en la ruta correcta, como el migrate_base.pl. Una vez que hay certeza de que eso es correcto, los scripts se han de ejecutar desde la misma ruta en la que se encuentran, para que el funcionamiento sea correcto.

En primer lugar se ejecuta el migrate_base.pl de la siguiente forma:
./migratebase.pl > /tmp/migrationbase.ldif

Esto genera un fichero ldif, con multitud de diferentes entradas, de las cuales en este caso, apenas se van a utilizar. Entonces, una vez ejecutado el script, es conveniente revisar el fichero ldif generado y eliminar las entradas que vayan a ser innecesarias en un futuro. En este ejemplo, se van a dejar en ese fichero únicamente las dos unidades organizacionales imprescindibles que son People y Group:

dn: ou=People,dc=codeplex,dc=ndos
ou: People
objectClass: top
objectClass: organizationalUnit

dn: ou=Group,dc=codeplex,dc=ndos
ou: Group
objectClass: top
objectClass: organizationalUnit

Después de esto se puede pasar a la migración de los grupos del sistema, ejecutando lo siguiente:
./migrategroup.pl /etc/group /tmp/migrationgroup.ldif

En primer lugar, hay que darse cuenta de que no todos los scripts tienen el mismo formato de ejecución. Cada uno acepta unos parámetros distintos, y generan una salida distinta, por lo que antes de ejecutar cada uno, hay que prestar atención a algún tutorial, al fichero de documentación adjunto, o simplemente ejecutando el script de migración deseado, sin indicar ningún parámetro lo que provoca que se obtenga por la salida estándar el modo de uso normal del script.
Otra cosa que hay que tener en cuenta tras la ejecución de este script es que nuevamente se puede encontrar con información que no resulta imprescindible para todos los casos. En esta situación no es necesario tener almacenada en el árbol LDAP los grupos que no son de uso concreto, es decir, los que vienen ya instalados en el sistema o se generan a partir de la instalación de alguna aplicación. Lo más normal, es que sea mejor que esos grupos permanezcan en cada máquina físicamente, porque lo más probable es que no coincidan con exactitud en cada una de las máquinas que van a aprovechar el árbol como elemento de autenticación.
Por esta razón, nuevamente, tras generarse el fichero ldif con toda la información de grupos extraídos del /etc/group, se revisa el fichero y se eliminan a mano los grupos que no se desea que se migren al árbol LDAP.
Un ejemplo de grupo deseado sería:

dn: cn=foousers,ou=Group,dc=codeplex,dc=ndos_
objectClass: posixGroup
objectClass: top
cn: foousers_
userPassword: {crypt}x
gidNumber: 1005

Por último, para extraer la información de los usuarios que hay registrados en un sistema Linux se ha de utilizar un nuevo script de la siguiente forma:
./migratepasswd.pl /etc/passwd /tmp/migrationpasswd.ldif

Esto generará un fichero ldif con toda la información de los usuarios que hay registrados en el sistema, con su correspondiente información de /etc/passwd y de /etc/shadow, donde se guarda la información adicional de las cuentas, además de las contraseñas encriptadas. De nuevo, hay que tener en cuenta, que en una situación de autenticación simple no es necesario, y a veces resulta inconveniente, almacenar en el árbol LDAP la información de usuarios propios del sistema. Así que en este caso solo se va a dejar la información correspondiente a los usuarios interactivos que se han ido registrando en el sistema. Dependiendo del sistema operativo, son fáciles de diferenciar fijándose en el uid que poseen. Por ejemplo en los sistemas Debian, los usuarios interactivos toman por defecto uid a partir de 1000. Un ejemplo de un usuario exportado a partir de un usuario de sistema sería el siguiente:

dn: uid=test,ou=People,dc=codeplex,dc=ndos
uid: test
cn:: dGVzdA==
sn:: dGVzdA==
mail: test@codeplex.ndos
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: krb5Principal
objectClass: shadowAccount
userPassword: {crypt}$1$bRVR4E8z$X8CEr7.mW6NwlizwkXKXZ1
shadowLastChange: 13314
shadowMax: 99999
shadowWarning: 7
krb5PrincipalName: test@CODEPLEX.NDOS
loginShell: /bin/bash
uidNumber: 1002
gidNumber: 1002
homeDirectory: /home/test

Aquí hay varias cosas que merece la pena observar detenidamente. No todos los atributos que se ven aquí tienen una correspondencia directa con los campos que se encuentran en cada usuario en los ficheros passwd y shadow del sistema. La correspondencia actual sería del siguiente tipo:

passwd.JPG
Relación entre la clase objeto posixAccount y una entrada de usuario del fichero /etc/passwd

shadow.JPG
Relación entre la clase objeto shadowAccount y una entrada de usuario del fichero /etc/shadow


Como se puede comprobar, no todos los atributos tienen su relación con los campos que hay en los ficheros de usuario. Por ello, también se puede percibir que hay atributos los cuales tienen valores que las propias migrationTools han impuesto. Alguno de ellos como el atributo mail, se puede controlar con la variable $DEFAULTMAILHOST del migrate_common.ph. Otros atributos que no siempre van a ser necesarios, son los relacionados con Kerberos (krb5), si esque no vamos a usar autenticación con Kerberos.

Una vez que ya tenemos toda la información preparada en ficheros ldif, se puede pasar a la importación en el árbol LDAP. Para esto, para mayor rapidez se va a volver a utilizar la herramienta de OpenLDAP ldapadd, de la siguiente manera:
ldapadd -D “cn=Manager,dc=codeplex,dc=ndos” -W -f /tmp/migrationbase.ldif_
ldapadd -D “cn=Manager,dc=codeplex,dc=ndos” -W -f /tmp/migrationgroup.ldif_
ldapadd -D “cn=Manager,dc=codeplex,dc=ndos” -W -f /tmp/migrationpasswd.ldif_

El servidor ya está listo con toda la información de usuarios y grupos, por lo que se puede prestar ya atención a la parte cliente del sistema Linux.

Antes de comenzar con las configuraciones, en el sistema han de estar instaladas las librerias pamldap y nssldap.

Una vez instaladas, se edita el fichero /etc/ldap/ldap.conf, modificando los siguientes valores:

BASE dc=codeplex,dc=ndos
URI ldap://codeplex.ndos

Hay que tener en cuenta que la URI ha de ser el host donde se encuentra el servidor LDAP, por lo que en caso de poner un nombre, ha de poderse resolver correctamente.

A continuación se edita el fichero /etc/libnss-ldap.conf modificando los siguientes valores básicos:

base dc=codeplex,dc=ndos
host 192.168.0.1

y en el caso de que se quisiera hacer bind en las consultas al árbol ldap, habría que fijarse atentamente en los parámetros binddn y rootbinddn. En este caso, no resulta necesario, por lo que se dejan por defecto.
Es conveniente prestar mucha atención a este último fichero de configuración, ya que es altamente modificable. Tiene una cantidad grande de parámetros, que se pueden adaptar a el servidor de cada uno.
Si se realiza una instalación y configuración por defecto como está aquí explicado, al igual que con la parte cliente, no existe ningún problema, pero en el momento en que cambian datos, como pueden ser las unidades organizacionales, hay que pasar a hacer las modificaciones precisas en este fichero.

Antes de cambiar el orden de resolución de usuarios, es imprescindible que siempre se tenga un usuario root logeado en la máquina, para que en caso de que haya algún problema con el momento de autenticación, se pueda hacer una recuperación, sin tener que hacer login de nuevo en el sistema.
Por último es preciso decir a los módulos de pam, de que manera tiene que comportarse cuando recibe un intento de autenticación. Esto se hace editando los siguientes módulos de la siguiente forma:


En el módulo /etc/pam.d/common-account se edita lo siguiente:
account sufficient pamldap.so_
account required pamunix.so tryfirstpass_

En el módulo /etc/pam.d/common-auth se edita lo siguiente:
auth sufficient pamldap.so_
auth required pamunix.so nulloksecure tryfirstpass

Y en el módulo /etc/pam.d/common-password se edita lo siguiente:
password sufficient pamldap.so_
password required pamunix.so nullok obscure min=4 max=8 md5 tryfirstpass_

De esta forma, pam entiende que si la autenticación da cierto contra el servidor LDAP, no va a ser necesario que compruebe el usuario y contraseña en el sistema. Si no da cierto, va a intentar autenticar contra el sistema.
Por último es preciso decir al que los usuarios y grupos intente resolverlos, no contra el sistema, sino contra el servidor LDAP. Esto se hace modificando el fichero encargado de estas resoluciones, que es /etc/nsswitch.com de la siguiente forma:

passwd: compat ldap
group: compat ldap
shadow: compat ldap

En realidad, en este caso, en primer lugar intentará resolver contra el sistema, y en caso de no encontrar ese usuario o grupo, lo hará contra el servidor LDAP previamente configurado.

Last edited Sep 26, 2006 at 2:32 PM by luisbosque, version 6

Comments

No comments yet.