40960, 40961 System Event errors:

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.

The possible causes list seems complete to me. It should resolve
99.999%, if not all, of 40960/40961 issues. I will be interested in
knowing how you checked you environment that none of the above applied
to you. For example, to check UDP fragmenation, you have to use ping -l
-f command or capture network traces.

other action includes:
- If on soem server, the error happens perodically, a network trace
will be helpful to see what error is returned by kerberos
- check any other kerberors error in System Log
- enable account logon auditing
- duplicate SPN or computer account?

I want to make a new contribution to this post with a new cause for 40961 System Event errors.
I followed one by one each of the possible causes mentioned in this article with no luck.
After 3 months triying diferent solutions I found following article.

http://support.microsoft.com/?scid=k...3931&x=21&y=13

In our installation we logon using smartcard and sometimes our users stay working more than 10 hours.

Microsoft article must be modified mentioning that TGT expiration also causes 40961 errors.

Solution. Edit Domain Default Group policy and change 2 options on Kerberos policies:
Maximum Service Ticket Lifetime from 10 to 20
Maximum User Ticket Lifetime from 10 to 20
and problem solved.

You replied to an old post.

Nonetheless, to get rid of 40961 errors, in *most* cases simply having a PTR
zone will take care of it. I do not believe changing TGT settings will take
care of the root causes of this error. More info in the following link on
40960 & 40961 errors:

http://eventid.net/display.asp?event...LsaSrv&phase=1
http://eventid.net/display.asp?event...LsaSrv&phase=1