Red SWL (IV): Ubuntu Precise y ClearOS. Autenticación SSSD contra LDAP nativo.

¡Hola amigos!. Directo al grano, no sin antes leer el artículo “Introducción a una Red con Software Libre (I): Presentación del ClearOS” y descargar 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. Ok? Desesperados Habituales.

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 Ubuntu: Ubuntu Desktop 12.04.2 Precise.
  • Nombre del equipo: precise
  • Dirección IP: Mediante DHCP

Preparamos nuestro Ubuntu

Modificamos el archivo /etc/lightdm/lightdm.conf para que acepte inicio de sesión manual, y lo dejamos con el siguiente contenido:

[SeatDefaults]
greeter-session=unity-greeter
user-session=ubuntu
greeter-show-manual-login=true
greeter-hide-users=true
allow-guest=false

Después de guardar los cambios, reiniciamos el Lightdm en una consola invocada mediante Ctrl + Alt + F1 y en ella ejecutamos, después de iniciar sesión, sudo service lightdm restart.

También es recomendable editar el archivo /etc/hosts y dejarlo con el siguiente contenido:

127.0.0.1    localhost
127.0.1.1    precise.amigos.cu precise
[----]

De esa forma obtenemos las respuestas adecuadas a los comandos hostname y hostname –fqdn.

Comprobamos que el servidor LDAP esté funcionando

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

:~$ sudo nano /etc/ldap/ldap.conf
[----]
BASE    dc=amigos,dc=cu
URI    ldap://centos.amigos.cu
[----]
:~$ sudo 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.

Instalamos el paquete sssd

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

:~$ sudo 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:

:~$ sudo 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:

:~$ sudo chmod 0600 /etc/sssd/sssd.conf
:~$ sudo 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 nos podemos mandar a correr y tratar de 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)
[----]

Ahora si reiniciamos:

:~$ sudo 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 una 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.

Si el equipo no quiere apagarse mediante el applet correspondiente, entonces ejecute en una consola sudo poweroff para apagar, y sudo reboot para reiniciar. Queda averiguar el porque a veces sucede lo anterior.

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!.


Categorías

Redes/Servidores

Ingeniero Termo Energético de profesión. Administrador de Redes desde hace ya varios años. Programador en Visual FoxPro. Debianero de Corazón, y "OldFashion Man". Contacto: federicotoujague@gmail.com / +53 5 5005735

4 comentarios

  1.   elav dijo

    Otro artículo a Marcadores 😀

    1.    federico dijo

      Gracias por comentar y Saludos !!!

  2.   joel dijo

    Hola. Estoy intentando hacerlo funcionar con un ubuntu server y otro ubuntu como cliente, y conectado funciona todo muy bien, pero a la que paro el servidor o desconecto la red no me acepta las contraseñas de los usuarios. No tengo ni idea de qué puedo estar haciendo mal. ¿Podría deberse a que no tengo el servidor ldap configurado para usar seguridad (ssl)?

    1.    braybaut dijo

      Exacto por eso es, como no tienes el canal encriptado no te aceptara la contraseña.

Deja un 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.