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