Computer failed to join or logon to domain days later after reboot

CrashResistant used Ask the Experts™
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:

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.  
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.

Open in new window

Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Are you sure that no one is playing with the Computer accounts on the Domain Controllers???

Probably someone is either resetting the computer account or deleting them on the domain controller.

You should probably disable LM hash on the local machines.

You can do it by GPO :

This is used to disable LM Hash on the server and SAM database If you would like to do that outside the GPO.
Success in ‘20 With a Profitable Pricing Strategy

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!


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.


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.
NOW the difficult part, How to explain what's going on:
I may not be extremely accurate on these details. So, some research may be needed.

There are three basic types of authentication algorythems.

1) LAN Manager Hash (LM Hash)
2) NT LAN Manager Hash (NTLM Hash)
3) Kerberose (The latest AD protocol)

What happens is this:
All three systems  work off a token based system. Someone with rights to the domain, who has an administrative token, tells active directory that you wish to join the domain with that client machine. If granted the rights, a hash is saved on the client and on the server. When you do transactions, the server will request that hash as an authenticating measure. If the client and server hashes are the same, it provides a access token.  

LM Hash was created before NTLM hash. NTLM hash was created before Kerberos.

By default, 2003 server uses LM Hash to be backwards compatible to legacy machines (Prior to Windows ME), printers and other hardware. However, LM Hash has some very serious vulnerabilities to anyone with the very basic understanding of hacks and works on the internal network. External Hackers have to bypass all other IT sec protocols before they can hack a computer. This is why the progression of a more secure algorythem.

The HASH is 14 charactors long. It is divided into two 7 charactor halves. If you use less than seven charactors, the last seven charactors will have what is called a NULL HASH. This means the hacker only has to hack seven charactors because a null hash is the same for everyone.

To worsten security, each charactor can be hacked separately. You have seen the movies where a hacker goes to the ATM and hacks one pin code number at a time. That's the same principle. To make things even worse, the password is converted to all caps. So, there is no distinction between capitalized letters. These vulnerabilities will allow a hacker to hack this computer in seconds.

In an attempt to resolve this issue, administrators tried to invold a security policy to use numbers and special charactors. Also, they wanted passwords larger than seven charactors long. But, it is still easily comprimised. There are only so many combinations to the safe.

(It's all right here:

As a result of LMHASH vulnerabilities-->on to NTLM HASH:

NTLM Hash:
NTLM added an additional feature to the LMHash. It added another hash called D4 or D5 encryption. Now the client will communicate with the server in three stages to get the LM hash back.

Stage1: (called type1 authentication). The client sends a request to the server for certain services or featurs. The information it requests is called flags.
Stage 2: (called type2 authentication) The server requests a request for authentication back to the client with a similar set of flags and an 8 bit challange.
Stage 3: The client sends back two types of authentication. One is the LM Hash and the other is the D4 or D5 hash.

Once again, it's right here:

There were still vulnerabilities in this method so, --> on to kerberose:


Kerberose has changed the entire spectrum of authentication. Still using an access token, known now as a access ticket. Except there is now a third party involved.

For more information on Kerberose, please see the following. I am working out the details on kerberose myself:

Since Microsoft is trying to make things backwards compatible, you may have clients trying to provide LMHash to a kerberose system for authentication. The problem is, these requests for services will not go through the third party, like kerberose does. This is why you see the $ sign on the end of the computer name and are having problems authenticating. It tells you these are LMhash authentications. As stated before, LM has was for authenticating legacy machines. Kerberose uses a third party, so to speak.

You may have involked a security policy to deny access to LM hashes. It's a good thing. You are increasing your security. Those would be machines prior to Windows ME, like Windows NT, 98,95 ect... If you disable LMhash on those machines, I don't think you will be able to use server services. I don't know if any of these lagecy machines have a method of communicating with the server that uses kerberose as its default authentication protocol.



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!

There you go, you're getting it,  I was hoping that point was getting across.


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.


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???

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.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial