I was experiencing issues with NETLOGON, SPN records, Kerberos, NLTEST, and connections beetwen servers and domain controllers.
Randomly we were losing connection with DC and only re-joining in domain solved this issue. There were also communication problems with Kerberos, SPN (even though the SPN was set correctly in schema) recprds, and NLTEST was always unsuccessful. Renaming and rejoining the domain did not help, neither re-promoting of DCs.
I fixed this by:
1. Removing another gateways from the network configuration
2. Inserting only primary and secondary DNS system into network settings of servers
3. Removing DNS systems which were not domain members from NAME Servers settings on domain DNS systems
I would recommend that first, install all the patches and hotfixes for the affected systems. I have also implemented the recommendations found at ME948496
We had a problem where the computer side of GPOs was not being applied to workstations; the user side of the GPO functioned just fine. This error was the only error in the event logs. We discovered that a Windows 2000 server configured as a domain controller had the Kerberos Key Distribution service disabled. After we re-enabled the service, the problem went away.
I have seen a secure channel problem causing this problem. Removing the machine from the domain, cleaning up DNS to remove the machines entries, then re-adding the machine back to the domain cleared the issue.
As per Microsoft: "This problem occurs when a Kerberos Privilege Attribute Certificate (PAC) validation error during logon causes the computer to fall out of scope for all Group Policy objects. Therefore, all assigned applications become unmanaged and are uninstalled. The Kerberos PAC validation error may occur because of transient network errors". See ME929624
for a hotfix applicable to Microsoft Windows XP.
See the link to "Citrix Support Document ID: CTX105953
" for more information about this event.
In my case, this event occured on a new DC W2003 SP1 because "File and Print sharing for Microsoft Networks" was missing in the network card's config. After installing this component and a reboot, the problem was solved.
We received this event after updating the domain controllers to SP1. The DCs are behind a firewall. We found out that since SP1 the port 1026/tcp is needed for authentication. After allowing it to the exception list the problem went away.
I received this error intermittently on workstations connected to our domain. The cause in the end was a Windows Firewall policy. If "Do not allow exceptions" is enabled when a workstation is booted up on a domain, the above error will occur and any assigned software will begin to uninstall. The reason this was happening intermittently on our domain was that "Do not allow exceptions" was only enabled on our "Standard" or non-domain Windows Firewall profile, as a security measure. Most of the time the workstations would start up correctly, but occasionally the detection mechanism would go wrong and the workstation would start up with the "Standard" profile instead of the "Domain" profile. This would leave "Do not allow exceptions" enabled and the error occurred. I simply removed the "Do not allow exceptions" setting from both profiles and now everything seems to be fine.
In one case, this occurred on a Windows XP SP2 computer that had been a member of a domain. The computer was removed from the domain (it was used by someone else on another project) and then re-joined to the original domain. The problem was fixed by removing the computer from the domain, deleting the computer account in Active Directory Users and Computers, and then re-joining the domain.
This event occurred after installing Windows 2003 SP1. The Dell server is connected to a Dell Powerconnect Switch. Turning the "Spanning Tree Protocol" feature off solved the problem.
I have a W2k3 server running DNS server that connects to another W2k3 server running as PDC on a NT4 domain. When this server first starts, I had this error, which followed an EventID 5790 from source NetLogon.
The problem was caused by Netlogon trying to load before the DNS server had started, therefore it did not know how to connect to the PDC. Modify the registry to make Netlogon dependant on DNS. Go to this key: “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon" and modify the “DependOnService” string adding DNS after LanmanWorkstation.
This problem may occur if one or more services that run in the Lsass.exe process or in the Services.exe process are no longer configured to run as shared service processes. See ME883268
to fix this problem.
From a newsgroup post: "Is your DC logging EventID 5723 from source Netlogon? One of our remote DCs in a area with a really slow link (24K) was logging a large number of Event IDs 7 along with 5723 Netlogon errors mentioning various computer names. The computers in question had experienced problems when they were joined to the AD. I reset the computer accounts using NETDOM and this instantly cured both the 5723 and the 7 errors on the DC".
for information on how to enable Kerberos debugging in Windows 2000.
See the links to "Troubleshooting Kerberos Errors" and MSW2KDB
for additional information on this event.
In my case the Workstation service was disabled, the Computer Browser and NetLogon service were not started. After enabling and starting these services the problem was solved.
This was one of many errors including (LASSRV ID 40960/40961 and NETLOGON 5719). I traced this down to the following (for a Windows 2003 Member Server in a Windows 2003 AD, which had its own DNS service running):
The problem was that the server was booting up and several services were trying to run (including NETLOGON) before the Member Servers DNS Server Service had started. This resulted in no name lookup for the Active Directory Domain and hence couldn't contact any Domain Controllers.
We had this error appear on a client PC event log randomly, and the problem turned out to be that one of the Win 2K domain controllers had its "Kerberos Key Distribution Center" (KDC) service stopped and disabled. The problem was solved by starting the service and setting it to start automatically. As far as I know, only DC's should run this service, it is usually disabled on member servers.
This event occured when I enabled "Secure Domain Logon" using SecuRemote via a VPN on my Windows XP machine. It occurs whether or not I'm authenticating to the remote domain. It may be trying to synchronise the Kerberos authentication for the computer using tickets generated in previous negotiation with the VPN destination domain. I was able to resolve this error by disabling "Secure Domain Logon" in VPN-1 SecuRemote NG (Feature Pack 3).