Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
Failed to authenticate with \\<computer name>, a Windows NT domain controller for domain <domain name>.
|English: Request a translation of the event description in plain English.|
|Concepts to understand:|
What is the role of the Netlogon share?
At boot, each Windows 2000 workstation or server that is a member of a domain is establishing a communication channel (known as the secure channel), with a domain controller. To establish this connection, the computer is using a "computer account password" that has to be changed every 30 days (by default). If somehow the password gets out of sync with the information that the domain controller has about this computer, the channel fails to be established and errors occur, including this event. Use the Netdom.exe and Nltest.exe tools to troubleshoot this problem. (The Netdom.exe and Nltest.exe tools are located on the Windows 2000 Server CD-ROM in the Support\Tools folder. To install these tools, run Setup.exe or extract the files from the Support.cab file.). See the links below for more details.
Applying the suggestions on ME150518 does not always solve the problem. See the links below for more conditions on which this event can occur.
One user reported this event as being recorded after a successful renaming of a domain (T738208 describes how domain renaming works). Some workstations however would report this event. The user considered that problem was that he had run rendom /clean before he had the workstations rebooted and renamed. Command rendom /clean deleted referencies to old domain so the workstations were not able to rename automatically after this cleanup. The affected computers had to be renamed manually.
In my case, I previously had an local administrator account created in the computer. So:
1.- Log on as local administrator (No in the domain, just in the PC)
2.- Joined the machine to a workgroup
3.- Change the full computer name
5.- Rejoined the machine to the domain
6.- I also had defined a prefered DNS server address, so I just select the option "Obtain DNS server adress Automatically"
This fixed the problem for me and I was able to log again.
In my case, I removed the PC from the Domain to a Workgroup and I deleted the computer account in Active Directory. Then, I rebooted the PC and moved it back to the Domain. This fixed my problem.
One of our Windows 2003 domain controllers suffered complete disk failure. The disk was replaced, the operating system reinstalled, rebooted into Directory Services Restore Mode and the System State restored. After rebooting, its authentication attempts failed. We followed the instructions as per ME325850 which explains how to use netdom.exe to reset the machine account password of a Windows Server 2003 domain controller.
In my case, I joined the machine to a workgroup and then I rejoined it to the domain. This fixed the problem for me and I was able to log again.
When you select Synchronize Entire Domain in Server Manager on the primary domain controller (PDC) this event appears on the backup domain controller (BDC). See ME142869 to resolve this problem.
This may occur if "Restrict Anonymous" was set through Group Policy. See ME281733 to fix this problem.
This problem can also occur if you are using F-Secure Anti-Virus version 5.3 on Windows XP, because F-Secure Anti-Virus version 5.3 is not compatible with Windows XP. See ME831348 for more details.
Also check ME104558, ME150298, ME175024, ME180114, ME324120, and the link to "EventID 3210 from source System" for additional information on this event.
This event can occur in a Windows 2000 member server if it is promoted to the role of Domain Controller for a child domain of the domain the server is currently a member of. When DCPROMO runs, the member computer account in the parent domain is disabled (not deleted) and a new domain controller account is created in the child domain. After reboot, the newly promoted domain controller (in the child domain) tries to authenticate with a domain controller in the parent domain in order to establish the (transitive) trust relationship between parent and child domains. This authentication fails because the parent domain controller sees the disabled member computer account still in the parent domain and refuses the authentication. This causes the trust functionality to fail (for the new domain controller only) and users in the parent domain lose access to resources on the new child domain controller. The problem can be resolved by deleting the disabled computer account in the parent domain and rebooting the new child domain controller.
Problem occurred after blocking TCP/135 (RPC) and all ICMP traffic across our WAN. Had to remove PCs from domain and re-add them.
This error is also reported when there is a broken trust relationship between a Windows 2000/2003 domain and a Windows NT 4.0 domain. Delete the trust and create a new one.
In our case, we got the same failed to authenticate .... access is denied message. What this came down to was a Domain Security Policy change that someone had made. We use MS Security Analyser and it recommended changing the restrict anonymous setting from 1 to 2. This is something to do with anonymous being able to enumerate users, groups etc. Anyway after tryin several things and talking to MS I changed this back and it worked. Note that I made the change a month before this started happening.
After several hundred NT 4.0 machines had been successfully joined to our new WIndows 2000 domain, the following error message began appearing up on these machines when attempting to login to the domain: "The system cannot log you on to this domain because the system's computer account in the primary domain is missing or the password on that account is incorrect". In concern with this popup, event id 3210 appeared in the system event log. Installation of the Active Directory Client extension for Windows NT 4.0 resolved both errors.
In our case, multiple 3210 events (every 15 minutes) occured on Windows NT 4 machines (workstations and standalone servers) just after transferring the Operations Masters Roles from a Windows 2000 SP3 Domain Controller to another one. Even though this process had been successful many times before, this time the result was that no workstation or server running windows NT 4 could log on to the network generating the following message:
"Access Denied. The computer account in the domain is missing or the password is incorrect".
The normal process to resolve this problem is to reset the secure channel either using the AD users and computers console or by using the NETDOM utility. This didn't work. Another solution is to remove and join the domain again. This didn't work neither. It was not a NTLM problem and not any kind of policy setting. All NT4 machines had to log on locally. We even tried to bring up a brand new Windows NT 4 BDC with the plan to promote it to PDC but we never managed to finish setup, since it could not authenticate to the DCs to retrieve the user list.
The problem was unexpectedly solved by itself, when we upgraded one Windows 2000 Domain Controller to the new version of Windows Server 2003.
|Private comment: Subscribers only. See example of private comment|
|Links: Active Directory Client for Windows NT 4.0, EventID 3210 from source System|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
Send comments or solutions
- Notify me when updated