¡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.
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
orLDAPS
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!.
Excelente.
Saludos ElioTime3000 y gracias por comentar !!!
Saludos eliotime3000 y gracias por el elogio al artículo !!!
¡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!
Muchas gracias por su elogio y comentario !!!. Fuerza que me das para continuar compartiendo conocimientos con la comunidad, en la que todos aprendemos.
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!
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.
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!