Source

Level

Description

The Security System could not establish a secured connection with the server <server name>. No authentication protocol was available.

Comments

 

In regedit HKLM\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\{AAF....} the DhcpNameServer had two entries, one correct and one an external IP address which ping -a came back as the 40961 code. I removed the entry and the problem was fixed.

Windows XP SP2 was getting application Event IDs 4226, 40961, 40960 for one end user only. End User was able to logon to the domain but the domain account would then get locked out right away. End User was also unable to map drives and access domain resources once the account was unlocked.  The end user stated this all happened when it was time for him to change his domain password. (Windows 2003 Domain). The end user's domain account was not a privileged account on the workstation.  

Based on info in this link and others we checked the "User Accounts" in Control panel and found one entry for his domain account. We removed the entry and reboot with no luck. We removed the workstation from the domain and re-joined with no luck.  

Added the end user to the local Administrators group, reboot and logged back in to the domain. Went back to" User Accounts" in Control Panel and there was another entry for his domain account.  Highlighted his account name and then clicked on the Advanced Tab and then click on "Managed Passwords" and found all kinds of line entries for server paths and such. Removed them all and then removed his account name. Rebooted the workstation and he was able to log in to the domain and access domain resources once again.

The key was adding the end user's domain account to the local administrators group to see the remaining entry for his "Manage Passwords" entries.

I want to echo others that said it was the time being off. I fixed the date on a computer and it started working.

As per Microsoft: "This problem occurs because the version number of the KRBTGT account increases when you perform an authoritative restoration. The KRBTGT account is a service account that is used by the Kerberos Key Distribution Center (KDC) service". See ME939820 for a hotfix applicable to Microsoft Windows Server 2003.

Microsoft article ME259922 describes a situation in which this event occurs.

Also see ME938702 for additional information about this event.

We opened a support incident with Microsoft, and they sent hotfix ME906681. This article is not related to this problem, but it has a newer version of kerberos.dll, which appears to be the culprit. If I am not mistaken, this new version is also included in XP SP3.

This problem occurs every now and then on our Windows XP SP2 systems. It used to happen a lot on SP1. Usually running a Winsock repair fixes the problem (see the link to “WinSock XP Fix 1.2”). Sometimes we also have to remove the system from the domain and rejoin it in order to fix the problem.

In my case, I got this event after adding a MS Windows XP SP2 workstation to a SBS 2003 R2 server. The problem was McAfee Security Center Suite, which I promptly removed.

This event only occurred when a specific user logged in on a specific XP SP2 machine, together with EventID 1030 from source Userenv. The User configuration policy was unable to be applied. If another user logged in on that same machine, no errors appeared and all policies were applied.
It turned out that there was a stored password on the machine when this specific user was logged in. When that was deleted from User accounts Password Management, the errors disappeared and Folder Redirection finally happened for this user.

In my case, a WinXP workstation logged events 40960 and 40961 from source LsaSrv as well as event 1053 from source UserEnv. The problem was corrected by updating the Intel Gigabit NIC driver on the server.

We received this event along with event 1219 and 1053 in the application log. The server lost connection to the DC and all accounts in the admin group showed just as their SIDs. We found that restarting the Site Server Content Deployment (CRS) service fixed the problem.

This Event ID appeared on a Windows XP SP2 computer each time it 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 stopped.

If you also get EventID 14 from source Kerberos with this event, go to Control Panel -> Users Accounts, click on the Advanced tab and then on Manage Passwords. There should be an entry there relating to the server and domain\user mentioned in the event id 14 description. Update or delete the entry.
The user was being prompted to authenticate (with different account info already filled in) when trying to open a share on a specific server to which there should have been seamless access. After removing the entry, access worked normally and the errors went away.

I was getting this error along with EventID 40960 from source LsaSrv and EventID 1006 from source Userenv. This was on a member server in a Windows 2003 domain. The events would all appear every two hours. It turned out that I had a user account (that was part of the admin group) still logged into the console and the password for that account had changed. Using Terminal Services Manager (since the machine is off-site), I logged that user out and had no more issues.

We have a domain with Win2k AD and various Win2k and XP clients. This event only occured on XP clients. Additionally, the logs showed event id 40961, 1054 and 1030. The logon process from the XP clients took forever, GPs were not applied and access to network shares was not possible. Increasing the kerberos ticket size, as suggested by MS, didn't do the trick. Recreating users and/or machine accounts didn't help either. Simple solution was to finally install SP4 for Win2k on the domain controllers which we hadn't done before. Since then everything has been running smooth.

