Detalles

Hoy, configuré mi router para que empezara con pruebas más "fuertes", esto debido a que mi router dará IPs estáticas a mis máquinas de escritorio (deimos, phobos, portia); deimos una PII que no había ocupado principalmente porque estaba algo lento, se quedó como servidor de ldap, pasé toda mi configuración y oh sorpresa no funcionó... después de casi dos horas de mover y revisar configurar, aprendí algunas cosas, pero también descubrí (como lo había sospechado en la mañana) que el rootbindn que explicaba utiliza algo como: cn=admin,dc=portia..., no era realmente úlil, debido a que el ACL de la configuración de OpenLDAP le permite a todos lectura, además es muy impráctico guardar en varias máquinas el passwd (que además lo guarda en texto plano), y si, basta con comentar esas líneas en los respectivos archivos y todo funciona igual; ¿porqué no funcionaba en mi P2 recién instalada?, fue algo que descubrí después de mucho tiempo lo que me frustró el mencionado archivo que guarda el pass: /etc/ldap.secret, por supuesto todo estaba bien, el "cliente" intentaba loggearse con el cn=admin, pero resulta que si tiene pass, entonces por eso no le daba permiso; después vino un poco de frustración con mi Mac, pero veo que es muy fácil después de todo pedir que se autentifique; aunque ahora estoy en un pequeño dilema, y es que como siempre, debemos tener usuarios locales y los de ldap.

Una nota mental al respecto es que NUNCA, pero NUNCA debe utilizarse el nsswitch con:

passwd ldap

es decir omitir los "defaults", en este caso el compat o los files, en mi desesperación lo edité y lamentablemente mis datos se corrompieron al intentar agregar un usuario nuevo, al reiniciar mi sistema se congeló debido a que no conocia ningún grupo, y claro ldap no se pudo iniciar por las bd corrompidas; tuve que entrar con un disco de rescate para arreglar ese desperfecto, generar las nuevas bds (con mi nuevo usuario) y reiniciar; ahora está funcionanado a la perfección mi P2, y pienso dejarla dentro de poco funcionando todo el día como servidor específico de LDAP.

Mac

Como decía es muy fácil configurarlo, aqui hay una descripción:
http://www.cs.dixie.edu/ldap/mac/ldap/

Primero abrimos la aplicación de Configuración de Directorio dentro de la carpeta Utilidades en la carpeta de Aplicaciones


Después seleccionamos LDAPv3:


Le damos configurar en la siguiente pantalla le damos Nuevo...:


Le damos un nombre de configuración y después le damos sobre Editar:


Configuramos nuestra IP, después le damos sobre la pestaña de Búsqueda y Mapas:


Debemos dar la base de la búsqueda (DN) para los atributos, en mi caso es: dc=deimos,dc=danguer,dc=com, todo lo demás queda tal cual.

Por último debemos decirle al sistema que para autenticarse busque también en nuestro servidor LDAP recién configurado, después de darle un par de Ok's, damos sobre la pestaña de Autentificación de la pantalla principal, le cambiamos la lista de buscar a Ruta personalizada, le damos sobre Añadir y nos listará los directorios disponibles, en este caso: /LDAPv3/192.168.1.1, una vez hecho, le damos aceptar:


Por último probamos, en mi caso he dado de alta el usuario xdanguer, como en ambos directorios tengo la cuenta de danguer, el sistema me responde con los datos locales, cuando no lo encuentra, me responde con los de ldap:

Ordenador-de-Daniel-Guerrero:~/Sites/ldap danguer$ id danguer

iuid=501(danguer) gid=20(staff) groups=20(staff), 0(wheel), 80(admin)

Ordenador-de-Daniel-Guerrero:~/Sites/ldap danguer$ id xdanguer

uid=1001(xdanguer) gid=100(users) groups=100(users)

Próximo paso: configuración de windogs, próximo: asegurar la conexión mediante TLS, paso después: NFS

Referencias

Encontré un Wiki muy interesante que revisaré con mayor detalle dentro de poco:
http://wiki.debian.net/index.cgi?LDAPAuthentication

Funcionando

Por fin parece que esto está funcionando, los errores de la vez pasada fueron debido a que no generé bien los entries para el directorio ldap, ahora los generé bien y pude ver los datos a través del directory administrator, el problema parece ser que no está bien "sincronizado" este programa con la base que genera migration tools, otro error fue que no configuré bien pam ni nss, bueno, aqui los pasos detallados del lo que hice:

1) después de bajar los paquetes que mencioné en el post anterior, configuré ldap para que me genere el directorio por default, en mi /etc/ldap/slapd.conf tengo:

suffix          "dc=portia,dc=danguer,dc=com"



access to attribute=userPassword

        by dn="cn=admin,dc=portia,dc=danguer,dc=com" write

        by anonymous auth

        by self write

        by * none



