Las sesiones de dominio o red se tratan aquí porque forman una parte integral de la funcionalidad esencial proporcionada por un controlador de dominio.
Todos los controladores de dominio tienen que ejecutar el servicio netlogon (domain logons en Samba). Un controlador de dominio se tiene que configurar con domain master = Yes (el controlador primario de dominio), en todos los controladores secundarios (BDC) hay que poner fdomain master = No.
Ejemplo 5.2. smb.conf para un PDC
|
[global] |
|
domain logons = Yes |
|
domain master = (Yes en PDC, No en BDC) |
|
[netlogon] |
|
comment = Network Logon Service |
|
path = /var/lib/samba/netlogon |
|
guest ok = Yes |
|
browseable = No |
Par dejarlo todo absolutamente claro: si quiere integrar MS Windows XP Home Edition en su sistema de seguridad de dominio MS Windows NT4 o Active Directory, entienda que esto no se puede hacer. La única opción es adquirir la actualización de MS Windows XP Home Edition a MS Windows XP Professional.
MS Windows XP Home Edition no tiene la posibilidad de unirse al sistema de seguridad de cualquier tipo de dominio. A diferencia de does not have the ability to join any type of Domain Security facility. Como MS Windows 9x/Me, MS Windows XP Home Edition también carece completamente de la capacidad de registrarse en una red.
Una vez dicho esto, por favor no pregunte el la lista de correo ni envíe correos a los miembros del Samba Team sobre como se hace esto funcionar. Esto no se puede hacer. Si se pudiera hacer, hacerlo supondría una violación del acuerdo de licencia de Microsoft y le recomendamos que no lo haga.
En téminos de apariencia de la red, un grupo de trabajo y un dominio son lo mismo. La diferencia es que en un dominio existe una base de datos de validación distribuida para sesiones seguras en la red. También, se pueden ofrecer a los usuarios diferentes derechos de acceso si se validan en un servidor de sesiones. Samba-3 hace esto de la misma forma que un MS Windows NT/200x.
Las conexiones clientes SMB en un dominio esperan que cualquier otro servidor del dominio acepte la misma información de validación. Las funciones para examinar la red del dominio y del grupo de trabajo son idénticas y se explican en este documento en las discusiones sobre el examen de la red.
Las características relativas al modelo de sesión simple de red se tratan en esta sección. El objetivo de esta sección son el soporte Samba de siones de dominio, de red, scripts de conexión y perfiles de usuario para grupos de trabajo y clientes MS Windows 9X/ME.
Cuando un cliente SMB de un dominio quiere iniciar una sesión hace una petición de difusión para localizar un servidor de sesiones. El primero en responder realiza el trabajo, valida la contraseña usando cualquiera de los mecanismos instalados por el administrador de Samba. Es posible crear un dominio donde la base de datos de usuarios no está compartida entre servidores, es decir, son de foram efectiva servidores de grupos de trabajo anunciándose a sí mismos como partícipes de un dominio. Esto demuestra como la validación es completamente diferente pero íntimamente asociada con los dominios.
Usando esta característica puede hacer que sus clientes verifiquen su sesión mediante un servidor Samba; hacer que los clientes ejecuten un fichero por lotes condo inicien la sesión de red y carguen sus preferencias, escritorio y menú inicio.
La versión MS Windows XP Home no puede unirse a un dominio y no permite el uso de sesiones de red.
Antes de entrar en las instrucciones de configuración, es mejor mirar como los clientes Windows 9x/Me realizan la sesión:
El cliente realiza una petición de difusión NetLogon (a la dirección broadcast de la subred en la que esté). Se envía al nombre NetBIOS DOMAIN en la capa NetBIOS. El cliente escoge la primera respuesta que reciba, la cual contiene el nombre NetBIOS del servidor de sesiones para usar de la forma \\SERVER.
El cliente se conecta con ese servidor, se registra (hace un SMBsessetupX) y se conecta al recurso IPC$ (usando un SMBtconX).
El cliente realiza un petición NetWkstaUserLogon que recupera el nombre del script de conexión del usuario.
Entonces el cliente se conecta al recurso NetLogon y busca dicho script. Si lo encuentra, y lo puede leer, el cliente lo ejecuta. Después es cliente se desconecta del recurso NetLogon.
El cliente envía una petición NetUserGetInfo al servidor para obtener el directorio personal del usuario que se usa para buscar los perfiles. Como la respuesta a la petición NetUserGetInfo no contiene nada más que el directorio personal del usuario, los perfiles para clientes Windows 9x tienen que guardarse en el directorio personal.
El cliente se conecta al directorio personal y busca el perfil del usuario. The client connects to the user's home share and searches for the user's profile. Se puede especificar el directorio personal del usuario como nombre y ruta. Por ejemplo \\server\fred\.winprofile. Si se encuentran los perfiles, se activan. If the profiles are found, they are implemented.
Entonces el cliente desconecta del usuario personal y vuelve a conectar con el NetLogon y busca CONFIG.POL, el fichero de políticas. Si encuentra este fichero lo lee y lo activa.
Para un servidor desesiones Windows 9x/Me no se necesitan contraseñas cifradas. Pero observe que empezando con MS Windows 98 la configuración predeterminada de contraseñas en texto plano está desactivada. Se puede reactivar con unos cambios en el registro, documentados en Políticas de sistema y cuentas.
Los clientes Windows 9x/Me no necesitan y no utilizan cuentas de confianza de máquina.
No es nunca aconsejable utilizar contraseñas sin cifrar. Si se utilizan, sepueden detectar fácilmente mediante un sniffer que examine el tráfico de la red.
Hay algunos comentarios que hacer para atar los cabos sueltos. Ha habido muchos debates sobre si es correcto configurar Samba como PDC en un modo de seguridad distinto a user. El único modo de seguridad que no funciona debido a razones técnicas es share. El dominio y el modo de seguridad son realmente una variación del nivel de seguridad User.
Efectivamente, esta características está íntimamente asociada al debate sobre si Samba tiene que ser el examinadoar principal para su grupo de trabajo cuando opera como controlador de dominio. Mientras puede ser técnicamente posible configurar un servidor de esa forma (después de todo, examinar y las sesiones en el dominio son dos funciones diferentes y ditintas), no es buena idea hacerlo. Debería recordar que el controlador de dominio tiene que registar el nombre netbios del dominio. Este es el nombre que usan los clientes Windows para localizar al controlador del dominio. Los clientes Windows no distinguen entre el controlador del dominio y el DBM. Un DBM es el examinador principal del dominio (Domain Master Browser), vea la sección Configurar examen del grupo de trabajo. Por este motivo es aconsejable configurar el controlador de dominio Samba como el DMB.
Ahora volvemos a la configuración del controlador de dominio Samba para usar un modo de seguridad distinto a security = user. Si un host Samba se configura para usar otro servidor SMB o controladoar de dominio para que valide las peticiones de conexión de los usuarios, implica que alguna otra máquina de la red sabe más de los usuarios que el propio host Samba. Sobre el 99% del tiempo este otro host es un controlador de dominio. Ahora para operar en modo de seguridad dominio, el parámetro workgroup se tiene que poner con el nombre del dominio Windows NT (que ya tiene un controlador de dominio). Si el dominio todavía no tiene un controlador de dominio, entonces no tiene un dominio.
Configurar un SAmba como controlador de dominio en un dominio que que ya, por definición, tiene un PDC es estar buscando problemas. Por esto, debería siempre configurar el controlador de dominio Samba para que sea el DMB de su dominio y poner security = user. Este es el único modo de operación oficialmente admitido.