Citrix VDA: The trust relationship between this workstation and the primary domain failed

Citrix VDA: The trust relationship between this workstation and the primary domain failed

September 20, 2019 0 By Amir Joseph Sayes

The trust relationship between this workstation and the primary domain failed

If you get this error for non-persistent RDSH/VDI provisioned using PVS, it could well be that there is a conflict in managing “machine account password” on your computer objects in AD between PVS and Netlogon. 

Machine account password for non-persistent machines provisioned with PVS should be only managed via PVS.

First things first

In a scenario when you have hundreds of machines; proactively catch and fix machines can come handy.

First, we need to make sure Netlogon service on the target machine is not negotiating machine passwords. This can be done by the Group Policy

Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Domain member: Disable machine account password changes – Enabled. 

Now we need to make sure PVS side is configured properly. You will also need to shutdown affected machines and reset their computer account as explained in this Citrix article.

Troubleshoot faster with PowerShell

Luckily, we can interrogate the event logs across all non-persistent machines and proactively find out which ones are going to lose trust with the domain.

Below I list the Event IDs that I look for and what they mean

Event ID

Message

Log

Source

Meaning

5823

“The system successfully changed its password on the domain controller <Domain Controller Name>

System

NETLogon

This is a symptom of the problem. PVS is not managing the account password and Netlogon service is stepping in and changing the password.

1015

Unable to negotiate new machine password

Application

BNDevice

PVS is trying to change the password but failing. The password that the PVS is injecting in the target device is not in sync with the one AD has.

1017

Updating machine account password – Client Service

Application

BNDevice

This the the expected behavior when PVS is configured properly.

1016

New machine account password negotiated – Client Service

Application

BNDevice

PVS injects the machine identity (name and password) upon boot, then while the machine is running, PVS software can negotiate a new password on a set intervals. Once negotiated successfully, PVS keeps a record of the new password so it can be injected the next time the target device reboots.

If another service e.g. Netlogon negotiated a new password with Active Directory, PVS will not know about this change and will inject an old password when the target device is rebooted.

To discover which service is changing the password, a script can run across the all target devices to match the password negotiation time with the lastpasswordset value in AD for each computer object.

I use Invoke-parallel to “fan” the script across all machines. You will need to download and import the module as shown below

Example of results – in this example we can see that the password negotiation was sucessful and was initiated by PVS service (BNDevice). We can also see that the timestamp of the password change in Active Directory corresponds to the event on the target device.

2019-09-20 17_09_00-Capture

Monitor and proactively act with PowerShell!

The following script would try and remotely connect to a machine and check the secure channel between the machine and the domain. if the machine is not contactable, that could be an indication of a failure in trust relationship.

The script also checks if the machine is already in maintenance mode or not

Example of the output: 

 

2019-09-20 18_07_08-Capture3