none
The security Database on the server does not have a computer account for this workstation trust relationship RRS feed

  • Pregunta

  • El dominio es un dominio W2000 pero todos los DC están en W2003. Se planea actualizarlos a W2008, subiendo el nivel del dominio a W2008.

    Pero, actualmente, el problema es el siguiente.

    Tenemos muchas máquinas con W2003, y W2008, alguna queda con W2000 Server. Además, están los clientes.

    Nuestro problema surge con una máquina W2008r2 Enterprise Edition. Esta máquina se creo con una IP y nombre (NetBios) pepitonew (existe otra máquina pepito, que ha de ser sustituida por esta). Se renombró pepito a pepitoold (por si existe necesidad de marcha atrás). Al cambiar la IP y el nombre de la máquina a pepito, con la IP de pepito (pepito old recibe una IP nueva), parece que todo va bien. se reinicia el sistema, y al ir a logarse con un usuario de dominio:

    The security Database on the server does not have a computer account for this workstation trust relationship

    surge el mensaje anterior. Hemos intentado volver a sacarlo, hemos hecho cierta limpieza en los DCS eincluso, sacado la máquina nueva del dominio, ejecutado Sysprep, vuelto a introducir en el dominio, pero continuamos con el problema.

    Si volvemos a ponerle el nombre pepitonew, nos podemos logar dentro de la máquina con usuarios del dominio, pero no nos permite con pepito a secas.

    Intuyo que el problema es una falta de entendimiento entre la base de datos de la SAM con la de AD.

    Alguna idea?

    El servidor aparece en AD, y los DNS lo reconocen (Nslookup...).

    miércoles, 30 de marzo de 2011 10:55

Respuestas

  • Pues no, no es cosa del WINS, te cuento la solución:

    Es un problema que sucede sólo con Windows 2008, con W2003 no sucede:

    -          Comprobamos cuantos SPNs existían asociados al servidor PEPITO con el siguiente comando:

     

    C:\ >ldifde -f check_SPN.txt -t 3268 -d "" -l servicePrincipalName -r "(servicePrincipalName=host/pepito.dominio*)" -p subtree

     

    -          Eliminaron la entrada HOST/PEPITO.dominio del usuario administrador de CRM (que se vio que tenía SPN duplicados) y aunque seguía sin entrar en dominio el mensaje era distinto: error de confianza entre la máquina y el dominio. La solución fue resetear la contraseña de la cuenta de máquina:

     

    C:\ >netdom resetpwd /s:pepito /ud:administrator /pd:*

    Type the password associated with the domain user:

     

     

    -          Después de ejecutar este comando ya pudimos entrar en dominio.

     Con lo que definitivamente, quedó solucionado. Con una solución semejante a la que se ve en el link que cito anteriormente.



    jueves, 31 de marzo de 2011 9:48

