Google
Web dns.bdat.net

ACLs y Samba

A partir de la version 2.2.0 de Samba, este incorpora soporte para ACLs si el sistema operativo nativo lo soporta. Si hemos activado las ACLs como se indica arriba en nuestro núcleo, sólo debemos instalar las bibliotecas de desarrollo de atributos extendidos (libattr.a y libattr.h) y listas de control de acceso (libacl.a y libacl.h) en nuestro sistema para poder recompilar Samba con soporte para ACLs nativo. Si hemos seguido las instrucciones de compilación e instalación dadas arriba, estará todo lo necesario ya instalado.

Una vez compilado y para poder usarlo es necesario instalar las bibliotecas de enlace dinamico de atributos (libattr.so) y listas de control de acceso (libacl.so) en los lugares habituales. De nuevo, si hemos seguido las instrucciones de más arriba, ya tendremos instalado todo lo necesario.

Ahora sólo nos resta compilar samba con la opción de soporte para ACLs. Lo único necesario en este caso es, a la hora de lanzar la orden ./configure debemos añadir la opcion --with-acl-support a la lista de opciones que usamos habitualmente:


      ./configure --with-acl-support ... otras opciones adicionales

y compilar e instalar los nuevos binarios. A partir de este momento Samba contiene todo el codigo necesario para traducir las ACLs del protocolo SMB en ACLs nativas y viceversa, con lo cual tenemos soporte completo para el modelo de permisos tradicional de Microsoft Windows NT o posteriores.

Sin embargo, lo anterior por lo general no es suficiente si utilizamos Samba integrado en un dominio NT o 2000 (en modo mixto, ya que la versión estable de Samba -2.2.x- no tiene soporte para modo nativo de Active Directory). En este caso queremos usar la lista de usuarios y grupos del propio dominio para asignar los permisos y ACLs del recurso compartido por Samba.

Lo cual significa que dichas cuentas de usuario y grupo deben existir en el sistema operativo anfitrión donde se ejecuta Samba, ya que las ACLs del sistema operativo las crea el núcleo de Linux y por tanto debe usar UIDs y GIDs existentes en el sistema.

La solución es dar de alta todas esas cuentas en el sistema anfitrión. Pero si lo hacemos de forma manual tenemos dos grandes inconvenientes:

  1. El número de cuentas puede ser muy alto (gran cantidad de trabajo) y podemos no conocer las contraseñas de buena parte (o la totalidad) de dichas cuentas.

  2. A partir de este momento tenemos dos bases de datos de usuarios que mantener de forma sincronizada (manualmente), lo cual es siempre un desastre a punto de suceder.

Por suerte los chicos de Samba lo han tenido en cuenta, y a partir de la version 2.1.x de Samba han incorporado un nuevo componente a la familia de soluciones SMB: winbind.

Winbind es un módulo que se integra en el sistema Name Service Switch (NSS) y que es un componente más del sistema que puede enumerar usuarios y grupos. Se une así al sistema tradicional basado en ficheros locales y a los sistemas de gestión de usuarios basados en red como NIS, NIS+ o LDAP entre otros. Es por tanto un componente más que se compila con el resto de samba y que genera una serie de biblitecas de enlace dinámico para el sistema NSS.

Lo único que tenemos que hacer es lanzar la ejecución de Winbind (corre como un demonio de sistema), añadir en el fichero de configuración de Samba unas pocas directivas de configuración de Winbind para indicarle los rangos de UIDs y GIDs a gestionar, y configurar el Name Service Switch para que consulte a Winbind cuando no encuentre los usuarios en el resto de subsistemas configurados. Como el sistema NSS utiliza cachés de nombres, el rendimiento de Winbind es bastante rápido incluso en sistemas con unos pocos miles de usuarios (el autor lo utiliza de forma rutinaria con unas 1.000 cuentas de usuarios en una red de área local con un impacto de velocidad aceptable).

Valores de Configuración de Winbind en el fichero smb.conf

Lo primero que tenemos que hacer es editar el fichero smb.conf y añadir los parámetros que queremos que utilice winbindd (el demonio que oferta el servicio Winbid). Para ello tenemos que añadir las directivas:


  winbind separator = "."
        # usar los ujids de 10000 a 20000 para los usuarios del dominio
        winbind uid = 15000-20000
        # usar los ujids de 10000 a 20000 para los grupos del dominio
        winbind gid = 15000-20000
        # permitir la enumeracion de los usuarios y grupos del dominio
        winbind enum users = yes
        winbind enum groups = yes
        # tiempo, en segundos, para el cacheo de la informacion
        winbind cache time = 60

