Red SWL (V): Debian Wheezy y ClearOS. Autenticación SSSD contra LDAP nativo.

¡Hola amigos!. Por favor, repito, lean antes «Introducción a una Red con Software Libre (I): Presentación del ClearOS» y descarguen el paquete de las imágenes de instalación Paso a Paso del ClearOS (1,1 mega), para estar enterados de lo que estamos hablando. Sin esa lectura será difícil seguirnos.

System Security Service Daemon

El programa SSSD o Demonio para el Servicio de Seguridad del Sistema, es un proyecto de Fedora, que nació de otro proyecto -también de Fedora- denominado FreeIPA. Según sus propios creadores, una corta y libremente traducida definición sería:

SSSD es un servicio que provee el acceso a diferentes proveedores de Identidad y Autenticación. Se puede configurar para un dominio LDAP nativo (proveedor de identidad basado en LDAP con autenticación mediante LDAP), o para un proveedor de identidad LDAP con autenticación mediante Kerberos. SSSD provee la interfaz al sistema mediante NSS y PAM, y un Back End insertable para conectarse a múltiples y diferentes orígenes de cuentas.

Opinamos que estamos frente a una solución más integral y robusta para la identificación y autenticación de usuarios registrados en un OpenLDAP, que las abordadas en los artículos precedentes, aspecto que queda a criterio de cada cual y a sus propias experiencias.

La solución planteada en éste artículo es la más recomendada para equipos móviles y laptos, ya que nos permite trabajar desconectados, pues el SSSD almacena las credenciales en el equipo local.

Red de ejemplo

  • Controlador de Dominio, DNS, DHCP: ClearOS Enterprise 5.2sp1.
  • Nombre del Controlador: centos
  • Nombre del Dominio: amigos.cu
  • IP del Controlador: 10.10.10.60
  • ——————————————-
  • Versión de Debian: Wheezy.
  • Nombre del equipo: debian7
  • Dirección IP: Mediante DHCP

Comprobamos que el servidor LDAP esté funcionando

Modificamos el archivo /etc/ldap/ldap.conf e instalamos el paquete ldap-utils:

:~# nano /etc/ldap/ldap.conf
[----]
BASE    dc=amigos,dc=cu
URI    ldap://centos.amigos.cu
[----]
:~# aptitude install ldap-utils
:~$ ldapsearch -x -b 'dc=amigos,dc=cu' '(objectclass=*)'
:~$ ldapsearch -x -b dc=amigos,dc=cu 'uid=trancos'
:~$ ldapsearch -x -b dc=amigos,dc=cu 'uid=legolas' cn gidNumber

Con los dos últimos comandos, comprobamos la disponibilidad del servidor OpenLDAP de nuestro ClearOS. Observemos muy bien las salidas de los comandos anteriores.

Importante: hemos comprobado también que el Servicio de Identificación en nuestro servidor OpenLDAP funciona correctamente.

red-swl-04-usuarios

Instalamos el paquete sssd

También es recomendable instalar el paquete finger para hacer comprobaciones más potables que el ldapsearch:

:~# aptitude install sssd finger

Al finalizar la instalación, el servicio sssd no se inicia debido a que falta el archivo /etc/sssd/sssd.conf. La salida de la instalación lo refleja. Por eso, debemos crear ese archivo y lo dejamos con el siguiente contenido mínimo:

:~# nano /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
services = nss, pam
# SSSD will not start if you do not configure any domains.
# Add new domain configurations as [domain/<NAME>] sections, and
# then add the list of domains (in the order you want them to be
# queried) to the "domains" attribute below and uncomment it.
domains = amigos.cu

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3

[pam]
reconnection_retries = 3

# LDAP domain
[domain/amigos.cu]
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap

# ldap_schema can be set to "rfc2307", which stores group member names in the
# "memberuid" attribute, or to "rfc2307bis", which stores group member DNs in
# the "member" attribute. If you do not know this value, ask your LDAP
# administrator.

# funciona con ClearOS
ldap_schema = rfc2307
ldap_uri = ldap://centos.amigos.cu
ldap_search_base = dc=amigos,dc=cu

# Note that enabling enumeration will have a moderate performance impact.
# Consequently, the default value for enumeration is FALSE.
# Refer to the sssd.conf man page for full details.

enumerate = false

# Allow offline logins by locally storing password hashes (default: false).

cache_credentials = true
ldap_tls_reqcert = allow
ldap_tls_cacert = /etc/ssl/certs/ca-certificates.crt

Creado el archivo le asignamos los permisos correspondientes y reiniciamos el servicio:

:~# chmod 0600 /etc/sssd/sssd.conf
:~# service sssd restart

Si deseamos enriquecer el contenido del archivo anterior, recomendamos ejecuten man sssd.conf y/o consulten la documentación existente en Internet, empezando por los enlaces reflejados al inicio del post. También consulten man sssd-ldap. El paquete sssd incluye un ejemplo en /usr/share/doc/sssd/examples/sssd-example.conf, que puede servir para autenticarnos contra un Directorio Activo de Microsoft.

Ahora podemos utilizar los comandos más potables finger y getent:

:~$ finger trancos
Login: trancos                    Name: Trancos El Rey
Directory: /home/trancos                Shell: /bin/bash
Never logged in.
No mail.
No Plan.

:~$ sudo getent passwd legolas
legolas:*:1004:63000:Legolas El Elfo:/home/legolas:/bin/bash

Aun no podemos autenticarnos como un usuario del servidor LDAP. Antes debemos modificar el archivo /etc/pam.d/common-session, para que se cree automáticamente la carpeta del usuario al iniciar su sesión, en caso de que no exista, y luego reiniciar el sistema:

[----]
session required pam_mkhomedir.so skel=/etc/skel/ umask=0022

### La línea anterior se debe incluir ANTES de
# here are the per-package modules (the "Primary" block)
[----]

Reiniciamos nuestro Wheezy:

:~# reboot

Después de iniciar una sesión, desconecten la red mediante el Administrador de Conexiones y cierren la sesión y vuelvan a entrar. Más rápido nada. Ejecuten en una terminal ifconfig y verán que la eth0 no está para nada configurada.

Activen la red. Cierren sesión e inicien sesión nuevamente. Comprueben de nuevo con ifconfig.

Por supuesto que, para trabajar desconectado, es necesario iniciar sesión al menos una vez estando el OpenLDAP en línea, para que se guarden las credenciales en nuestro equipo.

No olvidemos hacer miembro al usuario externo registrado en el OpenLDAP de los grupos necesarios, fijándonos siempre por el usuario creado durante la instalación.

Nota:

Declarar la opción ldap_tls_reqcert = never, en el archivo /etc/sssd/sssd.conf, constituye un riesgo de seguridad según se afirma en la página SSSD – FAQ. El valor por defecto es «demand«. Consulte man sssd-ldap. Sin embargo, en el capítulo 8.2.5 Configuring Domains de la documentación de Fedora, se plantea lo siguiente:

SSSD does not support authentication over an unencrypted channel. Consequently, if you want to authenticate against an LDAP server, either TLS/SSL or LDAPS is required.

SSSD no soporta la autenticación sobre un canal no encriptado. Por tanto, si usted quiere autenticarse contra un servidor LDAP, será necesario TLS/SLL o LDAP.

Personalmente opinamos que la solución abordada es suficiente para una LAN Empresarial, desde el punto de vista de la seguridad. A través de la Aldea WWW, recomendamos implementar un canal encriptado mediante TLS o «Transport Security Layer», entre el equipo cliente y el servidor.

Lo tratamos de lograr a partir de la correcta generación de certificados Auto Firmados o «Self Signed «en el servidor ClearOS, pero no pudimos. Es de hecho una asignatura pendiente. Si algún lector conoce el cómo hacerlo, ¡bienvenido sea a explicarlo!.

debian7.amigos.cu


8 comentarios, deja el tuyo

Deja tu comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.

  1.   eliotime3000 dijo

    Excelente.

    1.    federico dijo

      Saludos ElioTime3000 y gracias por comentar !!!

    2.    federico dijo

      Saludos eliotime3000 y gracias por el elogio al artículo !!!

  2.   kurayi dijo

    ¡Excelente! Quiero hacerle llegar una enorme felicitación al autor de la publicación por compartir su vasto conocimiento y al blog por permitir la publicación del mismo.

    ¡Muchas gracias!

    1.    federico dijo

      Muchas gracias por su elogio y comentario !!!. Fuerza que me das para continuar compartiendo conocimientos con la comunidad, en la que todos aprendemos.

  3.   phenobarbital dijo

    Buen articulo!, fijate que con respecto al uso de certificados, cuando generas el certificado debes agregar a la configuracion del ldap (cn=config) :

    olcLocalSSF: 71
    olcTLSCACertificateFile: /path/to/ca/cert
    olcTLSCertificateFile: /path/to/public/cert
    olcTLSCertificateKeyFile: /path/to/private/key
    olcTLSVerifyClient: try
    olcTLSCipherSuite: +RSA:+AES-256-CBC:+SHA1

    Con esto (y generando los certificados) tendras soporte SSL.

    Saludos!

    1.    federico dijo

      Gracias por tu aporte !!!. No obstante, publico 7 artículos sobre el OpenLDAP en:
      http://humanos.uci.cu/2014/01/servicio-de-directorio-con-ldap-introduccion/
      https://blog.desdelinux.net/ldap-introduccion/
      En ellos hago hincapié en el uso de Start TLS antes que SSL, que es lo recomendado por la openldap.org. Saludos @phenobarbital, y muchas gracias por comentar.
      Mi email es federico@dch.ch.gob.cu, por si quieres intercambiar más. Me resulta muy lento el acceder a Internet.

    2.    phenobarbital dijo

      Para TLS la configuracion es la misma, recordando que con SSL se hace el transporte transparente sobre un canal cifrado, mientras que en TLS se negocia un cifrado de doble via para el transporte de datos; con TLS el handshake se puede negociar en el mismo puerto (389) mientras que con SSL se hace la negociacion en un puerto alternativo.
      Cambia lo siguiente:
      olcLocalSSF: 128
      olcTLSVerifyClient: allow
      olcTLSCipherSuite: NORMAL
      (si eres paranoico de la seguridad usas:
      olcTLSCipherSuite: SECURE256:!AES-128-CBC:!ARCFOUR-128:!CAMELLIA-128-CBC:!3DES-CBC:!CAMELLIA-128-CBC)

      y reinicias, veras luego con:
      gnutls-cli-debug -p 636 ldap.ipm.org.gt

      Resolving ‘ldap.ipm.org.gt’…
      Checking for SSL 3.0 support… yes
      Checking whether %COMPAT is required… no
      Checking for TLS 1.0 support… yes
      Checking for TLS 1.1 support… yes
      Checking fallback from TLS 1.1 to… N/A
      Checking for TLS 1.2 support… yes
      Checking for Safe renegotiation support… yes
      Checking for Safe renegotiation support (SCSV)… yes

      Con lo cual el soporte a TLS tambien queda habilitado, usas 389 (o 636) para TLS y 636 (ldaps) para SSL; son completamente independientes uno del otro y no necesitas tener desactivado uno para usar el otro.

      Saludos!