Está en la página 1de 74

ADMINISTRACIÓN DE SISTEMAS OPERATIVOS

ASO_UT6.2

Configuración y utilización de redes


heterogéneas.
ÍNDICE

2 Configuración y utilización de redes heterogéneas ..........................................................................................3


2.1 El servidor Samba en un grupo de trabajo ...............................................................................................4
2.1.1 Usuarios ......................................................................................................................................................... 5
2.1.2 Recursos compartidos ................................................................................................................................... 7
2.1.3 permisos ........................................................................................................................................................ 9
2.1.4 Impresoras ................................................................................................................................................... 12
2.1.5 Master browser ........................................................................................................................................... 19
2.1.6 Acceso a los recursos mediante clientes GNU/Linux................................................................................... 21
2.1.7 Acceso a los recursos mediante clientes Microsoft Windows .................................................................... 24
2.2 El servidor Samba como controlador primario de dominio .................................................................... 26
2.2.1 El nombre del host ....................................................................................................................................... 27
2.2.2 La interfaz de red ......................................................................................................................................... 28
2.2.3 Instalación del software............................................................................................................................... 29
2.2.4 configurar Samba ......................................................................................................................................... 30
2.2.5 Creación y gestión de usuarios .................................................................................................................... 34
2.2.6 Vincular una máquina con Windows 10 al dominio. ................................................................................... 35
2.2.7 Uso de Windows 10 para la administración del dominio de Active Directory. ........................................... 39

2
2 Configuración y utilización de redes heterogéneas

En el mundo empresarial, Samba es un buen aliado de los administradores de sistemas cuando se dispone de una red
con varios sistemas operativos. Como veréis a continuación, se puede integrar de una manera sencilla en redes
heterogéneas, pero debemos ser conscientes de sus limitaciones.

En este contexto te puedes puede encontrar situaciones muy diferentes y Samba dispone de un nivel de configuración
muy elevado que permite obtener una buena adaptación a muchas de estas situaciones. Hacer una recopilación de
todas las posibilidades de configuración resultaría demasiado extenso, pero trataremos de analizar las dos situaciones
más comunes que nos podemos encontrar:

1. Samba como servidor independiente en un grupo de trabajo

2. Samba como servidor de dominio

A continuación verá cómo configurar y administrar Samba en cada una de estas situaciones.

3
2.1 El servidor Samba en un grupo de trabajo

El servicio Samba permite configurar un servidor basado en Linux para integrarlo dentro de un grupo de trabajo
Windows, de manera que pueda compartir recursos como un equipo más del conjunto lógico de la red. Uno de los
requisitos imprescindibles es que este servidor se comporte exactamente igual que un sistema Windows. Por ello, hay
que ajustar los parámetros de configuración de Samba tal como se detallan a continuación:

1. Nivel de seguridad: el nivel de seguridad determinará la forma en que los usuarios se identifican. El nivel
adecuado a una red igualitaria donde intervienen ordenadores Windows es el nivel user. Las opciones
restantes no son adecuadas o bien son caducas.

2. Backend: el tipo de backend que usamos determina de qué manera se almacenan los usuarios. En este caso,
la opción más recomendable es usar un archivo local, de tipo smbpasswd o tdbsam.

3. Grupo de trabajo: el nombre del grupo de trabajo (workgroup).

4. Nombre del equipo: también conocido como el nombre NetBIOS . Determina qué nombre tendrá este equipo
cuando se explore la red.

5. Master browser (opcional): el master browser es el equipo que contiene la lista de todos los equipos
conectados a la red.

Para establecer esta configuración es necesario modificar el archivo /etc/samba/smb.conf. Como podrán observar,
en este archivo encontrará cientos de parámetros que pueden dar lugar a miles de configuraciones diferentes.

Aunque el archivo de configuración smb.conf es muy extenso, para empezar hay que realizar muy pocos cambios
respecto a la imagen original que se incorpora con el paquete.

El archivo se divide en secciones identificadas por un nombre entre llaves, [ ]. Hay tres secciones
especiales: [global], [homes]y [printers]. La sección principal se identifica con [global] y nos permite configurar los
parámetros generales del servicio. La sección [homes] nos permite compartir los directorios de inicio (home) de cada
usuario para que cada usuario pueda acceder a su directorio a través de la red. La sección [printers] permite compartir
impresoras.

Dentro del apartado [global] se debe especificar el nombre del grupo de trabajo , el nombre de la máquina, el nivel de
seguridad y el tipo de backend deseado.

[ Global ]

workgroup = IEDIB

NetBIOS name = Debian-Samba

security = user

passdb backend = tdbsam

encrypt passwords = yes

Como veis, la configuración es simple: el nombre con el que se anuncia esta máquina es Debian-Samba, y se incluirá
en el grupo de trabajo llamado IEDIB. El parámetro security determina el nivel de seguridad y el backend almacenará
en una base de datos de tipo TDB.

4
Con esta configuración ya tendríamos suficiente para incorporar el servidor al grupo de trabajo. Para asegurarnos de
que las modificaciones del archivo smb.conf se llevan a cabo, es conveniente reiniciar el servicio.

# Service smbd restart


# service nmbd restart

2.1.1 Usuarios

Samba incluye un conjunto de herramientas para manipular las cuentas de usuario almacenados en el backend . Estas
herramientas se han diseñado de forma que funcionen igual independientemente del tipo de backend que utiliza:
archivo TDB, archivo smbpasswd o directorio LDAP. Las herramientas que se utilizan para manipular usuarios Samba
son, principalmente, las órdenes smbpasswd y pdbedit.

Para añadir usuarios a Samba usaremos la orden smbpasswd, tal como muestra el siguiente ejemplo:

# Smbpasswd -a usuario

New SMB password:

Retype new SMB password:

La pareja usuario/contraseña que introducimos aquí es aquella con la que se accederá desde los clientes
Windows. Puede utilizar smbpasswd tantas veces como usuarios desee crear.

La orden smbpasswd se comporta de dos maneras diferenciadas:

1. Si la ejecuta el usuario root , nos permite administrar los usuarios Samba: crear, borrar, listar,
habilitar/deshabilitar y cambiar la contraseña.

2. Si la ejecuta cualquier otro usuario, le permite cambiar la contraseña Samba en servidores remotos.

Opción Descripción

-a nom_usuari Añadir usuario.

-d nom_usuari Deshabilitar la cuenta de usuario.

-e nom_usuari Habilita la cuenta de usuario.

-n nom_usuari Aplica una contraseña vacía al usuario.

-x nom_usuari Borrar la cuenta de usuario.

-h Muestra la ayuda.

5
Aunque la herramienta pdbedit también se puede utilizar para realizar las mismas acciones, normalmente se utiliza
para tareas administrativas de bajo nivel, tales como cambiar las propiedades de un usuario o importar y exportar
usuarios del backend .
IMPORTANTE

Por otra parte, Samba necesita que todos los usuarios que acceden a los recursos se puedan vincular
a un usuario del sistema Linux (UID). Por este motivo, es necesario que antes de añadir un usuario
Samba lo damos de alta como usuario del sistema.

# Useradd usuario

# Passwd usuario

Introduzca la nueva contraseña de UNIX:

Vuelva a escribir la nueva contraseña de UNIX:

passwd: contraseña actualizada correctamente

Este requisito también se aplica a los usuarios invitados y por tanto, deben vincularse a una cuenta específica de
GNU/Linux. En general, cuando Samba recibe la petición de un usuario que no se ha podido autenticar correctamente,
como en el caso de no encontrar el usuario al backend , la petición se rechaza por defecto y no se otorga el acceso. A
veces, sin embargo, nos interesará que un usuario sin registrar pueda acceder a los recursos compartidos, como, por
ejemplo, en el caso de una empresa con muchos trabajadores puede resultar útil que todo el mundo tenga acceso a
un directorio público sin tener que dar de alta todos los trabajadores. En estos casos es necesario permitir el acceso a
usuarios no registrados y habilitar el acceso de invitado .

Si se desea que los usuarios puedan entrar sin estar registrados, lo primero que necesita hacer es cambiar el
comportamiento que Samba tiene por defecto cuando encuentra un usuario que no es el backend . Esto se realiza
indicando el parámetro y valor map to guest = bad user dentro de la sección [global]. De esta manera le indica que si
no se encuentra el usuario en el backend se utilice la cuenta de invitado.

Por último, indicar que usuario del sistema GNU/Linux se utilizará para vincular los usuarios invitados. Con el
parámetro guest account determinará qué cuenta de usuario GNU/Linux se utiliza como invitado.

[ Global ]

workgroup = IEDIB

NetBIOS name = Debian-Samba

security = user

passdb backend = tdbsam

encrypt passwords = yes

map to guest = bad user

guest account = invitado

6
Evidentemente, la cuenta de invitado debe estar creada previamente a Linux y vinculada a Samba.

# Useradd invitado
# smbpasswd -a invitado

No resulta imprescindible la creación de un usuario 'invitado' para poder acceder como usuario anónimo a un recurso
compartido, pero de esta manera conseguimos que el registro de las acciones realizadas por el usuario se asocie a la
cuenta que hayamos definido y tener así un mayor control sobre los accesos.

2.1.2 Recursos compartidos

Los recursos compartidos se definen añadiendo secciones en el fichero de configuración de Samba. Recuerde que el
comienzo de cada sección se indica con un nombre entre llaves, [ ] y a continuación se añade la información relativa a
un recurso compartido. Hay secciones especiales con nombres reservados que no podemos utilizar porque tienen un
significado especial: [global], [printers] y [home].

Entre llaves se indica el nombre del recurso compartido, que es aquel que verán los clientes cuando quieran
acceder. Posteriormente, a la variable path, indicamos la ruta local en el directorio compartido.

[ Recurs_compartit ]

path = /directorio

Es indispensable que el directorio exista previamente dentro del sistema de archivos original.

# Mkdir / directorio

Esta configuración es la mínima necesaria para compartir un recurso, pero hay que saber que por defecto el recurso
se compartirá con permisos de sólo lectura .

Sin embargo, cuando compartir recursos con Samba en una red donde se integran sistemas operativos Windows y
Linux, hay una serie de diferencias que tenemos que tener en consideración . Principalmente, se trata de diferencias
directamente relacionadas con los sistemas de ficheros.

Como sabéis, Windows y Linux disponen de sus propios sistemas de archivos. En el caso de Windows son FAT32 y NTFS,
mientras que para Linux los más comunes son ext2, ext3, ext4 y ReiserFS. Cada sistema de archivos tiene sus
características y limitaciones. Entre estas limitaciones encontramos:

1. La distinción entre mayúsculas y minúsculas

2. Los caracteres prohibidos en los nombres

3. Los accesos directos a Windows o soft-links y hard-links a Linux

7
IMPORTANTE Samba se encarga de solucionar las diferencias entre sistemas de ficheros Windows y Linux

Por ejemplo, los nombres de los ficheros en Windows no distinguen entre mayúsculas y minúsculas, por lo que los
directorios llamados escritorio y ESCRITORIO son lo mismo. Por eso un directorio no puede contener un
archivo document.txt y a la vez un DOCUMENT.txt . En cambio, si utilizamos los sistemas de ficheros Linux sí es
posible. Como sabéis, en GNU/Linux se suele distinguir mayúsculas y minúsculas.

El sistema operativo Windows no permite que los nombres de los archivos o directorios contengan los caracteres \
/:*?”< >|, pero en cambio, Linux sí podemos crear archivos con los caracteres :*?”<>|. Entonces, ¿qué ocurre cuando
un servidor Samba comparte algún archivo con uno de estos caracteres prohibidos para Windows? En estos casos, el
servidor realiza un proceso de transformación llamado mangle y muestra al cliente un nombre modificado, no el
original. Este nombre se representa en formato 8.3.

Formato 8.3
AMPLIACIÓN

Los nombres de los ficheros con formato 8.3 tienen como máximo 8 caracteres que indican el
nombre, seguidos de un punto y tres caracteres más que indican la extensión del archivo. Este
formato se utilizaba en MS-DOS y en las primeras versiones de Windows.

Tal como puede observarse en la figura 2.1 , el proceso de transformación permite que los clientes Windows puedan
acceder a los archivos con caracteres prohibidos, pero con un nombre totalmente distinto del inicial.

8
2.1.3 permisos

La autorización de una acción sobre un recurso compartido está determinada por los permisos asignados al
servidor. Así, si un usuario quiere acceder a un recurso compartido y crear archivos deberá tener permisos de escritura
dentro de ese directorio compartido.

Los recursos compartidos por Samba están afectados por dos tipos de permisos totalmente independientes:

1. Los permisos del sistema de archivos

2. Los permisos Samba, también llamados permisos de red

Cuando un cliente desea realizar una acción determinada (leer o escribir), debe tener los permisos adecuados tanto al
sistema de archivos como el recurso compartido. No sirve de nada que un usuario tenga todos los permisos a Samba
si después no tiene ningún sistema de archivos. Por lo tanto, siempre se aplica el permiso más restrictivo. Tener esto
siempre presente le ahorrará muchos dolores de cabeza.

Los permisos del sistema de archivos o permisos locales se representan mediante 9 bits (rwxrwxrwx) con los que los
sistemas Unix implementan el control de acceso a los archivos del sistema y que podemos modificar con el
orden chmod .

El significado de los permisos varía dependiendo de si se trata de un archivo o de un directorio, tal como muestra
la tabla 2.2 .

Tabla 2.2: Permisos tradicionales Unix

PERMISO ARCHIVO DIRECTORIO

r leer archivos Ver el contenido del directorio

w Grabar en un archivo Crear y borrar archivos dentro del directorio

x Ejecutar como programa Entrar en el directorio

- sin permiso sin permiso

Conviene recordar que en directorios, además de los tres permisos mostrados, también podemos asignar el permiso
del sticky bit . El sticky bit permite que sólo los propietarios de los archivos puedan renombrar o borrar sus archivos
aunque el resto de usuarios tenga permisos de escritura en ese directorio. Las opciones + t y t del
orden chmod permiten añadir o quitar el sticky bit .

# Chmod + t directorio

9
Los permisos Samba especifican en el fichero de configuración, dentro de cada una de las secciones donde haya un
recurso compartido. Las variables que controlan los permisos se indican en la tabla 2.3 . Por defecto, un recurso
compartido tiene permisos de sólo lectura para todos los usuarios del backend .

Tabla 2.3: Variables que controlan los permisos de los recursos compartidos

VARIABLE DEFINICIÓN

admin users Lista de usuarios con control total sobre el recurso compartido.

read list Lista de usuarios que tienen acceso de sólo lectura.

write list Lista de usuarios que tienen acceso de lectura y escritura.

guest ok Permitir el acceso como invitado al recurso.

invalid users Lista de usuarios a los que no se les permite acceder.

valid users Lista de usuarios que sí pueden entrar. Si la variable no se especifica, todos los usuarios con
cuenta al backend pueden acceder.

read only Indica que el recurso sólo es de lectura.

Por ejemplo, la variable read only = no permite que los usuarios puedan leer y escribir (siempre que también lo hagan
los permisos del sistema de archivos).

[ Recurs_compartit ]

path = / directorio

read only = no

También podemos indicar la lista de usuarios a los que restringimos el acceso con la variable invalid users .

[ Recurs_compartit ]

path = / directorio

read only = no

invalid users = alumne1, alumne2, @profesores

10
Listas de usuarios y grupos
AMPLIACIÓN
A los permisos de Samba puede indicar una lista de usuarios con los nombres separados por
comas. Los grupos se muestran con el símbolo @ delante.

Cuando deseamos que los usuarios invitados tengan acceso a un recurso en concreto, hay que asignar la variable guest
ok a yes . De lo contrario siempre se pedirá la autenticación del usuario.

[ Public ]

path = / directori_public

guest ok = yes

11
2.1.4 Impresoras

Cuando pensamos en Samba normalmente nos viene a la mente la función de compartir directorios, y de hecho, este
es el uso principal que se le da. Pero Samba también se puede usar como servidor central de impresoras en una red
con clientes Windows. En este apartado veremos cómo configurar el servicio para compartir impresoras.

Hay que decir, sin embargo, que Samba no es un sistema de impresión per se , sino que actúa como intermediario
entre las peticiones de los clientes y el sistema de impresión del sistema operativo ( figura 2.2 ). Esto significa que
Samba no se comunica directamente con las impresoras, simplemente ejecuta las órdenes del sistema necesarias para
imprimir trabajos, ponerlos en pausa, cancelarlos, ver los trabajos en cola, etcétera. En definitiva, Samba se comporta
de la misma manera que lo haría un usuario del equipo que quiere imprimir.
IMPORTANTE

Samba no es un sistema de impresión, sino que actúa como intermediario entre los clientes y el
sistema de impresión del sistema operativo.

Figura 2.2: Esquema de impresión del servicio Samba

12
Samba permite la comunicación con varios tipos de sistemas de impresión Unix, entre los que destacamos HPUX, BSD,
PLP, LPRng, y el más utilizado, CUPS .

CUPS
AMPLIACIÓN

CUPS (Common Unix Printing System) es el sistema de impresión por defecto se utiliza en muchas
distribuciones GNU/Linux actuales, entre ellas Debian y Ubuntu.

Visto esto, puede suponer que el paso previo a compartir una impresora con Samba es tenerla correctamente
configurada en el sistema de impresión . En su caso supondremos que utilice CUPS, y éste se puede administrar de
varias maneras:

1. Desde las herramientas gráficas que proporciona el escritorio de su distribución de GNU/Linux.

2. Desde el sitio web de administración de CUPS: http: // localhost: 631 / .

3. Directamente desde el archivo de configuración en /etc/cups/cups.conf.

Es conveniente asegurarnos de que el servicio CUPS está funcionando correctamente.

# Ps -A | grep cupsd

1,097 ? 12:00:01 cupsd

Para añadir una impresora de manera sencilla puede visitar la web http: // localhost: 631 / , clicar en la pestaña
de Administración ya continuación el botón de Añadir impresora . CUPS necesita introducir el nombre y la contraseña
del administrador ( root ) de la máquina.

Posteriormente, y como muestra la figura 2.3 , hay que indicarle donde está conectada la impresora y qué protocolo
utiliza, lo que se conoce como backend . La mayoría de impresoras para entornos empresariales actuales permiten
utilizar los protocolos IPP, LPD / LPR o JetDirect (AppSocket).

Pulsando el botón Siguiente le pedirá la marca y el modelo, el nombre y el resto de opciones. Si no está en la lista
también puede añadir un controlador específico con extensión PPD.

Controladores (drivers) CUPS


AMPLIACIÓN

Los controladores de impresoras para CUPS son archivos con extensión .ppd. Actualmente, la
mayoría de fabricantes dispone de controladores para Linux

13
Figura 2.3: Aplicación web de administración de CUPS

Una vez que haya añadido la impresora al sistema, debe indicarle a Samba qué servicio de impresión utilizará, en
nuestro caso CUPS.

[ Global ]

workgroup = IEDIB

NetBIOS name = Servidor-debian

security = user

printing = cups

printcap name = cups

14
Finalmente, es necesario que añada la definición de la impresora compartida de manera similar a como lo haría con
un directorio, con las siguientes diferencias:

1. El nombre del recurso compartido debe coincidir con el nombre de la impresora en el servicio de impresión de
Linux. Así, si ha puesto el nombre HP_1102W a la impresora en CUPS, será necesario que el recurso a Samba
llame igual.

2. Hay que añadir la variable print ok = yes al recurso compartido para indicar que este recurso es una impresora.

3. La variable path debe indicar el directorio donde se almacenan los trabajos que serán impresos. Es obligado
que el directorio que tenga permisos de escritura para todo aquel que pueda imprimir, de otro modo los
clientes tendrán un error al imprimir. Podemos usar el directorio /var/spool/samba, que ya está preparado
con el paquete Samba.

4. Típicamente, los controladores de impresión de Windows envían los datos a la impresora de forma que no es
necesario ningún filtro de procesado, al contrario de los sistemas Linux que envían los datos en PostScript. Si
no es necesario ningún procesado añada el parámetro cups options = "raw" .

[MFC-L2700DW ]

comment = "Brother MFC-L2700DW series"

print ok = yes

path = / var / spool / samba

cups options = "raw"

Esta es la configuración mínima imprescindible para tener accesible la impresora desde los clientes con Windows, tal
como puede observarse en la figura 2.4 .

Figura 2.4: Impresora accesible desde clientes Windows

15
Como no hemos proporcionado ningún controlador deberá añadir manualmente ( figuras 2.5 y 2.6 ).

Figura 2.5: Adición manual del controlador

Figura 2.6: Adición manual del controlador

16
Como veis, compartir una impresora es una tarea muy sencilla, pero se puede mejorar para facilitar las
tareas la administración. En primer lugar, podemos hacer que Samba detecte automáticamente las impresoras
conectadas al sistema de impresión y las comparta. De esta manera no es necesario añadir una a una. Para ello basta
con incluir el recurso compartido especial [printers]con los mismos parámetros que una impresora.

[ Printers ]

path = / var / spool / samba

print ok = yes

Esta pequeña modificación puede liberar la carga del administrador cuando haya muchas impresoras conectadas a la
máquina, como en el caso de un servidor de impresión de una oficina. En segundo lugar, podemos facilitar la tarea de
instalación de las impresoras a los clientes si permitimos la descarga e instalación automática de controladores , es lo
que se conoce como Apuntar e imprimir .
AMPLIACIÓN

Apuntar e imprimir ( Point and print) Es una característica de los dominios Windows que permite a
un usuario utilizar las impresoras de red haciendo clic sobre sus iconos.

Para habilitar esta característica, es necesario que el directorio /var/lib/samba/printers haya los controladores de
impresión que se pueden descargar los usuarios, separados según la arquitectura de la máquina cliente.

# Ls -l / var / lib / samba / printers /

total 32

drwxr-xr-x 2 root root 4096 ene 8 16 : 56 COLOR

drwxr-xr-x 2 root root 4096 ene 8 16 : 56 IA64

drwxr-xr-x 2 root root 4096 ene 8 16 : 56 W32ALPHA

drwxr-xr-x 2 root root 4096 ene 8 16 : 56 W32MIPS

drwxr-xr-x 2 root root 4096 ene 8 16 : 56 W32PPC

drwxr-xr-x 2 root root 4096 ene 8 16 : 56 W32X86

drwxr-xr-x 2 root root 4096 ene 8 16 : 56 WIN40

drwxr-xr-x 2 root root 4096 ene 8 16 : 56 x64

Así, por ejemplo, habrá que añadir los controladores para las máquinas con Windows de 32 bits dentro del
directorio W32X86, los controladores para las versiones del sistema Windows de 64 bits se deberán almacenar
dentro x64, y así sucesivamente.

Este directorio es necesario compartirlo con el nombre de [print$], que es el recurso donde las máquinas en un grupo
de trabajo Windows buscan los controladores de las impresoras. Salvo los administradores, es importante que todo el
mundo tenga acceso de sólo lectura a este recurso.

17
[ Print $ ]

path = / var / lib / samba / printers

browseable = yes

read only = yes

guest ok = no

write list = root

Debe haber al menos un usuario que pueda cargar los controladores en estos directorios. Como veis, en el ejemplo
asignamos permisos de escritura al usuario root , pero también podríamos asignarlos a otro usuario o grupo si fuera
necesario, siempre y cuando asignamos los permisos de escritura en el directorio /var/lib/samba/printers.

Finalmente, hay que dar el derecho SePrintOperatorPrivilege al usuario que pueda añadir controladores.

# net -U root%contrasenya rpc rights grant root \ SePrintOperatorPrivilege

El usuario root ya puede añadir al servidor todos los controladores que desee. Para hacerlo hay que conectarse al
servidor desde una máquina con Windows ( figura 2.7 ).

Figura 2.7: Conexión desde una máquina Windows

18
2.1.5 Master browser

En un entorno empresarial, los servidores suelen ser los equipos más potentes de la red y los que están disponibles la
mayor parte del tiempo. En este escenario es probable que Samba sea uno de los servicios instalados. Entonces, ¿por
qué no aprovechar la potencia de estas máquinas que Samba actúe como master browser ?

Si Samba instala en una máquina con alta disponibilidad y se configura como master browser aprovecharemos la
potencia de la máquina donde está instalado y podremos evitar parte de los problemas de sincronización debidos a la
desconexión repentina de las máquinas del entorno de trabajo.

En caso contrario puede correr el riesgo de que una máquina menos potente, como la de un trabajador, asuma ese
rol. Si esta máquina no es suficientemente potente o está saturada de trabajo, el resto del grupo de trabajo tendrá
problemas de lentitud cuando quiera acceder a la red.

Cualquiera de las máquinas de un grupo de trabajo es susceptible de tomar el rol de master browser . Si queremos que
Samba tenga este rol debemos forzar para que gane las elecciones .

El algoritmo de elección está implementado en todos los sistemas Windows, de manera que cuando se lleva a cabo,
todos ellos estarán de acuerdo en quien será el master y el backup browser . También hay que saber que en cualquier
momento se puede forzar el proceso de elección.

El proceso de elección se basa en algunos aspectos de los ordenadores, como el tiempo que llevan encendidas, el
sistema operativo o la versión del protocolo que utilizan. El sistema operativo que tenga un valor más alto en la escala
gana la elección.

Problemas de seguridad en el proceso de elección del master browser


IMPORTANTE

El mecanismo utilizado en el proceso de elección permite que cualquier máquina de la red pueda
tomar el rol de master browser . Esto ocasiona un problema de seguridad, ya que de este modo,
una máquina de un posible atacante podría forzar la elección, ganarla y hacer modificaciones en la
lista de equipos y suplantar así la identidad de una de las máquinas . A partir de aquí, el atacante
podría obtener los nombres de usuario y contraseñas que envían los clientes.

Por defecto, un servidor Samba está configurado para poder actuar como master browser y se asigna a sí mismo un
valor por encima del que tienen los clientes de Windows. Por lo tanto, en una red igualitaria (sin controladores de
dominios) un ordenador Samba siempre ganará la elección ante equipos Windows . Si, en cambio, hay un controlador
de dominio, la perderá, ya que estos tienen asignado un valor superior.

En cualquier caso, siempre puede establecer el valor desde el archivo de configuración con la variable os level, que
como máximo puede tomar el valor 255.

[ Global ]

...

os level = 100

...

19
Si además se desea forzar el proceso de elección cada vez que se inicie el servidor Samba, hay que poner la
variable preferred master = yes .

[ Global ]

...

os level = 100

preferred master = Yes

...

La tabla 2.4 muestra un resumen de las variables implicadas en la elección del master browser .

Tabla 2.4: Variables implicadas en el proceso de elección del master browser.

VARIABLE VALOR DESCRIPCIÓN

Determina si Samba puede actuar como master browser . Por defecto, lo


local master yes / no
puede hacer.

Valor que se tendrá en cuenta en el proceso de elección. Cuanto más


os level numérico 0-255
elevado, más probabilidades tiene de ganarlo.

preferred Si se establece a yes , se fuerzan las elecciones cuando Samba se incorpora


yes / no
master a la red.

20
2.1.6 Acceso a los recursos mediante clientes GNU/Linux

En Linux un cliente dispone de varias formas de acceder a los recursos compartidos en un grupo de trabajo. En
cualquier distribución puede descargarse el paquete smbclient y acceder vía órdenes.

# Apt-get install smbclient

El paquete smbclient contiene varias herramientas:

# Dpkg -L smbclient | grep bin

/Usr/bin

/Usr/bin/smbspool

/Usr/bin/rpcclient

/Usr/bin/smbtree

/Usr/bin/smbcacls

/Usr/bin/findsmb

/Usr/bin/smbget

/Usr/bin/smbcquotas

/Usr/bin/smbclient

/Usr/bin/smbtar

Sólo verá algunas de las opciones más significativas, ya que explicar la función de todas ellas ocuparía mucho tiempo,
y en caso necesario todas disponen de páginas al manual que puede consultar escribiendo man <orden> en un
terminal.

21
La orden smbtree muestra todos los equipos del grupo de trabajo en modo texto, de manera similar a la Entorno de
red de Windows. Dibuja un árbol con todos los dominios conocidos, los servidores que comparten recursos y sus
nombres.

# Smbtree -N

G-IEDIB

\\ UBUVM ubuvm server (Samba, Ubuntu)


\\ UBUVM \ Ubu-compartida Directorio compartido en Ubuntu
\\ UBUVM \ IPC $ IPC Service (ubuvm server (Samba, Ubuntu))
\\ UBUVM \ print $ Printer Drivers
\\ PC- WIN10 PC-Win10-B
\\ PC-WIN10 \ Users
\\ PC-WIN10 \ IPC $ IPC remota
\\ PC-WIN10 \ COMPA_1 Enlace a Compartida_1
\\ PC-WIN10 \ Compartida_2
\\ PC-WIN10 \ Compartida_1
\\ PC -WIN10 \ C $ Recurso predeterminado
\\ PC-WIN10 \ ADMIN $ Admin remota

Con la opción -N puede hacer la consulta sin necesidad de introducir ninguna contraseña.

Para listar los recursos compartidos por una máquina se puede utilizar la orden smbclient -L seguida del nombre del
ordenador.

# Smbclient -L PC-WIN10 -N

Sharename Type Comment


--------- ---- -------
ADMIN $ Disk Admin remota
C $ Disk Recurso predeterminado
Compartida_1 Disk
Compartida_2 Disk
COMPA_1 Disk Enlace a Compartida_1
IPC $ IPC IPC remota
Users Disk

22
En el ejemplo puede observar que la máquina comparte siete recursos en total, tres de los cuales son
ocultos. Utilizando la misma orden, puede acceder al recurso indicando la dirección UNC, y con la opción -U especificar
qué usuario utiliza para realizar la conexión.

# Smbclient // pc-win10 / Compartida_1 -U usuario


Enter G-IEDIB \ usuario s password:
Try "help" to get a list of posible commands.
smb: \> ls
. D 0 Fri Feb 21 10:30:47 2020
.. D 0 Fri Feb 21 10:30:47 2020
Acta_23.rtf A 7 Fri Feb 21 10:30:40 2020

12.958.463 blocks of size 4096. 6811354 blocks available


smb: \ > exit

Un entorno interactivo le permite realizar las acciones deseadas en el recurso compartido. Algunas de las órdenes
utilizadas son similares a las de Unix ( cd , ls , pwd ...), mientras que para subir o descargarnos archivos puede
utilizar put y get , respectivamente. En caso de duda, escribiendo help obtendrá la lista de opciones.

1. smb: \ > help

También puede acceder con la interfaz gráfica que proporciona el escritorio. Se puede acceder desde Otras
ubicaciones o Lugares > Red (depende de la distribución que emplees) y se abrirá una ventana del estilo de la mostrada
en la figura 2.8 .

Figura 2.8: Acceso a la red desde la interfaz gráfica de Ubuntu

De manera sencilla se puede navegar por los diferentes servidores de red de forma muy similar a Windows.

23
2.1.7 Acceso a los recursos mediante clientes Microsoft Windows

El acceso a los recursos compartidos por Samba mediante un cliente Windows se puede realizar utilizando las
utilidades gráficas que proporciona el mismo explorador del sistema operativo de forma totalmente intuitiva.

Para acceder al servidor Samba primero debe asignar un nombre NetBIOS y unir el equipo Windows al mismo grupo
de trabajo.

En la figura 2.9 se observa la ventana de configuración de un ordenador unido al grupo de trabajo G-IEDIB con el
nombre PC-Win10-A. Una vez unido al grupo de trabajo se debe reiniciar la máquina.

Figura 2.9: Ventana de configuración del grupo de trabajo

Se accede a los recursos compartidos a través del explorador de la red o bien escribiendo la dirección UNC del recurso
compartido directamente en la barra superior (por ejemplo, \\Servidor\recurs), utilizando el nombre NetBIOS del
servidor o bien la dirección IP seguida del nombre del recurso, tal y como muestra la figura 2.10 .

Son muchos los elementos que participan del funcionamiento del explorador de red 'y muy a
IMPORTANTE

menudo, algún parámetro mal configurado puede hacer que su funcionamiento no sea el
esperado y no veamos representado un recurso compartido donde tocaría ser. La vía más fiable,
y por lo tanto la recomendada, es el uso de la dirección UNC del recurso compartido.

24
Definición de UNC:

(Universal Naming Convention) Un estándar para identificar servidores, impresoras y otros recursos
en una red, que se originó en la comunidad de Unix. Una ruta UNC utiliza barras dobles o barras
diagonales inversas para preceder al nombre del equipo. La ruta de acceso (disco y directorios)
AMPLIACIÓN

dentro del equipo se separa con una sola barra o barra diagonal inversa, como en los ejemplos
siguientes.

Ejemplos:
// nombre_servidor / ruta - Unix / Linux
\\ nomi_servidor \ ruta - Windows

Figura 2.10: El acceso a los recursos compartidos mediante Windows se realiza de manera intuitiva

25
2.2 El servidor Samba como controlador primario de dominio

Sin duda, Active Directory es la característica más atractiva a la hora de decidirnos por Windows Server como servidor
de nuestra red local. El conjunto de servicios y utilidades que ofrece para la gestión de usuarios y equipos permite una
gestión tremendamente productiva, especialmente si trabajamos con clientes Windows.

Por otra parte Samba, la implementación para el mundo Linux del protocolo CFIS de Windows, permitía hasta hace
unos años implantar un servidor de dominio NT, que aunque permitía la autenticación centralizada, quedaba muchos
pasos atrás respecto a las funcionalidades de cualquier Windows Server de 2003 hacia delante. Pero desde la aparición
de la versión 4 (finales de 2012), Samba 4 permite implementar un DC (Domain Controller) basado en Active Directory.

A continuación veremos cómo crear un controlador de dominio basado en Active Directory usando Samba. En nuestro
caso, utilizaremos una máquina con Ubuntu 4.18. La configuración se hará sobre los siguientes datos:

• Nombre del controlador de dominio de Active Directory: IEDIB-CD

• Nombre DNS del dominio de Active Directory: xiedib.local

• Nombre NEBIOS del dominio: xiedib

• Dirección estática del servidor: 192.168.10.10

• Rol del servidor: Domain Controler (DC)

Si para probar una configuración como ésta quieres utilizar maquinas virtualizadas a VirtualBox la opción
recomendable sería configurar las máquinas con una red NAT con una configuración como la que puedes ver a
continuación (figura 2.1):

Figura 2.1: Configuración de red NAT en VirtualBox

26
2.2.1 El nombre del host

Antes de entrar propiamente en la instalación y configuración de Samba tenemos que preparar la máquina que nos
hará de servidor. Al haber comprobado que el sistema operativo está actualizado, estableceremos lo que debe ser el
nombre del host y el del dominio. Para definir el nombre de host, una de las opciones que tenemos es editar los
archivos /etc/hostname y /etc/hosts .

hostnamectl set-hostname <nombre del servidor>


AMPLIACIÓN

La orden hostnamectl nos permite cambiar de manera permanente el nombre del host pero
igualmente nos conviene editar /etc/hosts.

En el archivo / etc / hosts aparecen una serie de direcciones IP con sus correspondientes nombres
lógicos. De este modo, cuando se hace referencia a un ordenador que está identificado en esta
lista, el acceso es inmediato, y no se necesita la intervención de un servidor DNS para resolverlo.

Este archivo contenía una referencia al nombre antiguo del propio servidor, que Cambiaremos el
nombre antiguo del servidor. En este caso, además, incluiremos tanto el nombre DNS como el
IMPORTANTE

nombre NetBIOS (IEDIB-CD.xiedib.local y IEDIB-CD).

También incluiremos una referencia a la dirección IP estática que asignaremos al equipo en el


siguiente apartado.

#Contingut de / etc / hosts


127.0.0.1 localhost
127.0.1.1 IEDIB-CD.xiedib.local IEDIB-CD
192.168.10.10 IEDIB-CD.xiedib.local IEDIB-CD

27
2.2.2 La interfaz de red

Al tratarse de un servidor es más que conveniente que la IP sea estática.

Network-Manager

Si queremos controlar de manera completa la configuración de las interfaces de red de nuestro


sistema y éste tiene instalado un entorno gráfico, puede darse el caso de que la herramienta gráfica
Network-Manager interfiera con la configuración manual que realizamos.
AMPLIACIÓN

Si quieres evitar esto, tienes la opción de desinstalar la herramienta.

sudo apt purge network-manager

Esta es una precaución que no deberíamos haber tomado si hubiéramos optado por la versión
Server de Ubuntu.

Optamos por usar netplan para la configuración de la interfaz.

Editamos o creamos un archivo dentro /etc/netplan/ como 01-netcfg.yaml y definimos el siguiente contenido:

#Arxiu para la configuración estática de la red


network:
version: 2
renderer: networkd
Ethernets:
enp0s3:
dhcp4: no
dhcp6: no
addresses: [192.168.10.10/24]
gateway4: 192.168.10.1
nameservers:
addresses: [192.168.10.10 , 8.8.8.8, 8.8.4.4]

Guardado los cambios y aplicamos la configuración:

sudo netplan apply

En principio hasta aquí los pasos previos. Podemos reiniciar si queremos tener la certeza de que todos los cambios se
han realizado como es debido.

28
2.2.3 Instalación del software

El software necesario implica los siguientes paquetes:

• samba: El servidor de archivos, impresión y autentificación para SMB / CIFS.

• smbclient: Clientes de línea de comandos para SMB / CIFS.

• winbind: Servicio para resolver información sobre usuarios y grupos.

Lanzaremos de una vez la instalación de toda la paquetería necesaria para la configuración del servidor con la siguiente
orden:

sudo apt install samba smbclient winbind krb5-config

La instalación de Kerberos lanzará un asistente interactivo que nos pedirá información (o confirmación) sobre el
dominio y el nombre del servidor (figura 2.2).

29
2.2.4 configurar Samba

Ahora toca configurar Samba. En primer lugar renombramiento el archivo de configuración. Esto nos sirve para
asegurarnos de que no se usarán los datos que contiene durante el proceso de configuración y que sólo se usan las
que hemos introducido. De paso, tenemos un backup por si algo falla:

sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.old

Después de esto ya podemos promover nuestro servidor como controlador de un dominio con Samba 4 que podrá
hacer el papel de un servidor de dominio de Active Directory. Para ello utilizaremos la orden samba-tool domain
provision y, de forma interactiva, se nos pedirán los valores que se necesiten y se sugerirán sus valores
predeterminados.

sudo samba-tool domain provision

Si hemos realizado correctamente todo el proceso hasta llegar aquí, los valores que nos sugiere el asistente (los que
aparecen entre []) serán todos correctos y, por tanto, sólo será necesario pulsar INTRO para aceptarlos. Para terminar
introduciremos por dos veces la que será la contraseña del usuario administrator . Esta contraseña requiere cierta
complejidad. Una sencilla no será aceptada y se tendrá que repetir el proceso. Poner atención en la información que
le da por pantalla.

Figura 2.3: Asistente samba-tool

30
Si puede ver el resumen del final, es que la operación ha resultado exitosa.

Figura 2.4: Asistente samba-tool

El procedimiento anterior, además de configurar Samba como controlador de dominio, ha generado un archivo de
configuración para Kerberos en la ruta /var/lib/samba/private/krb5.conf . Su ubicación adecuada para poder
funcionar es /etc/ , entonces el copiamos allí:

sudo cp /var/lib/samba/private/krb5.conf /etc/

Antes de ajustar la resolución de nombres detendremos y deshabilitaremos los servicios implicados

sudo systemctl stop smbd.service nmbd.service winbind.service systemd-resolved.service


sudo systemctl disable smbd.service nmbd.service winbind.service systemd-resolved.service

Si quisiéramos conocer el estado del servicio samba-ad-dc en este momento podrían ejecutar la orden:

systemctl status samba-ad-dc.service

31
Es muy probable que se dé una salida como la siguiente:

Figura 2.5: systemctl status samba-ad-dc.service

Como hay que asegurarse de que el servicio se iniciará sin inconvenientes, desenmascararemos el servicio con la
siguiente orden:

sudo systemctl unmask samba-ad-dc.service

ACTIVAR, HABILITAR Y ENMASCARAR

Para gestionar servicios en systemd , hay que tener en claro los tres estados en los que se puede encontrar un
servicio. Estos estados son los siguientes:

• Activo e inactivo

• Habilidad e inhabilitado

• Enmascarado o desenmascarado

Activo e inactivo: Un servicio está activo cuando está en funcionamiento.

Habilidad o inhabilitado: El siguiente estado en el que podemos encontrar los servicios en systemd es el de
habilidad o inhabilitado. Que un servicio JavaScript nos indica que se iniciará de manera automática cuando
iniciamos el equipo. Por el contrario estará inhabilitado, cuando no se inicie de forma automática. Este estado,
no es incompatible con la anterior, es decir, un servicio puede estar activo y deshabilitado, inactivo y habilidad, y
sucesivamente.
AMPLIACIÓN

Enmascarado y desenmascarado

El último estado que nos queda por definir para gestionar servicios en systemd es el enmascaramiento. Un
servicio está enmascarado cuando no se puede iniciar de forma manual o por medio de otro servicio. Por
supuesto, cuando un servicio está enmascarado no puede ser iniciado en el arranque de la máquina. Es decir, un
servicio enmascarado puede estar activo, pero no puede estar habilitado. Ahora bien, si el servicio no está activo
y está enmascarado, no se podrá iniciar.

En resumen, podemos decir que existen tres niveles de apagado:

• El primer nivel de apagado, simplemente termina la instancia del servicio que está en funcionamiento. Esto
se hace con la instrucción sudo systemctl stop service. Esto simplemente termina la instancia del servicio
que esté en funcionamiento.

• El segundo nivel de apagado, evita que un servicio se inicie con el arranque de la máquina. Para impedir
que un servicio arranque con la máquina, tan sólo tenemos que ejecutar la siguiente instrucción sudo
systemctl disable service.

• Finalmente, el tercer nivel de apagado es el enmascaramiento. Este nivel de apagado impedirá que se inicie
un servicio, ni de forma manual, ni en el arranque de la máquina.

32
El archivo /etc/resolv.conf encarga de configurar la parte del sistema de resolución de nombres de dominio. Lo hemos
de editar para conseguir que esta resolución de nombres funcione como es debido.

En este momento este archivo es sólo un enlace a otro archivo (/run/systemd/resolve/stub-resolv.conf), por tanto, lo
que tendremos que hacer es eliminarlo y crear uno nuevo con el contenido necesario.

Indicaremos dentro del archivo a qué dominio pertenece la máquina y como primer servidor de DNS hará referencia a
sí misma (127.0.0.1). Opcionalmente si queremos tener la certeza de que también se podrán resolver los dominios del
exterior podemos añadir las direcciones de servidores DNS públicos (la muestra se han añadido las de Google). El orden
en que aparecen es importante para que este será el orden en que serán consultadas. El archivo quedará por tanto
así:

Figura 2.6: /etc/resolv.conf

Y ahora sólo nos falta iniciar el servicio samba-ad-dc y habilitarlo para que también se inicie automáticamente al
arrancar el sistema.

sudo systemctl start samba-ad-dc


sudo systemctl enable samba-ad-dc

33
2.2.5 Creación y gestión de usuarios

La creación simple de un usuario para el dominio la podemos hacer así:

sudo samba-tool user create username

También podemos optar por hacerlo aportando más información desde la propia orden:

(ejemplo)
sudo samba-tool user create tamengual iedIB_2020 --given-name="Toni" --surname="Amengual" --
department="Dirección" --mail=tamengual@iedib.net --compañero="IEDIB" --job-title="Jefe de estudios
de FP"

TAREA DE APRENDIZAJE:

samba-tool es una herramienta muy potente que nos permite realizar toda una colección de tareas
bastante importantes. Te propongo hacer una búsqueda por internet para descubrir todas las posibilidades
de esta orden y probar al menos las que te resulten más interesantes.

34
2.2.6 Vincular una máquina con Windows 10 al dominio.

Ya podemos añadir máquinas al dominio de Active Directory que hemos configurado sobre Ubuntu de la misma manera
que si el servidor fuera un Windows Server. El procedimiento es exactamente el mismo.

Antes de establecer el vínculo puede resultar recomendable comprobar que la máquina Windows ve el servidor y ve
el dominio. Si están sobre la misma red, verá el servidor sin duda. Bastará hacer los pings correspondientes a la IP de
servidor (192.168.10.10) o en su nombre (iedib-cd) y recibiremos respuesta satisfactoria. Para poder ver el dominio
(xiedib.local) la máquina necesitará tener el servidor como servidor de DNS. Lo podemos comprobar haciendo ping
xiedib.local .

En la figura 2.7. podemos ver cómo modificamos la configuración del dispositivo de red para que pueda ver el dominio
y, de paso, como segundo servidor de DNS uno público que pueda resolver los nombres de dominio del exterior.

Figura 2.7: Configuración interfaz de red

35
Podemos comprobar el cambio realizado (figura 2.8)

Figura 2.8: El dominio resulta 'visible'

Ahora ya podemos proceder con la vinculación.

Abriremos las propiedades del sistema y pulsamos sobre la opción que nos permite cambiar la configuración del equipo
(nombre, dominio y grupo de trabajo).

Figura 2.9: Propiedades del sistema

36
Una vez dentro, un botón nos da opción a cambiar el dominio o grupo de trabajo y nos presenta la pantalla
Ingresaremos el nombre del equipo que queramos y números el dominio (xiedib.local).

Figura 2.10: Cambiar el dominio y el nombre del equipo

A continuación se nos pide identificarnos como usuario con privilegios (el administrador de Samba es, por defecto,
administrator -con indiferencia al uso de mayúsculas y minúsculas-).

Figura 2.11: Acreditación como administrador para cambiar el dominio

37
Si todo ha funcionado correctamente, una ventana emergente nos lo comunicará ya continuación nos informará de
que los cambios tendrán efecto una vez reiniciado el equipo.

Figura 2.12: Los cambios se aplicarán después de reiniciar el equipo

Tras el reinicio del equipo ya podremos iniciar sesión con alguno de los usuarios del dominio creados anteriormente
con samba-tool.

Figura 02.13: Inicio de sesión dentro del dominio

38
2.2.7 Uso de Windows 10 para la administración del dominio de Active Directory.

Existe una posibilidad bastante interesante por si se quiere gestionar Active Directory de la manera en que se haría
sobre una máquina con Windows Server.

Se trata de instalar en un cliente de Windows un software llamado 'Herramientas de administración remota del
servidor' (RSAT - Remote Server Administration Tool). Este software se debe bajar desde la página de Microsoft y, una
vez instalado, nos permitirá, entre muchas otras opciones, gestionar usuarios, grupos, unidades organizativas,
directivas, etc... del mismo modo que se hace ante un Windows Server. A quien esté acostumbrado a este tipo de
gestión no le supondrá un problema que Active Directory esté controlado por un servidor con GNU/Linux.

A continuación tienes una selección de capturas del procedimiento de lo anteriormente indicado:

1.

39
2.

3.

40
4.

41
5.

42
6.

43
ADMINISTRACIÓN DE SISTEMAS OPERATIVOS

ASO_UT06

Integración de sistemas operativos


en red libres y propietarios.
ÍNDICE

1 Redes heterogéneas .......................................................................................................................................3


1.1 Descripción de escenarios heterogéneos ................................................................................................3
1.1.1 Redes igualitarias ........................................................................................................................................... 4
1.1.2 Redes centralizadas ..................................................................................................................................... 10
1.2 El servicio Samba en un escenario heterogéneo .................................................................................... 15
1.2.1 Roles del servicio Samba en un escenario heterogéneo ............................................................................. 17
1.2.2 Instalación del servicio Samba ..................................................................................................................... 18
1.2.3 Niveles de seguridad .................................................................................................................................... 21
1.2.4 backends ...................................................................................................................................................... 27

2
1 Redes heterogéneas

Una red es un conjunto de equipos interconectados entre sí que permite el envío y la recepción de datos. De manera
análoga a cuando un conjunto de personas se quiere comunicar entre sí, en una red los equipos pueden utilizar
diferentes "idiomas" (protocolos) para comunicarse. De esta manera, el intercambio de datos es posible sólo si los dos
extremos de la comunicación entienden el protocolo utilizado. En este sentido, a lo largo de los años se han
desarrollado enormes cantidades de protocolos, más o menos especializados, destinados a este intercambio de datos.

En los últimos años, y gracias al proceso de estandarización de algunos protocolos utilizados en Internet (HTTP, FTP ,
SMTP, etc.), se ha conseguido que dispositivos de diferentes familias se pudieran comunicar a través de Internet sin
problemas. Así pues, actualmente sería impensable imaginar un escenario donde para visitar una página web alojada
en un servidor Linux no pudieras usar un equipo Windows o viceversa.

Como verás a continuación, en las redes locales algunos de los protocolos más utilizados han ido siempre ligados al
fabricante de los sistemas, lo que ha dificultado la integración entre diferentes sistemas.

1.1 Descripción de escenarios heterogéneos

