CrashResistant
asked on
Computer failed to join or logon to domain days later after reboot
We have several PCs at our branch that are giving the error below. I have no idea what might be causing this. I have to logon as the local administrator, only to find the PC has a $ appended to the name. I manually rejoin the domain and rename the computer.
However this problem is occurring on several PCs and all of them have unique names and manually assigned IP addresses. (No DHCP)
Please advise!
The error is attached:
However this problem is occurring on several PCs and all of them have unique names and manually assigned IP addresses. (No DHCP)
Please advise!
The error is attached:
The session setup from computer 'BR03-LEND-01' failed because the security database does not contain a trust account 'BR03-LEND-01$' referenced by the specified computer.
USER ACTION
If this is the first occurrence of this event for the specified computer and account, this may be a transient issue that doesn't require any action at this time. Otherwise, the following steps may be taken to resolve this problem:
If 'BR03-LEND-01$' is a legitimate machine account for the computer 'BR03-LEND-01', then 'BR03-LEND-01' should be rejoined to the domain.
If 'BR03-LEND-01$' is a legitimate interdomain trust account, then the trust should be recreated.
Otherwise, assuming that 'BR03-LEND-01$' is not a legitimate account, the following action should be taken on 'BR03-LEND-01':
If 'BR03-LEND-01' is a Domain Controller, then the trust associated with 'BR03-LEND-01$' should be deleted.
If 'BR03-LEND-01' is not a Domain Controller, it should be disjoined from the domain.
You should probably disable LM hash on the local machines.
You can do it by GPO :
http://www.microsoft.com/technet/abouttn/flash/tips/tips_062205_2.mspx
You can do it by GPO :
http://www.microsoft.com/technet/abouttn/flash/tips/tips_062205_2.mspx
This is used to disable LM Hash on the server and SAM database If you would like to do that outside the GPO.
http://support.microsoft.com/kb/299656
http://support.microsoft.com/kb/299656
ASKER
I followed your advice Chief and enabled the disable LM Hash option via GPO.
However I highly doubt this is the problem, but for the sake of clarification, why would this be applicable? Could you expand on this possible solution theory.
I al 100% positive no one is playing with the computer accounts on the DCs.
However I highly doubt this is the problem, but for the sake of clarification, why would this be applicable? Could you expand on this possible solution theory.
I al 100% positive no one is playing with the computer accounts on the DCs.
ASKER
PS. So far this has happened to 10 computers at the branch. The names do not literally have a $ appended to them, however I still found that was very odd when I look at the error.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
So basically, by disabling LM Hash on the local machines, their authentication access token is defaulted to Kerberose, thus improving security but also compatible with the domain controllers? (since they use kerberose, I assume)
Thanks for the lengthy hash explanations, that one is for the books!
Thanks for the lengthy hash explanations, that one is for the books!
There you go, you're getting it, I was hoping that point was getting across.
ASKER
Ok. Well I hope this solves the problem however I'm very skeptical because there was no hostile intervention or "messing with" on the active directory- so it would seem like a very popular "problem" if it is accidental or poor/improper configuration.
If there are any other ideas please share, and I will give an update on Monday morning when these computers and user accounts are attempted to log in.
If there are any other ideas please share, and I will give an update on Monday morning when these computers and user accounts are attempted to log in.
ASKER
Thanks. I think this solvved it.
Hi guys!!!
as far as I know on windows 2003, kerbose is the default authenticating protocol!!! So, whats the problem in disabling LM Hash???
as far as I know on windows 2003, kerbose is the default authenticating protocol!!! So, whats the problem in disabling LM Hash???
You are correct:
Kerberose is the default protocol. However, In this scenario, there was a dollar sign "$" appeded to the end of the client computer name. This is a result of clients trying to communicate using the older authentication protocol, LMhash. While trying to authenticate by using LMHash, the clients were not able to join the domain and probably ran into other AD issues. So, LMhash needed to be disabled so the clients were forced to go back to the default protocol.
Why clients were resorting to LMhash instead of kerberose is something I don't know. I haven't figured that out, yet. But, I have seen these errors before and the fix was disabling LMhash.
Kerberose is the default protocol. However, In this scenario, there was a dollar sign "$" appeded to the end of the client computer name. This is a result of clients trying to communicate using the older authentication protocol, LMhash. While trying to authenticate by using LMHash, the clients were not able to join the domain and probably ran into other AD issues. So, LMhash needed to be disabled so the clients were forced to go back to the default protocol.
Why clients were resorting to LMhash instead of kerberose is something I don't know. I haven't figured that out, yet. But, I have seen these errors before and the fix was disabling LMhash.
Probably someone is either resetting the computer account or deleting them on the domain controller.