A vueltas con los Dominios Samba: Clientes Linux con el software PBIS Open

2 mayo 2017

Siguiendo con mi serie de entradas sobre AD, Linux y demás, voy a explicar cómo podemos agregar un cliente Linux a un Active Directory. Mi servidor está montado sobre Samba, como sabemos de entradas anteriores, pero voy a intentar “generalizarlo” para que sirva también para servidores Windows.

Recopilemos datos:

VirtualBox_WinCli_03_05_2017_21_42_25.png

En primer lugar, configuramos el cliente para que reconozca al servidor adecuadamente:

Red del Cliente

  • IP fija y dentro de la misma subred del servidor
  • Nombre de equipo fácilmente localizable dentro de la red
  • Único servidor DNS: el servidor (10.0.2.111 en mi caso)
  • Dominio de búsqueda: fedecasa.local
  • Fichero “nsswitch.conf” modificado si hiciera falta, para que reconozca el dominio.

VirtualBox_Cliente Ubuntu_03_05_2017_21_52_13

Todo esto se puede configurar con la ayuda de network-manager (o del fichero “interfaces”, siempre más recomendable)

Instalación de PBIS

Después de eso, tenemos varias posibilidades. Yo, por ahora me quedo con instalar PBIS Open; versión libre del software “PowerBroker Identity Services”, que promete integración total con AD desde Linux, Windows y otras plataformas. Simplifica mucho el trabajo. Más adelante hablaré de las otras opciones, también muy interesantes y completas. El cómo instalar los repositorios de PBIS lo obtuve aquí: https://repo.pbis.beyondtrust.com/apt.html

VirtualBox_Cliente Ubuntu_03_05_2017_21_51_36

Vemos que en el enlace correspondiente nos dice claramente las instrucciones de instalación. Hay dos versiones: “Open” y “Enterprise”. La Open es más que suficiente para nuestro propósito, así que será la que utilicemos.

Para instalar el repositorio:

wget -O - http://repo.pbis.beyondtrust.com/apt/RPM-GPG-KEY-pbis|sudo apt-key add - 
sudo wget -O /etc/apt/sources.list.d/pbiso.list http://repo.pbis.beyondtrust.com/apt/pbiso.list 
sudo apt-get update

Una vez termine de actualizar, instalamos el programa:

sudo apt-get install pbis-open

Alta en el Dominio

Por ejemplo, en somebooks. es nos explican este proceso, de forma ligeramente distinta a cómo lo estamos haciendo nosotros.

sudo domainjoin-cli join --disable ssh fedecasa.local administrator@fedecasa.local

La opción “disable ssh” se podría obviar, instalando soporte ssh en nuestro cliente. Pero como queremos simplificar más que complicar, seguimos con lo establecido.

Adjunto la captura del resultado de este comando según la guía de somebooks. Yo obtuve un resultado similar pero no hice la captura en su momento.

cap05v2-267.png

Para el módulo de autenticación dicen que hay un pequeño fallo, y la solución es la siguiente: editar el archivo /etc/pam.d/common-session y modificar la línea correspondiente a session pam_lsass.so, poniendo ésta en su lugar:

session [success=ok default=ignore] pam_lsass.so

07

En este momento, tendremos ya activado el inicio de sesión con usuarios del Dominio. Problemas:

  • aparecerán con un shell “mínimo” (sin prompt, sin configuración alguna, muy espartano)
  • Olvidaos de privilegios administrativos, por muy administradores del dominio que seamos.
  • la ruta por defecto del directorio “home” para el nuevo usuario será la siguiente (por ejemplo, para el usuario administrator@fedecasa.local) :
/home/local/FEDECASA/administrator

A partir de aquí, simplemente se trata de “jugar” con las opciones de este estupendo software. Definiremos una serie de opciones y podemos obtener fácilmente usuarios de dominio perfectamente integrados en Linux, con shell y directorio de inicio perfectamente definidos, utilizando algunos comandos encontrados en la Web.

VirtualBox_Cliente Ubuntu_03_05_2017_21_49_11

En esta web, por ejemplo, encontramos la mejor solución. Traduzco:

Primero uso el comando de configuración de PBIS para configurar correctamente el prefijo de los nombres de usuario (UserDomainPrefix), poner nuestro dominio por defecto (AssumeDefaultDomain), cambiar el shell por defecto (LoginShellTemplate) y la ruta del directorio “home” por defecto para los usuarios AD (HomeDirTemplate)

sudo /opt/pbis/bin/config UserDomainPrefix $domain
sudo /opt/pbis/bin/config AssumeDefaultDomain true
sudo /opt/pbis/bin/config LoginShellTemplate /bin/bash
sudo /opt/pbis/bin/config HomeDirTemplate %H/%U

