One of the frequent asked questions is that, suddenly the server or workstation drops out the domain and cannot establish successful logon. I have seen such scenarios even on Exchange servers, where administrator goes to AD finds the computer account for the exchange server and clicks on "reset" by mistake, don't ask me how but seriously I have seen this happen at client side.
I have also seen after P2V (Physical to virtual) computer secret is broken and they could not log on to domain. The fix for all these were taking these computers out the domain and adding them back to the domain and re-establish the secure channel between PC, or server to Domain controllers.
The security channel's password is stored along with the computer account on all domain controllers. For Windows 2000 or Windows XP, the default computer account password change period is every 30 days
Below is some very useful information in regards to how windows based computing works with local secret and how this can be reset ?
Each Windows-based computer maintains a machine account password history that contains the current and previous passwords that are used for the account. When two computers try to authenticate with each other and a change to the current password is not yet received, Windows relies on the previous password. If the sequence of password changes exceeds two changes, the computers involved may not be able to communicate, and you may receive error messages. For example, you may receive "Access Denied" error messages when Active Directory replication occurs.
You cannot change the machine account password by using the Active Directory Users and Computers snap-in, but you can reset the password by using the Netdom.exe tool
The Netdom.exe tool resets the account password on the computer locally (known as a "local secret") and writes this change to the computer's computer account object on a Windows domain controller that resides in the same domain. Simultaneously writing the new password to both places ensures that at least the two computers involved in the operation are synchronized, and starts Active Directory replication so that other domain controllers receive the change.
Now the question is, is there any way to find out if the trust is broken or in place, to answer this question follow the below examples and investigate each output.
The utility called nttest is used for to test trust relationships
The workstation that is a member of the TESTD domain has an implicit trust with a domain controller
- C:\>nltest /server:vmdc2 /sc_query:smtp25
- To determine if a domain controller can authenticate a user account:
- C:\>nltest /Whowill:smtp25 zz-oozugurlu
- NLTEST can be used to find a trusted domain that has a given user account.
- C:\>nltest /finduser: zz-oozugurlu
- To determine the domain controllers in the ESS domain:
- C:\>nltest /dclist:smtp25
- To determine the user
- C:\>nltest /user: zz-oozugurlu
MCITP (EMA) , MCITP (EA ) MCITP(SA),
MCSE (M+,S+) MCDST, Security+, Server +,Project+