Todas las respuestas

  • Lo que indican amablemente en este otro post, ya lo hemos probado:

    http://social.technet.microsoft.com/Forums/es-ES/windowsserveres/thread/fb7e8b28-4196-4b4c-b28a-940b867706ab

    No funciona.

    No es problema del Firewall de Windows (bajado), y tampoco parece serlo de los Firewalls de la red.

    El AD registra correctamente los SPN, aparece su entrada cuando se llama SPN. Pero no es cierto... incluso aparecen los nombres de las instancias de MS SQL Server.

    miércoles, 30 de marzo de 2011 11:16
  • Hola Octavio, normalmente ese error se produce cuando se des-sincroniza la contraseña de la cuenta de máquina con el dominio. Y la solución pasa por, sacarla a grupo de trabajo, eliminar la cuenta de máquina en el AD (o Reset), y luego volverla a unir al dominio.

    Cuando ejecutas Sysprep es como si estuvieras creando una máquina nueva, ya que cambia el SID de la misma, y por lo tanto es lógico el mensaje de error

    Quizás el problema venga por la información "cacheada" de nombre e IP anteriores, en los DNSs o en los clientes. Yo comenzaría revisando en los DNSs (todos si hubiera más de uno) que esté la registración nueva, y no la vieja. Borraría la cache DNS de los servidores (botón derecho sobre el servidor en la consola DNS, o reiniciando el servicio)

    Descarto que dicha máquina está apuntando como DNSs *exclusivamente* a los DNSs internos que resuelve el AD ¿si?

    También a tener en cuenta, cuando se renombran máquinas, y más en este caso donde una reemplaza a otra, hay que darle tiempo para que se elimine la información "cacheada"

     


    Guillermo Delprato - Buenos Aires, Argentina
    Visite Notas Windows Server
    MVP-MCT-MCSE-MCSA MCITP: Enterprise/Server Administrator MCTS: Active Directory/Network/Applications Configuration
    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.
    miércoles, 30 de marzo de 2011 11:25
    Moderador
  • Gracias Guillermo,

    Efectivamente, esa máquina apunta a los DNS del dominio. Pero lo de revisar DNS ya lo hemos hecho, pues hemos mirado varios de arriba abajo tanto el dominio como el servidor en cuestión.

    Evidentemente le ha debido quedar cacheada información del nombre viejo, pues entiendo que aquí es donde está el problema, pero me temo que es más a nivel de máquina que del AD.

    La máquina ha salido a Workgroup n veces, pues es otra de las cosas que hemos probado. Como cuando hicimos Sysprep.

    Incluso cambiamos los nombres de Instancia, para que no quedara la reminiscencia MS SQL, en dicho servidor. Sysprep nos hizo peroder la conectividad con los discos de la cabina. No se si esto es normal, pero no nos ha pasado otras veces (ej: clonando máquinas virtuales de plantilla).

    miércoles, 30 de marzo de 2011 13:15
  • Separemos temas que con el tema de SQL no me entiendo mucho :-)
    Para eso creo que lo mejor sea que plantees el caso en el foro de SQL

    De todas formas, entiendo que el mensaje de la "trust relationship" lo está dando entre la máquina y el dominio al tratar de iniciar sesión con un usuario de dominio ¿si?

    Veo que hay cliente de varias versiones ¿hay WINS? Cuando pones el nombre de dominio a unir ¿usas el nombre DNS?

    El procedimiento para Sysprep es: sacarla a grupo de trabajo, sysprep, y luego re-unirla al dominio

     


    Guillermo Delprato - Buenos Aires, Argentina
    Visite Notas Windows Server
    MVP-MCT-MCSE-MCSA MCITP: Enterprise/Server Administrator MCTS: Active Directory/Network/Applications Configuration
    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.
    miércoles, 30 de marzo de 2011 14:48
    Moderador
  • Pues te cuento, el dominio tiene Wins, pero es reminiscencia.

    Este dominio es un dominio con varias subredes. con diversos entornos y con subdominios, con clientes y servidores con SO diversos.

    así es como hicimos sysprep

    Lo del SQL es para que tengas una idea sobre que hay otras cosas en el servidor que hacen referencia a otro nombre de máquina.

    y como dices, el problema se da al logarse en la máquina como usuario de dominio. lo hemos probado con el administrador del dominio y con otros usuarios, con diversos niveles. Incluso hemos creado usuarios nuevos para probar.

    miércoles, 30 de marzo de 2011 16:03
  • Te vuelvo a preguntar ahora con más razón sabiendo que hay WINS. Cuando ponen el nombre de dominio para unir ¿usan el nombre DNS?

    Porque aunque me dices que has revisado que queden rastros en el DNS, podrían haber quedado en el WINS

     


    Guillermo Delprato - Buenos Aires, Argentina
    Visite Notas Windows Server
    MVP-MCT-MCSE-MCSA MCITP: Enterprise/Server Administrator MCTS: Active Directory/Network/Applications Configuration
    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.
    miércoles, 30 de marzo de 2011 17:24
    Moderador
  • Pues no, no es cosa del WINS, te cuento la solución:

    Es un problema que sucede sólo con Windows 2008, con W2003 no sucede:

    -          Comprobamos cuantos SPNs existían asociados al servidor PEPITO con el siguiente comando:

     

    C:\ >ldifde -f check_SPN.txt -t 3268 -d "" -l servicePrincipalName -r "(servicePrincipalName=host/pepito.dominio*)" -p subtree

     

    -          Eliminaron la entrada HOST/PEPITO.dominio del usuario administrador de CRM (que se vio que tenía SPN duplicados) y aunque seguía sin entrar en dominio el mensaje era distinto: error de confianza entre la máquina y el dominio. La solución fue resetear la contraseña de la cuenta de máquina:

     

    C:\ >netdom resetpwd /s:pepito /ud:administrator /pd:*

    Type the password associated with the domain user:

     

     

    -          Después de ejecutar este comando ya pudimos entrar en dominio.

     Con lo que definitivamente, quedó solucionado. Con una solución semejante a la que se ve en el link que cito anteriormente.



    jueves, 31 de marzo de 2011 9:48
  • Gracias Octavio por compartir la solución

     


    Guillermo Delprato - Buenos Aires, Argentina
    Visite Notas Windows Server
    MVP-MCT-MCSE-MCSA MCITP: Enterprise/Server Administrator MCTS: Active Directory/Network/Applications Configuration
    Este mensaje se proporciona "como está" sin garantías de ninguna clase. Usted asume todos los riesgos.
    jueves, 31 de marzo de 2011 11:59
    Moderador
  • De nada, de esto se trata, no? muchas gracias por tu ayuda Guillermo ;-)
    jueves, 31 de marzo de 2011 14:55