We spotted this event after demoting one of our domain controllers. For a couple of weeks we had problems on the network but nothing specific, just minor problems here or there. Eventually, we realized that dcpromo had not removed all the DNS entries for the old server. We still had a NS record pointing to a server that no longer existed.

I received this when my XP systems were connected to a Cisco switch. By default, Cisco switches take up to 20 seconds to begin passing traffic after the host brings up their Ethernet interface. You can set a particular port to start immediately using the "spanning-tree portfast" command on the port your hosts are connected to. This resolved the issue for me.

I started to get this event on an SBS 2003 server every hour or so after I changed the domain administrator's password. The DHCP server used the same credentials, so when I also changed the password in DHCP's properties, the warnings stopped appearing.

I installed a new ISA 2004 server and I started to receive many errors of this type. In my case, the server referenced in the event description was an external DNS server from my ISP. I disabled DNS registration on the WAN NIC and the error went away.

See ME885887 for a hotfix applicable to Microsoft Windows XP Professional Service Pack 2.

As per Microsoft: "The Negotiate package could not select a secure authentication protocol because the user provided incorrect credentials or because the domain controller was temporarily unavailable". See MSW2KDB for more details on this event.

This can occur if the File Replication Service (Ntfrs.exe) tries to authenticate before the directory service has started. See ME824217 to troubleshoot this problem.

From a newsgroup post: "In my case, this error occurred because the credentials specified in my DHCP server on “DC1” for dynamic DNS registration were misspelled".

From a newsgroup post: "1. If the 40960/40961 events only happen at boot, it is likely that ME823712 and ME824217 will help you to fix this problem.
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 is not 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.
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.

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 registry value to 1465. See ME315150 and ME244474 for details.
9. Reset the secure channel.
10. Create a reverse lookup zone and add the DNS server to it. 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".

From a newsgroup post: "I was having this problem when using Microsoft’s Virtual PC 2004 with Windows 2003. I keep getting messages that the server’s clock on the virtual machine is out of sync with my physical box running Windows Server 2003. In the end, I just noticed that the date on my other box was 7/26, but the date on the virtual machine was 7/25. After making the necessary adjustments, the problem disappeared".

From a newsgroup post: "If this server is joined to a domain called mydomain.com and you have two adapters, configure both adapters to point to your Active Directory DNS server or disable DNS registration on the second adapter. See ME246804 for information on how to enable or disable dynamic DNS registrations in Windows 2000 and in Windows Server 2003".

