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.
The function InitializeSecurityContex received a Kerberos Error Message:
on logon session <logon session>
Client Time: <time>
Server Time: <server time>
Error Code: 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN
Client Realm: <realm>
Client Name: <name>
Server Realm: <domain name>
Server Name: krbtgt/<domain>
Target Name: HOST/<firstname.lastname@example.org>
Error Data is in record data.
|English: This information is only available to subscribers. An example of English, please!|
|Concepts to understand:|
What is Kerberos?
In our case this message was occuring on a workstation when a user tried to open a document on Sharepoint (via trim). The issue was resolved by adding our Sharepoint server to the trusted websites list.
See ME230476 for a description of common Kerberos-related errors in Windows 2000.
- Error code: 0x29 = KRB_AP_ERR_MODIFIED "Message stream modified" - Make sure, as the error says, that you do not have identical names on your network. On our DC's, when the servers were first booted they picked up an IP via DHCP and registered this in DNS, then when I manually configured them with a static IP address the servers registered themselves again but the old IP number remained, hence the servers had to DNS entries. Check your DNS server for duplicate entries for your DCs.
See the article "Troubleshooting Kerberos Errors" for additional information on troubleshooting Kerberos related errors.
Users were periodically getting disconnected from the network drive mappings for no reason. We had a failed DC a few months ago and replaced it with a different server, but used the same IP address. We forgot to remove the old DC info from the AD. The problem was resolved after using the information provided in Microsoft article ME216498.
As per Microsoft: "Search the client domain for accounts with the same name as the target server, and then either rename the duplicate account or remove it". See MSW2KDB for additional information.
Try “ipconfig /displaydns” to see if the machine name for the local host entry is correct. If not, check your "hosts" file. In our case, a program inserted the old machine name as local host into the "hosts" file. As the machine name changed, this old entry caused this error. This event was accompanied by "EventID 5789 from source NETLOGON".
Error code: 0x20 (KRB_AP_ERR_TKT_EXPIRED) - no info.
Error code: 0x7 (KRB_ERR_S_PRINCIPAL_UNKNOWN) "Server not found in Kerberos database"
The KDC could not translate the server principal name from the KDC request into an account in the Active Directory. Generally, verifying whether the server account exists and has propagated to the DC that generated the error. Checking AD replication may provides an indication of why the error occurred. Also if the server is not at least Windows 2000, there will not be any service principal names registered because that server is not capable of authenticating with Kerberos. In this case, this error can be ignored because the client will then switch to NTLM for authentication.
|Private comment: Subscribers only. See example of private comment|
|Links: EventID 5789 from source NETLOGON, Troubleshooting Kerberos Errors|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
|Custom search for *****: Google - Bing - Microsoft - Yahoo|
Send comments or solutions
- Notify me when updated