El modelo de red determina cuál es el rol de los equipos que la integran. Este depende en mayor o menor medida de
las necesidades de la organización. En este aspecto se puede distinguir entre:

1. redes igualitarias

2. redes centralizadas

Cada modelo tiene sus ventajas e inconvenientes, y para cada familia de sistemas operativos podemos encontrar
diversas implementaciones. Históricamente, los grandes fabricantes han ofrecido soluciones adaptadas a su propia
familia de sistemas operativos y se han preocupado poco de la compatibilidad con el resto.

Actualmente, sin embargo, son pocas las redes homogéneas que se encuentran en las organizaciones y cada vez crece
más la necesidad de integrar diferentes familias de sistemas operativos en un mismo entorno.

Por ello conviene conocer cuáles son las soluciones que podemos encontrar en los diferentes sistemas operativos.

3
1.1.1 Redes igualitarias

Originalmente, las redes igualitarias se diseñaron para permitir compartir recursos desde máquinas de escritorio con
otros usuarios de la red.

En una red igualitaria, cada ordenador ( host ) toma el rol de cliente y servidor, de manera que cada una de las
máquinas determina los recursos que ofrece al resto y es responsable de su propia seguridad.
AMPLIACIÓN

La palabra host en este contexto hace referencia a cualquier ordenador conectado a la red.

Los protocolos utilizados en estas redes también permiten visualizar y navegar por la lista de recursos compartidos sin
que haya un servidor central. Los usuarios pueden encender o apagar sus máquinas sin temor a interrumpir otros
usuarios o servicios de la red (excepto cuando están accediendo a recursos propios).

Este escenario es el más común cuando la red tiene un número reducido de ordenadores. En estos casos también es
el más simple de configurar y administrar. Algunas de las ventajas que presentan las redes igualitarias respecto a las
redes centralizadas son:

1. Fiabilidad: la disponibilidad de los recursos no depende sólo de una máquina.

2. Escalabilidad: añadir ordenadores a la red es una tarea simple.

3. Distribución de carga: la carga de trabajo se distribuye entre diferentes máquinas y no recae sólo en el servidor.

4. Disponibilidad: la caída de una máquina sólo afecta a los recursos compartidos por ella.

4
REDES IGUALITARIAS EN ENTORNOS WINDOWS

Históricamente, las redes igualitarias entre sistemas Windows se conocen con el nombre de grupo de
trabajo o workgroup y utilizan los protocolos NetBIOS y SMB / CIFS . El grupo de trabajo se identifica con un nombre
y determina una agrupación de equipos que comparten recursos, pero en ningún caso marca los límites de una zona
de seguridad (es decir, un miembro de un grupo de trabajo puede acceder a una máquina en otro grupo de trabajo).

Los equipos que comparten el mismo nombre de grupo de trabajo y pertenecen a la misma red aparecen agrupados
cuando se explora el entorno de red. Un host Windows, independientemente de la versión, debe ser miembro o bien
de un grupo de trabajo o bien de un dominio.

Dado que cada máquina de un grupo de trabajo es responsable de su propia seguridad, cuando un usuario quiere
acceder a un recurso compartido debe tener una cuenta de usuario local en la máquina servidor.

Un recurso dentro de una red se identifica con una ruta UNC (universal naming convention), que típicamente toma la
forma \\NomMaquina\Recurs. Por ejemplo, si suponemos que dentro de nuestro grupo de trabajo hay una máquina
llamada IEDIB que comparte una carpeta llamada Public , podremos acceder al recurso con la
UNC \\IEDIB\Public. También podemos utilizar la dirección IP del servidor ( \\192.168.0.6\Public).
AMPLIACIÓN

Las direcciones UNC no distinguen mayúsculas y minúsculas.

Una de las características más útiles de los grupos de trabajo en Windows es la posibilidad de explorar los recursos
compartidos de una red. De esta manera, no es necesario que el usuario sepa la dirección UNC exacta del recurso al
que quiere acceder, sino que puede "navegar" por todos los equipos de la red de manera similar a como lo haría en el
sistema de archivos local. Simplemente hay que haga clic sobre el botón Entorno de red y la lista de ordenadores
aparecerá en la ventana.

Para que todos los equipos puedan explorar la red de una manera óptima y sin saturarla, una de las máquinas del
grupo de trabajo contiene una base de datos con todos los ordenadores conectados a la red, como puede observarse
en la figura 1.1 . Esta máquina se conoce con el nombre de master browser . El master browser es responsable de
obtener toda la información necesaria para crear y mantener la lista de ordenadores del grupo de trabajo. El resto de
equipos anuncian su presencia justo en el momento en el que se conectan al grupo de trabajo y el master browser los
añade a la base de datos. Cualquier máquina de un grupo de trabajo es susceptible de ser master browser y el proceso
de elección se realiza de forma totalmente transparente para los usuarios.

5
Para evitar que el master browser sea un punto de quiebra en caso de que se pierda la conexión, también existe el rol
de backup browser . El backup browser es otra máquina con una copia de la lista de ordenadores. Cada cierto
tiempo, master y backup browser sincronizan sus bases de datos.

Problemas de sincronización en grupos de trabajo

Si ha usado los grupos de trabajo para compartir archivos entre sistemas Windows, probablemente
alguna vez habréis visto como dos equipos de una misma red muestran listas de equipos diferentes
sin razón aparente. Algunos equipos aparecen en una lista pero no en la otra. El motivo principal
AMPLIACIÓN

suele ser que el master y backup browser aún no se han sincronizado.

Los grupos de trabajo funcionan relativamente bien mientras haya pocas conexiones y
desconexiones en la red. No ocurre lo mismo cuando nos encontramos en un escenario con
cambios continuos de ordenadores, con muchas conexiones y desconexiones en intervalos cortos
de tiempo. El resultado se traduce en unas bases de datos no actualizados y no sincronizadas, que
conllevan una experiencia no muy agradable para el usuario. Actualmente, con el auge de los
dispositivos portátiles, donde son frecuentes las conexiones y desconexiones, este mecanismo
resulta muy poco práctico.

6
Con Windows 7 apareció un nuevo sistema destinado a la compartición de recursos en redes igualitarias domésticas
llamado HomeGroup . Se trata de una función que simplifica la tarea de compartir recursos.

Microsoft publicó la especificación de HomeGroup como parte del programa Open Specification. Este hecho permite
a cualquiera crear su propia implementación de HomeGroup , y por tanto abre la puerta a la implementación libre en
otros sistemas operativos. HomeGroup utiliza una tecnología similar a las que usan las redes P2P, como BitTorrent,
gracias a dos protocolos:

1. Peer-to-peer graphing protocol (PPGRH): permite que todos los nodos de una red tengan exactamente la
misma base de datos de ordenadores (desaparece el rol de Master Browser ).

2. Peer name resolution protocol (PNRP): permite la resolución de nombres.

Estos protocolos, a diferencia de NetBIOS y SMB / CIFS, se han diseñado de manera que la red se puede expandir por
Internet y sin necesidad de que ninguna máquina actúe como master browser . Por lo tanto, se eliminan los problemas
de sincronización.
AMPLIACIÓN

Microsoft decidió retirar el sistema HomeGroup a partir de la versión 1803 de Windows 10.

Anuncio de Microsoft

7
REDES IGUALITARIAS EN ENTORNOS UNIX / LINUX

Tradicionalmente, la compartición de archivos entre máquinas Unix ha consigue con el protocolo network file
system (NFS). La última versión, NFSv4, incorporó muchas mejoras respecto a las versiones previas y es la que se utiliza
en todas las distribuciones de GNU / Linux.

En Debian podemos instalar un servidor NFS añadiendo los paquetes nfs-kernel-server, nfs-common y portmap:

# Apt-get install nfs-kernel-server nfs-common portmap

La configuración de NFS al servidor se realiza dentro del archivo /etc/exports. En este se indica, para cada línea:

1. Directorio que se quiere compartir

2. Nombre o IP de la máquina que tendrá acceso

3. Opciones (entre paréntesis y separadas por comas)

# cat /etc/exports

/Directorio/compartido 192.168.0.0 ( ro, root_squash )

/Directorio/compartit2 192.168.0.0 ( ro, root_squash )

Los clientes GNU / Linux pueden acceder al servidor montando el directorio compartido tal como se haría con cualquier
otro dispositivo, indicando el tipo nfs a la orden mount y la dirección o el nombre del servidor tal y como se muestra
a continuación:

$ Mount -t nfs4 192.168.0.6: /directorio/compartido/puntodemontaje

NFS controla quien puede montar los sistemas de archivos basándose en la máquina que lo pide y no en el usuario que
utilizará el sistema de ficheros.
IMPORTANTE

Aunque el protocolo NFS se ha utilizado durante años, en un mundo dominado por el sistema
operativo Windows muchas distribuciones de GNU / Linux de escritorio incorporan también
Samba como cliente-servidor SMB / CIFS para integrarse en las redes Windows .

8
REDES IGUALITARIAS EN ENTORNOS MAC

Los equipos con sistemas operativos MacOS trabajan de forma nativa con varios protocolos para la compartición de
recursos. En general, un sistema MacOS implementa:

1. El protocolo Apple filing protocolo (AFP)

2. Los protocolos SMB / CIFS y NetBIOS

3. El protocolo NFS

Esta característica permite la compatibilidad con sistemas operativos Unix/Linux y Windows sin necesidad de instalar
ningún software de terceros. Típicamente, el protocolo AFP utiliza cuando se comparten archivos entre equipos Mac
gracias a que provee una interfaz totalmente adaptada al sistema de archivos de Apple. La dirección de un recurso
compartido por un servidor AFP empieza por afp://. Pero también podemos conectarnos a un recurso SMB y NFS
utilizando las direcciones smb:// y nfs:// respectivamente.

Una de las ventajas de usar Mac OS es que la conexión a diferentes tipos de servidores se realiza de una manera
uniforme a través del programa Finder ( figura 1.2 ).

El acceso a un recurso compartido por Windows especifica con la forma smb://servidor/recurs, donde servidor es la
IP o el nombre del servidor y recurso es el nombre del recurso compartido.

9
1.1.2 Redes centralizadas

El modelo de red de igual a igual, o de entorno de trabajo, funciona relativamente bien cuando se implanta en un
entorno con un grupo de usuarios reducido y con pocos equipos. A medida que el número de ordenadores conectados
a la red va aumentando, la administración de los recursos, los usuarios y los permisos comienza a ser una tarea tediosa.

En las redes grandes, los usuarios y las máquinas suelen agrupar en dominios , por lo que la administración de los
recursos, así como sus permisos, se puede realizar de manera centralizada.
IMPORTANTE

Desde el punto de vista de la administración de sistemas, un dominio es un conjunto de equipos


interconectados que comparten información administrativa (usuarios, grupos, contraseñas, etc.).

En este escenario, un servidor es el que se encarga del control de acceso a los recursos, y no cada máquina, como es
el caso de las redes igualitarias, típicamente mediante un esquema cliente-servidor. Por ejemplo, cuando un usuario
desea iniciar una conexión en cualquiera de los ordenadores (clientes) del dominio, este ordenador deberá validar las
credenciales del usuario en el servidor, y obtener de este todos los datos necesarios para poder crear el contexto inicial
de trabajo para el usuario.

Por otra parte, uno de los inconvenientes de este modelo es que el acceso a la red queda supeditado a la disponibilidad
del servidor. Es decir, que si un cliente no puede contactar con el servidor tampoco podrá acceder a los recursos. Este
problema se puede solucionar disponiendo uno o varios servidores de reserva ( backup ), que actúan en caso de caída
del servidor principal.

10
DOMINIOS EN ENTORNOS UNIX

Históricamente, en el mundo Unix los dominios solían implementarse mediante el conocido network information
service ( NIS ), del que existen actualmente múltiples variantes para diferentes sistemas y entre las que podemos
encontrar versiones para GNU / Linux. El diseño original de NIS fue desarrollado por Sun Microsystems, y se trata de
un protocolo cliente-servidor que permite el acceso a un servicio de directorio. La finalidad de este protocolo es
centralizar la administración de sistemas Unix. La implementación inicial de Sun constaba de un servidor, una librería
para la parte de los clientes y diversas herramientas de administración del directorio.

En general, en un dominio NIS se diferencian tres tipos de ordenadores: servidores maestros, servidores esclavos y
clientes. Un dominio NIS debe tener, como mínimo, un servidor maestro. En este servidor se almacena la información
referida a los usuarios y grupos del dominio, así como los recursos. Los servidores esclavos permiten liberar la carga
del servidor maestro y de cara a los clientes se comportan de la misma manera. Las actualizaciones sólo se pueden
realizar directamente en el servidor maestro. Una limitación importante de NIS es que todos los clientes deben estar
en la misma subred IP que el servidor maestro.

