The NetLogon service on the PDC logs this error message when the password is not synchronized between the computer and PDC. This is a common problem. When a workstation joins the domain, a trust is created with the PDC along with a secured channel password on both machines. This password, by default, automatically changes every seven days. If for some reason the process of password change fails, this error will be generated. One may have to reset the machine account password (can be done with the NETDOM utility - from NT Resource Kit or for Windows 2000 from the Support Tools ). The password change is initiated by the workstation. This change can be disabled by altering the Registry (DisablePasswordChange on the workstation or RefusePassowrdChange on the server). See ME154501
, link below.
This event may also mean that the computer does not have an account in the domain or has been deleted.
I my case, I had added a Windows 2008 domain controller to the environment. The FSMO holder was a Windows 2003 domain controller. Telling the 2003 server to use TCP for kerberos seemed to fix the issue (ME244474
). Had to reboot the 2003 server for it to take affect then the 2008 server. Course most of the servers have to be rebooted at that point to talk on TCP versus UDP. Not an easy change to implement in a large environment.
In my case, I got this event along with Event ID 11 from source KDC. The problem was that I had a few accounts of workstations duplicated in the Active Directory.
Check and see that you do not have duplicate accounts in your AD. Delete the duplicated workstations and in "ADSI edit" fix the correct workstation with his SPN.
Also, remove the $DUPLICATE-2d0ae if there is one.
Another alternative that has not been touched is if you took an image of a PC already on a network and then used this image on other PCs. You not only have to change the computer name, but you also have to change the SID. If you do not, the DC will not authenticate the computer trying to access the domain. For example, if you used Ghost to image a PC, then you would need to use Ghostwalk to change the SID and computer name to allow it to be authenticated on the domain.
I had a NT 4.0 BDC that had been down for a number of weeks. Upon bring it online, I received this error on the 2003 Enterprise PDC. I found that the NETLOGON service on the BDC would not start. I used Server Manager to highlight the offending BDC and told it to sync with the PDC. The NETLOGON service of the NT 4.0 server started immediately and the service was fine from then on.
In one case, this event appeared on a Windows 2003 domain controller because of the linux machine that was not in the AD. The linux machine must join the domain. Use the following command on linux as root user:
net rpc join -U administrator%password
In one case this event appeared on a Windows 2003 SP1 domain controller each time a Windows XP SP2 computer was started. This computer could ping the domain controller but not vice versa. When the Windows XP Firewall was disabled and the computer was removed and re-joined to the domain, this event ceased to reappear.
If a domain trust in the trusted domain automatically resets, the next time a trusting Windows 2000 domain controller tries to update the password, the authenticating domain controller in the trusted domain may log an event ID 5722 event. This problem typically occurs when a Windows NT 4.0 domain trusts a Windows 2000 domain. See ME821240
for more details.
As per ME154398
, a BDC secure channel may fail if more than 250 computer accounts exist. The latest service pack for Windows NT 4.0 or Windows NT Server 4.0 fixes this problem.
Look at ME200900
to see how Windows NT handles incorrect User/Machine account passwords. It should shed more light on why this event appears.
The event may appear if the computer account does not exist. See MSW2KDB
for more details.
See Error code 5
for general information for "Access is denied" errors.
for additional information on this problem.
This event appears when you select Synchronize Entire Domain in Server Manager on the primary domain controller (PDC). See ME142869
to resolve this problem.
On our Windows NT network this occurs sometimes when the PDC could not be found when registering the computer in the domain. Solution in this case was to enter the IP address from the PDC as the WINS server for this specific machine. After you add the computer you can remove the WINS server.
This event occurred when I tried to add a Windows XP client to a Windows 2003 server domain. The message received on the XP client was: “The server is unable to process your request”. The solution that worked for me was to change the DNS settings of the client to point to the domain controller(s) instead of an external DNS server.
Microsoft’s article ME216393
, referenced by contributor Diane made this fix easy. With Windows 2000 or Windows XP, you can also reset the machine account from within the graphical user interface (GUI). In the Active Directory Users and Computers MMC (DSA), you can right-click the computer object in the Computers container and then click Reset Account. This resets the machine account. Resetting the password for domain controllers using this method is not allowed. Resetting a computer account breaks that computer's connection to the domain and requires it to rejoin the domain.
I received this error on a NT4 PDC whenever I tried to add a certain XP PC to the domain. At first, I suspected a WINS problem or the recent SP2 upgrade to the XP PC caused the error, but since it was necessary to provide a very quick fix, I renamed the PC and it could then join the domain.
In our case, this event appeared because the time between the server and the workstation was out of sync.
We had the same problem with one PDC, one BDC, and Windows XP Workstations. We tried to remove and re-add them to the domain but it did not fix the problem. For some strange reason we could not re-establish the secure connection between the DCs. To workaround the problem, we brought down the BDC, removed and rejoined the workstations, and repaired the BDC from the CD.
to find out more about the effects of machine account replication on a Domain.
This event occurs in two different cases on our network with 3 BDC’s and a PDC, all NT4.0:
Case 1: The event occurs repeatedly and in rapid succession, numbering 10, 20, 50 or more, all for the same NT4.0 client. Events may be logged on more than one DC, sometimes on all of them. The client’s event log also contains NETLOGON error events. The utilities for fixing the problem never seem to work, but removing the client from the domain and adding it back almost always solves the problem. Users experiencing this problem on their workstations are unable to perform operations that require domain authentication.
Case 2: The event occurs a single time for random clients and is typically logged on only one DC. If the event log on a corresponding client is examined, there is no NETLOGON error or any other error that can be associated with the event logged on the DC. The users of the particular client do not report any problem. We have come to regard this case as just a nuisance message. We do not understand what causes this to happen.
If you have a client failing to authenticate, the easiest way to fix it is remove it from the domain, then check DC's to see if the computer account is there in AD. If it is delete it manually. Then rejoin client to domain. This worked for me.
The error code is in Data. For example, the error 0xC0000022 = "STATUS_ACCESS_DENIED" means the computer account's password is invalid, while the error 0xC000018B = "STATUS_NO_TRUST_SAM_ACCOUNT" means the computer account has been deleted, and so on.
If your symptoms are as it follows:
If a domain trust in the trusted domain automatically resets, the next time a trusting Windows 2000 domain controller tries to update the password, the authenticating domain controller in the trusted domain may log an event ID 5722.
(This problem typically occurs when a Windows NT 4.0 domain trusts a Windows 2000 domain.)
Then the problem could be that:
Under these conditions, Event ID 5722 event messages that the trusting domain controller logs are only noise because the trusts are operational. When you reset the trust passwords manually, they automatically reset again within a day (plus a random interval).
The Windows NT 4.0 domain sends the new password to the Windows 2000 domain, and the new password does not work. The Windows NT 4.0 domain then sends the old password. The old password succeeds. Windows 2000 logs the event message because the initially presented password did not work.
A supported fix is now available from Microsoft, but it is only intended to correct the problem described. This problem was corrected in Microsoft Windows Server 2003.
When you use the Active Directory Sites and Services snap-in to manually replicate data between Windows 2000 domain controllers, you may receive the error. See Microsoft Knowledge Base Article - ME288167
This also happens, when a Windows 2000 Domain is running in Native Mode(accidentially) and there are some NT 4 BDCs left. Clients before W2K (NT 4, Windows 9x) using the NT 4 BDC have the problems. Update the BDC to W2K and (most) problems are gone.
This event also occurs under Windows 2000, even though Microsoft does not mention it in the Q articles. In a mixed-mode windows 2000 domain, a standalone server may lose machine-password synchronization. In this case, if you are on mission-critical systems and do not want to remove and rejoin the computer to the domain, try the Win2000 ResKit utility NETDOM as follows:
NETDOM /RESET <servername>
The result should be succesful and the message contains the name of the DC the operation was processed with. This should resolve the problem.