Manejo de usuarios centralizado con LDAP

 

Daniel F. Moisset

Advertencia: Estas son más notas personales para dictado de la charla que material. Puede servir para darse una idea de los temas y como encararlos; para información más precisa y ordenada fijate en las referencias de abajo.

Contenidos

  • Overview del sistema de autenticación/usuarios
    • La forma clásica en UNIX
    • NSS (Solaris, GNU libc)
      • Servicios: usuarios, grupos, ...
    • PAM (Solaris, Linux)
      • Servicios: authentication, account, session, password
  • LDAP: una base de datos client/server
    • Configuración de slapd
    • Módulos de PAM/NSS y Configuración
    • Configuración del cliente
  • GNU TLS/SSL: Servicios de red con seguridad
    • Esquema general
    • Generación de certificados
    • Configuración

Overview del sistema de autenticación/usuarios

  • La forma clásica en UNIX
  • NSS (Solaris, GNU libc)
    • Servicios: usuarios, grupos, ...
  • PAM (Solaris, Linux)
    • Servicios: authentication, account, session, password

LDAP: una base de datos client/server

Lo que se almacena en la base de datos son objetos que pertenecen a una o varias objectClasses. Las que interesan para centralizar manejo de usuarios son: top, posixAccount, shadowAccount y posixGroup

Configuración del cliente

Vamos a necesitar ldap-client-tools (paquete), incluso en el server. Además necesitamos cierta configuración para que estas herramientas anden. En particular, /etc/ldap/ldap.conf: 

    BASE dc=example,dc=com,dc=ar
    URI ldap://server.example.com.ar

Sirve tener instalado el nscd, que acelera el proceso de búsqueda usando cacheado. El problema es que el cacheado hace que a veces se use la configuración vieja, así que conviene apagarlo hasta que se haya terminado de configurar todo.

Configuración de slapd

Lo asumimos instalado (viene en casi toda distro) y corriendo por defecto.

Necesitamos que tenga los esquemas que definen las clases de objetos en 

/etc/ldap/slapd.conf
: 
    include         /etc/ldap/schema/core.schema
    include         /etc/ldap/schema/cosine.schema
    include         /etc/ldap/schema/nis.schema
    include         /etc/ldap/schema/inetorgperson.schema

Lo usual es almacenar los datos en una Berkeley DB: 

    moduleload      back_bdb
    backend         bdb
    database        bdb

Ahora definimos el nombre de dominio que vamos a administrar. Puede ser ficticio, pero is importante que resuelva bien, y que se corresponda con la FQDN del servidor: 

    suffix          "dc=example,dc=com,dc=ar"

Luego de eso, tenemos que agregar un objeto representando el dominio. Generamos un LDIF, 

base.ldif
: 
    dn: dc=example,dc=com,dc=ar
    objectClass: top
    objectClass: organization

    dn:ou=Group,dc=example,dc=com,dc=ar
    objectclass: top
    objectclass: organizationalUnit
    ou: Group

    dn:ou=People,dc=example,dc=com,dc=ar
    objectclass: top
    objectclass: organizationalUnit
    ou: People

    dn: cn=admin,dc=example,dc=com,dc=ar
    objectClass: simpleSecurityObject
    objectClass: organizationalRole
    cn: admin
    description: LDAP administrator

Con esto hacemos: 

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

Podemos probar si todo anduvo bien con: 

    ldapsearch -x -D "cn=admin,dc=example,dc=com,dc=ar" -W

y deberían aparecer los registros anteriores

Con esto ya debería andar el slapd y tener la estructura para agregar usuarios

CPU

CPU es una herramienta muy piola de manejo de usuarios. Aunque se pueden manejar los usuarios con las herramientas de LDAP y pasandole LDIFs, se vuelve incómodo.

Hay que darle poca información de configuración, /etc/cpu/cpu.conf va: 

    LDAP_URI                = ldap://localhost
    BIND_DN                 = cn=admin,dc=example,dc=com,dc=ar
    BIND_PASS               = dsa89er23n9
    USER_BASE               = ou=People,dc=example,dc=com,dc=ar
    GROUP_BASE              = ou=Group,dc=example,dc=com,dc=ar

Después de eso uno tiene comandos cpu useradd, cpu groupadd, etc. Leer man cpu-ldap

Configuración de NSS

Pasamos ahora a los clientes (el servidor puede ser uno de ellos, y sería razonable). Con la configuración de NSS, deberíamos poder ver los nombres de usuarios al hacer un ls.

Toda esta parte conviene hacerla dejando siempre una consola de root abierta y no cerrarla hasta saber que todo anda. Nunca se sabe que es lo que se puede romper. Por empezar necesitamos el módulo apropiado de PAM, en Debian es libpam-nss. Despues de eso, tenemos que indicarle NSS que use ese módulo para buscar usuarios, editando /etc/nsswitch.conf: 

    passwd:         files ldap
    group:          files ldap
    shadow:         files ldap

