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