Исправление ошибки ‘Ошибка доверительного отношения между рабочей станцией и основным доменом’ – techsyncer

Одной из наиболее распространенных проблем, с которыми сталкиваются администраторы систем Windows, является сбой доверия между компьютерами Active Directory и доменом. Известная ошибка “сбой доверия между рабочей станцией и основным доменом” встречается слишком часто.

В этом руководстве вы узнаете все трюки, с которыми я столкнулся в своей 20-летней работе с Active Directory, и как автоматизировать их с помощью PowerShell.

Сообщение об ошибке “Сбой доверия между рабочей станцией и основным доменом“

Если домен AD больше не доверяет компьютеру, вероятно, это происходит из-за того, что пароль на локальном компьютере не совпадает с паролем, хранящимся в Active Directory.

The Trust Relationship Between This Workstation and the Primary Domain Failed

Для того, чтобы домен AD доверял компьютеру, два пароля должны быть синхронизированы. Если они не совпадают, вы получите известное сообщение об ошибке “сбой доверия между рабочей станцией и основным доменом”.

К сожалению, до сих пор не существует единственного решения, которое бы работало на 100% всех случаев. Вот почему я написал это руководство.

Цель этого руководства – собрать все способы решения этой проблемы одним местом и автоматизировать процесс с помощью PowerShell.

Пароли учетных записей компьютеров в Active Directory

При добавлении нового компьютера в Active Directory создается учетная запись компьютера с паролем. По умолчанию этот пароль действителен в течение 30 дней. По истечении 30 дней он автоматически изменяется. Если пароль изменяется, а пароль клиента нет, то возникает ошибка “связь между этой рабочей станцией и основным доменом не удалась”.

Просмотр существующих политик

Вы можете просмотреть политику, действующую во всем домене, открыв Консоль управления групповыми политиками (GPMC). Внутри GPMC нажмите на Политика по умолчанию для домена, а затем перейдите в Конфигурация компьютера –> Настройки Windows –> Параметры безопасности > Локальные политики > Параметры безопасности.

Перейдите в Параметры безопасности и найдите политику с названием Включенный в домен: Максимальное время действия пароля учетной записи компьютера.

На компьютере, присоединенном к AD, откройте редактор реестра (regedit) и перейдите к ключу реестра HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. Найдите значение MaximumPasswordAge, как показано ниже.

Local Computer Account Password Age Registry Value

Пока вы там, вы можете запретить локальному компьютеру изменять пароль вообще, установив значение DisablePasswordChange равным 1.

Когда меняется учетная запись компьютера, как локального компьютера, так и учетной записи компьютера AD, должны изменить пароль вместе. AD знает текущий и предыдущий пароль для случаев, когда они на короткое время становятся несинхронными.

Процесс смены пароля учетной записи компьютера.

Когда все работает нормально, используется служба Netlogon Windows, компьютер автоматически инициирует изменение пароля. Это происходит при перезагрузке компьютера или когда объект компьютера должен проходить аутентификацию в AD.

Используя службу Netlogon Windows, локальный компьютер инициирует последовательность изменения пароля. Сначала компьютер инициирует изменение пароля на контроллере домена. Если это успешно, то затем компьютер пытается изменить локальный пароль так, чтобы он совпадал с паролем в реестре HKLM\SECURITY\Policy\Secrets<hostname>.ACC.

Обычно этот процесс работает отлично, даже если компьютер выключен или находится в автономном режиме более 30 дней, потому что локальный компьютер инициирует изменение пароля.

Однако возникает проблема, когда:

компьютер меняет учетную запись компьютера AD, но не может изменить локальный пароль
компьютер переобразовывается без запуска Sysprep
ОС переустанавливается и пытается проходить аутентификацию с помощью старой, активированной учетной записи компьютера AD
…и так далее?

Если происходит что-либо из вышеперечисленного, вы увидите сообщение об ошибке “связь между рабочей станцией и основным доменом была прервана”.

Проверка проблемы

Как только вы узнаете о существовании проблемы, как ее воспроизвести или хотя бы определить, с какими компьютерами возникает проблема? Вы можете попробовать войти в каждый компьютер интерактивно, но это не масштабируемо, и я не хочу вставать со своего стола!

Давайте создадим скрипт, который можно запустить как локально, так и удаленно, чтобы определить, какие компьютеры в домене имеют эту проблему, чтобы окончательно избавиться от сообщения об ошибке “отношение доверия между этим рабочим местом и основным доменом не удалось”.

Прежде всего, поскольку вы предполагаете, что аутентификация в домене не работает, вам нужно будет знать локальную учетную запись пользователя в группе администраторов. Надеюсь, вы знаете пароль вашего локального администратора!

nltest (Консольная утилита)

nltest – это старомодная консольная утилита, которая проверяет отношение доверия для компьютера. Этот инструмент устанавливается при установке RSAT или доступен напрямую на контроллере домена.

Вы можете проверить отношение доверия на компьютере, выполнив вход на компьютер и запустив:

> nltest /sc_verify:<your domain FQDN>

ПРЕДУПРЕЖДЕНИЕ: Этот метод не рекомендуется, потому что nltest работает только в контексте пользователя, в котором он был запущен. Если у компьютера нарушено доверие, и вы вошли в систему как локальный пользователь, он попытается подключиться к домену, используя учетные данные локального пользователя. Это приведет к ошибке доступа отклонено.

netdom (Консольная утилита)

netdom – это еще один инструмент командной строки, который вы можете использовать для проверки доверительных отношений. Этот инструмент также устанавливается при установке RSAT или доступен непосредственно на контроллере домена.

Вы можете проверить доверие, используя netdom verify, предоставив:

имя компьютера для проверки
FQDN домена
имя пользователя для аутентификации запроса
пароль учетной записи пользователя

Приведен пример:

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

Предоставив значение * параметру PasswordO, netdom запросит пароль.

Test-ComputerSecureChannel (PowerShell)

Один из лучших способов решить проблему “доверительные отношения между этим рабочим местом и основным доменом не удалось” – использовать cmdlet Test-ComputerSecureChannel. Этот cmdlet PowerShell поставляется с Windows 10 и более прост в использовании.

Cmdlet Test-ComputerSecureChannel работает локально на компьютере с операционной системой Windows 10. При входе в систему интерактивно откройте консоль PowerShell и выполните команду Test-ComputerSecureChannel без параметров. Возвращаемое значение будет True или False в зависимости от того, является ли доверие действительным.

PS51> Test-ComputerSecureChannel
True

Вы также можете указать конкретный контроллер домена для подтверждения синхронизации паролей, используя параметр Server.

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

Эта команда проста в использовании и имеет опцию Repair, но мы сохраним демонстрацию этой опции для раздела по исправлению.

Если вы знаете пароль локального администратора для тех компьютеров, которые вы хотите проверить, и на них включено удаленное выполнение PowerShell, вы также можете использовать команду Invoke-Command. Используя команду Invoke-Command, вы можете удаленно запустить команду Test-ComputerSecureChannel на одном или нескольких компьютерах одновременно.

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

Проверка доверительных отношений массово

Теперь, когда вы знаете, как удаленно проверить доверительное отношение, вот фрагмент кода, который вы можете использовать для проверки всех ваших компьютеров AD! В этом скрипте я сначала проверяю, находится ли компьютер в сети. Если нет, возвращается значение Offline. Если компьютер находится в сети, выполняется команда Test-ComputerSecureChannel на каждом компьютере, и возвращается значение True или 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
 
})

Знание и понимание проблемы – это первый шаг, но как ее исправить? Теперь вы знаете, что вам необходимо сделать так, чтобы учетная запись компьютера, хранящаяся на локальном компьютере, была такой же, как учетная запись компьютера, хранящаяся в AD.

Есть много различных “решений” для проблемы “the trust relationship between this workstation and the primary domain failed”. Эти решения могут быть выполнены через графический интерфейс, через PowerShell или с использованием старых инструментов командной строки.

Сброс пароля учетной записи компьютера в AD
Сброс пароля локальной учетной записи компьютера
Отключение и повторное подключение компьютера с Windows
Полное удаление учетной записи компьютера и повторное подключение к компьютеру с Windows

Много вариантов! В этом руководстве мы сосредоточимся на решении этой проблемы с помощью PowerShell и инструментов командной строки (для полноты). Если вы еще не используете PowerShell, вам стоит начать!

Исправление проблемы: сброс паролей компьютеров

netdom (Инструмент командной строки)

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.

В этом примере:

DC – имя контроллера домена
abertram – имя учетной записи пользователя Active Directory с правами на сброс пароля учетной записи компьютера
* – заполнитель для пароля учетной записи пользователя, который вызовет запрос пароля.

> netdom resetpwd /s:DC /ud:abertram /pd:*

Reset-ComputerMachinePassword (PowerShell)

Один из лучших способов исправить доверительные отношения – использовать cmdlet Reset-ComputerMachinePassword. Этот cmdlet запускается на локальном компьютере и инициирует последовательность сброса пароля. Его синтаксис прост в использовании.

PS51> Reset-ComputerMachinePassword

Если вы хотите указать конкретный контроллер домена для сброса, вы можете указать его с использованием параметра Server вместе с учетными данными (по умолчанию используются учетные данные локального пользователя).

Пример ниже попросит ввести имя пользователя и пароль AD и попытается сбросить пароль на локальном компьютере и контроллере домена DC.

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

Это также можно запустить удаленно, используя Invoke-Command, если удаленный PowerShell доступен на компьютере. Ниже я получаю имя пользователя и пароль для локальной учетной записи администратора на компьютере. Я также получаю учетные данные, которые имеют права сбросить пароль учетной записи AD этого компьютера. Затем я передаю $domainCredential в удаленную сессию, используя конструкцию $using.

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

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

Обратите внимание, что это также работает, даже если учетная запись компьютера была удалена из Active Directory. Создайте учетную запись компьютера с тем же именем, и Reset-ComputerMachinePassword обеспечит синхронизацию пароля.

Сброс паролей учетных записей локального компьютера массово

Хотите решить проблему “несоответствия доверия между этим рабочим местом и основным доменом”? Нет проблем. Используя удобный цикл foreach, мы также можем запускать Reset-ComputerMachinePassword массово.

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)

Другой способ начать процесс смены пароля – выполнить Test-ComputerSecureChannel, но на этот раз использовать опцию Repair. По всей видимости, этот процесс идентичен использованию Reset-ComputerMachinePassword. На консоли компьютера используйте параметры Repair и Credential.

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

Обязательно используйте параметр Credential здесь. Если этого не сделать, аналогично утилите nltest, она попытается использовать локальную учетную запись и не сработает.

Восстановление доверительных отношений массово

Добавьте эту команду в удобный foreach-цикл, который мы уже использовали, и все будет в порядке!

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
 
})

Исправление проблемы: Повторное присоединение к домену

Если сброс паролей учетных записей компьютера для вас не работает, всегда есть ядерный вариант. Вы можете повторно присоединить компьютер к домену Active Directory. Хотя это не всегда необходимо, были случаи, когда мне приходилось прибегать к этому подходу.

Обратите внимание, что я слышал о некоторых отчетах, что отсоединение не обязательно. Возможно, вам удастся обойтись простым принудительным присоединением. Ваш опыт может отличаться.

Вы можете:

войти в систему через локальную учетную запись администратора
перейти в Свойства системы
нажать Изменить
установить его в рабочую группу
перезагрузить
установить обратно в домен

Заметьте, как я упоминаю, что можете. Не делайте этого. Это трата вашего времени, когда вы можете автоматизировать это с помощью PowerShell.

Существуют два способа, которые я нашёл, чтобы использовать PowerShell для отключения от домена и присоединения к домену.

Используя CIM

Вы можете присоединиться к домену с помощью PowerShell (и отключиться от него), используя класс CIM Win32_ComputerSystem. Этот класс имеет два метода, которые позволяют отключиться и присоединить компьютер к домену, называемые UnJoinDomainOrWorkgroup() и JoinDomainOrWorkGroup.

Поскольку это CIM, вы можете запустить это так же легко удаленно, как и локально. Поскольку я предполагаю, что вы предпочли бы запустить это удаленно, находясь в удобстве своего стола, вот фрагмент кода, который делает именно это.

Ошибка “доверительное отношение между этой рабочей станцией и основным доменом не удалось” исчезнет!

$computername = 'PITA'

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

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

Обратите внимание на параметр FUnjoinOptions выше. Я выбрал здесь указать 4. Это выполняет поведение по умолчанию при отключении компьютера вручную. Этот вариант отключает учетную запись компьютера в Active Directory (если он может её найти). Если вам не хочется такого поведения, вы можете использовать здесь вариант 0.

После того как компьютер будет отключен от домена, вы можете присоединить его к домену, используя метод 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

Обратите внимание на параметр FJoinOptions выше. Здесь я выбрал указать 3. Это выполняет поведение по умолчанию при присоединении компьютера вручную. Эта опция создает учетную запись компьютера в AD. Вы можете найти еще несколько вариантов, например, добавление в определенную организационную единицу через документацию JoinDomainOrWorkgroup.

СОВЕТ: Вы также можете отсоединить и снова присоединить множество компьютеров за один раз с помощью этого метода, указав несколько компьютеров через параметр ComputerName на Get-CimInstance.

Использование Cmdlets Remove-Computer и Add-Computer

Вы также можете использовать встроенные cmdlet PowerShell для отсоединения и присоединения компьютера к домену с помощью PowerShell. Вы можете использовать cmdlet Remove-Computer и Add-Computer.

Для отключения компьютера с помощью PowerShell войдите на консоль компьютера и используйте командлет Remove-Computer. Укажите учетные данные домена с разрешениями на отключение компьютера. Вы также можете указать параметр Restart, чтобы принудительно перезагрузить компьютер после отключения, и параметр Force, чтобы не запрашивать подтверждение.

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

После перезагрузки компьютера вы можете использовать командлет Add-Computer для присоединения компьютера к домену с помощью PowerShell. Вы можете использовать командлет Add-Computer удаленно, указав параметр ComputerName. Вы также будете использовать учетные данные локального пользователя для соединения и учетные данные домена для аутентификации в домене.

Когда компьютер снова включится, надеюсь, вы больше не увидите сообщение об ошибке “the trust relationship between this workstation and the primary domain failed”.

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

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

Автоматическое отключение и повторное присоединение к домену

Поскольку мне пришлось выполнить этот процесс слишком много раз, я создал сценарий PowerShell, который делает все за вас. Если вы укажете имя компьютера, он:

Отключит компьютер
Перезагрузится и дождется включения
Присоединит компьютер
Перезагрузится и дождется включения

Вы можете попробовать этот сценарий через GitHub.

Сводка

Вы должны теперь полностью понимать проблему и иметь несколько решений для печально известного сообщения об ошибке «Отношение доверия между этой рабочей станцией и основным доменом не удалось». Надеюсь, этот руководство дал вам некоторые идеи и позволил вам придумать собственные решения проблемы отключения компьютеров от домена!

Дополнительное чтение

Обязательно ознакомьтесь с другими связанными сообщениями!