Arreglar ‘La relación de confianza entre la estación de trabajo y el dominio principal falló’

Una vez que los problemas más comunes que afectan a los administradores del sistema de Windows se consideran confiables, las computadoras del Active Directory parecen desconectarse del dominio. El infame error “la relación de confianza entre esta estación de trabajo y el dominio principal ha fallado” es demasiado común.

En esta guía, aprenderás todos los trucos que he descubierto en mis más de 20 años administrando Active Directory y cómo automatizarlo con PowerShell.

La relación de confianza entre esta estación de trabajo y el dominio principal ha fallado” Mensaje de error

Cuando un dominio de AD ya no confía en una computadora, es probable que sea porque la contraseña de la computadora local no coincide con la contraseña almacenada en Active Directory.

The Trust Relationship Between This Workstation and the Primary Domain Failed

Las dos contraseñas deben estar sincronizadas para que AD confíe en una computadora. Si no están sincronizadas, recibirás el infame mensaje de error “la relación de confianza entre esta estación de trabajo y el dominio principal ha fallado”.

Desafortunadamente, nunca ha habido una solución única que yo y otros administradores de sistemas hayamos encontrado que funcione el 100% del tiempo. Por eso escribí esta guía.

Esta guía pretende ser un repositorio único para cada forma de resolver este problema de una vez por todas y automatizar el proceso con PowerShell.

Contraseñas de cuentas de computadoras en Active Directory

Cuando se agrega una nueva computadora al Directorio Activo, se crea una cuenta de computadora con una contraseña. Esa contraseña es válida por 30 días de forma predeterminada. Después de 30 días, cambia automáticamente. Si cambia y la contraseña del cliente no lo hace, obtendrá el mensaje de error “La relación de confianza entre esta estación de trabajo y el dominio principal ha fallado”.

Visualización de las políticas existentes

Puede ver la política en todo el dominio abriendo la Consola de Administración de directivas de grupo (GPMC). Dentro de GPMC, haga clic en la Directiva de dominio predeterminada y navegue a Configuración del equipo –> Configuración de Windows –> Configuración de seguridad > Directivas locales > Opciones de seguridad.

Una vez en Opciones de seguridad, busque la directiva llamada Periodo máximo de la contraseña de la cuenta de máquina de miembro del dominio.

Computer Account Password Age Policy

En una computadora unida a AD, abra el regedit y navegue a la clave del registro HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters y encuentre el valor MaximumPasswordAge como se muestra a continuación.

Local Computer Account Password Age Registry Value

Mientras esté allí, puede desactivar que la computadora local cambie la contraseña en absoluto estableciendo el valor DisablePasswordChange en 1.

Cuando cambia la cuenta de computadora, tanto la computadora local como la cuenta de computadora AD deben cambiar sus contraseñas juntas. AD conoce la actual y la anterior en caso de que se desincronicen durante un breve período.

El proceso de cambio de contraseña de la cuenta de computadora

Cuando las cosas funcionan normalmente, utilizando el servicio Netlogon de Windows, la computadora inicia automáticamente un cambio de contraseña. Esto ocurre durante un reinicio de la computadora o cuando el objeto de la computadora necesita autenticarse en AD.

Usando el servicio Netlogon de Windows, la computadora local inicia una secuencia de cambio de contraseña. La computadora primero inicia un cambio de contraseña en un controlador de dominio. Si eso es exitoso, luego intenta cambiar la contraseña local para que coincida dentro de la clave del registro HKLM\SECURITY\Policy\Secrets<hostname>.ACC.

Normalmente este proceso funciona muy bien incluso si la computadora se apaga o está sin conexión durante más de 30 días porque la computadora local inicia un cambio de contraseña.

Sin embargo, surge un problema cuando:

  • la computadora cambia la cuenta de equipo AD pero no puede cambiar la contraseña local
  • la computadora se reimagen sin ejecutar Sysprep
  • el sistema operativo se reinstala y está intentando autenticarse con la cuenta de equipo AD antigua y habilitada
  • … ¿y más?

