Usually caused by either incorrect DNS settings (not pointing to your DC(s) and -nothing- else) or unhealthy AD (run dcdiag on all DC's to check for errors).
Spice (8)flagReport
3 found this helpful thumb_up thumb_down
You can fix the trust without removing from the domain:
However, that's a bandaid. You should rarely have this issue if your DNS and AD are healthy.
Spice (9)flagReport
2 found this helpful thumb_up thumb_down
Really no proper solution to that other than a quick remove/readd to the domain. I'm not sure about 10 but everything prior you could almost always just remove and readd without a reboot and it would come up fine. You're basically just remaking the Computer Account in the AD.
Spice (9)flagReport
3 found this helpful thumb_up thumb_down
P.S. Make sure you don't have duplicate computer names. This can cause this issue.
Spice (13)flagReport
5 found this helpful thumb_up thumb_down
If you reset the computer account in AD, you will have to rejoin the computer to the domain to re-establish the trust relationship.
By disconnecting from the network, you were able to log into the computer using locally cached credentials since it could not verify those credentials with AD.
Spice (4)flagReport
Was this post helpful? thumb_up thumb_down
What are you handing out for DNS to the workstations? Only your domain controllers should be listed. No external DNS.
Spice (2)flagReport
Was this post helpful? thumb_up thumb_down
Duplicate names is GREAT for that. As submitted above there's a few ways to re-establish trust. We use LAPS so I usually just remote in with local admin throw it in a WORKGROUP, then back in the Domain. But, the ways above may be easier? I'm just old and crusty and set in my way (at 47).
:-)
Spice (3)flagReport
Was this post helpful? thumb_up thumb_down
As others have said, you'll probably have to leave/rejoin the domain. It will probably be fine.I'm curious, though; did anything change with these workstations?Usually, when I encounter this, it's following a System Restore or something like that.
Hi JoeyBing, it sounds like your PC password needs resetting.
You can reset the computer password using the PowerShell cmdlet Reset-ComputerMachinePassword. This is the fastest and most convenient way to reset the password of a computer and doesn’t require reboot.Reset-ComputerMachinePassword -Server DomainServer -Credential DomainName\UserNameTo test a trust relationship use Test-ComputerSecureChannel.Test-ComputerSecureChannel -VerboseYou can also repair secure channel between computer and Active Directory domain using PowerShell cmdlet Test-ComputerSecureChannel.Test-ComputerSecureChannel -Repair -Credential DomainName\UserName
Spice (6)flagReport
7 found this helpful thumb_up thumb_down
I always fix this problem by rejoining the computer to the domain.- Login as a local admin- Join a workgroup / leave the domain (including a reboot)- Join the domain- All done
Edit: Never lost any data by doing that.
Spice (5)flagReport
4 found this helpful thumb_up thumb_down
I ran into this before where 2 computers had the exact same serial number for some reason (our machine names include the serial number of the machine).When I figured this out I came up with a unique Serial for it and gave them both a reboot. Solved the issue.
thelanranger wrote:
P.S. Make sure you don't have duplicate computer names. This can cause this issue.
I had this exact issue occur once when I was setting up a new PC for an employee. I accidentally used the same name for the new PC as the old one, thus causing the problem. It took a bit of detective work before I figured out why this issue kept happening!
Surprised no one mentioned this, but it's worth checking AD to see if the computer still exists.
At my last job, there was an automated script that booted computers off the domain if they hadn't connected within 60 days. Good or bad idea aside, that's how they ran things, so when someone called in w/ that message, it was because they'd been on vacation or somehow managed to work for a couple months without using their computer (or maybe used it offline?).
Spice (4)flagReport
2 found this helpful thumb_up thumb_down
Da_Schmoo wrote:
Usually caused by either incorrect DNS settings (not pointing to your DC(s) and -nothing- else) or unhealthy AD (run dcdiag on all DC's to check for errors).
+1 CheckDNS settings.
Maybe your clients try to authenticate to a demoted DC?When we lose domain trust on clients it's most likely because someone kicked the wrong workstation by accident.
thelanranger wrote:
P.S. Make sure you don't have duplicate computer names. This can cause this issue.
I was going to add this as well.
We also have run into this as well. Simple fix was to unplug network cable (then using cached credentials), remove from domain and re-add. Seems to have resolved the issue for us in the past.
As others have mentioned, duplicate computer names and bad computer account password can cause this. It doesn't sound like it in this case, but I have also seen where using a program like DeepFreeze, reverting a VM snapshot, or doing a System Restore can get the computer account passwords out of sync and you will get this error.
If it is a duplicate computer name issue, the problem usually bounces between them until one is renamed.
My recommendations:
1) Change the computer name and reboot. This has fixed it in almost all cases for me.
2) If it persists, run "Reset-ComputerMachinePassword -Server DomainServer -Credential DomainName\UserName" as suggested by Colin7115. This does not require a reboot, but I do anyway.
These are really the low "hanging fruit", especially if there is only one or two machines having this problem. If it was more wide spread, then I would dig deeper into the AD replication issues that some others have mentioned.
Sometimes caused by two devices with the same name on the same domain.
Spice (1)flagReport
1 found this helpful thumb_up thumb_down
JoeyBing wrote:
I would like to avoid leaving and rejoining the domain, because I did that before and some data was lost.
This indicates some other problem (including possible administrator inexperience).
Leaving and rejoining the domain shouldn't result in data loss (number 1, because you've backed up all your data right?). Worst case would be the user account being recreated on the workstation after re-joining. But all the data would still be on the drive under the original, but now-defunct account folder.
It's been so long since I've had this issue I don't remember if I ever had to copy over the account data.
Since you're basically recreating the computer account, not the user account, the user's account/data/settings should survive the process.
Spice (2)flagReport
1 found this helpful thumb_up thumb_down
This usually only happens to us when the machine has been sitting around off too long, like months. Never really looked into why though.
Spice (1)flagReport
Was this post helpful? thumb_up thumb_down
thelanranger wrote:
Really no proper solution to that other than a quick remove/readd to the domain. I'm not sure about 10 but everything prior you could almost always just remove and readd without a reboot and it would come up fine. You're basically just remaking the Computer Account in the AD.
This is the proper solution^. Remove from domain, re-add, reboot.
You need to disjoin and rejoin the domain to get that fixed.
Spice (1)flagReport
Was this post helpful? thumb_up thumb_down
as others have said best way to fix this is to remove from domain then rejoin
please note that you will need to have the local admin password to re-add
Spice (1)flagReport
1 found this helpful thumb_up thumb_down
Check the SID for both systems - if they match that could explain the problem. It could happen if one system was cloned to the other and not correctly sysprepped.
If they match, backup the data and run sysprep on one system.
This issue appears very rarely but I seen this issue all the way back to XP. I have allows just removed the system AD and then re-added it to the domain.
Login as a local administrator account and re-join the computer to the domain.
If you disjoin and rejoin, you can do it without a reboot so it does not clear any of the domain profiles on the computer, not usually important, but if you do not have folder redirection it can prevent data loss. I would still recommend a backup in case though.
I found this from a fellow Spicer and it work the 3 times I had used it.
DamienGibson Jan 24th, 2016 at 12:01pm
I run into this often with remote employees that do not rely heavily on internal resources and dont VPN in everyday.
I have created a powershell script that has worked for me 100% of the time when you are able to login with any other admin account on the machine. For instance a service desk or helpdesk account.
when it reboots it will be resolved, and able to login. this just automates the disjoin process, but removes the need to reboot between disjoining and rejoining.
hope this helps.
Would you be able to provide some configuration details of your machine ? I mean IP address of the machine , IP address of dns servers, r u able to disjoin / rejoin while you are connected to wifi / internet ? R u able to login with a user account which was not logged on previously on the machine ? R u able to access sysvol network share after logged on to machine ?
Used to get this all the time at some of our locations so I did a bunch of research into it: Most common reasons for this happening:
Machine Account was reset on the DC Large Time Skews Network connectivity issues occur during computer password reset, which by default happens every 30 days. There are replication issues between multiple domain controllers. DIfferent domain controllers have different passwords for the workstation.
Another vote for remove from domain, reboot, join the domain, reboot, and the issue is resolved. If another system then experiences the challenge, you probably have duplicate names somewhere.
Lots of recommendations in this thread to remove the PC from the domain and rejoin it to the domain.
This will fix the immediate symptom (assuming you have a working Domain and DNS), But it doesn't help you determine the root cause of the issue.
It is still important to take the time to determine why this happened in the first place so that you can prevent it happening in the future.