access to *

        by dn="cn=admin,dc=portia,dc=danguer,dc=com" write

        by * read

Aunque al inicio tuve un problema porque me generó la bd con datos de nodomain o algo similar, lo que hice fue borrar la bd (/var/lib/ldap) y reconfigurarla con los datos del "dominio".

Ahora si slapcat me regresa la bd mínima:

dn: dc=portia,dc=danguer,dc=com

objectClass: top

objectClass: dcObject

objectClass: organization

o: portia.danguer.com

dc: portia

structuralObjectClass: organization

entryUUID: 1f592eb4-6684-1028-8da4-b6799de0b87a

creatorsName: cn=anonymous

modifiersName: cn=anonymous

createTimestamp: 20040710061419Z

modifyTimestamp: 20040710061419Z

entryCSN: 2004071006:14:19Z#0x0001#0#0000



dn: cn=admin,dc=portia,dc=danguer,dc=com

objectClass: simpleSecurityObject

objectClass: organizationalRole

cn: admin

description: LDAP administrator

userPassword:: ******

structuralObjectClass: organizationalRole

entryUUID: 1f8b08bc-6684-1028-8da5-b6799de0b87a

creatorsName: cn=anonymous

modifiersName: cn=anonymous

createTimestamp: 20040710061419Z

modifyTimestamp: 20040710061419Z

entryCSN: 2004071006:14:19Z#0x0002#0#0000

NSS

Siguiente paso, ya que bajé los módulos de NSS y PAM para ldap, hay que configurarlos, mi archivo de /etc/libnss-ldap.conf está así:

host 127.0.0.1

base dc=portia,dc=danguer,dc=com

rootbinddn cn=admin,dc=portia,dc=danguer,dc=com

Un error que me marcaba de Authentication service cannot retrieve authentication info (podía entrar como root a cualquier cuenta, pero simplemente no podía verificar los passwords), fue debido a que omití mi rootbinddn.

Ahora falta decirle a nss que utilice ldap, en mi archivo /etc/nsswitch.conf

passwd:         ldap compat

group:          ldap compat

shadow:         ldap compat

por supuesto faltan los de hosts y demás, pero por el momento sólo utilizo los de autentificación.

PAM

Ahora a configurar PAM, mi archivo /etc/pam_ldap.conf es muy similar al de nss:

host 127.0.0.1

base dc=portia,dc=danguer,dc=com

rootbinddn cn=admin,dc=portia,dc=danguer,dc=com

Mi archivo /etc/pam.d/common-password está asi:

password   required   pam_unix.so nullok obscure min=4 max=8 md5

password sufficient pam_ldap.so

con esto queda claro que si llega la autentificación por ldap, que se de por bien servido =).

Migración

Ahora viene lo interesante, "migrar" nuestros datos a ldap, esto se logra con migration tools, una vez descargado, se instala sobre: /usr/share/migrationtools, basta con editar el archivo:
migrate_common.ph para darle nuestras opciones, he aqui las mias:

# Default DNS domain

$DEFAULT_MAIL_DOMAIN = "portia.danguer.com";



# Default base 

$DEFAULT_BASE = "dc=portia,dc=danguer,dc=com";

Ahora hay que generar los archivos ldif (para insertarlos a nuestra bd de ldap):

perl migrate_base.pl > base.ldif

perl migrate_passwd.pl /etc/passwd > passwd.ldif

perl migrate_group.pl /etc/group > group.ldif

Cabe destacar que el base me generó dos dn, uno que ya existía (dc=portia,dc=danguer,dc=com) y otro que no puede
escribirse(dc=danguer,dc=com), borrándo estos dos nos permite
insertar sin problemas los datos, para insertar con el comando:

ldapadd -D "cn=admin,dc=portia,dc=danguer,dc=com" -x -W -f base.ldif

ldapadd -D "cn=admin,dc=portia,dc=danguer,dc=com" -x -W -f group.ldif

ldapadd -D "cn=admin,dc=portia,dc=danguer,dc=com" -x -W -f passwd.ldif

Después de dar estos comandos, nuestra bd estará lista, para probar se puede meter un caracter extra a un usuario de nuestro sistema:

danguer:x:1000:1000:Daniel Guerrero,,,:/home/danguer:/bin/bash

convertirlo a:

xdanguer:x:1000:1000:Daniel Guerrero,,,:/home/danguer:/bin/bash

e intentar loggearnos por ssh, su, login, al sistema, y si nos da acceso con nuestra cuenta "vieja" podemos saltar de alegria =). También podemos iniciar el servidor slapd en modo debug:

slapd -d 255

Así veremos que cuando intentamos ingresar, el sistema busca primero accesar por medio de ldap, si no lo intentará por archivo (por eso es importante la precedencia en el pam).