En lo que respecta al último punto, la ruta del directorio “home”, hay que indicar que la ruta original por defecto se escribiría así: %H/local/%D/%U. Sabiendo esto, deducimos fácilmente lo siguiente:

  • %H significa “/home”
  • %D significa “FEDECASA”, es decir, el nombre del dominio (el que sea)
  • %U será el nombre del usuario.

Por tanto, si lo que quiero es definir una ruta de usuario convencional, puedo usar %H/%U, como en el ejemplo. Pero si quiero distinguir estas carpetas de alguna forma especial, tendremos que cambiar eso. Veamos cómo queda la ruta del usuario de dominio “administrator”, aunque más adelante volveremos sobre ese punto.

VirtualBox_Cliente Ubuntu_03_05_2017_21_54_25

Por último, tendremos que añadir privilegios administrativos a los administradores del Dominio. Para ello, habremos de modificar el fichero “/etc/sudoers”, usando el comando visudo y añadiendo la siguiente línea:

%domain^admins ALL=(ALL:ALL) ALL

junto a la línea correspondiente al grupo “sudo”. El nombre “domain admins” está en inglés porque, recordemos, estamos usando un dominio Samba y los nombres vienen en ese idioma.

Comprobamos como nuestro usuario, ahora sí, tiene otra pinta (perdonad que la captura es de otro ejemplo, pero vale igual):

Uso de carpeta personal remota

Nos queda el “toque final”: inicio de sesión en la carpeta remota. Para ello, disponemos de dos opciones:

  • Montaje automático de la carpeta previamente compartida con Samba. Problema: permisos. Necesitaríamos usuario/contraseña para determinarlos, y eso para un montaje automático es complicado…
  • Compartir nuestra carpeta con NFS. Problema: permisos.

Primera opción: SAMBA

En primer lugar, voy a simplemente montar la carpeta remota para su utilización, sin automatizar el inicio de sesión remoto. Para ello, utilizaremos los siguientes comandos:

sudo mkdir /mnt/home-red
sudo chmod 777 /mnt/home-red
sudo apt-get install smbclient cifs-utils
sudo mount //fmpserver/home-red /mnt/home-red -o username=administrator

Y nos pedirá la contraseña del usuario utilizado. En este caso, estaremos utilizando el usuario administrador del dominio, y tendremos acceso a todas las carpetas de todos los usuarios desde el directorio “/mnt/home-red”.

Esto, como podemos ver fácilmente, es matar moscas a cañonazos, básicamente. Tenemos que ser más finos.

Por ejemplo, podemos “afinar” un poco más la puntería y escoger mejor tanto el punto de montaje como el usuario conectado.

Por ejemplo, si estamos con el usuario “prueba1”, podemos crear una carpeta en su perfil, y usarla para montar sólo su propia carpeta remota:

mkdir /home/prueba1/remoto
chmod 777 /home/prueba1/remoto
sudo mount //fmpserver/home-red/prueba1 /home/prueba1/remoto -o username=prueba1

Con esto, tendremos acceso restringido a nuestro usuario y nuestros datos. Podemos integrar la orden de montaje en algún script de inicio de sesión, y tendremos de forma sencilla nuestra carpeta remota a nuestra disposición.

Problemas de esta solución:

  • Para instalar el software “smb-client” y “cifs-utils” hace falta ser administrador; igual que para usar mount. Por tanto, un usuario “normal” nunca podría hacerlo, tendríamos que estar jugando con sudo y demás
  • No podemos hacerlo de forma automática para todos los usuarios del dominio. Es decir, esto funcionará para “prueba1”, pero no para “prueba2”.
  • No es ni mucho menos automático. No es un proceso “transparente” para un usuario cualquiera.

Una posible solución pasaría por montar automáticamente en fstab la carpeta remota “home-red” como administrador, y cambiar el “home” por defecto de los usuarios del dominio. El problema de esta solución es que los permisos SAMBA son siempre los del usuario administrador usado para el montaje. Veamos cómo se haría:

  • Iniciamos sesión con un usuario administrador, sea local o del dominio.
  • Instalamos el software “smb-client” y “cifs-utils”
  • Añadimos la línea correspondiente al fichero /etc/fstab: (gracias a https://blogdeanillas.wordpress.com/2011/10/24/montar-unidades-con-fstab-en-un-active-directory/ por la ayuda)
    //fmpserver/home-red /home/fedecasa cifs sec=ntlmv2,iocharset=utf8,auto,nocase,noperm,file_mode=0777,dir_mode=0777,credentials=/root/.smbcredentials 0 0
    • //fmpserver/home-red es la ruta de la carpeta remota
    • /home/fedecasa es donde se va a montar dicha carpeta
    • cifs Common Internet File System. CIFS es el nombre que adoptó Microsoft en 1998 para el protocolo SMB.
    • iocharset=utf8 para que no nos aparezcan caracteres extraños cuando montemos la unidad.
    • auto para que se monten las unidades cuando iniciamos el sistema
    • file_mode y dir_mode permisos de creación de archivos y de directorio, en este caso le otorganos permisos de escritura, lectura y ejecución para todos los grupos, para que samba ejecute sus permisos sin problemas. Usamos la notación octal.
    • credentials=/root/.smbcredentials archivo donde guardaremos el usuario a usar para montar la unidad. También podemos usar user=usuario y pass=clave del usuario pero de esta manera la clave es visible por cualquier persona que quiera ver el fstab.
  • Creamos el fichero de credenciales para ocultar usuario y contraseña, y así evitar problemas de seguridad:
#nano /root/.smbcredentials
#Contenido: usuario y clave

domain=fedecasa
username=administrator
password=******

Cambiamos los permisos del fichero a 600 (sólo podrá acceder el root)

  • Y, para terminar, modificamos la carpeta “home” por defecto de nuestros usuarios del dominio para que usen la nueva: /home/fedecasa/username
#/opt/pbis/bin/config HomeDirTemplate %H/%D/%U

De todas maneras, esta última parte no funciona. La dejo aquí por si alguien en los comentarios tiene una solución mejor…

El resultado obtenido con Samba es el siguiente: accedemos a la carpeta de usuario, pero no podemos utilizarla como “home” en Linux, por un problema con los permisos (acl en Linux y Windows no son iguales). Para arreglar esto, hace falta una de dos: o configurar las acl de linux adecuadamente, añadiendo los permisos adecuados a cada carpeta, o usando carpetas NFS “aparte”. Vamos a probar con NFS

Segunda Opción: NFS

Pasamos aquí a hablar del otro sistema de compartición de carpetas en red: NFS. Concretando: en realidad, Windows y Linux no comparten ficheros de configuración. Sólo compartiremos carpetas puntuales, pero podemos fácilmente acceder a ellas. Podemos usar un sistema “dual”, almacenando las carpetas de Linux aparte de las de Windows.

Vamos a probarlo: primero instalamos nfs en el servidor y lo configuramos adecuadamente, como se indica en somebooks:

sudo apt-get install nfs-kernel-server nfs-common rpcbind

La carpeta original Samba no va a funcionar correctamente vía nfs, así que necesitaremos un sistema “aparte”.

Creamos, por tanto, una carpeta aparte para los usuarios “linux” en nuestro servidor:

mkdir /home-linux
chmod 777 /home-linux

Luego, en el fichero /etc/exports, añadimos la línea correspondiente:

/home-linux *(rw,sync,no_root_squash,no_subtree_check)

Y reiniciamos el servidor, para evitar problemas.

CLIENTE:

sudo apt-get install nfs-common rpcbind

A continuación, probamos a montar la carpeta, a ver si funciona correctamente. La montamos en “/mnt”, que para eso está.

sudo mount 10.0.2.111:/home-linux /mnt

Si va, procedemos a crear el punto de montaje automático. Creamos primero la carpeta (en nuestro caso, los usuarios iniciarán sesión en /home/FEDECASA, así que esa será la carpeta)

mkdir /home/FEDECASA
chmod 777 /home/FEDECASA

Miramos en el fichero /etc/mtab para tener bien claras las opciones, y obtendremos algo así:

10.0.2.111:/home-linux /mnt nfs4 rw,relatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,local_lock=none,addr=10.0.2.111 0 0

… o parecido. Cambiamos el punto de montaje (en negrita) por el correcto, a saber,  /home/FEDECASA en mi caso, lo pegamos en fstab y reiniciamos a ver qué tal.

Conclusión

Para aunar “lo mejor” de ambos mundos, propongo lo siguiente:

  • Tal y como hemos visto en el punto para NFS, utilizaremos una carpeta distinta para los “homes” de los usuarios linux. Esa carpeta funcionará sólo con NFS.
  • Para acceder a los datos de Windows, lo más fácil es montar automáticamente la carpeta donde tenga dichos datos, con privilegios de administrador del dominio (administrator). Si nos preocupa la seguridad de la red, ésta no es ni mucho menos la mejor opción, pero al menos tendremos acceso a nuestros datos.

Al final ha quedado un poco embrollo, pero hay que entender que es muy difícil aunar todo en una misma carpeta. Voy a seguir intentándolo con otras opciones, pero eso lo dejamos para otra entrada del blog. Espero que sirva de algo.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: