The error may appear if a new account is created, used for authentication, but the credentials have not yet been replicated to the KDC that the client is using for authentication.
Verify that the name is in the Active Directory. If the principal name is not in the local Active Directory, but you know the account should exist and the user was recently added to the domain, verify that Active Directory replication is current. It could be that the updates have not yet reached the domain controller that is acting as the KDC for that user. For information about how to manually initiate an update, see the article "Troubleshooting Kerberos Errors".
If the name is present in Active Directory, check to see if the account has expired. It is possible for a user to be in the middle of a session and suddenly be locked out. This can happen if "Enforce user logon restrictions" is set to true—the default setting—and the account expiration date passes. "Enforce user logon restrictions" forces the domain controller to check the user's account each time a TGT is presented. For information on the "Enforce user logon restrictions” Group Policy object (GPO), see "Troubleshooting Kerberos Errors" and "Authentication for Administrative Authority".
For additional information on this error read M230476, "Kerberos Authentication Tools and Settings", "Service logons fail due to incorrectly set SPNs", and Error code 0x7.
The KDC could not translate the client principal Name from the KDC request into an account in the Active Directory. To troubleshoot this error check whether the client account exists in AD, whether it hasn’t expired, and whether AD replication is functioning correctly.
This indicates that a handle was deleted without removing all the references to it. For example within a program a file might be opened and a "handle" created to point to the opened file. Various subcomponents of the application would use this handle to perform I/O operations against that file. If the main program or one of its subcomponents is closing the file and deletes the handle (to free system resources) any other part of the program that is trying to use that handle will generate this error. The program should contain all the instructions to notify all the components using that handle that it was deleted.
Since this is a programming error, there is little that a network administrator can do:
- install the latest service packs/hotfixes
- determine in what conditions does the problem appear and avoid them until the fix for it is released by the developer
- use "standard" hardware - most developers test their applications on a certain range of hardware devices (motherboards, network cards, controllers, etc...). Chances are that for that hardware they fixed most of the bugs. That's why MS has a list of supported hardware.
M101786 presents one example when the nature of the application makes it prone to such errors. Managing handles may prove to be too expensive for the application performance.
See the various links for some instances of this error - the vast majority of them point to fixes for software bugs.
Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net.
Obtain enhanced visibility into Cisco ASA firewall logs using the free Firegen for Cisco ASA Splunk App. Take advantage of dashboards built to optimize the threat analysis process.