Donde:

  1. winbind separator: indica el carácter a usar como separador entre el nombre del dominio al que pertenece Samba y el nombre de usuario o grupo individual. Winbind construye nombres de usuarios del tipo DOMINIO_separador_USUARIO y DOMINIO_separador_GRUPO. Por ejemplo: ESCOMPOSLINUX.iarenaza usando el valor indicado en el ejemplo de arriba.

  2. winbind uids: indica el rango de UIDs del sistema anfitrion que Winbind usa para mapear los usuarios del dominio NT en los usuarios nativos del sistema local. Lo que hace Winbind es crear de forma artificial tantos usuarios locales (UIDs) como usuarios haya en el dominio, y hacer una asignacion estática entre ambos. Esta información se guarda en un fichero de bases de datos que conviene no perder (llamado winbindd_idmap.tdb, ubicado en /var/lib/samba en el caso de Debian GNU/Linux) o borrar, ya que la asignacion puede ser diferente la proxima vez que se construya la base de datos (de forma automatica por parte de Winbind si ve que esta falta).

    Es muy importante asegurarse de que el rango de UIDs (y GIDs para el valor siguiente) no estén siendo ya usados por otros subsistemas de enumeración/validación de usuarios (NIS, NIS+, LDAP, etc.)

  3. winbind gids: idéntico al parámetro anterior, pero para el rango de identificadores de grupos GIDs) a usar. Se almacenan en el mismo fichero que antes.

  4. winbind enum users: indica si queremos que winbind genere la lista de usuarios en respuesta a la ejecución de las funciones de biblioteca setpwent(), getpwent() y endpwent() que sirven para enumerar todos los usuarios existentes y sus datos asociados.

    En instalaciones con muchos usuarios (varios miles o decenas de miles) puede ser interesante suprimir esta enumeración (valor "no") por razones de rendimiento. Sin embargo, algunos programas se comportan de forma extraña en estos casos, con lo cual habrá que hacer pruebas en dichos casos.

  5. winbind enum groups: Idéntico al caso anterior, pero para las funciones de biblioteca setgrent(), getgrent() y endgrent(), que sirven para enumerar los grupos existentes en el sistema anfitrión.

  6. winbind cache time: tiempo en segundos a cachear la información sobre usuarios y grupos del dominio antes de volver a pedir los datos al controlador del dominio de nuevo.

Una vez ajustados los valores anteriores, debemos reinciar los demonios de Samba.

Configuración del Name Service Switch

Por último nos queda configurar el sistema NSS para enganchar Winbind como parte del mismo. Para ello debemos copiar las bibliotecas de enlace dinamico compiladas durante la compilación de Samba en el directorio /lib: el fichero llamado libnss_winbind.so.2 y crear un enlace simbólico a este llamado libnss_winbind.so.

Una vez copiados dichos ficheros, debemos configurar el sistema Name Service Switch para que utilice dichos servicios. Para ello editamos el fichero /etc/nsswitch.conf y añadimos el nombre winbind a las entradas passwd: y group::


  passwd: files ... otros ... winbind
        group: files ... otros ... winbind

Ejecución del demonio winbindd

Para poner en marcha el demonio winbindd, basta con lanzarlo como usuario root. Si nuestro sistema tiene arranque de tipo System V, podemos agregar un script que lo lance durante el arranque del mismo (después de haber lanzado el demonio nmbd ya que requiere de sus servicios) y que lo detenga durante la parada del sistema.

Una vez puesto en marcha winbind como parte del sistema NSS, podemos usar las ordenes:


  getent passwd
        getent group

para obtener un listado de todos los usuarios y grupos locales de la máquina, listado que debería contener todos los usuarios y grupos creado (importados) por winbind:


  root:x:0:0:root:/root:/bin/bash
        daemon:x:1:1:daemon:/usr/sbin:/bin/sh
        bin:x:2:2:bin:/bin:/bin/sh
        ...
        DOMINIO/aajuria:x:10011:10000:Ander Ajuria:/home/DOMINIO/aajuria:/bin/false
        DOMINIO/aalberdi:x:10012:10000:Amaia AlberdI:/home/DOMINIO/aalberdi:/bin/false
        DOMINIO/aalcelay:x:10014:10000:Amaia Alcelay:/home/DOMINIO/aalcelay:/bin/false
        ...

lo cual nos muestra que winbind está funcionando correctamente.