JohnH.Terpstra Samba Team <jht@samba.org>
JeremyAllison Samba Team <jra@samba.org>
Gerald(Jerry)Carter Samba Team <jerry@samba.org>
AndrewTridgell Samba Team <tridge@samba.org>
JelmerR.Vernooij The Samba Team <jelmer@samba.org>
GuentherDeschner LDAP updates SuSE <gd@suse.de>
La pertenencia a un dominio es un tema de gran importancia para los administradores de redes. Samba tiene que participar como elemento servidor en el contexto de seguridad de de un dominio local y tiene que poder proporcionar cuentas de máquinas de confianza o si no podría ofrecer una opción viable para muchos usuarios.
En este capítulo encontraremos información sobre la pertenencia a un dominio, la correspondiente configuración de Samba y los prodedimientos de los clientes MSW para unirse al dominio. Esto es necesario para cubrir las grandes lagunas de información que existen al respecto.
Las estaciones de trabajo y servidores MSW que pretenden participar en la seguridad del dominio necesitan ser miembros del mismo. Ls particiàción en la seguridad del dominio con frecuencia se denomina Single Sign On (o SSO para abreviar). Este capítulo describe el proceso que se tiene que seguir para que una estación de trabajo u otro servidor formmen parte de del contexto de seguridad de un dominio MSW.
Samba-3 se puede unir como a un dominio estilo NT4 como miembro servidor, a un dominio MSW Active Directory como un servidor miembro nativo o a una red de Dominio Samba. La pertenencia a un dominio presenta diversas ventajas:
Los usuarios de estaciones de trabajo MSW se benefician del registro en el dominio (SSO.).
Los derechos de acceso y propiedad de los miembros del dominio se pueden definir en la base de datos SAM (Security Account Manager) del dominio. Funciona tanto con serviodores del dominio como con estaciones de trabajo pertenecientes al dominio.
Sólo las versiones Profesionales de la estaciones de tabajo MSW NT4/200x/XP miembros del dominio pueden usar las características de conexión (logon).
Las estaciones de trabajo pertenecientes al dominio se pueden controlar mejor mediante el uso de ficheros de políticas (NTConfig.POL) y perfiles.
Mediante el uso de scripts de conexión los usuarios pueden tener una acceso transparente a la aplicaciones de red albergadas por los servidores.
Los administradores de red consiguen mejorar la gestión de acceso de los usuarios ya que no necesitan mantener cuentas de usuario en cada estación cliente o servidor, salvo la base de datos central del dominio, que puede ser mediante bien mediante una base da datos SAM dominio NT4/Samba, un dominio NT4 Domain soportado por un directorio LDAP o mediante la infrestructura de un an Active Directory.
Una cuenta de máquina de confianza es una cuenta que se utliza para validar una máquina cliente en lugar de a un usuario en un servidor controlador de dominio. En la terminología Windows esto se conoce como cuenta de máquina. El propósito de la cuenta de máquina es prevenir que un usuario no autorizado pueda obtener acceso a una estación de trabajo del dominio.
Esta es una característica de seguridad para prevenir que una máquina no autorizada com el mismo nombr NetBIOS se una al dominio y obtenga acceso a las cuentas de usuario/grupo. Los clientes porfesionales NT/200x/XP utilizan las cuentas de máquina de confianza, sin embargo los clientes W9x/Me/XP Home no lo hacen. En consecuencia los clientes W9x/Me/XP Home nunca serán auténticos miembros del dominio ya que no poseen cuantas de máquina de confianza y por tanto no tienen una contraseña compartida con el controlador de dominio.
Un PDC NT4 almacena cada cuenta de confianza de maquina en el registro. Con la aparición de MSW 2000 surge Active Directory,el nuevo almacenamiento para las cuentas de confianza de máquinas, sin embargo almacena cada cuenta de maquina en dos partes de la siguiente forma:
Una cuenta de seguridad del dominio, almacenada en la base de datos de usuarios definida en smb.conf en el parámetro passdb backend. La naturaleza de la información de la cuenta dependerá del tipo de almacenamiento elegido, smbpassd, tdbsam, ldapsam.
El viejo formato de estos datos es la base de datos smbpasswd que contiene id ID Unix para el login, el identificador de usuario Unix (UID) y las contraseñas LanMan y NT cifradas. También hay alguna otra información que por ahora no nos resulta relevante.
Los dos nuevos tipos de bases de datos se llaman ldapsam, y tdbsam. Ambas almacenan muchos más datos que el viejo fichero. La información extra permite implementar nuevos controles de cuentas de usuario.
Una cuenta Unix asociada, normalmente almacenada en /etc/passwd. Se espera que pronto se pueda prescindir de de las cuentas de usuarios Unix.
Hay tres formas de crear cuentas de usuario:
De forma manual desde la línea de órdenes. Ambas cuentas, la cuenta Unix y la cuenta Samba se crea a mano.
Utilizando la gesión del servidor MSW NT4, bien desde un servidor miembro del dominio o bien utilizandolas herramientas Nexus disponibles en la Web de MS. Esta herramienta se puede utilizar desde cualquier máquina MSW siempre que esté conectado con una cuenta de administrador.
Creación al vuelo. La cuenta de muina de confianza la crea Samba cuando el miembro se une al dominio. Este es el método recomedado por motivos de seguridad. La cuenta unix correspondiente se puede crear automáticamente o manualmente.
El primer paso en la creación manual de las cuentas es la creación de la cuenta Unix en /etc/passwd. Lo podremos hacer utilizando useradd o una herramienta similar o usando vipw:
root# /usr/sbin/useradd -g machines -d /dev/null -c "machine nickname" \ -s /bin/false machine_name$ root# passwd -l machine_name$ |
En el ejemplo anterior suponemos que existe una grupo machines que se usa como grupo primario para las cuentas de máquina. En los siguientes ejemplos el grupo machines tiene un GID igual a 100.
El valor correspondiente en /etc/passwd contendrá el nombre de la máquina terminado en "$", sin contraseña, una shell nula y sin directorio personal. Por ejemplo una máquina llamada ?doppy podría tener una entrada en /etc/passwd similar a:
doppy$:x:505:100: machine_nickname:/dev/null:/bin/false |
El nombre de máquina puede ser algo descriptivo que facilite su identificación, por ejemplo, Sitio_Nombre. El nombre de máquina tiene que ser el nombre NetBIOS del cliente para unirse al dominio. El "$" tiene que añadirse al nombre NetBIOS o Samba no los reconocerá como cuenta de máquina de confianza.
Ahora que se ha creado la cuenta Unix correspondiente, el siguiente paso es crear la cuenta samba para el cliente que contiene la contraseña inicial ce cuenta de confianza. Esto se puede hacer con lar orden smbpasswd de la siguiente forma:
root# smbpasswd -a -m machine_name |
donde machine_name es el nombre NetBIOS de la máquina. El RID de la nueva cuenta de máquina se genera a partir del UID de la correspondiente cuenta Unix.
La creción manual de la cuenta de confianza de máquina usando este método es equivalente a crear una cuenta de confianza de máquina en un PDC NT usando Server Management Tools. Desde el instante de la creación de la cuenta y el instante en que el cliente se une al dominio y cambia la contraseña, el sistema es vulnerable a que un intruso se una al dominio utilizando una máquina con el mismo nombre NetBIOS. Un PDC, por definición, confía en los miembros del dominio y puede proporcionar un buen conjunto de información sobre a esos clientes.
Para crear automáticamente cuentas de confianza de máquinas es básico un script que agregue la máquina. Esto se aplica, no importa si uno usa la creación de cuenta automática o la gestión de Servidor de Dominio NT4.
Si la máquina desde la cual está intentando gestionar el dominio es un estación MSW NT4 o 200x/XP Professional, la herramienta que tiene que escoger es SRVTOOLS.EXE. Cuando se ejecuta, en el directorio destino, descomprimirá SrvMgr.exe y UsrMgr.exe (ambas son herramientas de gestión del dominio para estaciones MSW NT4).
Si su estación es de la familia 9x/Me, debería descargar el paquete Nexus.exe de la web de Microsoft. uando se ejecuta, en el directorio destino, descomprimirá las mismas herramientas per o para estas plataformas.
Mas información sobe estas herramientas en:
|
http://support.microsoft.com/default.aspx?scid=kb;en-us;173673 |
|
http://support.microsoft.com/default.aspx?scid=kb;en-us;172540 |
Lance srvmgr.exe (Server Manager for Domains) y siga estos pasos:
Gestión de cuentas de confianza de máquina del servidor
Del menú seleccione Máquina
Seleccione el dominio
Seleccione el nombre del dominio que quiere a admistrar en el panel Seleccionar Dominio y pulse Aceptar.
De nuevo, seleccione Máquina.
Seleccione Agregar a Dominio
En el cuado de diálogo, haga clic en el botón Añadir Estación NT del servidir, entonces introduzca el nombre de maquina en el campo correspondiente u pulse el botón Agregar.
El segundo método, y recomendado, de creación decuentas de confianza de máquinas es simplmente permitir que el servidor samba las cree cuando lo necesite cuando el cliente se une al dominio.
Como cada cuenta de confianza de máquina de samba necesita una cuenta Unix asociada es necesario proporcionar un método para crearla; para esto es necesario configurar el parámetro de samba add machine script en smb.conf. Sin embar go las cuentas Unix correspondiente también se pueden crear a mano.
Por ejemplo(RedHat)
|
[global] |
|
# <...remainder of parameters...> |
|
add machine script = /usr/sbin/useradd -d /dev/null -g 100 \ |
|
-s /bin/false -M %u |
El procedicmiento para integrar estaciones o servidores MSW como miembros el dominio varía con la versión.
Cuando el usuario quiere hacer cliente un miembreo del dominio, W2000 solicita una cuenta y una contraseña que tengan privilegios par crear cuentas de máquina en el dominio. Se tiene que introducir una cuenta de administrador de Samba (una cuenta Samba con privilegios en el servidor); la operación falla si se introduce una cuenta de usuario ordinario.
Por motivos de seguridad, la cuenta de administrador debería tener una contraseña distinta a la de root en /etc/passwd.
El nombre de la cuenta que se usa para crear cuentas de máquinas miembro, puede ser cualquiera. Si es distinta a root, fácilmente se puede asociar a la de root en el fichero indicado por el parámetro, por ejemplo username map = /etc/samba/smbusers.
La clave de sesión de la cuenta de administrador Samba actúa como clave de cifrado para definir la contraseña de la cuenta de confianza de máquina. La cuenta de confianza de máquina se creará automáticamente o se acutaliza si existe.
Si la cuenta de máquina se ha creado manualmente, introduzca el nombre de dominio en el menú de cambio de identificación, pero no marque en crear cuenta de máquina en el dominio. En este caso se usa la cuenta de confianza de máquina para unir la máquina al dominio.
Si la cuenta de confianza de máquina se crea automáticamente, introduzca el nombre de dominio en el menú de cambio de identificación, y marque en crear cuenta de máquina en el dominio. En este caso, la unión al dominio actúa como en el caso de W2000, es dedir, se pide una cuenta de administrador de Samba.
Este modo de operación del servidor implica que la máquina Samba sea miembro del contexto de seguridad de un dominio. Eso, por definición, significa que todas las validaciones se realizarán de foram centralizada. El mecanismo de validación puede ser estilo NT3/4 o puede ser mediante un servidor Active Directory bajo MSW 2000 o posterior.
Por supuesto, debe quedar claro que el mecanismo último de validación podría ser cualquier arquitectura de servidor de directorios admitida por samba. Puede ser LDAP (de OpenLDAP), iPlanet de Sun, o NetWare Directory Server, u otros.
Cuando samba se configura para utilizar LDAP, u otro servicio de gestión de identidad o de directorio hace que samba continúe realizando validaciones de usuarios y máquinas. Se debe observar qie el servidor LDAP no realiza la validación en lugar de lo que samba estádiseñado para hacer.
Consulte Control del Dominio para más información sobre como crear cuentas de maquina para servidores miembros del dominio y también información sobre como activar la máquina samba miembro del dominio para unirse al dominio y que sea completamente confiable.
La siguiente tabla muestra las lista de nombres que se van a utilizar en el resto del capítulo.
|
Nombre NetBIOS: |
SERV1 |
|
nombre de dominio Windows 200x/NT: |
MIDEARTH |
|
Nombre Netbios del PDC: |
DOMPDC |
|
Nombres Netbios del BDC: |
DOMBDC1 and DOMBDC2 |
Primero tiene que editar el fichero smb.conf para indicar a Samba que utilice la seguridad del dominio.
Cambie (o añada) el parámetro security en la sección [global] de smb.conf para que aparezca:
A continuación modifique el paráemtro workgroup de la sección [global] y ponga:
Este es el nombre del dominio al que nos estamos uniendo.
También tiene que tener el parámetro encrypt passwords puesto a "yes" para que sus usuarios se validen en el PDC NT. Este es el valor predeterminado del parámetro si no se especifica. No hay necesidad de especificar este parámetro, pero si se especifica tiene que tener el valor Yes.
Finalmente, añada o modifique el parámetro password server:
Estos son los controladores primario y secundarios que samba intentará contactar para validar usuarios. Samba intentará contactar en orden, por lo que puede ser intersante reordenar la lista para agilizar la validación entre los distintos controladores de dominio.
De forma alternativa si quiere que smbd determine automáticamente la lista de controladores de dominio puede poner la línea como:
Este método permite a Samba usar exactamente el mismo mecanismo que NT. Este método utiliza una resolución basada en broadcast, una búsqueda WINS o utiliza DNS para localizar el controlador de dominio.
Para unirse al dominio, ejecute:
root# net join -S DOMPDC -UAdministrator%password |
Si no se incluye el argumento -S DOMPDC, el nombre de dominio se obtiene de smb.conf.
La máquina se une al dominio DOM y el PDC del dominio (la única máquina que tiene acceso de escritura en la base de datos SAM del dominio) es DOMPDC, por consiguiente use la opción -S. También Administrator%password son el nombre y la contraseña de la cuenta que dispone de los privilegios necesarios para agregar máquinas al dominio. Si todo es correcto, aparecerá un mensaje con el texto que viene a continuación.
Para el caso de dominios estilo NT4
Joined domain DOM. |
Si se usa Active directory::
Joined SERV1 to realm MYREALM. |
En la página de manual de net podemos encontrar más información.
Este proceso une el servidor al dominio sin tener que crear la cuenta de confianza de máquina en el PDC previamente a mano.
Esta orden se ejecuta a través del protocolo de cambio de contraseña de cuenta de máquina, escribe la nuena contraseña (aleatoria) de máquina para este servidor Saamba en un fichero en el mismo directorio donde se deberia guardar normalmente el fichero smbpasswd:
/usr/local/samba/private/secrets.tdb o /etc/samba/secrets.tdb. |
Este fichero lo crea root y es de su propiedad y ningún otro usuario lo puede leer. Esta es la clave para la seguridad a nivel de dominio se su sisteama y debería protegerse de la misma forma que el fichero de "shadow password".
Por último, reinicie los demonios Samba y está listo para que los clientes empiecen a usar la seguridad del dominio. La forma e reiniciar samba dependerá de la distribución, per en la mayoría de los casos sería suficiente con:
root# /etc/init.d/samba restart |
o
root# /etc/init.d/samba restart |
Actualmente la seguridad del dominio en Samba no leevita tener que crear los usuarios locales UNIX para representar a los usuarios enlazados al servidor. Esto significa que si el usuario del dominio DOM\fred se enlaza a su servidor de seguridad de dominio samba, tiene que haber una cuenta Unix local llamada fred para representar a ese usuario en el sistema de ficheros Unix. Esto es parecido al antiguo sistema de seguridad security = server, donde Samba pasaría la solicitud de validación a Un servidor WNT de la misma forma que lo harían unos W95 o W98.
Mire Winbind, el capítulo de "Uso de cuentas de dominio" para tener más detalles sobre un sistema que asigne automáticamente UID y GID Unix a los usuarios y grupos del WNT.
La ventaja de la seguridad a nivel de dominio es que la validación pasa por el canal de validaciín RPC de la misma forma que lo haría un servidor WNT. Esto quiere decir que los servidores Samba participan en las relaciones de confianza del dominio de la misma forma que lo hacen los servidores WNT, es decir, puede agregar servidores Samba a los recursos de un dominio y tener la validación del recurso del PDC del dominio a una cuenta PDC del dominio.
Además, con security = server, cada demonio samba del servidor tiene que mantener una conexión abierta para validar. Esto puede restar recursos de conexión a un WNT ya agotar la conexiones disponibles. Sin embargo, con security = domain los demonios Samba conectan con el PDC/BDC sólo mientras es necesario para validar al usuario y cierran la conexión, conservando así recursos de conexión el PDC.
Y para terminar, actuando del la misma manera que un servidor WNT validándose en un PDC significa que como parte de la espuesta de validación, el servidor Samba obtiene la informacón de identificación del usuario como el SID, la lista de grupos NT a los que pertenece, etc.
La mayor parte del texto de este documento se publicó como un artículo en "Web magazine LinuxWorld",LinuxWorld como el artículo http://www.linuxworld.com/linuxworld/lw-1998-10/lw-10-samba.html Doing the NIS/NT Samba.
Después aparece con la documentacón incluida con la distribución de samba.
Esto una guía, a grandes resgos, sobre como configurar la validación Samba-3 con Kerberos en un KDC W200X. Se supone al lector famimliarizado con Kerberos.
Al menos debe tener las siguientes opciones en smb.conf: smb.conf:
|
realm = your.kerberos.REALM |
|
security = ADS |
|
# The following parameter need only be specified if present. |
|
# The default setting is not present is Yes. |
|
encrypt passwords = yes |
En caso de que samba no pueda identificar correctamente el servidor ADS adecuado usando el nobre de ámbito (realm), utilice la opción password server en smb.conf:
No es necesario un fichero smbpasswd, y los clientes más antiguos se validarán como si estuviera security = domain, aunque no hará ningún daño y permitirá tener usuarios locales que no están en el dominio.
Con Kerberos de MIT y Heimdal no es necesario configurar /etc/krb5.conf.
Los servidores MS ADS crean automáticamente registros SRV en la zona _kerberos.REALM.NAME DNS para cada KDC del ámbito (realm) Microsoft Active Directory servers automatically create SRV records in the DNS zone _kerberos.REALM.NAME for each KDC in the realm. Esto es parte del proceso de instalación y configuración usado para crear un dominio Active Directory.
Tanto las biblitoecas KRB5 MIT como Heimdal verifican los registros SRV, por tento encontrarán automáticamente el KDC. Además, krb5.conf sólo permite especificar un solo KDC incluso si hay más de uno. Mediante las búsquedas DNS podremosusar cualquier KDC disponible:
Cuando se configura krb5.conf, la configuración mínima es:
[libdefaults]
default_realm = YOUR.KERBEROS.REALM
[realms]
YOUR.KERBEROS.REALM = {
kdc = your.kerberos.server
}
[domain_realms]
.kerberos.server = YOUR.KERBEROS.REALM
|
Si usa versiones de Heimdal previas a 0.6 use la siguiente configuración:
[libdefaults]
default_realm
= YOUR.KERBEROS.REALM
default_etypes
= des-cbc-crc des-cbc-md5
default_etypes_des = des-cbc-crc des-cbc-md5
[realms]
YOUR.KERBEROS.REALM = {
kdc = your.kerberos.server
}
[domain_realms]
.kerberos.server = YOUR.KERBEROS.REALM
|
Verifique su configuración ejecutando kinit USERNAME@REALM y asegurándose que su contraseña la acepta el KDC W2000.
Con las versiones Heimdal anteriores a 0.6.x sólo puede usar cuentas nuevas creadas en ADS o cuentas con la contraseña modificada tras la instalación. Por el momento, el KDC de W2003 sólo se puede usar con versiones de Heimdal posteriores a 0.6. Por desgracia toda el área está en modificación.
El realm tiene que ir en mayúsculas o aparecera el mensaje de error kerberos Cannot find KDC for requested realm while getting initial credentials. Kerberos distingue entre mayúsculas y minúsculas.
La hora entre servidores tiene que estar sincronizada. Obtendrá kinit(v5): "Clock skew too great while getting initial credentials" si la diferencia es mayor a cinco minutos.
Las desviaciones del reloj se pueden configurar en le protocolo kerberos; el valor predeterminado es cinco minutos.
La forma más fácil de asegurarse de que esto va a funcionar es añadir una línea en /etc/hosts asociando la dirección IP del KDC con el nombre NetBIOS. Si no hace esto correctamente aparecerá un error cuando trate de unir el realm.
The easiest way to ensure you get this right is to add a /etc/hosts entry mapping the IP address of your KDC to its NetBIOS name. If you do not get this correct then you will get a local error when you try to join the realm.
Si sólo quiere soporte Kerberos en smbclient entonces puede ir directamente a la verificaciones smbclient ahora. La creación la cuenta de máquina y las verificaciones de la configuración del servidor sólo son necesarias si quiere soporte Kerberos para smbd y winbindd.
Ejecute lo siguiente con un usuario, normalmente root, que tenga permisos en el directorio privado (private) de samba:
root# net ads join -U Administrator%password |
Cuando cree un cliente Windows miembro de un dominio ADS con una organización compleja, le puede interesar la cuenta de máquina en una unidad organizativa especial. Samba-3 lo permite utilizando la siguiente sintaxis:
root# kinit Administrator@your.kerberos.REALM root# net ads join "organizational_unit&" |
Por ejemplo, puede querer crear una cunta de máquina en un contenedor llamado Servers bajo el directorio organizativo Computers\BusinessUnit\Department de esta forma:
root# net ads join "Computers\BusinessUnit\Department\Servers" |
Hay que reconfigurar Samba (borrar config.cache) y recompilar (make clean all install) una vez que las bibliotecas y ficheros de cabecera Kerberos estén instalados.
Tiene que identifiarse en le dominio usando kinit USERNAME@REALM. USERNAME tiene que ser un usuario que tenga permisos para añadir una máquinaal dominio.
Asegúrese de que /etc/krb5.conf está configurado corerctamente para los tipo y versión de kerberos instalado en el sistema.
Si la unión al dominio ha sido correcta verá unanueva cuenta de máquina con el nombre NetBIOS del servidor Samba en Active Directory (en la carpeta Máquinas bajo Usuarios y máquinas).
En un cliente W2000, intente net use * \\server\share. Debería conectarse con with Kerberos sin necesidad de contraseña. Si falla ejecute klist tickets. ¿Ha obtenido un ticket para el servidor? ¿Tiene cifrado DES-CBC-MD5?
Intente iniciar una sesión desde su servidor samba en un servidor W2000 o su servidor samba usando smbclient y Kerberos. Use smbclient de la forma habitual, pero especifique la opción -k para elegir la validación Kerberos.
Tiene que cambiar la contrasela del administrador al menos una vez tras la instalación del controlador de dominio para crear los tipos de cifrado correctos.
W2000 parece no crear las configuraciones DNS predeterminadas _kerberos._udp y _ldap._tcp. Quizás esto se corrija en próximos service packs.
Samba asocia usuarios UNIX y grupos (identificados por UID y GID) con usuarios y grupos Windows (identificados por SID). Estas asociacione la realiza el subsistema idmap de Samba.
En algunos casos es útil compartir estas asociaciones entre miembros Samba del dominio, así la asociación nombre->id es idéntica en todas la máquinas. Esto puede ser necesario en paarticular cuando comparte ficheros a travñes de CIFS y NFS.
Para usar ldap idmap suffix de LDAP ponga:
Vea la página de manual de smb.conf y consulte el parámetro "ldap idmap suffix para más detalles.
No olvide especificar también ldap admin dn y asegúrese de que la contraseña administrativa de ldap está en secrets.tdb usando:
root# smbpasswd -w ldap-admin-password |
En el proceso de añadir/borrar/volver a añadir cuentas de máquina del dominio hay muchas trampas en las que se puede caer y pequeñas cosas que peden ser erróneas. Es particularmente interesante con qué frecuencia los suscriptores de las lista de Samba han llegado a la conclusión, tras repetidos intentos de añadir una cuenta de máquina que es necesaria, de que es necesario reinstalar MSW en la máquina. En realidad es raramente necesario reinstalar a causa de ste tipo de problemas. La solución real es con frecuencia bastante simple y si no se entienden bien las funciones de red de MSW el probable que esto suceda.
Se ha reinstalado unaestación de trabajo del dominio. La cuenta de máquina del dominio original se eliminó y se agregó inmediatamente. La estación de trabajo no se une al dominio si se usa el mismo nombre de máquina. Los intentos de añadir la máquina fallan si uso el mismo nombre de máquina con un mensaje que indica que la máquina ya existe en la red.
Esto se debe a que el nombre original aun está en la cache de nombres NetBIOS y tiene que expirar tras el borrado de la cuenta antes de poder añadir el nuevo nombre como miembreo del dominio. Lo mejor es borrar la anterior cuenta y añador la máquina con un nuevo nombre.
El fallo al agregar máquinas W200x/XP Professional al PDC Samba del dominio produce un mensaje similar la 'La máquina no se pudo agrgar al dominio en este momento, hay un problema de red, inténtelo más tarde'.
Debería comprobar que hay un parámetro add machine script en el fichero smb.conf. Si no existe, incorpórelo de forma apropiada para su sistema. Si se ha definido un script, tendrá que depurar su ejecución. Incremente log level en the smb.conf a nivel 10, entonces intente de nuevo la operación. Observe los logs para ver que operación está fallando.
Las posibles causas incluyen:
* El script no existe o puede que no esté en la ruta especificada.
Corrección: Asegúrese de ejecutarlo manualmente y que crea las cuentas unix y SAM de Samba.
* La máquina no se puede añadir al fichero /etc/passwd de cuentas del sistema UNIX.
Corrección: Verifique que eñl nombre de máquina es un nombre UNIX legal. Si se llama a useradd asegúrese que el nombre de máquina se puede añadir con esta herramienta. Useradd, en algunos sistemas no permiten ni mayúsculas ni espacios.