El sistema NIS original ha demostrado tener graves limitaciones inherentes a su diseño, especialmente en referencia a
la escalabilidad y la seguridad. Este hecho provocó que el reemplazaran otras tecnologías. Como contrapartida, y con
la intención de mejorar y corregir los problemas iniciales de NIS, Sun Microsystems introdujo NIS + . Añadió fuertes
mejoras en seguridad, flexibilidad y escalabilidad. Estas mejoras también fueron ligadas a un aumento de la
complejidad en la administración de estos sistemas, lo que provocó, casi de forma definitiva, el abandono de NIS a
favor de otras tecnologías mucho más potentes y escalables como LDAP .

Un dominio LDAP estructura de manera similar a un dominio NIS: hay servidores maestros, esclavos y clientes. Los
clientes pueden obtener información de los maestros o esclavos, pero todos los cambios deben aplicarse a los
servidores maestros. Hay muchas implementaciones de un servicio de directorio LDAP, pero una de las más utilizadas
es OpenLDAP .

OpenLDAP es un software de código libre que permite adaptarse a diversas necesidades. Se trata de un servicio de
directorio robusto, rápido y escalable que no tiene nada que envidiar a otros servicios de directorio. La complejidad
de OpenLDAP será valorada por aquellos administradores que quieran construir un servicio de directorio
personalizado.

11
DOMINIOS EN ENTORNOS WINDOWS

El servicio de controlador de dominio en redes Windows se implementó por primera vez en la versión 3.5 de Windows
NT y mejoró posteriormente a Windows NT 4. Este servicio se conoció inicialmente como NT directory
services (NTDS). Por primera vez se ofrecía la posibilidad de unificar y centralizar la administración de los equipos
Windows de una red. Hasta entonces, esta tarea se debía realizar equipo a equipo. Entre otras muchas ventajas, se
permitía que los usuarios de una red pudieran acceder a los recursos del dominio independientemente de la máquina
que utilizaran.

La estructura de un dominio Windows NT en una red es muy simple. Dentro de cada dominio tiene que haber, como
mínimo, un controlador primario de dominio (CPD) y, de manera opcional, uno o más controladores de dominio de
reserva (BDC). Es en estas máquinas donde se encuentra la información administrativa y de seguridad del dominio. Si
el controlador primario deja de estar operativo, los usuarios pueden acceder al dominio a través de uno de los
controladores de reserva (en caso de existir). Sin embargo, las tareas administrativas sólo se pueden realizar
directamente en el controlador primario de dominio.

Con la aparición del primer sistema operativo de la familia Windows Server (Windows 2000 Server) se introdujeron
cambios importantes en el servicio de controlador de dominio . Este, que anteriormente se conocía como NTDS, pasó
a llamarse Active Directory domain services . De este modo, podemos distinguir dos tipos de dominios Windows:

1. dominios NT

2. Dominios Active Directory

La diferencia más significativa entre dominios NT y active directory radica en que los segundos permiten controlar una
variedad muy grande de tipos de objetos dentro de un dominio: usuarios, grupos, máquinas, servicios, e incluso definir
nuevos tipos de objetos (NTDS sólo permitía definir usuarios y grupos). Además, todos los objetos quedan organizados
de forma jerárquica y accesible mediante el protocolo LDAP . Esta última característica abrió la puerta a
la interoperabilidad con aplicaciones de otras plataformas como Unix.
IMPORTANTE

Windows Server utiliza el protocolo LDAP para acceder a la base de datos de Active Directory, lo
que permite la interoperabilidad con aplicaciones de otras plataformas, como por ejemplo
GNU/Linux.

12
DOMINIOS EN ENTORNOS MAC

El servicio de directorio nativo a MacOS llama open directory y cualquier sistema actual de Apple, sea versión servidor
o de escritorio, incluye una base de datos open directory local. En este directorio se almacena la información de las
cuentas de usuarios locales.

Un ordenador MacOS Server puede tomar el rol de controlador de dominio open directory cuando se configura
como open directory master . Open directory utiliza el protocolo LDAP y almacena información de administración,
usuarios, grupos y cuentas de máquina de forma jerárquica. El servicio de directorio se puede vincular a un servidor
de contraseñas ( open directory password server ) y, opcionalmente, a un reino Kerberos, que provee un mecanismo
de autenticación seguro.

Es importante destacar que hasta la versión v10.6 los servidores Mac podían simular el rol de un controlador de
dominio Windows NT. A partir de entonces esta funcionalidad, muy útil en entornos heterogéneos, se ha dejado de
implementar. De todos modos, a MacOS se puede usar Samba.

DOMINIOS EN ENTORNOS HETEROGÉNEOS

Es cada vez más habitual que las organizaciones tengan simultáneamente sistemas operativos de diferentes
familias. En este tipo de escenarios, la opción más sencilla, y muchas veces utilizada, es gestionar los diferentes
sistemas de forma independiente, utilizando las herramientas administrativas que cada fabricante proporciona.

En un entorno como el descrito, una de las soluciones que se puede adoptar es crear diferentes dominios para cada
tipo de sistema: un dominio Unix, un dominio Windows, etcétera. Esta es una manera simple con la que podemos
administrar, de forma centralizada, los recursos de red agrupados en familias. Es evidente que esta solución supone la
repetición de tareas administrativas para cada dominio: creación de usuarios y grupos, configuración de permisos,
políticas de seguridad, administración de recursos compartidos entre sistemas ...

Una opción más elegante, pero más complicada, es integrar todos los equipos en un mismo dominio de modo que se
agrupen todos los sistemas de la organización en una única administración centralizada. Lamentablemente, esta
opción no es sencilla, ya que los diferentes fabricantes de sistemas no suelen hacer el diseño para que sean
compatibles entre sí (especialmente cuando el fabricante es una empresa que defiende un producto
comercial). Incluso cuando los sistemas se basan en tecnologías estándar (como LDAP en el caso de Windows Server y
Linux), esta integración no resulta fácil. Esto es debido principalmente a las diferencias de diseño entre sistemas y a
que ninguno de los sistemas suele implementar los estándares de forma completa hasta el último detalle.

Sin embargo, administrar un dominio en el que los sistemas no pertenecen a la misma familia es una tarea que se ha
ido simplificando cada vez más. Si bien al principio era muy difícil integrar sistemas operativos diferentes en un mismo
dominio, en los últimos años han surgido algunas soluciones que facilitan esta integración, tanto si se utilizan
servidores Windows con clientes GNU / Linux como al revés.

Entre estas soluciones podríamos destacar Samba , para integrar sistemas Windows con servidores Unix y derivados.

NFS
AMPLIACIÓN

Network file system es un protocolo diseñado para acceder a sistemas de archivos remotos. NFS se
incluye por defecto en todos los sistemas operativos de la familia Unix y permite compartir archivos
a través de la red.

13
14
1.2 El servicio Samba en un escenario heterogéneo

Samba es uno de los grandes logros del movimiento de código abierto. Prueba de ello es el reconocimiento y la
aceptación que ha tenido últimamente en el mundo de las TIC, donde se ha convertido en una especie de servicio
estándar en redes donde conviven sistemas operativos GNU/Linux y Windows. De hecho, gran parte de su popularidad
se debe precisamente a su capacidad para integrarse en redes Windows. Samba toma el nombre del protocolo server
message block (SMB), inicialmente desarrollado por Microsoft, IBM, Intel y otros para permitir que los sistemas
operativos DOS, Xenix, OS/2 y Windows, al final de los años 80, pudieran compartir unidades , archivos e impresoras. El
protocolo SMB cambió de nombre en 1998 y pasó a llamarse common Internet file system(CIFS). A día de hoy, este
protocolo es el que todavía se utiliza en los sistemas Windows para compartir archivos. La alternativa en sistemas
GNU/Linux es Samba: un paquete de software que puede estar presente en situaciones muy diversas, desde un
entorno doméstico para compartir archivos e impresoras hasta un entorno corporativo realizando las tareas de un
controlador de dominio.

SMB y CIFS
IMPORTANTE

CIFS se puede considerar una evolución de las muchas que se han hecho del protocolo SMB. El
cambio de nombre fue parte de una estrategia de Microsoft, pero popularmente se ha seguido
llamando SMB. Por ello, en muchos textos aún podemos encontrar las siglas SMB o CIFS,
indistintamente, para referirse al mismo protocolo.

Inicialmente se diseñó para permitir la compartición de directorios e impresoras entre máquinas con diferentes
sistemas operativos, en concreto entre Windows y Unix, pero a medida que pasaba el tiempo se han ido añadiendo
más funcionalidades. Samba puede trabajar en la mayoría de sistemas de tipo Unix, como GNU / Linux, Solaris, AIX,
BSD y Mac OS . Actualmente, Samba implementa diversos servicios y protocolos que permiten, entre otras
funcionalidades:

1. La compartición de directorios

2. La administración y compartición de impresoras, con controladores asociados para acceder desde los clientes
Windows

3. La autenticación de clientes en un dominio Windows

4. La asistencia a la navegación del entorno de red ( network browsing )

Estas funciones facilitan que máquinas Windows y GNU/Linux puedan convivir dentro de una misma red . Tanto es
así, que en algunas situaciones es posible sustituir un sistema Windows para un sistema GNU/Linux con Samba sin que
los clientes se den cuenta. En realidad, un cliente Windows no sabe si la máquina con la que se está comunicando es
otro sistema Windows, lo único que hace falta es que la máquina del otro extremo se comporte como tal, y en algunos
aspectos Samba puede actuar como un servidor Windows.

Muchas son las ventajas del uso de Samba respecto a un sistema Windows, pero destacan sobre todo:

1. El coste: usar los sistemas Windows requiere adquirir previamente las licencias; en cambio, podemos utilizar
GNU/Linux y Samba de forma gratuita.

2. La interoperabilidad entre sistemas: podemos utilizar GNU/Linux y Samba para compartir impresoras o
archivos accesibles desde Windows o Unix.

15
3. La adaptabilidad: al tratarse de un proyecto de código abierto, se pueden introducir las modificaciones que
convengan.

Sin embargo, no podemos ver en Samba la solución gratuita que nos permite sustituir definitivamente un servidor
Windows. Hay funcionalidades que aún no están implementadas pero que están en proceso, y hay otros que
probablemente no se implementarán.

16
1.2.1 Roles del servicio Samba en un escenario heterogéneo

El rol de Samba en una red está determinado por su configuración, que generalmente se hará a través del
archivo /etc/samba/smb.conf. La tabla 1.1. detalla cuáles son los roles que cumple.

Tabla 1.1: Roles que puede tomar Samba

Servidor de archivos y de impresoras

Servidor independiente ( stand-alone )

Controlador de dominio de tipo Windows NT

Miembro de dominio de Windows NT

Controlador de dominio de tipo Active Directory

Miembro de dominio de tipo Active Directory

Interacción con otros controladores de dominio Windows

Interacción con otros controladores de dominio Samba

Master browser local

Master browser de dominio

A continuación se describe el significado de algunos de estos roles:

• Servidor de archivos y de impresoras : el uso más común de Samba es para compartir archivos e impresoras
en escenarios heterogéneos.

• Servidor independiente ( stand-alone ): la forma más simple de funcionamiento de Samba es aquella en la


que actúa como servidor independiente ( stand-alone ). Esto significa que no forma parte de ningún dominio
y el acceso a los recursos compartidos es controlado exclusivamente por Samba. Este rol es el que se utiliza en
escenarios con redes de igual a igual o grupo de trabajo.

• Samba como miembro de un dominio : cuando Samba forma parte de un dominio, el acceso a los recursos
que ofrece es controlado por el controlador de dominio y no por la propia máquina. Samba puede unirse a un
dominio NT (Samba o Windows NT) o Active Directory (Windows Server 20xx).

• Samba como controlador de dominio primario : Samba puede actuar como un controlador primario de
dominio (PDC) de tipo Windows NT y de tipo Active Directory. En esta situación, Samba es responsable de la
autenticación de los clientes.

17
• Samba como controlador de reserva : los controladores de reserva (BDC) contienen una copia de la base de
datos de usuarios y grupos del controlador primario de dominio, llamada SAM ( security account
manager) . En caso de caer el PDC, el controlador de reserva se encargará de sustituirlo hasta que vuelva a
estar operativo.