y el archivo de configuración del módulo. Puede ser /etc/ldap.conf o /etc/libnss-ldap.conf: 

    host server.example.com.ar
    base dc=example,dc=com,dc=ar
    ldap_version 3
    rootbinddn cn=admin,dc=example,dc=com,dc=ar
    port 389

Eso debería alcanzar. Se prueba con chown y ls :)

Configuración de PAM

Mismas recomendaciones que antes, más fuerte. Hay que instalar libpam-ldap. Y configurar en /etc/ldap.conf o /etc/pam_ldap.conf: 


    host server.example.com.ar
    base dc=example,dc=com,dc=ar
    ldap_version 3
    rootbinddn cn=admin,dc=example,dc=com,dc=ar
    port 389
    pam_password crypt

Fijense que es casi igual (en algunas distros es el mismo archivo). Después de eso, necesitamos configurar los servicios de pam; normalmente hay una forma común de hacerlo. Por ejemplo en debian, están los /etc/pam.d/common... donde hay que poner: 

    account sufficient      pam_ldap.so
    account required        pam_unix.so try_first_pass

    auth    sufficient      pam_ldap.so
    auth    required        pam_unix.so nullok_secure try_first_pass

    password   requisite    pam_cracklib.so retry=3 minlen=6 difok=3
    password   sufficient   pam_ldap.so use_authtok
    password   required     pam_unix.so use_authtok md5

En mandrake eso va todo en common-system-auth

NSCD

Si se carga mucho la red, se puede poner este demonio que hace un poco de caching. Conviene ponerlo después de que todo anda, solo si ven que es una mejora.

GNU TLS/SSL: Servicios de red con seguridad

Todo el tráfico de LDAP va en plano por la red, lo que puede ser un riesgo de seguridad si se sospecha de posibles sniffers. La solución usual a este problema es configurar los clientes y servidores para que establezcan una conexión encriptada via SSL.

Aunque usualmente todo el mundo hace SSL con la biblioteca OpenSSL, el LDAP de debian lo hace con GNUTLS. Las herramientas para generar claves, y firmarlas son ligeramente distintas. Lo que va a abajo es una traducción del tutorial de LDAP+openssl para poder hacer las cosas en debian. Las cosas con el prompt "$" son de openssl, las del ">" son las de gnutls. Usar sólo las que correspondan a tu distribución.

Esquema general

Generación de certificados

El server necesita un certificado, firmado por una CA (autoridad certificante). Como la mayoría de los mortales no tenemos acceso/plata para conseguir una firma de una CA conocida, normalmente vamos a acabar generando una CA propia.

Creamos entonces una CA: 

    $ mkdir /br/ldap-certs/ca
    $ cd /br/ldap-certs/ca
    $ openssl req -new -x509 -keyout ./ca.key -out ./ca.crt

    > certtool --generate-privkey --outfile ca-key.pem
    > certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca-cert.pem

Ahora tenemos un certificado de CA y una clave privada de esta

Creamos un directorio para el certificado del servidor LDAP.: 

    $ mkdir /br/ldap-certs/server
    $ cd /br/ldap-certs/server
    $ openssl genrsa -out server.key

    > certtool --generate-privkey --outfile server.key

Y generamos un CSR (Pedido de Firma de Certificado): 

    $ openssl req -new -key server.key -out server.csr
    > certtool --generate-request --load-privkey server.key --outfile server.csr

Ahora, nuestra CA acepta el pedido y nos firma el certificado. 

    $ openssl ca -config ./openssl.cf -out server.crt -infiles ./server.csr
    > certtool --generate-certificate --load-request server/server.csr --outfile server/server.crt 
      --load-ca-certificate ca/ca-cert.pem --load-ca-privkey ca/ca-key.pem

Podemos revisar el contenido del certificado con este comando: 

    $ openssl x509 -text -in server.crt
    > certtool --certificate-info <  server.crt

Configuración

Hay que indicarle al servidor de ldap, /etc/ldap/slapd.conf esto: 

    TLSCipherSuite HIGH:MEDIUM:+SSLv2:RSA
    TLSCertificateFile /etc/ssl/ldap-certs/server/server.crt
    TLSCertificateKeyFile /etc/ssl/ldap-certs/server/server.key

Al cliente, /etc/ldap/slapd.conf: 

    TLS_CACERT /etc/ssl/ldap-certs/ca/ca-cert.pem

y en /etc/libnss-ldap.conf: 

    ssl start_tls
    tls_cacertfile /etc/ssl/ldap-certs/ca/ca-cert.pem
    tls_ciphers HIGH:MEDIUM:+SSLv2:RSA

Referencias

LDAP Implementation HOWTO: http://www.tldp.org/HOWTO/LDAP-Implementation-HOWTO/

LDAP SSL HOWTO: http://www.raphinou.com/ldaps/LDAP-SSL.HOWTO

 

Volver a la página principal