Si ocurre alguno de los casos anteriores, verá el mensaje de error “la relación de confianza entre esta estación de trabajo y el dominio principal ha fallado”.

Verificando el problema

Una vez que sabe que el problema existe, ¿cómo lo replica o al menos tiene un método para determinar qué computadoras tienen el problema? Puede intentar iniciar sesión interactivamente en cada computadora, ¡pero eso no es escalable y no quiero levantarme de mi escritorio!

Vamos a construir un script que podamos ejecutar tanto local como remotamente para determinar qué computadoras en el dominio tienen este problema y erradicar el mensaje de error “la relación de confianza entre esta estación de trabajo y el dominio principal ha fallado” de una vez por todas.

En primer lugar, dado que estás asumiendo que la autenticación de dominio no está funcionando, necesitarás conocer una cuenta de usuario local en el grupo de administradores. ¡Espero que conozcas la contraseña de tu administrador local!

nltest (Herramienta de línea de comandos)

nltest es una herramienta de línea de comandos clásica que probará la relación de confianza de una computadora. Esta herramienta se instala cuando instalas RSAT o está disponible directamente en un controlador de dominio.

Puedes verificar una relación de confianza en una computadora cuando estás conectado a ella ejecutando:

> nltest /sc_verify:<your domain FQDN>

ADVERTENCIA: Este método no se recomienda porque nltest solo funciona en el contexto de usuario en el cual fue lanzado. Si la computadora tiene una relación de confianza rota y estás conectado como un usuario local, intentará conectar al dominio usando las credenciales del usuario local. Esto resultará en un error de acceso denegado.

netdom (Herramienta de línea de comandos)

netdom es otra herramienta de línea de comandos que puedes utilizar para verificar una relación de confianza. Esta herramienta también se instala cuando instalas RSAT o está disponible directamente en un controlador de dominio.

Puedes verificar una confianza utilizando netdom verify proporcionando:

  • el nombre de la computadora a verificar
  • FQDN del dominio
  • nombre de usuario para autenticar la solicitud
  • contraseña de la cuenta de usuario

A continuación, se muestra un ejemplo:

> netdom verify MYCOMPUTER /Domain:domain.local /UserO:abertram /PasswordO:*

Al proporcionar el valor de * al parámetro PasswordO, netdom solicitará la contraseña.

Test-ComputerSecureChannel (PowerShell)

Una de las mejores maneras de resolver el problema “la relación de confianza entre esta estación de trabajo y el dominio principal ha fallado” es utilizar el cmdlet Test-ComputerSecureChannel. Este cmdlet de PowerShell viene con Windows 10 y es más fácil de usar.

El cmdlet Test-ComputerSecureChannel funciona localmente en una computadora con Windows 10. Cuando estás conectado a la computadora de forma interactiva, abre una consola de PowerShell y ejecuta Test-ComputerSecureChannel sin ningún parámetro. Devolverá True o False dependiendo de si la confianza es válida.

PS51> Test-ComputerSecureChannel
True

También puedes especificar un controlador de dominio en particular para confirmar que las contraseñas estén sincronizadas usando el parámetro Server.

PS51> Test-ComputerSecureChannel -Server 'DC.domain.local'
False

Este cmdlet es fácil de usar y tiene una opción de Repair, pero dejaremos la demostración de eso para la sección de reparación.

Si conoces la contraseña del administrador local de esas computadoras que deseas verificar y la Remotización de PowerShell está habilitada en ellas, también puedes usar el cmdlet Invoke-Command. Al usar el cmdlet Invoke-Command, puedes ejecutar de forma remota Test-ComputerSecureChannel en una o muchas computadoras a la vez.

PS51> Invoke-Command -ComputerName PC1, PC2, PC3 -ScriptBlock { Test-ComputerSecureChannel }

Verificación de Relaciones de Confianza en Masa

Ahora que sabes cómo verificar remotamente una relación de confianza, ¡aquí tienes un fragmento de código que puedes usar para verificar todos tus computadoras AD! En este script, primero estoy probando para asegurarme de que la computadora esté en línea. Si no lo está, devolverá Offline. Si lo está, ejecutará Test-ComputerSecureChannel en cada computadora y devolverá True o False.

Testing trust relationships in bulk
$localCredential = Get-Credential @(Get-AdComputer -Filter *).foreach({ $output = @{ ComputerName = $_.Name } if (-not (Test-Connection -ComputerName $_.Name -Quiet -Count 1)) { $output.Status = 'Offline' } else { $trustStatus = Invoke-Command -ComputerName $_.Name -ScriptBlock { Test-ComputerSecureChannel } -Credential $localCredential $output.Status = $trustStatus } [pscustomobject]$output })

Saber y entender el problema es el primer paso, pero ¿cómo lo solucionas? Ahora sabes que necesitas que la cuenta de computadora almacenada en la computadora local sea la misma que la cuenta de computadora almacenada en AD.

Hay muchas “soluciones” disponibles para el problema de “la relación de confianza entre esta estación de trabajo y el dominio principal ha fallado”. Estas soluciones se pueden realizar a través de la interfaz gráfica, mediante PowerShell o utilizando herramientas de línea de comandos más tradicionales.

  1. Restablecer la contraseña de la cuenta de la computadora en el Directorio Activo
  2. Restablecer la contraseña de la cuenta de la computadora local
  3. Desvincular y volver a unir la computadora con Windows
  4. Eliminar completamente la cuenta de la computadora y volver a unir la computadora con Windows

¡Son muchas opciones! En esta guía, nos centraremos en solucionar este problema con PowerShell y herramientas de línea de comandos (por completitud). ¡Si aún no estás utilizando PowerShell, deberías empezar!

Resolviendo el problema: Restableciendo contraseñas de computadora

netdom (Herramienta de línea de comandos)

A trust can be repaired and the “the trust relationship between this workstation and the primary domain failed” error message can be eliminated by using the old-school netdom command-line tool. If you’re logged into the computer locally as an administrative user, you can run netdom resetpwd to initiate the password reset sequence as shown below.

En este ejemplo:

  • DC es el nombre del controlador de dominio
  • abertram es el nombre de la cuenta de usuario de Active Directory con derechos para restablecer la cuenta de la computadora
  • * es un marcador de posición para la contraseña de la cuenta de usuario, la cual se solicitará.
> netdom resetpwd /s:DC /ud:abertram /pd:*

Reset-ComputerMachinePassword (PowerShell)

Una de las mejores maneras de solucionar un problema de relación de confianza es mediante el uso del cmdlet Reset-ComputerMachinePassword. Este cmdlet se ejecuta en la computadora local e iniciará una secuencia de restablecimiento de contraseña. Su sintaxis no podría ser más sencilla.

PS51> Reset-ComputerMachinePassword

Si deseas especificar un controlador de dominio en particular para restablecer, puedes hacerlo utilizando el parámetro Server junto con una opción de credencial (se usará la del usuario local por defecto).

El siguiente ejemplo solicitará un nombre de usuario y contraseña de AD e intentará restablecer la contraseña en la computadora local y en el controlador de dominio DC.

PS51> Reset-ComputerMachinePassword -Server DC -Credential (Get-Credential)

Esto también se puede ejecutar de forma remota utilizando Invoke-Command si PowerShell Remoting está disponible en la computadora. A continuación, estoy obteniendo el nombre de usuario y la contraseña de la cuenta de administrador local en la computadora. También estoy obteniendo las credenciales que tienen derechos para restablecer la contraseña de la cuenta AD de esta computadora. Luego, paso $domainCredential a la sesión remota utilizando el constructo $using.

$localAdminCredential = Get-Credential
$domainCredential = Get-Credential

PS51> Invoke-Command -Computername MYCOMPUTER -Credential $localAdminCredential -ScriptBlock { Reset-ComputerMachinePassword -Server DC -Credential $using:domainCredential }

Tenga en cuenta que esto también funciona incluso si se ha eliminado la cuenta de computadora de Active Directory. Crear una cuenta de computadora con el mismo nombre y Reset-ComputerMachinePassword asegurará que la contraseña esté sincronizada.

Restablecimiento de contraseñas de cuentas de computadora local a granel

¿Quieres ocuparte del error “la relación de confianza entre esta estación de trabajo y el dominio principal ha fallado” en varias computadoras a la vez? No hay problema. Utilizando un práctico bucle foreach, también podemos ejecutar Reset-ComputerMachinePassword a granel.

Resetting computer account passwords in bulk
$localAdminCredential = Get-Credential $domainCredential = Get-Credential @(Get-AdComputer -Filter *).foreach({ $output = @{ ComputerName = $_.Name } if (-not (Test-Connection -ComputerName $_.Name -Quiet -Count 1)) { $output.Status = 'Offline' } else { $pwChangeOutput = Invoke-Command -Computername $_.Name -Credential $localAdminCredential -ScriptBlock { Reset-ComputerMachinePassword -Server DC -Credential $using:domainCredential } $output.PasswordChangeOutput = $pwChangeOutput } [pscustomobject]$output })

Test-ComputerSecureChannel -Repair (PowerShell)

Otra forma de iniciar el proceso de cambio de contraseña es ejecutar Test-ComputerSecureChannel, pero esta vez utilizando la opción Repair. Por lo que puedo decir, este proceso es idéntico al uso de Reset-ComputerMachinePassword. En la consola de la computadora, utiliza el parámetro Repair y el parámetro Credential.

PS51> Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Asegúrate de siempre usar el parámetro Credential aquí. Si no lo haces, al igual que con la utilidad nltest, intentará usar la cuenta local y no funcionará.

Reparar Relaciones de Confianza en Masa

Introduce este comando en el práctico bucle foreach que hemos estado utilizando ¡y listo!

Resetting computer account passwords in bulk
$localAdminCredential = Get-Credential $domainCredential = Get-Credential @(Get-AdComputer -Filter *).foreach({ $output = @{ ComputerName = $_.Name } if (-not (Test-Connection -ComputerName $_.Name -Quiet -Count 1)) { $output.Status = 'Offline' } else { $repairOutput = Invoke-Command -Computername $_.Name -Credential $localAdminCredential -ScriptBlock { Test-ComputerSecureChannel -Repair -Credential $using:domainCredential } $output.RepairOutput = $repairOutput } [pscustomobject]$output })

Resolviendo el Problema: Volver a Unirse al Dominio

Si restablecer las contraseñas de las cuentas de computadora no funciona para ti, siempre está la opción nuclear. Puedes volver a unir una computadora al dominio de Active Directory. Aunque no es necesario todo el tiempo, ha habido ocasiones en las que he tenido que usar este enfoque.

Nota que he escuchado algunos informes de que no es necesario desvincular. Puede que puedas solucionarlo simplemente forzando una nueva unión. Tu experiencia puede variar.

podrías:

  • iniciar sesión en la computadora a través de una cuenta administrativa local
  • ir a Propiedades del Sistema
  • hacer clic en Cambiar
  • configurarlo para un grupo de trabajo
  • reiniciar
  • configurarlo nuevamente para el dominio

Nota cómo menciono que podrías. No hagas esto. Es una pérdida de tiempo cuando puedes automatizarlo con PowerShell.

Hay dos formas que he encontrado para usar PowerShell para desvincular un dominio y usar PowerShell para unirse a un dominio.

Usando CIM

Puedes unirte a un dominio con PowerShell (y desvincularlo) usando la clase CIM Win32_ComputerSystem. Esta clase tiene dos métodos que te permiten desvincular y unir una computadora a un dominio llamados UnJoinDomainOrWorkgroup() y JoinDomainOrWorkGroup.

Dado que esto es CIM, puedes ejecutarlo tan fácilmente de forma remota como localmente. Dado que supongo que preferirías ejecutarlo de forma remota desde la comodidad de tu escritorio, aquí tienes un fragmento de código que hace justo eso.

¡Adiós al error “la relación de confianza entre esta estación de trabajo y el dominio principal ha fallado”!

$computername = 'PITA'

