OK - det er bare fordi det fylder ret meget....
Ionut Marin (Last update 2/20/2005):
This can also occur if the File Replication Service (Ntfrs.exe) tries to authenticate before the directory service has started. See Q824217 to troubleshoot this problem. Also seeing the Kerberos FAQ might be of some help.
See Q891559 and the link to "Microsoft event 40960 from source lsasrv" for more details on this event.
Peter Van Gils (Last update 12/14/2004):
According to a newsgroup post, this error might be caused by problems with the W32time service. Check your time settings throughout the forest and solve all W32time errors and warnings first.
Christopher Kurdian (Last update 10/5/2004):
As per PK’s comments (see below), in order to make this event log entry disappear, simply make NETLOGON depend on DNS. This can be done in the registry easily, just go to “\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon”, and add the string “DNS” to the key "DependOnService" (place it under LanmanServer).
Martin Eisermann (Last update 8/25/2004):
One of our customers got this error on two of his Windows XP workstation. The workstations could initially be connected to the Windows Small Business Server 2003 domain, but after a reboot, the domain was not accessible (logon, network drive mapping, etc.). The resolve this problem we replaced the client’s network card. The old card was an Acer network adapter that had no drivers for Windows XP but worked fine with the Intel standard driver and the existing NT 4.0 domain. However, Kerberos authentication with SBS 2003 domain was impossible.
K-Man (Last update 7/7/2004):
I experienced this problem on Windows XP workstations, when users logged into a terminal server and terminal sessions were disconnected (but not terminated). To fix this problem I configured the terminal server to end disconnected sessions, and end sessions where users were idle for more than a specified amount of time.
PK (Last update 2/25/2004):
We were also getting this error on a Windows 2003 Member Server (in a Windows 2003 AD) which had its own DNS Server 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 could not contact any Domain Controllers.
Vazy Gee (Last update 8/5/2003):
I had this event for users were connecting to our RRAS service. The end user could connect to RRAS and could ping hosts, nslookup hosts, tracert, etc... However, when the user tried to access any network resources in our Windows 2003 Active Directory that actually required authentication, it would fail. 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
Note: On his XP Professional w/SP1 client, I had to create the Parameters subkey and MaxPacketSize DWORD value manually.
See Q244474.
Adrian Grigorof (Last update 8/5/2003):
From a newsgroup post: "An authenticated connection was requested but the negotiation to find a mutually agreeable security provider (SPNEGO) failed."
As per Q823712, on a Windows 2003 server, this behavior occurs when you restart the server that was promoted to a domain controller. In this scenario, the Windows Time service (W32Time) tries to authenticate before Directory Services has started. There are no adverse effects on computers that experience the warning events that are described in the "Symptoms" section.
Greg Martin
Had this on a WinXP workstation which could no longer access domain resources. The fix was changing the DNS settings to point to a Win2k DNS which was tied into Active Directory. Apparently the workstation could no longer locate SVR records for the kerberos authentication server. These records were not in our UNIX DNS but were in the Win2k DNS. Related directly to Event 40961 - LsaSrv
Anonymous
In our case, one of our customer reports that they are periodically seeing slow logon times, (defined as the time between entering the password and hitting enter on the “Logon on to Windows Screen” and the disappearing of that screen) sometimes1 -3 minutes on Windows XP SP1. Windows 2000 Pro computers are unaffected. The domain these computers are logging onto is a Windows 2000 AD Native Mode Domain with AD Integrated DNS zones. Checking the event log of a machine reveals these 40960 errors in the system log.
Soluton: User Logon Failures must be enabled.
By looking at the logon failure audit event logged at the same time as the SPNEGO event, more information about the logon failure can be obtained. Windows XP performs a reverse lookup on the DNS Server it is configured for as part of its own blackhole router detection. In the case where the DNS Server used does not have the Reverse Lookup Zone and/or no PTR Record for their DNS Server, the request gets forwarded out to the Internet.
The response comes back with one of the following server names:
prisoner.iana.org
blackhole-1.iana.org
blackhole-2.iana.org
These servers own the public PTR records for the 192.168.x.x zones. Since they have no record of your DNS Server, they reply with a "Server does not exist" reply, which causes LSASRV to log the error.
Solution: On the local DNS Server, create a Reverse Lookup Zone, and enter a record for your DNS Server.
Anothe case: The client was pointed to the ISP's DNS servers which contained a zone for the customer's domain. We removed the External DNS server addresses and ensured that DHCP was only assigning the Internal DNS server address. For testing we manually configured the DNS server address on a workstation which overrides the DHCP values. We can reference the following Knowledge Base Articles - Q291382 Frequently Asked Questions About Windows 2000 DNS.
Another case: Check the time on the workstation. Ensure that the day, time, time zone, AM/PM, year are correct. In my case the year was incorrect everything else was correct.
Last case: In this situation they actually were not authenticating to the DC. They were being logged in with cached credentials.
Se evt:
http://www.microsoft.com/technet/support/ee/result.aspx?EvtSrc=lsasrv&EvtID=40960&ProdName=Windows+Operating+System&LCID=1033&ProdVer=5.2