Voy a escribir un art�culo en el que se trata de
hacer que un linux corriendo samba haga de servidor como Controlador
Primario de Dominio.
La raz�n por la que escribo esto estriba en que he tenido varios problemas
a la hora de configurarlo, y mi deseo consiste en que no os pase a vosotros
lo mismo.
La cuesti�n no es balad� pues hay que tener configurado nuestro samba
no solo con las caracter�sticas habituales para usarlo en una red de
windows diferentes (95, 98, 2000 etc) sino que adem�s hay que ``retocar''
varias cosas m�s.
Este art�culo seguir� los siguientes pasos:
- Configurar unas cuantas opciones por defecto en samba
- Configurar samba como PDC en el fichero smb.conf
- Crear las cuentas de confianza de las m�quinas que tenemos en
la red.
- Configurar las estaciones de trabajo para que se ``autentiquen''
con el PDC
Empezamos pues
2 Configurar opciones por defecto
Aqu� poco vamos a colocar, s�mplemente vamos a darle
un nombre al servidor y al grupo de trabajo, adem�s vamos a crear
un recurso ``homes'' para que los usuarios vean su directorio home
cuando se conecten .
global
netbios name = servidor
workgroup = grupo
wins support = yes
homes
writable = yes
browseable = no
En la primera opci�n le ponemos nombre netbios al
servidor. Si teneis DNS ponedle el mismo nombre que el que figura
en el dns, sin la coletilla del dominio DNS.
En la segunda opci�n le decimos a samba que pertenezca
al grupo de trabajo ``grupo''. Este dato es importante que lo tengamos
en cuenta, pues a la hora de ajustar los clientes, el dominio se va
a llamar ``grupo'', que es el mismo que el etiquetado en workgroup.
La opci�n wins support = yes es de propina. Que samba
haga de soporte wins no perjudica a nadie y a samba no le cuesta nada,
adem�s es recomendado para que act�e de PDC.
El recurso homes, no home, no hay que confundirse,
es un recurso especial pues si est� presente hacemos que los usuarios
accedan a su directorio home en el servidor.
Decimos que browseable = no para que no se vean en
los Windows dos recursos: homes y la carpeta del usuario apuntando
los dos al mismo contenido.
La opci�n writable = yes es para que se pueda escribir
y crear elementos en el recurso, pues samba por defecto hace los recursos
no escribibles y, en consecuencia, solo lectura.
3 Configurar Samba como PDC
Para ello debemos:
- Hacer que sea visualizador maestro local y de dominio en la
red.
- Poner la seguridad a nivel de usuario
- Soportar las passwords encriptadas
- La m�s importante: decirle a samba que �l es el PDC
- Adem�s no estar�a de m�s crear el servicio (recurso m�s bien)
netlogon aunque no es estrictamente necesario.
3.1 Visualizador maestro
Un visualizador maestro de dentro de una red windows
sirve para proporcionar informaci�n a los dem�s sobre dos aspectos:
- qu� puestos hay en la red windows
- qu� recursos ofrecen esos puestos a los dem�s.
Esta facilidad puede soportarla cualquier windows
integrado en la red. No es necesario que sea un server. Para ser
visualizador maestro solamente se requiere que le toque al equipo
de marras.
Nosotros vamos a hacer que esta visualizaci�n le toque a nuestro
Samba siempre.
Pare ello debemos a�adir las l�neas siguientes a la secci�n
global:
os level = 64
preferred master = yes
domain master = yes
local master = yes
Pero �cuidado! porque debemos asegurarnos de que no exista ning�n
otro PDC en la red, y tampoco debe haber en la red ning�n visualizador
maestro de dominio. Si somos los �nicos, no hay problema, pero vigilad
de forma concienzuda si hay alg�n servidor w2000 server, o WNT server
o algo peor; en caso de que existan no les dejeis que hagan de visualizadores,
porque de lo contrario habr� problemas a la hora de ver qu� equipos
existen en la red y sus recursos.
La opci�n os level hace referencia a la informaci�n del sistema
operativo que ofrece Samba. Me explico: cuanto mayor sea este
n�mero m�s avanzado pensar�n los demas windows que es el SO de
Samba. Para citar un ejemplo si pusieramos el n�mero 34, los windows
pensar�n que se trata de un Windows NT. Es decir, que con este
n�mero enga�amos miserablemente a los puestos sobre la versi�n
(windows) de nuestro SO.
Las opciones prefered, domain y local master hacen referencia
de que se prefiera a este servidor como visualizador maestro de
dominio, local y master sucesivamente.
3.2 Poner la seguridad a nivel de usuario
Esta parte es f�cil.
Samba tiene cuatro niveles de seguridad: recurso, usuario, servidor
y domain.
La seguridad a nivel de usuario quiere decir que el usuario cuando
se autentica en el cliente solo tiene acceso a lo que se le deje
tener. En contraposici�n a nivel de recurso significa que se tiene
acceso al recurso cuando pinchando en este desde windows y una vez
iniciada la sesi�n, se nos pide la clave. Si conocemos la clave
(seamos quien seamos) entraremos al recurso, si no la conocemos,
no entraremos. A nivel de servidor y a nivel de dominio es lo mismo
que a nivel de usuario con la diferencia que cuando iniciamos la
sesi�n quien nos autentica es un servidor (no el samba) o un PDC
(tampoco el mismo que samba).
Basta a�adir en la secci�n global esto:
security = user
Y con esto ya est�.
3.3 Soportar las passwords encriptadas
Es lo m�s correcto. Las passwords pueden dar vueltas
por la red interna encriptadas o no. Le decimos que encriptadas para
que nadie las esnife.
Se escribe esto, simplemente:
encrypt passwords = yes
Pero aprovecho este p�rrafo para a�adir y comentar c�mo se crean
usuarios samba.
Para crear un usuario debemos crearlo anteriormente como usuario
unix y, posteriormente darle una contrase�a para samba.
adduser usuario
Nos crea un usuario unix, y
smbpasswd -a usuario
Nos crea un usuario samba, que servir� para que los puestos nos
autentiquen contra esta contrase�a. Mi recomendaci�n es que la contrase�a
que creemos en windows sea la misma que la que tengamos en samba
¿de acuerdo? As� nos quitamos l�os de encima.
Luego volver� a repetir lo que voy a decir ahora: debemos crear
una cuenta de root en samba para que despu�s agreguemos el cliente
al dominio.
smbpasswd -a root
Luego indicamos la contrase�a dos veces.
Despu�s de agregar todas las m�quinas al dominio �borra esa cuenta
de root!, elimina esa l�nea del usuario root que aparecer� en el
fichero smbpasswd. Es m�s, en la opci�n global ``invalid users =
usuarios inv�lidos'' poner por si las moscas a root y dem�s usuarios
que no pertenezcan exclusivamente al dominio de esa red. S�mplemente
lo digo porque no nos va a apetecer que alguien ande enredando como
root (u otro usuario de sistema) por nuestra querida red.
3.4 La m�s importante: decirle a samba que �l es el PDC
Esta es facilita. En la secci�n global a�adir:
domain logons = yes
Con esto el servidor samba dice a la red que �l es el PDC.
3.5 Crear el servicio (recurso m�s bien) netlogon
Este servicio sirve para ejecutar diversos scripts
cuando se conecta un windows al servidor. Los scripts son peque�os
programas ``por lotes'' escritos desde windows para ejecutar en windows.
Digo que hay que escribirlos en windows por las diferentes formas
de entender los retornos de carro de un sistema operativo a otro.
Y digo que se ejecuta en windows porque se trata de sencillas instrucciones
(p.e. ponte en hora con respecto al servidor o net time \\nombre_netbios_servidor_o_IP
/set /yes ) que solo entiende MSWindows.
En la secci�n global se escribe esto:
logon script = netlogon.bat
Y se crea un recurso llamado netlogon:
netlogon
path = /home/netlogon
read only = yes
En el path copiamos el fichero netlogon.bat construido por nosotros.
Si este fichero no existe, no importa pues samba sigue leyendo su
configuraci�n.
De esta forma cuando se conecta alguien, se ejecuta el script
netlogon.bat y ejecuta lo que deseemos (o podamos) en el cliente.
Solamente un apunte m�s. Este recurso NO es estrictamente necesario
para que funcione la cosa (el PDC), pero me quiero curar en salud
pues en todos los manuales que he visto me colocan esta secci�n
como si fuera indudable su uso.
4 Crear las cuentas de confianza de las m�quinas que tenemos en
la red.
Aqu� empezamos con el cogollo de la cuesti�n.
Resulta que para crear un dominio windows (es decir grupo de trabajo
+ PDC) en caso de clientes NT, W2000 y XP pro hay que crear lo que
se llama cuentas de confianza de las m�quinas.
Esas cuentas de confianza es algo que podr�amos definir como ``esta
m�quina y esta otra est�n en mis dominios''. No solamente los usuarios
se autentican y se tienen en cuenta, sino que tambi�n las mismas
m�quinas han de ser tenidas en cuenta.
Para ello hay que crear usuarios en Linux con el nombre netbios
de las clientes seguidos del s�mbolo de dolar.
Lo explico por pasos.
- Crearemos un grupo, y para evitar l�os, con el mismo nombre
que le hemos puesto en el smb.conf en la opci�n workgroup:
- Hay que crear un usuario Unix con el nombre netbios de la m�quina
y (ojo con esto) seguido del s�mbolo dolar, sin shell, sin directorio
home e integrado en un grupo. El nombre de la m�quina es el que
figura en el cliente en Panel de Control -> Sistema - Nombre
de equipo. Imaginemos el grupo que se llama grupo y la m�quina
se llame m�quina
adduser -g grupo -d /dev/null -s /dev/null
-c ``cliente XP'' maquina$
Si observamos el fichero /etc/password, veremos una entrada que
empieza por maquina$ que es la cuenta de la m�quina.
- Hay que crear la cuenta de confianza a�adiendo a smbpasswd la
m�quina:
Observa con cuidado que aqu� no hace falta poner el s�mbolo de
d�lar. Hay que indicar, eso s�, que se trata de una m�quina (la
opci�n -m). No va a pedir contrase�as.
Si hay m�s m�quinas, pues lo mismo para cada una de ellas.
Con todo esto ya est� hecho el trabajo en lo que respecta
al servidor.
5 Configurar las estaciones de trabajo para que se ``autentiquen''
con el PDC
5.1 Preparar el cliente
Esta es la parte m�s diferenciada con respecto a clientes W2000,
WNT y W98/95.
Resulta que WXP home no puede integrarse en un dominio Windows.
En cambio el XP profesional s�.
Hay que hacer y comprobar los siguientes pasos:
- Ir a Panel de Control -> Herramientas Administrativas ->
Directivas de Seguridad local y mirar Directivas Locales ->
Opciones de seguridad
- Miembro de dominio: descifrar o firmar digitalmente datos de
un canal seguro (siempre): Deshabilitar
- Miembro de dominio: Deshabilitar cambios password en cuenta
m�quina -> deshabilitar
- Miembro de dominio: Requerir clave de sesi�n protegida (W2000
o m�s reciente) -> deshabilitar
- Cambiar una cosilla del registro. Esto merece comentario aparte.
Hay un archivo en /usr/share/doc/samba.XXXX/docs/Registry/
que se llama WinXP_SignOrSeal.reg. Este archivo lo guardamos
en un diskette y en cada cliente le damos dos clicks para que
se agregue su informaci�n al registro de windows.
Simplemente cambia esta l�nea del registro dej�ndola as�:
5.2 Agregar el cliente al dominio.
Vamos a Panel de Control -> Sistema y pinchamos
en la pesta�a ``Nombre del equipo''
Vereis una descripci�n del equipo. Pues escrib�s lo que dese�is.
Pinch�is en el bot�n ``Cambiar''
Nombre del equipo: en nuestro ejemplo maquina.
Miembro de: elegimos dominio.
El nombre del dominio es el nombre ``WorkGroup'' del archivo smb.conf.
Le damos a aceptar y nos pide un usuario y una contrase�a.
Esto me dio guerra.
Hay que poner root (s� root) y la contrase�a de root del servidor.
Nos dar� la bienvenida.
Una cosa: el usuario root tiene que estar agregado en el fichero
smbpasswd, para que el cliente pueda autenticarlo y as� tenerlo
en el dominio, pero agregad root solamente para esta cuesti�n, luego
(una vez configurada toda la red) es recomendable borrarlo, porque
¿no querremos que exista un usuario samba que se llame root?¿verdad?
a partir de all� root no tiene que estar agregado a smbpasswd. No
s� si repetirlo m�s veces ... si: root NO tiene que estar agregado
a smbpasswd.
Con todo esto tiene que funcionar.
6 Agradecimientos
A mis alumnos: que me hacen moverme por mundos
en los que no deseo moverme y que si no fuera por ellos yo no hubiera
instalado un Windows XP ni de broma para probar esto.
A mi esposa: que no se por qu� obscura raz�n no deja de una vez
de utilizar Windows.