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: http://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 (http://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
