Microsoft Patch KB3179575 causing authentication issues with Windows 2012 servers
Seems yet another Microsoft security patch is causing issues this month. KB3179575 which was in the August Patch Tuesday deployment is to fix issues with the Windows 2012 (not R2) operating system.
Taken directly from the Microsoft site, this update includes quality improvements but no new operating system features are being introduced.
The key changes include:
Addressed issue that required users to wait up to 30 seconds after booting-up, before the device was available and ready for use.
Addressed issue that prevents the automatic deletion of old Dynamic Host Configuration Protocol (DHCP) backup files—Extensible Storage Engine (ESE) transaction logs.
Addressed issue that caused Cluster service on remaining nodes to stop unexpectedly when a failover cluster node experiences a power outage.
Addressed issue that causes a NFS service to stop responding on a two-node Windows cluster deployment, affecting clients to not be able reach an NFS share.
Addressed issue after installing KB3146706 that causes Office 2010 to stop responding when Enhanced Mitigation Experience Toolkit (EMET) is enabled.
At this stage it seems to be only affecting logons (authentication) to Windows 2012 Domain Controllers, again at this stage the only fix is to uninstall this update, or if you deployed this security update using Microsoft’s SCCM and SnaPatch, you can roll this update deployment back. There is no known fix at this stage.
The trust relationship between this workstation and the primary domain failed.
Have you ever encountered the error message, “The trust relationship between this workstation and the primary domain failed”? This can be a frustrating issue for IT administrators and end-users alike. But don’t worry! In this article, we’ll dive deep into the reasons behind this error and provide actionable solutions to fix it. Along the way, we’ll discuss domain environments, trust relationships, and how to prevent this problem from occurring in the future.
Understanding Trust Relationships in a Domain Environment
The trust relationship between this workstation and the primary domain failed error occurs when there’s a disruption in the trust relationship between the computer and the domain controller. Here are some common causes of this error:
Password synchronization issues: If the computer’s password doesn’t match the password stored in the domain controller, it can cause trust relationship issues.
Time synchronization issues: If the time on the computer and the domain controller is out of sync, it can cause trust relationship issues.
Computer account deletion: If the computer account is deleted from the Active Directory, it can cause trust relationship issues.
The computer account password in Active Directory (AD) is not in sync with the password stored on the local machine.
Corruption of the local security database on the workstation.
Issues with DNS configuration or connectivity.
Symptoms caused by this Error
Symptoms of “The trust relationship between this workstation and the primary domain failed”:
Here are some symptoms that indicate that you’re facing “The trust relationship between this workstation and the primary domain failed” error:
Unable to log in to the computer with domain credentials.
Unable to access network resources.
Unable to access shared folders.
Error message: “The trust relationship between this workstation and the primary domain failed.”
Applications that rely on domain authentication fail to function properly.
Event logs display error messages related to trust relationship failures.
How to Fix “The trust relationship between this workstation and the primary domain failed”
There are several solutions to resolve the “The trust relationship between this workstation and the primary domain failed” error. Here are some of them:
Solution 1: Reset computer account password:
Log in to the computer with local administrator credentials.
Open Command Prompt as an administrator.
Type the following command and press Enter: netdom resetpwd /s:domaincontroller /ud:domainadmin /pd:*
Note: Replace “domaincontroller” with the name of your domain controller and “domainadmin” with the domain administrator account.
Restart the computer.
Solution 2: Rejoin the computer to the domain:
Log in to the computer with local administrator credentials.
Open Control Panel and navigate to System.
Click on “Change settings” next to “Computer name, domain, and workgroup settings.”
Click on “Change” next to “To rename this computer or change its domain or workgroup, click Change.”
Select “Domain” and enter the domain name.
Enter the domain administrator credentials.
Restart the computer.
Solution 3: Restore the computer account:
Log in to the domain controller with domain administrator credentials.
Open Active Directory Users and Computers.
Navigate to the “Computers” container.
Right-click on the computer account and select “Restore.”
Solution 4: Increase the Time out period of the computer account:
Increase the computer account password age or even disable password changes altogether to prevent this error from occurring in the future. To do so, you’ll need to set the following registry key:
This will disable password changes for the computer account, ensuring that the machine’s account password remains the same even if you restore an older snapshot.
Preventing Trust Relationship Failures
Preventing trust relationship failures is crucial to maintaining a smooth domain environment. Here are some best practices to help you avoid these issues:
Regularly Updating Passwords
Ensure that computer account passwords are regularly updated in both Active Directory and on the local workstations. By default, this happens every 30 days, but you can modify the password update interval if necessary.
Monitoring Active Directory Health
Keep an eye on the overall health of your Active Directory environment. Regularly monitor domain controllers, replication, and system logs to catch potential issues before they escalate into trust relationship failures.
Ensuring Proper DNS Configuration
Proper DNS configuration is vital for the smooth functioning of a domain environment. Make sure that workstations are using the correct DNS servers and that domain controllers have properly configured DNS settings.
FAQs
What is a trust relationship between a computer and a domain?
A trust relationship is established between a computer and a domain when the computer joins the domain. This trust allows the computer to access network resources and authenticate users.
Can I prevent “The trust relationship between this workstation and the primary domain failed” error?
Yes, you can prevent this error by ensuring that the computer’s time and password are synchronized with the domain controller.
How can I avoid trust relationship issues in the future?
You can avoid trust relationship issues by regularly resetting computer account passwords, synchronizing time between the computer and domain controller, and ensuring that the computer is not deleted from the Active Directory.
Can a non-administrator account resolve the “The trust relationship between this workstation and the primary domain failed” error?
No, a non-administrator account cannot resolve this error. You need to have local administrator or domain administrator credentials to resolve this error.
What causes a trust relationship to fail?
Trust relationship failures can occur due to reasons such as password synchronization issues, disabled or deleted computer accounts, DNS configuration problems, or corruption of the local security database.
How can I reset a computer account in Active Directory?
You can reset a computer account in Active Directory using the Active Directory Users and Computers console or PowerShell.
What is the Test-ComputerSecureChannel cmdlet in PowerShell?
The Test-ComputerSecureChannel cmdlet is a PowerShell command that allows you to test and repair the trust relationship between a workstation and the primary domain.
How can I prevent trust relationship failures?
To prevent trust relationship failures, ensure regular computer account password updates, monitor Active Directory health, and maintain proper DNS configuration.
Conclusion:
“The trust relationship between this workstation and the primary domain failed” error can be frustrating, but it’s a common issue faced by many computer users. This error occurs when there’s a disruption in the trust relationship between the computer and the domain controller. You can resolve this error by resetting the computer account password, rejoining the computer to the domain, or restoring the computer account. By following these solutions, you can prevent this error from occurring in the future. Remember to ensure that the computer’s time and password are synchronized with the domain controller to avoid trust relationship issues.
As a system administrator, you might face situations where a Domain Controller (DC) in your network fails due to hardware issues or software corruption. In such cases, restoring the DC from a snapshot can be a lifesaver. A snapshot is an image of the system’s state at a particular point in time, and restoring from it can bring back the system to that state. In this article, we will discuss how to restore a Domain Controller from a snapshot, step by step.
Understanding the Importance of Domain Controllers
Before we jump into the process of restoring a Domain Controller from a snapshot, let’s first understand why DCs are crucial for a network. In simple words, a Domain Controller is a server that manages network security and enables users to access shared resources, such as printers and files, on the network. It is the backbone of the Active Directory (AD) infrastructure, which is responsible for authentication and authorization in a Windows environment.
Reverting a snapshot of an active Domain Controller can be a risky and problematic issue.
If you are considering using this procedure it should be your very LAST option. This is not a supported Microsoft procedure and use of it could cause fatal issues to Active Directory.
Reassess your environment and take the proper steps to ensure this recovery model doesn’t have to be used again.
Use at your own risk!
What are the risks with doing this?
The risks of reverting a snapshot of a Domain Controller are significant and can have severe consequences for an organization’s Active Directory infrastructure. Some of the potential risks include:
Data loss: Reverting a snapshot of an Active Domain Controller can result in data loss, as the snapshot may not contain all of the latest changes to the Active Directory.
Active Directory corruption: The Active Directory database may become corrupted during the snapshot revert process, leading to issues with authentication, authorization, and other critical services.
Replication problems: The snapshot revert process can cause problems with replication between Domain Controllers, leading to inconsistencies in the Active Directory data across different servers.
Service disruptions: The snapshot revert process can result in disruptions to critical services, such as DNS, that depend on the Active Directory.
Security risks: The snapshot revert process can result in security risks, as it may expose sensitive data or compromise the security of the Active Directory infrastructure.
It is important to carefully consider the potential risks and consequences before attempting to revert a snapshot of an Active Domain Controller. It is recommended to only use this procedure as a last resort, and to thoroughly research and understand the potential risks before proceeding.
Preparing for the Restoration
Before you start the restoration process, you need to ensure that you have a snapshot of the Domain Controller that you want to restore. It is essential to note that restoring a DC from a snapshot is a risky process and should be performed only when no other options are available. Moreover, you must have a proper backup and recovery plan in place to avoid any data loss during the restoration.
Steps to revert a Domain Controller Snapshot
1) Revert to your last known good snapshot
2) Disable your network card so that it is unable to talk to the network
3) Note the value of your Invocation Id
From a command prompt run the following command
Repadmin /showrepl
4) Reboot your Domain Controller and make sure you boot into Directory Services Restore Mode
5) Stop the NTFRS service
6) From a command prompt start Regedit
Drill down to HKLM – System – CurrentControlSet – Services – NTDS – Parameters
Modify the RegKey “Database restored from backup” = 1
If this RegKey doesn’t exist create one as a DWORD and set to a 1
If the RegKey DSA Previous Restore Count exists in the same path, note its value. Upon reboot it should increment by one. If it didn’t exist it should be created and it should be set to a value of 1.
Drill down to HKLM – SYSTEM – CurrentControlSet – Services – NtFrs – Parameters – Backup – Restore – Process
Modify the RegKey BurFlags to D2
7) Reboot the server
8) Log back in to the Domain Controller
Verify that the Invocation Id has changed
In the Event Log look for the Event Id 1109 (AD restored from backup)
9) If both events have occurred in bullet point 8 then, enable the network card again
Best Practices for Restoring a Domain Controller from a Snapshot
Here are some best practices that you should follow while restoring a Domain Controller from a snapshot:
Best Practice 1: Ensure the Snapshot is Consistent
Make sure that the snapshot is consistent and the system is shut down gracefully before taking the snapshot.
Best Practice 2: Test the Snapshot
Before performing the actual restoration, test the snapshot on a test environment to ensure that the restoration process goes smoothly.
Best Practice 3: Have a Backup Plan in Place
Always have a backup plan in place and test it regularly to ensure that it is effective.
Best Practice 4: Monitor the DC after Restoration
Monitor the Domain Controller closely after the restoration to ensure that it is functioning correctly.
Conclusion
Restoring a Domain Controller from a snapshot can be a lifesaver in critical situations. However, it is a risky process and should be performed only when no other options are available. It is essential to have a proper backup and recovery plan in place and follow the best practices while restoring a Domain Controller
Cut Your SharePoint Costs with Squirrel!
Automatically archive documents to Azure Blob Storage and save big.
