40960, 40961 System Event errors:
These errors are showing up frequently on member servers and workstations in all sites.
Some of these hosts & member servers had a period when these errors appeared, but then stopped - while others are recording numerous errors all the time, no real pattern.
We don't suffer from any actual authentication issues but these errors are numerous and annoying. I've done extensive research into this error and it seems no-one out there has a 'silver bullet' fix for this.
The results of a netdiag / look clean, our DNS servers are running error-free too.
I've started to follow the MS whitepaper "Troubleshooting Kerberos Errors" so far, klist and ktray utilities show no issues.
We have 5 sites with 8 domain controllers (all running 2003 server, non-SP1) in our environment. The remote sites are connected with fast links (OC-12).
We're starting to think this issue could be the result of a higher-level networking problem.
Does anyone have an experience to share on how they addressed this?
------------------------------------------------------------------------------
Sample event logs & suggested resolutions:
------------------------------------------------------------------------------
Type: Warning
Source: LSASRV
Event ID: 40960
Event Time: 3/12/2006 1:49:22 AM
User: n/a
Computer: hosta
Description:
The Security System detected an authentication error for the
server LDAP/domainctrlr.net/.net@.net. The failure code from authentication protocol Kerberos
was "The attempted logon is invalid. This is either due to a bad username or authentication information.
(0xc000006d)".
------------------------------------------------------------------------------------
Event Type: Warning
Event Source: LSASRV
Event Category: SPNEGO (Negotiator)
Event ID: 40961
Date: 4/19/2006
Time: 2:24:02 PM
User: N/A
Computer: HOSTA
Description:
The Security System could not establish a secured connection with the server ldap/ domainctrlr.net. No authentication protocol was available.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
-------------------------------------------------------------------------------------
Event Type: Warning
Event Source: LSASRV
Event Category: SPNEGO (Negotiator)
Event ID: 40960
Date: 4/19/2006
Time: 2:24:02 PM
User: N/A
Computer: HOSTA
Description:
The Security System detected an attempted downgrade attack for server cifs/ domainctrlr.net. The failure code from authentication protocol Kerberos was "The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested.
(0xc0000234)".
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
-----------------------------------------------------------------------------------------
>>>>>>>>>>none of these suggestions apply to our environment:
I found the following KB articles but neither provides much help:
http://support.microsoft.com/default...s;823712&sd=ee
http://support.microsoft.com/default...s;824217&sd=ee
Another suggestion was theres no reverse zone associated with the dns host, they do exist
It is usually harmelss. I'd either turn down logging, or just ignore it.
If you turn down auditing it should go away.
change the psw on the user that is being used for in the
DHCP server credentials
every night for at least 6 hours at about 1.5 hour intervals. Further investigation revealed that the NIC was going into sleep mode and it was generating the errors. Going into Device Manager and properties of the NIC, under the Power Management tab, I cleared the checkbox that states "Allow the computer to turn of this device to save power". I have not received any more errors since doing this.
This can also occur if the File Replication Service (Ntfrs.exe) tries to authenticate before the directory service has started
After a support call with Microsoft, it was determined that somewhere between his home machine and our RRAS server, the Kerberos UDP packets were being fragmented, hence any authentication was failing (recall he could ping, nslookup, etc). We set the following reg key to a value of 1 to force Kerberos authentication to use TCP instead of UDP and everything worked perfectly.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LsaKerberos\Parameters\MaxPacketSize=1
add a Kerberos SRV record to the reverse
lookup zone.
A service attempts to authenticate before the directory service is
available. In that scenario, the events can be ignored.
2. If the 40960/40961 events happen at a regular interval (i.e., hourly),
try to determine what service may be need to authenticate at that interval.
For example,
if a XP/2003 machine is pointed directly at a DNS server that doesn't
support Kerberos, secure dynamic updates will generate 40960/40961 events.
Even if the
XP/2003 machine is pointed to a 2000/2003 DNS server, if the SOA for the
zone is a non-Microsoft DNS server that doesn't support Kerberos, the
40960/40961 events can still be generated.
3. Get a list of the computer names of the DCs in the domain, and compare
that to a list of all machine accounts in the forest to see if there is a
name conflict. For
example, if NTSERVER is a member server in the parent domain, and NTSERVER
is a DC in the child domain, you can see 40960/40961 events because of the
name conflict.
4. Verify RPC Locator is correctly configured:
Started, Automatic - Windows 2000 domain controllers.
Stopped, Manual - Windows Server 2003 domain controllers & member servers.
Stopped, Disabled - Windows 2000 clients & member servers, XP clients.
5. If the registry on the DC contains the NT4Emulator registry value in the
following registry key, set it to 0, or delete it entirely.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters
6. Verify the DHCP client service is started on all machines. Even machines
with static IP addresses (including domain controllers and member servers)
need to have
DHCP client service enabled because that service handles DNS dynamic
updates.
7. Verify there isn't a time skew between machines. Make sure to verify the
time, date, and year, are all the same. Appendix A of the Troubleshooting
Kerberos Errors
white paper shows a sample trace where clock skew breaks Kerberos.
http://www.microsoft.com/technet/pro...ver2003/techno...
security/tkerberr.mspx#XSLTsection131121120120
8. Kerberos UDP packet fragmentation can result in Kerberos failure.
Appendix A of the Troubleshooting Kerberos Errors white paper shows a
sample trace where UDP
fragmentation breaks Kerberos.
http://www.microsoft.com/technet/pro...ver2003/techno...
security/tkerberr.mspx#XSLTsection131121120120
2003 - RTM defaults to MaxPacketSize of 1465 bytes.
2000 - RTM defaults to 2000 bytes. With hotfix 315150 or SP4, default is
1465
XP - RTM defaults to 2000 bytes. With SP2, default is 1465. There is no
hotfix, SP2
is the only way to get the 1465 default without manually setting the
MaxPacketSize reg value to 1465.
315150 Logon Authentication, Active Directory Replication, and Domain Joins
Do
http://support.microsoft.com/?id=315150
Otherwise, use the MaxPacketSize registry value to force the use of TCP for
Kerberos instead of UDP.
244474 How to force Kerberos to use TCP instead of UDP
http://support.microsoft.com/?id=244474
9. Reset the secure channel.
10. Create a reverse lookup zone and add the DNS server to it. NOTE: If you
can explain why this would resolve 40960/40961 events, please email
clandis. The step
is included here because it was the fix in a customer verified solution
object, but more information is needed to understand why this would resolve
the 40960/40961
events.
11. Verify the necessary SPNs are registered, based on the information in
the event description.
12. Clear cached credentials.
2003 - Control Panel, Stored User Names and Passwords, Remove them all.
13. Based on the information in the event description, verify that the SAM
account name of one account is not the same as the UPN of another account.
Bookmarks