• Samba como local master browser : en una red de igual a igual (sin controladores de dominio) cada ordenador
debe anunciar su presencia en el resto de equipos del entorno de trabajo. Si el número de equipos es elevado
se puede generar una situación donde haya un tráfico continuo de paquetes por la red. Para evitar el problema,
se selecciona una de las máquinas del grupo para que contenga la lista de todos los equipos conectados. De
este modo, cualquier una máquina puede anunciarse y obtener la lista de todos los equipos haciendo una sola
petición. El equipo con la lista de máquinas llama local master browser y Samba se puede configurar para
actuar como tal.

• Samba como domain master browser : de manera similar al local master browser , cuando nos encontramos
en un entorno de dominio, una de las máquinas se hace responsable de la lista de equipos registrados en el
dominio. Esta se conoce como domain master browser .

Antes de profundizar más en la configuración de Samba es muy recomendable repasar los conceptos básicos de su
funcionamiento . En los apartados siguientes trataremos de explicar algunos de los aspectos que hay que conocer
previamente a la administración de Samba en uno u otro escenario.

1.2.2 Instalación del servicio Samba

Para instalar el servidor Samba en un equipo con el sistema operativo Debian hay que descargarse e instalar el paquete
principal, llamado samba .

# Apt-get install samba

Este paquete tiene dos dependencias que también se instalarán de forma automática: samba-commony samba-
common-bin. Aunque hay más paquetes relacionados con samba, tales como smbclient, smbfs, swat, etc., sólo el
paquete samba y sus dos dependencias son necesarias para establecer un servidor .

Puede observar cuáles son los archivos que se han instalado con el paquete:

# Dpkg -L samba

En general, el servicio Samba incluye varias aplicaciones y los siguientes tres demonios:

1. smbd : proceso que recibe y atiende las peticiones que permiten acceder a los recursos compartidos y
autentica los clientes.

2. nmbd : se encarga del registro de nombres NetBIOS y participa en el proceso de elecciones a master browser .

3. winbindd : proceso que se comunica con los controladores de dominio para intercambiar información sobre
las cuentas de usuario. Sólo es necesario cuando queremos que una máquina GNU / Linux forme parte de un
dominio Windows. Por defecto no se inicia, y en determinadas situaciones ya ni se instala.

18
Una vez descargado e instalado, el servicio se inicia de forma automática tomando como configuración
predeterminada indicados en el archivo /etc/samba/smb.conf. Puede comprobar si los demonios están funcionando
correctamente listando todos los procesos y filtrando por el nombre del proceso:

root @ debian: / home / usuario # ps -A | grep nmbd

2283 ? 12:00:00 nmbd

root @ debian: / home / usuario # ps -A | grep smbd

2287 ? 12:00:00 smbd

2.296 ? 12:00:00 smbd

Para detener, iniciar o reiniciar los demonios podemos utilizar la herramienta service , que será necesaria cuando se
cambien ciertos aspectos de la configuración.

# Service smbd restart


# service nmbd restart

En versiones más antiguas se podían manejar los servicios de manera conjunta invocando sólo a
samba:
ALERTA

# Service samba restart

Stopping Samba daemons: nmbd smbd.

Starting Samba daemons: nmbd smbd.

Opcionalmente podemos instalar un paquete con documentación muy útil, tanto en texto plano como en PDF:

# Apt-get install samba-doc samba-doc-pdf

Este paquete contiene manuales y archivos de configuración de ejemplo que podemos encontrar dentro del
directorio /usr/share/doc/samba-doc. Si disponemos de un navegador podemos abrir un archivo HTML que contiene
vínculos a toda la documentación descargada.

# Firefox /usr/share/doc/samba-doc/htmldocs/index.html

19
Una vez comprobado que el servicio funciona correctamente, hay que determinar qué rol debe asumir el servicio
Samba y configurarlo adecuadamente según el escenario en el que nos encontramos.

Como el proceso de configuración es delicado, se recomienda cuando sea necesario revisar los registros ( logs ) de los
demonios nmbd y smbd. Se pueden consultar en los archivos /var/log/samba/log.nmbd y /var/log/samba/log.smbd
respectivamente. Es muy útil de cara a descubrir posibles problemas y le ayudará en el proceso de administración.

Por defecto, Samba muestra sólo una cantidad muy reducida de mensajes a los registros. Cuando la información que
ve en registro no le ayude a detectar el problema puede subir el nivel de logging para ver mensajes más detallados. El
nivel de los mensajes mostrados se puede cambiar con el parámetro log level, y puede tomar un valor de 0 (menos
detalle) a 10 (más detalle).

[ Global ]

...

log level = 3

...

En general, el nivel 3 es suficiente en la mayoría de escenarios. Si utiliza la orden tail con la opción -f verá los mensajes
en tiempo real a medida que aparecen:

# Tail -f /var/log/samba/log.nmbd

O bien:

# Tail -f /var/log/samba/log.smbd

20
1.2.3 Niveles de seguridad

Cuando un cliente quiere acceder a un recurso compartido por Samba o por Windows hay que comprobar si el usuario
tiene los privilegios necesarios. Esta acción se puede llevar a cabo de diversas maneras, que están determinadas por
el protocolo SMB / CIFS. En general, SMB / CIFS define dos niveles de seguridad: user y share . Cada uno de estos
implica un modelo de autenticación para validar las peticiones de entrada. A continuación vemos cuáles son las
diferencias entre estos dos niveles y cómo se pueden configurar a Samba.

1. Nivel de seguridad share . El nivel de seguridad share permite asignar una contraseña a cada uno de los
recursos compartidos. De este modo, sólo aquellos usuarios que conozcan la contraseña podrán acceder. Este
sistema tiene muchos inconvenientes, el principal es que el administrador no puede controlar qué usuarios
saben la contraseña. Esto es especialmente grave en redes con un gran número de usuarios. Además, si se
cambia la contraseña, hay que darla a conocer de nuevo. Actualmente, el nivel share se considera
obsoleto. Se mantiene por razones históricas, porque era el sistema utilizado en los sistemas Windows 95/98
/ Me y anteriores. Los desarrolladores de Samba esperan eliminar esta característica en futuras versiones.

2. Nivel de seguridad user . Cuando se configura el nivel de seguridad user , la autorización para acceder a los
recursos está determinada por los permisos de red de cada usuario. Cuando un usuario (cliente) quiere
acceder a un recurso necesario que se autentique en el servidor , típicamente mediante nombre de usuario
y contraseña (véase figura 1.5 ).

Figura 1.5: El nivel de seguridad user requiere que el cliente autentique previamente con usuario y contraseña

En Samba, el nivel de seguridad lo determina la variable security dentro del apartado [global]. Esta variable puede
tomar cinco valores diferentes, uno correspondiente al nivel de seguridad share y los cuatro restantes
correspondientes al nivel de seguridad user . Estos valores son: share, server, user, domain y ads. Las
opciones server y share están obsoletas, por lo que a continuación sólo se describe el comportamiento
de user , domain y ads .

21
MODO DE SEGURIDAD USER

[ Global ]

...

security = user

...

Este modo se utiliza cuando Samba actúa como un servidor independiente (stand-alone). Esto significa que es el mismo
servidor Samba el que se encarga de la autenticación de usuarios. Por lo tanto, user es el modo utilizado en escenarios
con redes de igual a igual o entorno de trabajo . En este caso, Samba normalmente dispone de su propia base de
datos de usuarios, que se administra de forma local.

MODOS DE SEGURIDAD DOMAIN Y ADS

Cuando el servidor Samba y el cliente se encuentran dentro del mismo dominio utilizan los modos de
seguridad domain y ads . De este modo, cuando un usuario desea autenticarse para acceder a un recurso del servidor
Samba (directorio o impresora), la petición se redirige a un controlador de dominio y éste determina si el usuario es
válido. Dicho de otro modo, la tarea de decidir si el usuario puede acceder se delega en el controlador de dominio.

El controlador de dominio puede ser una máquina remota, tal y como se muestra en la figura 1.6 . Pero también puede
ser la misma máquina con el servidor Samba si éste funciona como CPD.

Figura 1.6: Modos de seguridad domain y ads

22
¿Cuál es la diferencia entre los modos domain y ads ? Desde el punto de vista del cliente no hay ninguno : un servidor
Samba configurado en el modo de seguridad ads se comporta de la misma manera que configurado en
modo domain . La diferencia entre estos dos radica únicamente en el proceso de comunicación entre Samba y el
controlador de dominio, donde se utilizará un protocolo u otro.

Los dos modos de seguridad, domain y ads , permiten el uso del protocolo de desafío / respuesta NTLM, que es el
utilizado en el proceso de autenticación en dominios NT o Active Directory en modo mixto. Pero el modo ads es el
único que permite el uso del protocolo Kerberos , que es el que utilizan los controladores de dominio Active Directory
en modo nativo. En resumen, el modo de seguridad domain se utilizará cuando el controlador de dominio sea de tipo
NT o Active Directory en modo mixto (opción activada por defecto en Windows Server). El modo ads se puede utilizar
en los mismos casos que con domain y, además, cuando el controlador de dominio sea Active Directory con
autenticación NTLM deshabilitada (modo nativo) .

Para configurar el servidor para utilizar el modo de seguridad domain necesario especificar las opciones dentro del
archivo de configuración:

[ Global ]

...

security = domain

encrypt passwords = yes

workgroup = NOM_DEL_DOMINI

...

Posteriormente hay que unir el servidor Samba al dominio. Por ello usaremos la orden net join, indicándole una cuenta
de usuario del dominio.

# net join -U alumne

Enter alumne's password:

Joined domain NOM_DEL_DOMINI.

Configurar Samba en modo de seguridad ads es algo más complejo. En primer lugar, es necesario que dentro de la red
haya un servidor DNS , ya que las librerías Kerberos lo necesitan para resolver las direcciones de los centros de
distribución de claves ( key distribution center ). Por lo tanto, hay que configurar la máquina con Samba para que use
estos servidores (mediante el archivo /etc/resolv.conf). A continuación se muestra un ejemplo suponiendo que el
servidor DNS tenga la dirección 10.0.0.1.

# Cat /etc/resolv.conf

search NOM_DOMINI.com

nameserver 10.0.0.1

23
Active Directory y DNS

AMPLIACIÓN Las librerías Kerberos necesitan el servicio DNS para resolver las direcciones de los centros de
distribución de claves (KDC). Es por eso que cuando se promueve una máquina Windows Server a
controlador de dominio (utilizando dcpromo) también se acostumbra a instalar el servicio de DNS .