From a newsgroup post: "Other posts in various newsgroups suggested that a problem with a user’s profile could be the cause of failures to apply GPOs, which is the root cause of My Documents redirection failures. This was consistent with what I was seeing. I was not using roaming profiles, so User A’s profile on PC01 was (potentially) different than it is on PC02. Furthermore, PC01 was installed with Windows XP Pro from scratch while PC02 ran Windows XP Home for 2 years and then was upgraded to Windows XP Pro. User A's profile on PC01 was created "fresh" while on PC02 it was migrated when PC02 was joined to the domain.
I did not find specific information concerning what gets screwed up in the profile or why it causes GPO failures. However, the fix steps were reasonably uniform:
1. Logon to the problematic PC as Administrator.
2. Backup the profile of the problem user. (E.g., copy it elsewhere. Be sure hidden and system files are copied. For example, \Documents and Settings\<username>\Local Settings\Application Data\Microsoft\Outlook often contains “.OST” and/or “.PST” files. I compared the total size and number of files in the original and backup before proceeding to Step 3.)
3. Delete the problematic profile. (Right-click My Computer -> Properties -> Advanced Tab -> User Profiles [Settings] button. Select the profile to be deleted with care.
4. Logoff as Administrator and logon as the problem (domain) user to recreate the profile.
5. Restore (copy back) the files from the backed-up profile. (Be careful about what gets overwritten.)
When I did this for User A on PC02, the 1030 and 40961 events stopped and My Documents redirection worked".

WITP76916 also provides information about this event.

See ME891559 for additional information on this event.

See ME810207 for information on IPSec default exemptions.

I started getting this error message on Windows XP workstations on our network after I promoted our Domain Controller from WinNT to Win2k. I noticed that the problem was occurring right after EventID 35 from source W32time. Basically what was happening was that the XP workstations affected were set to sync to an external time source rather than with their domain controller. Run the following while logged on as administrator to get rid of this log entry:
1. Stop the Windows time service by going to Control panel/Admin tools/Services.
2. Open a command prompt and type “net time /setsntp: <IP address of domain controller>”.
3. Restart the Windows time service and the message should go away.

- Data: 0000: c000018b = STATUS_NO_TRUST_SAM_ACCOUNT - This error code means the computer account has been deleted.

What I discovered, for our situation, is that the credentials for DNS dynamic updates were invalid. These credentials are entered in the DHCP snap-in.

1. Launch the DHCP snap-in.
2. Right-click the Domain and select Properties.
3. Click once on the Advanced tab.
4. Towards the bottom of the dialogue box, you will see a button labeled "Credentials". Click on the button.
5. Enter a user, which has been created for this purpose and is a member of the "DnsUpdateProxy" group.
6. Click on "Apply".
7. Click on "OK" and the problem should disappear.

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.

This happened to me when I installed new drivers for the internal DSL modem. This would probably also apply to any network card connected to the internet through any modem or router. The default settings were to "Register this connection's address in DNS". When registration was attempted I got the "Security System could not establish a secured connection with the server DNS/<host name>". Why a connection was attempted with that name server rather than the ISP's I'll never know. Unchecking "Register this connection's address" solved the problem.

This error may result from securing Client-to-Domain Controller and Domain Controller-to-Domain Controller traffic with IPSec. This is unsupported as per ME254949.

I came across this problem after installing two Windows 2003 DCs onto our Windows 2000 network. The user was attempting to map a drive to an OS400 V5R2 machine. This had worked previously, but stopped working after the introduction of the new DCs. The connection attempt would eventually timeout instead of asking for credentials. I modified default domain GPO to disable the following setting: "Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Microsoft Network Server: Digitally sign communications (always)".

We were also getting this error along with Event ID 40960 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.

I saw this event together with 40960 on a Windows Server 2003 acting as member server in a Windows 2000 domain. The errors appear in the log, when some users try to access the web server, IE will prompt for credential, even if the credential is correct, the users are denied access. The problem seems to be resolved after restarting NETLOGON service.

If this warning appears by itself on an hourly basis, check that the credentials assigned to the DHCP server to register DNS dynamic updates are valid. Spelling errors or incorrect passwords and/or domain names can be to blame. To do this in Windows Server 2003, open the DHCP snap-in, open the properties for your DHCP server, select the "Advanced" tab, and click the "Credentials" button. Verify the username, password, and domain listed here are valid.

We had the same problem on one of the workstations that had a long logon timeout. This has worked for us:
1. logon as an admin.
2. remove from domain.
3. add to domain.
4. restart.

From a newsgroup post: "If there is there a matching 40960 event then it is more likely a forward lookup zone issue in DNS. If not, it probably is that Windows is looking for a reverse lookup zone."

As per ME823712, this may occur when you restart the server that was promoted to a domain controller.

If the server name is prisoner.iana.org, blackhole-1.iana.org or blackhole-2.iana.org, this is just telling you that Windows could not perform a reverse lookup on the IP address configured as a DNS server. These names are used to respond with "server does not exist" when you use a private IP range, for example 192.168.1.0. This can be quickly cleared up by adding a Reverse Lookup zone, and adding a record for your DNS Server.

From a newsgroup post: "If the system is Win XP and if the errors were not occuring under a different profile the folowing steps can solve the problem:
1. Log on as a different user
2. Back up the profile in mention.
3. Delete the profile.
4. Create a new profile by logging on.
5. Restore the files from the backed up profile."

I get this error on all DC's that I upgrade to Windows 2003 Server. I upgraded one DC from W2k3 beta3 to the released version, and the events immediately started to show up. After I created the reverse lookup zones for the network they stopped.

This happened when machines were trying to register PTR records, and we didn't have reverse lookup zones. The solution was to add them for all our subnets.

I'm on a small home test network with Win2k domain behind a Linksys 4 port DSL router. The router handles DNS. A power failure sacked my domain controllers. After some restores and GP resets, my DCs were up and talking. But my workstation could not access AD Users and computers. The problem was the order of DNS in the Lynksys. After putting my local DNS server first in the list on the Linksys, I was able to get to AD.

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 40960 - LsaSrv.