14.3. Tipos de servidores Samba y el archivo smb.conf
La configuraci�n de Samba es bien directa. Todas las modificaciones a Samba se realizan en el archivo de configuraci�n /etc/samba/smb.conf. Aunque el archivo predeterminado smb.conf est� bien documentado, no menciona t�picos complejos como LDAP, Active Directory y numerosas implementaciones de controladores de dominio.
Las secciones siguientes describen las diferentes formas en que se puede configurar un servidor Samba. Tenga en cuenta sus necesidades y los cambios requeridos al archivo smb.conf para una configuraci�n exitosa.
14.3.1. Servidor independiente
Un servidor independiente puede ser un servidor de un grupo de trabajo o un miembro de entorno de grupo de trabajo. Un servidor independiente no es un controlador de dominio y no participa en un dominio de ninguna manera. Los ejemplos siguientes incluyen varias configuraciones de seguridad a nivel de recursos compartidos an�nimas y una configuraci�n de seguridad a nivel de usuario. Para m�s informaci�n sobre los modos de seguridad a nivel de recurso compartido y de usuarios, consulte la Secci�n 14.4.
14.3.1.1. An�nimo de s�lo lectura
El archivo smb.conf siguiente muestra una configuraci�n de ejemplo necesaria para implementar compartir recursos de archivos de forma an�nima y de s�lo lectura. El par�metro security = share hace el recurso compartido an�nimo. Observe que, los niveles de seguridad para un servidor Samba �nico no se pueden mezclar. La directriz security es un par�metro Samba global localizado en la secci�n [global] del archivo de configuraci�n smb.conf.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = share
[data]
comment = Documentation Samba Server
path = /export
read only = Yes
guest only = Yes
14.3.1.2. An�nimo Lectura/Escritura
El siguiente archivo smb.conf muestra una configuraci�n de muestra necesaria para implementar compartir recursos de archivos de lectura/escritura de forma an�nima. Para activar compartir archivos de lectura/escritura an�nimos, configure la directriz read only a no. Las directrices force user y force group tambi�n se a�aden para reforzar la propiedad de cualquier archivo nuevo especificado en el recurso compartido.
Nota
Es posible tener un servidor de lectura/escritura an�nimo, pero no es recomendable. Cualquier archivo colocado en el espacio compartido, sin importar el usuario, se le asigna la combinaci�n de usuario/grupo como se especific� para un usuario (force user) y un grupo (force group) gen�rico en el archivo smb.conf.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = share
[data]
comment = Data
path = /export
force user = docsbot
force group = users
read only = No
guest ok = Yes
14.3.1.3. Servidor de impresi�n an�nimo
El siguiente archivo smb.conf muestra una configuraci�n de muestra necesaria para implementar un servidor de impresi�n an�nimo. Configurando browseable a no como se muestra, no lista la impresora en el Entorno de red. Aunque est� oculto para prop�sitos de navegaci�n, se puede configurar la impresora expl�citamente. Al conectar DOCS_SRV usando NetBIOS, el cliente puede tener acceso a la impresora si el cliente tambi�n es parte del grupo de trabajo DOCS. Tambi�n se asume que el cliente tiene el controlador de impresora correcto, pues la directriz de use client driver est� configurada a Yes. En este caso, el servidor Samba no tiene responsabilidad de compartir los controladores de impresora con el cliente.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = share
printcap name = cups
disable spools= Yes
show add printer wizard = No
printing = cups
[printers]
comment = All Printers
path = /var/spool/samba
guest ok = Yes
printable = Yes
use client driver = Yes
browseable = Yes
14.3.1.4. Archivo seguro de lectura/escritura y servidor de impresi�n
El archivo siguiente smb.conf muestra una configuraci�n de ejemplo necesaria para implementar un servidor de impresi�n seguro de lectura/escritura. Configurando la directriz security a user obliga a Samba a autenticar las conexiones de clientes. Observe que el recurso compartido [homes] no tiene una directriz force user o force group como si lo tiene el recurso [public]. El recurso compartido [homes] utiliza los detalles del usuario autenticado para cualquier archivo al contrario de force user y force group en [public].
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = user
printcap name = cups
disable spools = Yes
show add printer wizard = No
printing = cups
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
[public]
comment = Data
path = /export
force user = docsbot
force group = users
guest ok = Yes
[printers]
comment = All Printers
path = /var/spool/samba
printer admin = john, ed, @admins
create mask = 0600
guest ok = Yes
printable = Yes
use client driver = Yes
browseable = Yes
14.3.2. Servidor miembro de dominio
Un miembro de dominio, aunque es similar a un servidor independiente, es conectado a un controlador de dominio (bien sea Windows o Samba) y est� sujeto a las reglas de seguridad del dominio. Un ejemplo de un servidor miembro de dominio podr�a ser un servidor departamental ejecutando Samba que tiene una cuenta de m�quina en el Controlador de Dominio Primario (PDC). Todos los clientes del departamento todav�a se autentifican con el PDC y se incluyen los perfiles del escritorio y todas los archivos de pol�ticas. La diferencia es que el servidor departamental tiene la habilidad de controlar las impresoras y recursos de red compartidos.
14.3.2.1. Servidor miembro de dominio Active Directory
El archivo siguiente smb.conf muestra una configuraci�n de ejemplo necesaria para implementar un servidor miembro de dominio Active Directory. En este ejemplo, Samba autentifica usuarios para servicios que se ejecutan localmente pero tambi�n es un cliente del Active Directory. Aseg�rese de que su par�metro realm se muestra en may�sculas (por ejemplo realm = EXAMPLE.COM). Puesto que Windows 2000/2003 requiere de Kerberos para la autenticaci�n de Active Directory, se requiere de la directriz realm. Si Active Directory y Kerberos se est�n ejecutando en servidores diferentes, se puede necesitar la directriz password server para ayudar a diferenciar.
[global]
realm = EXAMPLE.COM
security = ADS
encrypt passwords = yes
# Optional. Use only if Samba cannot determine the Kerberos server automatically.
password server = kerberos.example.com
Para poder unir un servidor miembro a un dominio de Active Directory, se deben completar los pasos siguientes:
Configuraci�n del archivo smb.conf en el servidor miembro
Configuraci�n de Kerberos, incluyendo el archivo /etc/krb5.conf file, en el servidor miembro
Creaci�n de la cuenta de la m�quina en el servidor de dominio Active Directory
Asociaci�n del servidor miembro al dominio Active Directory
Para la cuenta de la m�quina y unirse al Active Directory de Windows 2000/2003, primero Kerberos se debe inicializar para el servidor miembro que desea unirse al dominio Active Directory. Para crear un t�quet administrativo Kerberos, escriba el comando siguiente como root en el servidor miembro:
El comando kinit es un script de inicializaci�n que hace referencia a la cuenta administrativa del Active Directory y el reino Kerberos. Puesto que Active Directory requiere de los t�quets Kerberos, kinit obtiene y coloca en cach� los t�quets de Kerberos para la autenticaci�n cliente/servidor. Para m�s informaci�n sobre Kerberos, sobre el archivo /etc/krb5.conf y sobre el comando kinit, consulte el Cap�tulo 19.
Para unir un servidor Active Directory (windows1.example.com), escriba el comando siguiente como root en el servidor miembro:
root# net ads join -S windows1.example.com -U administrator%password
Puesto que la m�quina windows1 se encontr� autom�ticamente en el reino Kerberos correspondiente (el comando kinit fue exitoso), el comando net se conecta al servidor Active Directory usando su cuenta administrativa y contrase�a rerquerida. Esto crea la cuenta de la m�quina en el Active Directory y otorga los permisos para que el servidor miembro Samba se una al dominio.
Nota
Puesto que se utiliza security = ads y no security = user, no se necesita un motor de contrase�as tal como smbpasswd. Los clientes m�s viejos que no soportan security = ads son autentificados como si security = domain estuviese configurado. Este cambio no afecta la funcionalidad y permite a los usuarios locales que no se encontraban previamente en el dominio.
14.3.2.2. Servidor miembro de dominio basado en Windows NT4
El archivo smb.conf siguiente muestra una configuraci�n de ejemplo necesaria para implementar un servidor miembro de dominio basado en Windows NT4. Convertirse en un servidor miembro de un dominio basado en Windows NT4 es similar a conectarse a un Active Directory. La principal diferencia es que los dominios basados en Windows NT4 no utilizan Kerberos en su m�todo de autentificaci�n, haciendo que el archivo smb.conf m�s sencillo. En este caso, el servidor miembro Samba sirve como un pase al servidor de dominio basado en NT4.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
security = domain
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
[public]
comment = Data
path = /export
force user = docsbot
force group = users
guest ok = Yes
Tener un servidor miembro Samba puede ser �til en muchas situaciones. Hay veces en donde el servidor Samba puede tener otros usos adem�s de compartir archivos e impresoras. Puede ser �til hacer Samba un servidor miembro de dominio en casos en los que se requiere utilizar aplicaciones puramente Linux en el entorno del dominio. A los administradores les gusta llevar un seguimiento de todas las m�quinas en el dominio, a�n si no est�n basadas en Windows. En el caso de que el hardware del servidor basado Windows est� descontinuado, es f�cil modificar el archivo smb.conf para convertir el servidor a un PDC basado en Samba. Si los servidores basados en Windows NT son actualizados a Windows 2000/2003, es f�cil modificar el archivo smb.conf para incorporar el cambio de infraestructura a un Active Directory si se necesita.
Importante
Despues de configurar el archivo smb.conf, �nase al dominio antes de iniciar Samba, escribiendo el comando siguiente como root:
root# net rpc join -U administrator%password
Observe que la opci�n -S, que especifica el nombre de host para el servidor de dominio, no necesita especificarse en el comando net rpc join. Samba utiliza el nombre de host especificado por la directriz en el archivo smb.conf en vez de este especificarlo expl�citamente.
14.3.3. Domain Controller
Un controlador de dominio en Windows NT es similar funcionalmente a un servidor NIS, Servicio de Informaci�n de Red (Network Information Service), en un entorno Linux. Los controladores de dominio y los servidores NIS ambos hospedan bases de datos de informaci�n sobre usuarios/grupos as� como tambi�n servicios relacionados. Los controladores de dominioo son utilizados principalmente por seguridad, incluyendo la autenticaci�n de usuarios accediendo a recursos del dominio. El servicio que mantiene la integridad de la base de datos de usuarios/grupos se llama Administrador de Cuentas de Seguridad (Security Account Manager, SAM). La base de datos SAM es almacenada de forma diferente entre sistemas Windows y sistemas Linux basados en Samba, por lo tanto la replicaci�n SAM no se puede lograr y las plataformas no se pueden mezclar en un entorno PDC/BDC.
En un ambiente Samba, solamente pueden existir un PDC y cero o m�s BDCs.
Importante
Samba no puede existir en un ambiente controlador de dominios mixto Samba/Windows, (Samba no puede ser un BCD de un PDC de Windows o viceversa). Alternativamente, los PDCs y BDCs de Samba pueden coexistir.
La implementaci�n m�s simple y com�n de un PDC Samba utiliza el motor de bases de datos de contrase�as tdbsam. Dise�ada para convertirse en el reemplazo del motor smbpasswd, tdbsam tiene varias mejoras que se explican con m�s detalles en la Secci�n 14.5. La directriz passdb backend controla cual motor se utilizar� para el PDC.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
passdb backend = tdbsam
security = user
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/usermod -G %g %u
add machine script = \
/usr/sbin/useradd -s /bin/false -d /dev/null \
-g machines %u
# The following specifies the default logon script
# Per user logon scripts can be specified in the user
# account using pdbedit
logon script = logon.bat
# This sets the default profile path.
# Set per user paths with pdbedit
logon path = \\%L\Profiles\%U
logon drive = H:
logon home = \\%L\%U
domain logons = Yes
os level = 35
preferred master = Yes
domain master = Yes
idmap uid = 15000-20000
idmap gid = 15000-20000
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
writable = Yes
[public]
comment = Data
path = /export
force user = docsbot
force group = users
guest ok = Yes
[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon/scripts
admin users = ed, john, sam
guest ok = No
browseable = No
writable = No
# For profiles to work, create a user directory under the
# path shown. mkdir -p /var/lib/samba/profiles/john
[Profiles]
comment = Roaming Profile Share
path = /var/lib/samba/profiles
read only = No
browseable = No
guest ok = Yes
profile acls = Yes
# Other resource shares
...
...
Nota
Si necesita m�s de un controlador de dominios o tiene m�s de 250 usuarios, no utilice un motor de autenticaci�n tdbsam. En estos casos se recomienda LDAP.
La implementaci�n m�s poderosa y vers�til de un PDC Samba es su habilidad para tener un motor de contrase�as LDAP. LDAP es bastante escalable. Los servidores de bases de datos LDAP se pueden utilizar para redundancia y fail-over mediante su replicaci�n a un BDC de Samba. Los grupos de PDCs y BCDs de LDAP con balanceo de cargas son ideales para un entorno corporativo. Por otro lado, las configuraciones LDAP son por naturaleza complejas de configurar y mantener. Si se va a incorporar SSL con LDAP, la complejidad se multiplica instant�neamente. M�s a�n, con una planificaci�n cuidadosa y precisa, LDAP es una soluci�n ideal para los entornos corporativos.
Tenga en cuenta la directriz passdb backend as� como tambi�n las especificaciones de sufijos LDAP. Aunque la configuraci�n de Samba para LDAP es directa, la instalaci�n de OpenLDAP no es trivial. LDAP deber�a ser instalado y configurado antes de hacer cualquier configuraci�n Samba. Tambi�n tenga en cuenta que Samba y LDAP no necesitan estar en el mismo servidor para que funcione. Se recomienda separarlos sobre todo en un ambiente empresarial.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
passdb backend = ldapsam:ldap://ldap.example.com
username map = /etc/samba/smbusers
security = user
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/usermod -G %g %u
add machine script = \
/usr/sbin/useradd -s /bin/false -d /dev/null \
-g machines %u
# The following specifies the default logon script
# Per user logon scripts can be specified in the
# user account using pdbedit
logon script = scripts\logon.bat
# This sets the default profile path.
# Set per user paths with pdbedit
logon path = \\%L\Profiles\%U
logon drive = H:
logon home = \\%L\%U
domain logons = Yes
os level = 35
preferred master = Yes
domain master = Yes
ldap suffix = dc=example,dc=com
ldap machine suffix = ou=People
ldap user suffix = ou=People
ldap group suffix = ou=Group
ldap idmap suffix = ou=People
ldap admin dn = cn=Manager
ldap ssl = no
ldap passwd sync = yes
idmap uid = 15000-20000
idmap gid = 15000-20000
...
# Other resource shares
...
...
Nota
La implementaci�n de LDAP en este archivo smb.conf asume que se ha instalado exit�samente un servidor LDAP en ldap.example.com.
Un BCD en una parte integral de una soluci�n corporativa Samba/LDAP. Los archivos smb.conf entre el PDC y BDC son virtualmente id�nticos excepto por la directriz domain master. Asegurese de que el PDC tiene un valor de Yes y que el BDC tiene un valor de No. Si tiene varios BDCs para un PDC, es �til la directiva os level para configurar la prioridad de selecci�n del BDC. Mientras m�s alto el valor, m�s alta ser� la prioridad para los clientes que se est�n conectando.
Nota
Un BCD puede utilizar un base de datos LDAP del PDC o tener su propia base de datos LDAP. Este ejemplo utiliza la base de datos del PDC como se ve en la directriz passdb backend.
[global] workgroup = DOCS
netbios name = DOCS_SRV2
passdb backend = ldapsam:ldap://ldap.example.com
username map = /etc/samba/smbusers
security = user
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/usermod -G %g %u
add machine script = \
/usr/sbin/useradd -s /bin/false -d /dev/null \
-g machines %u
# The following specifies the default logon script
# Per user logon scripts can be specified in the
# user account using pdbedit
logon script = scripts\logon.bat
# This sets the default profile path.
# Set per user paths with pdbedit
logon path = \\%L\Profiles\%U
logon drive = H:
logon home = \\%L\%U
domain logons = Yes
os level = 35
preferred master = Yes
domain master = No
ldap suffix = dc=example,dc=com
ldap machine suffix = ou=People
ldap user suffix = ou=People
ldap group suffix = ou=Group
ldap idmap suffix = ou=People
ldap admin dn = cn=Manager
ldap ssl = no
ldap passwd sync = yes
idmap uid = 15000-20000
idmap gid = 15000-20000
...
# Other resource shares
...
...
14.3.3.4. Primary Domain Controller (PDC) con Active Directory
Aunque es posible para Samba ser miembro de un Active Directory, no le es posible operar como un controlador de dominio Active Directory