Además de ello, es indispensable que la máquina con Samba tenga instalada una librería que implemente el protocolo
Kerberos versión 5. Hay varias opciones, pero la más conocida es krb5 ( http://web.mit.edu/kerberos / ). A los
ejemplos usamos krb5, pero es válida cualquier librería que implemente Kerberos v5. Como se muestra, krb5 se puede
instalar fácilmente en Debian usando la siguiente secuencia:

# Apt-get install krb5-config krb5-clientes krb5-user

Estas librerías se pueden configurar a través del archivo /etc/krb5.conf. En el caso que nos ocupa hay que indicar, como
mínimo:

1. El reino Kerberos : típicamente coincide con el nombre del dominio, y se especifica en la


variable default_realm. Es imprescindible que se escriba en mayúsculas.

2. Direcciones de los centros de distribución de claves Kerberos : hay que identificar cuál o cuáles máquinas
dentro del reino actúan como centros de distribución de claves (KDC) Kerberos. Para averiguarlo de forma
automática podemos poner la variable dns_lookup_kdc a true .

[ Libdefaults ]

default_realm = NOM_DOMINI.COM

dns_lookup_kdc = true

Para verificar que hemos hecho la configuración correctamente, tenemos que poder conectarnos con la
herramienta kinit con un nombre de usuario del dominio.

# Kinit alumno

Password for alumno@NOM_DOMINI.COM:

Si todo ha funcionado correctamente, debería haber obtenido un ticket Kerberos. Este se puede consultar
utilizando klist.

# klist

Ticket cache: FILE: /tmp/krb5cc_0

Default principal: alumno@ NOM_DOMINI.COM

Valid starting Expires Service principal

12 / 05 / 11 17 : 32 : 18 12 / 06 / 11 03: 32 : 19 krbtgt/NOM_DOMINI.COM@NOM_DOMINI.COM

renew until 12/06/11 17:32:18

24
Finalmente hay que modificar el archivo smb.conf de forma similar a como queda con el modo domain, pero indicando
el reino Kerberos a la variable realm .

[ Global ]

...

security = ads

encrypt passwords = yes

workgroup = nombre_dominio

realm = NOM_DOMINI.com

...

A continuación puede unir la máquina al dominio utilizando la orden net.

# net ads join -U alumno

Enter alume 's password:

Using short domain name - nombre_dominio

Joined ' DEBIAN ' to realm ' NOM_DOMINI.com

Sin embargo, no hay que olvidar que aunque Samba esté conectado a un dominio, internamente Linux asigna permisos
basándose en los usuarios locales de /etc/passwd. Por ello, en esta situación hay también un mecanismo que traduzca
los nombres del dominio a nombres locales.

Así pues, aunque el controlador de dominio haya autenticado correctamente un usuario que quiere acceder a los
recursos del servidor, es necesario que Samba sepa qué usuario local representa. De otro modo no tendrá permisos
para acceder. Para vincular usuarios del dominio usuarios locales puede utilizar uno de los siguientes mecanismos:

1. Crear todos los usuarios del dominio local y definir el parámetro username map en el archivo de configuración.

2. De forma totalmente transparente utilizando el demonio winbind.

winbind
AMPLIACIÓN

winbind actúa como intermediario entre un controlador de dominio Windows y el servicio de


autenticación local de Linux. De este modo, se puede hacer que los usuarios del dominio sean
también usuarios de Linux.

Puede encontrar bastante información al respecto en las páginas oficiales de documentación de


Samba.

25
Cuando Samba forma parte de un dominio, hay que utilizar un proceso de traducción de usuarios

IMPORTANTE
del dominio usuarios locales. Este proceso se puede llevar a cabo mediante id mapping o el proceso
winbind.

Como tiene resumido en la tabla 1.2 , el uso del modo de seguridad dependerá de la situación.

Tabla 1.2: Uso de los diferentes modos de seguridad en diferentes escenarios

security = user security = domain security = ads

Samba como servidor


independiente sí no no
(red de igual a igual)

Samba como miembro de un


no sí no
dominio NT

Sí, siempre que Windows Server


Samba como miembro de un
no acepte autenticación vía NTLM (modo sí
dominio de Active Directory
mixto)

26
1.2.4 backends

Tradicionalmente, el sistema GNU/Linux almacena la información de las cuentas de usuario, de las contraseñas y los
grupos a los ficheros /etc/passwd, /etc/shadow y /etc/group, respectivamente.

De manera análoga, los sistemas Windows lo hacen dentro de la base de datos SAM , un fichero que podemos
encontrar dentro del directorio \windows\system32\config. Consideramos que estos archivos contienen la base de
datos de usuarios del sistema. De este modo, cuando un usuario local se autentica en el sistema se consultan estos
archivos y se determina si las credenciales son correctas o no.

Validación de usuarios GNU / Linux


AMPLIACIÓN

Para validar usuarios, GNU/Linux puede utilizar otros mecanismos además de la consulta al
conocido fichero /etc/passwd. Los Pluggable authentication modules (PAM) son módulos de
software que permiten utilizar otros mecanismos de autenticación tales como sistemas
biométricos, directorios LDAP, dominios Windows, servidores Kerberos, RADIUS, etc…

De forma similar, el servicio Samba implementa un mecanismo de autenticación de usuarios para acceder a los
recursos que ofrece. Así, cuando un cliente quiere conectarse a un recurso compartido por Samba, como un directorio
o una impresora, se envían las credenciales y Samba verifica que el usuario esté dado de alta. Si las credenciales
recibidas son correctas, se hace el siguiente paso: determinar si este usuario tiene permisos o no para realizar la acción
solicitada. Se hace evidente, pues, que Samba debe disponer de una base de datos propia donde almacenar las cuentas
de usuario. A menudo, a esta base de datos se la conoce con el nombre en inglés de backend .

Algunos usuarios, sobre todo los acostumbrados a trabajar con Microsoft Windows, tal vez se plantearán la pregunta
siguiente: ¿por qué motivo Samba utiliza una base de datos diferente a la del sistema GNU/Linux? No resultaría más
fácil que los propios usuarios del sistema, dados de alta en /etc/passwd, también tuvieran acceso como clientes
Samba? La respuesta es que Samba necesita almacenar atributos adicionales para cada usuario que no se pueden
encontrar en /etc/passwd. Ejemplos de estos atributos son: el SID del usuario, las contraseñas cifradas en NT/LM o la
dirección UNC del directorio home (por citar algunos).
IMPORTANTE

Para cada usuario, Samba necesita almacenar atributos adicionales que no puede encontrar dentro
de /etc/passwd. Es por ello que debe disponer de una base de datos independiente de la del
sistema.

Podemos especificar el backend que Samba utilizará el atributo passdb backend , dentro de la sección [global]del
archivo de configuración. De manera nativa, Samba permite utilizar tres tipos de backends diferentes:

1. Archivo de texto plano

2. archivo TDB

3. directorio LDAP

Sin embargo, mediante módulos adicionales podemos utilizar otros backends como bases de datos MySQL,
PostgreSQL, archivos XML, etcétera. A continuación se detallan las características de los tres backends utilizados por
Samba.

27
ARCHIVO DE TEXTO PLANO

Es el método más simple. Los datos de los usuarios quedan registrados en un fichero de texto, normalmente
a /etc/samba/smbpasswd. Este archivo lo podemos visualizar con un editor de texto.

[ Global ]

...

security = user

passdb backend = smbpasswd

encrypt passwords = yes

...

La ubicación del archivo se puede definir manualmente:

passdb backend = smbpasswd: /ubicacion/archivo/smbpasswd

El archivo smbpasswd contiene una línea para cada usuario Samba, ya cada una de estas, sus atributos separados por
dos puntos ":".
usuario: uid: hash_1: hash_2: flags: darrera_modificació

Dónde:

1. usuario : es el nombre de usuario que utilizarán los clientes para conectarse a los recursos.

2. uid : el UID de la cuenta de usuario en el sistema.

3. hash_1 : hash de la contraseña de tipo Lanman (LM).

4. hash_2 : hash de la contraseña de tipo NT / LM.

5. flags : diversos caracteres que representan el tipo y el estado de la cuenta.

6. darrera_modificació : muestra cuándo fue la última vez que se cambió la contraseña (LCT o last change time ),
en formato hexadecimal.

28
# Cat / etc / samba / smbpasswd

usuario: 1000 : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: 7CE21F17C0AEE7FB9CEBA532D0546AD6: [ U ] : LCT-


4EBA44DE:

lluis: 1001 : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: 7CE21F17C0AEE7FB9CEBA532D0546AD6: [ U ] : LCT-4EBA6D0C:

manel: 1003 : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: 588FEB889288FB953B5F094D47D1565C: [ U ] : LCT-4EBA6D15:

marta: 1005 : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: 05B073DAA9C1B3B909FF5AE2E4604BB5: [ U ] : LCT-4EBA6D1C:

silvia: 1004 : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: DF54DE3F3438343202C1DD523D0265BE: [ U ] : LCT-4EBA6D22:

pep: 1.002 : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX: 37D02806094AD4CE5AEDD139D9943BED: [ U ] : LCT-4EBA6D39:

hash

Las contraseñas de los usuarios no se almacenan más de manera legible, sino que se aplica un
mecanismo de cifrado para evitar que nadie, ni siquiera el administrador, las pueda leer. Al
resultado de aplicar un mecanismo de cifrado a una contraseña se le conoce como hash.
AMPLIACIÓN

A lo largo de su historia, Windows, y de rebote Samba, ha utilizado dos mecanismos de cifrado para
almacenar las contraseñas de sus usuarios, LM y NT / LM. El primero, LM, ha quedado en desuso
por problemas de debilidad. NT / LM corrige algunas de estas debilidades y es el método utilizado
en las últimas versiones. Windows XP utilizaba los dos mecanismos a la vez (por compatibilidad con
versiones anteriores), pero a partir de Windows Vista el mecanismo de cifrado por defecto pasó a
ser NT / LM.

Actualmente, Samba tampoco utiliza el mecanismo LM. Es por ello que los backends podemos
observar una hilera de X donde debería haber el hash LM.

El uso del backend smbpasswd es ideal para escenarios simples con pocos usuarios, pero no es recomendable cuando
el número de usuarios es elevado. La razón es que no se puede acceder al archivo de manera concurrente, es decir
que cuando varios clientes quieren autenticarse a la vez, Samba atenderá las peticiones de manera secuencial, una
tras otra, por lo que puede provocar un cuello de botella en la red. Otro inconveniente es que no hay lugar para
atributos adicionales tales como la fecha de expiración de la contraseña o la dirección UNC del directorio home
(necesaria para aplicar perfiles de usuario).

29
ARCHIVO TDB

El backend TDB ( trivial database ) o tdbsam utiliza un archivo binario para almacenar los datos de los usuarios. Como
tal, no se puede manipular ni visualizar con un editor de texto, sino que tenemos que utilizar las herramientas que
proporciona el paquete de Samba.

[ Global ]

...

security = user

passdb backend = tdbsam

encrypt passwords = yes

...

Por defecto, este archivo está ubicado en un fichero llamado passdb.tdb en el directorio /var/lib/samba/, aunque
siempre dependerá de la distribución que estamos utilizando. La ubicación del archivo se puede definir manualmente:

passdb backend = tdbsam: / ubicacion / archivo / passdb.tdb

Tiene algunas ventajas respecto al backend smbpasswd : dispone de más atributos por usuario y permite el acceso
concurrente en el archivo, lo que mejora el rendimiento en caso de múltiples peticiones de autenticación. La parte
negativa es que no se puede usar en un escenario con múltiples controladores de dominio. El motivo es que cuando
hay varios controladores de dominio se necesita algún método de replicación del backend . Según los desarrolladores
de Samba, esta configuración es la recomendada siempre y cuando el número de usuarios no sea superior a 250.
Este backend lo encontramos seleccionado por defecto en la mayoría de distribuciones de GNU/Linux, como Ubuntu,
Debian o Fedora.
IMPORTANTE

El backend tdbsam está configurado por defecto en la mayoría de distribuciones GNU / Linux
actuales, tales como Ubuntu, Debian o Fedora.

30
DIRECTORIO LDAP

El backend ldapsam nos permite utilizar un servicio de directorio LDAP para almacenar las cuentas de usuario
Samba. LDAP nos permite mantener una base de datos de usuarios centralizada y accesible para cualquier controlador
de dominio. Para configurarlo sólo hay que indicar la URL del servicio LDAP dentro del archivo de configuración, tal
como muestra el ejemplo.

[ Global ]

...

security = user

passdb backend = ldapsam: ldap: // servidor /

...

Para utilizar un directorio LDAP como backend no basta con instalar e iniciar el servicio de directorio, sino que
previamente hay que prepararlo. A grandes rasgos, preparar el directorio quiere decir:

1. Cargar los esquemas propios de Samba en el directorio LDAP: es necesario que los elementos del directorio,
como usuarios o grupos tengan los atributos específicos de Samba.

2. Configurar Samba para usar el directorio: es necesario que Samba sepa dónde encontrar los elementos dentro
del directorio. Recuerde que el directorio puede almacenar muchos más datos.

Hay situaciones en las que es conveniente disponer de más de una copia del servidor LDAP. De esta manera nos
aseguramos de que en caso de fallo de uno de ellos pueda haber una alternativa. En este caso se pueden indicar las
direcciones de todos los servidores en el fichero de configuración:

passdb backend = ldapsam: "ldap://servidor1/ ldap://servidor2/ ldap://servidor3/ "

Otra ventaja de tener más de un servidor LDAP configurado es que Samba realiza, de forma automática, distribución
de carga . Así se evita que todas las peticiones de autenticación se redirijan a un mismo servidor LDAP.

En resumen, vemos que cada backend tiene sus ventajas e inconvenientes; la decisión sobre cuál elegir depende de la
situación. La tabla 1.3 muestra en qué situaciones se pueden utilizar estos backends .

Tabla 1.3: Uso de los backends en diferentes escenarios

smbpasswd tdbsam ldapsam

Samba como servidor independiente SÍ SÍ SÍ

Samba como controlador de dominio (PDC) NO SÍ SÍ

Múltiples controladores de dominio (PDC y BDC) NO NO SÍ

31

También podría gustarte