So here is the story. All of this started when a client updated Symantec Client Security on their domain, which has since been uninstalled but some strange problems persist. Here are the relavent details:
- A single Windows Server 2003 domain running in 2003 native mode.
- The domain has no children, parents, etc.
- There have been no changes to the domain structure in years.
- There have been no new DCs in years.
- Laptop running Windows XP Pro SP3
- The laptop worked fine on the domain for years.
- Now when you try to connect to a shared folder on the domain controller you get the meesage "System error 1396 has occured. Logon Failure: The target account name is incorrect."
- This is true no matter what share you try to connect to (including administrative shares)
- This is true whether you are logged on with a normal domain user or a domain admin user
- Other computers on the domain are able to connect to the share no problem.
- I am able to connect to the share if I am logged on to the laptop with a local user account. (They have the share open to Everyone, I've told them it's a bad idea, but I have no decision making power at the company).
I have tried disconnecting the laptop from the domain. Deleting the laptop computer account on the domain controller and then reconnecting to the domain with no luck. When I google the error message I get a bunch of stuff about duplicate computer accounts in child domains, which doesn't seem to be relevant to this situation. Does anyone have any other ideas?
Best Answer
So I finally figured out what was going on (after much trial and error). We had a domain controller that crashed a while ago and the company chose not to do a recovery. Messy and ugly and not best practices, but whatever. What they did was put an A record for that DC pointing to another DC's IP address. What this did was allow the SRV records from that DC to continue working. What happened was that someone saw the "wrong" A record and deleted it. Thus causing SOME but not all requests for authentication to fail. It was then made worse by some somewhat odd caching rules for SRV records in Win XP. Any patterns I saw were either secondary, or just my brain trying to see patterns where there was really just random data. Restoring the A record fixed the problem, and since the company is being shut down by it's parent at the end of the year, nobody is going to bother to do anything better.