$instance = Get-CimInstance -ComputerName $computername -ClassName 'Win32_ComputerSystem'

$invCimParams = @{
    MethodName = 'UnjoinDomainOrWorkGroup'
    Arguments = @{ FUnjoinOptions=0;Username="Administrator";Password="mypassword" }
}
$instance | Invoke-CimMethod @invCimParams

Observa el parámetro FUnjoinOptions arriba. He elegido especificar 4 aquí. Esto realiza el comportamiento predeterminado al desvincular manualmente una computadora. Esta opción deshabilita la cuenta de computadora en Active Directory (si puede encontrar una). Si prefieres no tener este comportamiento, puedes usar la opción 0 aquí.

Una vez que la computadora está desvinculada, puedes unirte al dominio utilizando el método JoinDomainOrWorkGroup().

$computername = 'PITA'

$instance = Get-CimInstance -ComputerName $computername -ClassName 'Win32_ComputerSystem'

$invCimParams = @{
    MethodName = 'JoinDomainOrWorkGroup'
    Arguments = @{ FJoinOptions=3;Name=mydomain.local;Username="mydomain\domainuser";Password="mypassword" }
}
$instance | Invoke-CimMethod @invCimParams

Observa el parámetro FJoinOptions arriba. He elegido especificar 3 aquí. Esto realiza el comportamiento predeterminado al unir manualmente una computadora. Esta opción crea una cuenta de computadora AD. Puedes encontrar algunas otras opciones como agregar a una OU específica a través de la documentación JoinDomainOrWorkgroup.

CONSEJO: También puedes desunir y volver a unir muchas computadoras a la vez mediante este método especificando múltiples computadoras a través del parámetro ComputerName en Get-CimInstance.

Usando los Cmdlets Remove-Computer y Add-Computer

También puedes usar los cmdlets integrados de PowerShell para desunir y unir una computadora a un dominio con PowerShell. Puedes usar los cmdlets Remove-Computer y Add-Computer.

Para desvincular una computadora con PowerShell, inicia sesión en la consola de la computadora y utiliza el cmdlet Remove-Computer. Proporciona las credenciales de dominio con permisos para desvincular la computadora. También puedes especificar el parámetro Restart para forzar un reinicio después de la desvinculación y Force para no solicitar confirmación.

PS51> Remove-Computer -UnjoinDomaincredential (Get-Credential) -Restart -Force

Una vez que la computadora se haya reiniciado, puedes usar el cmdlet Add-Computer para unir la computadora al dominio con PowerShell. Puedes utilizar el cmdlet Add-Computer de forma remota proporcionando el parámetro ComputerName. También utilizarás credenciales de usuario locales para hacer la conexión y credenciales de dominio para autenticarte en el dominio.

Cuando vuelva a estar en funcionamiento, esperemos que ya no recibas el mensaje de error “la relación de confianza entre esta estación de trabajo y el dominio principal ha fallado”.

$localCredential = Get-Credential
$domainCredential = Get-Credential

Add-Computer -ComputerName PITA -LocalCredential $localCredential -DomainName domain.local -Credential $domainCredential -Restart -Force

Desvinculación y Vinculación Automágica al Dominio

Debido a que tuve que realizar este proceso muchas veces, creé un script de PowerShell que hace todo por ti. Si le proporcionas el nombre de la computadora, hará lo siguiente:

  • Desvincular la computadora
  • Reiniciar y esperar a que vuelva a estar en funcionamiento
  • Unir la computadora
  • Reiniciar y esperar a que vuelva a estar en funcionamiento

Puedes probar este script en GitHub.

Resumen

Deberías tener ahora una comprensión completa del problema y múltiples soluciones para el infame mensaje de error “La relación de confianza entre esta estación de trabajo y el dominio principal ha fallado“. Espero que esta guía te haya proporcionado algunas ideas y te haya permitido encontrar algunas soluciones por tu cuenta al problema de las computadoras que se caen del dominio.

Lecturas adicionales

Asegúrate de consultar algunos otros mensajes relacionados

Source:
https://adamtheautomator.com/the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/