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. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
|Type: Failure Audit|
Service Ticket Request Failed:
User Name: <user name>
User Domain:<domain name>
Service Name: <service/server/port>
Ticket Options: <options code>
Failure Code: <failure code>
Client Address: <ip address>
|English: Request a translation of the event description in plain English.|
See the link to "Audit Account Logon Events" for information on this event.
In my case, this event was generated by a user that didn't change the expired windows password, and was still logged on to the network trying to print and access mapped drives.
See ME824905 for a hotfix applicable to Microsoft Windows 2000 and Microsoft Windows Server 2003.
See ME230476 for a description of common Kerberos-related errors in Windows 2000, and ME266080 for answers to frequently asked Kerberos questions.
- Failure code: 0xE = KDC_ERR_ETYPE_NOTSUPP - "KDC has no support for the encryption type" - Info taken from Experts Exchange: “I opened a ticket with Microsoft on the issue, and the problem turns out to be an issue between 2000 DC's and 2003 member servers. Here is an excerpt from the Microsoft email: “As I mentioned in my previous email, Windows 2003 introduces support for constrained delegation which by leveraging the S4U2Proxy extension to Kerberos. The Kerberos client on a Windows 2003 server will regularly (every 15 minutes by default) check the KDC to see if it supports S4U. Windows 2000 does not support S4U and will instead log a Security Audit event. I discussed the event with the development team and confirmed that it will NOT impact the upgrade to Exchange 2003”. The end result was that they sent me a hotfix to install on the DC to stop the errors from being recorded in the security log every couple of minutes”. See Experts Exchange Question 20794534 for more details.
A failure code of 0x20 indicates a normal Kerberos ticket expiration and may be ignored.
See the Documents section, article Event ID 677 for a discussion about this event.
As per Microsoft: "Windows 2000 attempts Kerberos (pass-through) authentication to the trusted Microsoft Windows NT 4.0 domains when Windows 2000 users need access to Windows NT 4.0 resources. The initial attempt and its associated service ticket request do not work because Windows NT 4.0 does not support Kerberos. When this failure occurs, it is logged as an Event ID 677 in the Security log as a failure event, and the NTLM authentication package is then used for authentication." This situation is described in ME302879 and apparently was fixed with SP3.
This event may also indicate that someone may try to login with a forged SID. The failure code for this would be: "0xC000019B". See ME289243.
H. Sean Shilling, Sr.
I have run into this message and hundreds of event ids 677's, when I created a new OU for the Controllers and did not put a link to the Default Domain Controller Policy The minute that I either created an identical Default Domain Policy on the new OU or linked the default one the problems went away.
This error usually appears when a user is trying to access a windows 2000 machine which either does not support kerberos authentication, or is running an application that doesn't support Kerberos authentication. Examples would Be Exchange 5.5, MS SQL 7.0, or even Win2k clusters. The reason is that these non-kerberos aware applications do not register a Service Principal Name with the KDC on Win2k domain controllers. It can also happen if users are trying to access servers in a different domain that is not using a kerberos trust. You can see which SPN's are registered on a particular server by performing an LDAP query on the server and grabbing the servicePrincipalName propery. As far as I know these errors can be ignored aslong as you have not turned off NTLM authentication, as it is the fallback method once the kerberos authentication has failed. This is only applicable to Win2k native mode domains, as hybrid mode uses NTLM by default.
I received this error when trying access server moved from my domain to workgroup. After I deleted the disabled computer account from Active Directory, the errors stopped occuring.
|Private comment: Subscribers only. See example of private comment|
|Links: Event ID 677, A Kerberos Primer, Kerberos in Win2K, Kerberos ticket options, Online Analysis of Security Event Log, Kerberos and authentication troubleshooting, Experts Exchange Question 20794534, Audit Account Logon Events|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
Send comments or solutions
- Notify me when updated