Freigeben über

"The trust relationship between this workstation and the primary domain failed."

  • Artikel

How many times have you came across reports of users complaining that they cannot logon to the domain?

Logon fails with "The trust relationship between this workstation and the primary domain failed."

Additionally the NETLOGON service also logs:

Event ID 5723

"The session setup from the computer DOMAINMEMBER failed to authenticate.
The name of the account referenced in the security database is DOMAINMEMBER$.

The following error occurred: Access is denied."

What do you have to do in those cases?

Exactly... I heard you saying "Disjoin and rejoin the machine to the domain"

Some of you may wonder why we can’t just reset the computer account password in AD and fix the problem.

Well by resetting the computer account password, AD sets the password to the default value and the probability of the member having the same password is practically null.

Every domain member has a secure channel (SC) with a domain controller, this SC is created and mantained by the NETLOGON service on both member and DC.
(Like users, computers also have passwords which are managed automatically).

If the SC gets broken the member won't be able to authenticate in the domain.

Note:

A secure channel is an authenticated remote procedure call (RPC) connection between two machines in a domain with an established security context used for signing and encrypting RPC packets.

For the SC to be successfully established, the computer account password (stored in Active Directory) and the member's password (known as LSA secret and stored in the member) have to be in sync.

The member has to change its password every 30 days by default.

This setting is controlled by "Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Domain member: Maximum machine account password age" using Local computer policies or domain GPOs.

Note:
If you increase this interval significantly, or set it to 0 so that the computers no longer change their passwords, an attacker will have more time to undertake a brute force attack to guess the password of one or more computer accounts.

For more information on recommended security settings see Microsoft Security Compliance Manager (SCM) which you can download from: https://www.microsoft.com/en-us/download/details.aspx?id=16776

So you might be asking what can go wrong if the member's password is automatically changed and managed.

One thing that is very important to keep in mind is that the requirements for a machine to change its password has changed in versions later than Windows XP/Server 2003.

Later OSes only change their password if they can contact a DC whereas Windows XP/Server 2003 change their password even without being able to contact a DC.

Which breaks the secure channel immediately.

Let me give you 3 examples for clarity sake:

Example 1:

Joe laptop (running XP) changes its password on Nov 15 (and syncs with AD)

Joe goes on leave and takes his laptop with him on Dec 1

On Dec 15 while Joe was preparing his agenda for his 1st day of work, his laptop decides to change its password without being able to notify the DC

Joe returns on Dec 16

when he tries to logon he gets the message mentioned above - and you get a phone call :)

Example 2:

Same situation but now Joe closes his laptop and leaves it on his desk.

When he returns notices his laptop has been stolen...

please ignore previous line :)

starts his laptop and logs on without problems.

The computer password gets reset later on the same day and life goes on.

Example 3:

Wisely the IT department has upgraded all laptops to Windows 8.

So when Joe returns from leave experiences no problems logging on to the domain because his computer only changes its password if it can contact a DC.

By the way if you read my previous blog, mind the Windows XP support lifecycle note.

Recently I came across an issue that has been puzzling System Admins minds for some time.

Since deployment of Windows 7 that machines in training rooms where "re-imaged" as needed via SCCM.

However broken secure channels where happening daily on many of them.

You may ask how that can happen if Windows 7 doesn't change the password unless it can communicate with a DC.

Well cutting a long story short, after enabling netlogon logging on the DCs (https://support.microsoft.com/kb/109626) and analysing a number of netlogon logs, I ended up finding a number of Windows XP machines that no one was aware of and that didn't even appear in SCCM since they were not managed via SCCM.

Basically found out that a particular branch was still using the old re-imaging process with Windows XP images using the same names as the Windows 7 machines, thus using and changing the password of Windows 7 members.

So once a Windows 7 member tries to authenticate it would fail and that was happening on an endless loop, because the Windows 7 admins would disjoin/re-jointhe Windows 7 box (thus fixing the SC problem) and then the XP admin would do the same on the XP machine.

This post is a bit long now so I will add another one for the ones interested in knowing that SC issues may also occur on DCs and Domain trusts.
Additionally, tools we can use for troubleshooting.

As always you are very welcome to add your comments!

Thanks

Paulo

Comments

  • Anonymous
    January 01, 2003
    Nice article !

  • Anonymous
    January 01, 2003
    I just found an interesting link:http://windowsmatters.com/2012/10/24/using-windows-powershell-to-fix-a-broken-secure-channel-and-reset-the-computer-account/I never tried it but it could be worth a try:with powershell input the following command:Test-ComputerSecureChannel -repair

  • Anonymous
    January 01, 2003
    hay guys is their any solution for this problem rather than "Disjoin and rejoin the machine to the domain"????????????

  • Anonymous
    January 01, 2003
    That's what I was used to do: "Disjoin and rejoin the machine to the domain". Great article :)

  • Anonymous
    November 22, 2012
    What I have found that breaks the Windows 7 machine in this manner is when the machine runs a startup repair and rolls the machine back in to a restore point. This can happen after attempting to install windows updates or installing managed software. Then you still get to disjoin and rejoin to fix it.

  • Anonymous
    January 26, 2013
    The comment has been removed

  • Anonymous
    April 19, 2013
    The comment has been removed

  • Anonymous
    December 04, 2013
    Thanks for this Article Paolo!!It assisted us in Resolving a Produciton issue within 17min!!

  • Anonymous
    December 13, 2013
    I have seen this happen on the client computer more than 3 times.  If what you are saying is true, then seems like it would fix it after disjoining and rejoining the first time?  This keeps happening over and over.  I have found a few articles that is might have something to do with Sysprep.  Maybe some of our guys forgot to sysprep before storing the image after being built.  I am still in search of answers.  I work at a place with over 3,000 machines and do not have time to go disjoin and rejoin them all several times.  Well it hasn't been that bad, but you know what I mean.  

  • Anonymous
    April 04, 2014
    I have used powershell to resolve the issue. I use this to remotely fix the issue.
    Here is the script I wrote to do this:

    #Start remote powershell session
    Enter-PSSession -ComputerName worksation1
    #Reset the password
    Reset-ComputerMachinePassword -Credential domain/username -Server dc-server
    #Test trust relationship
    Test-ComputerSecureChannel
    Exit-PSSessionssue.

    Replace workstation1 with your actual target machine name
    Replace domain/name with a user that has administrative rights
    Replace dc-server with your actual server name
    It will prompt for a password.
    I'm new to powershell so somebody may have a better approach. Hope this helps someone.