14.3. Tipos de servidores Samba y el archivo smb.conf

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.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:

root# kinit [email protected]

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.1. Primary Domain Controller (PDC) usando tdbsam

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.

14.3.3.2. Primary Domain Controller (PDC) usando 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.

14.3.3.3. Backup Domain Controller (BDC) usando LDAP

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