We have a .Net Windows Service that uses a Httplistener and authenticates requests using Kerberos. When users are connecting via their browser, an error in the users event log shows a Kerberos Event ID 4:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the
server $username$. The target name used was HTTP/$servername$.$domain$.com.au.
This indicates that the target server failed to decrypt the ticket
provided by the client. This can occur when the target server
principal name (SPN) is registered on an account other than the
account the target service is using. Ensure that the target SPN is
only registered on the account used by the server. This error can also
happen if the target service account password is different than what
is configured on the Kerberos Key Distribution Center for that target
service. Ensure that the service on the server and the KDC are both
configured to use the same password. If the server name is not fully
qualified, and the target domain ($domain$.COM.AU) is different from the
client domain ($domain$.COM.AU), check if there are identically named
server accounts in these two domains, or use the fully-qualified name
to identify the server.
For some reason the server that it is reporting is the user that is running the service. The first line:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the
server $username$.
Every website (including Server Fault) has fixes for this error to do with SPN problems, but it always has a servername in the error. I cannot find the above message with a username.
We have tried different users and it changes the above part of the error message. All domain accounts have the same problem. If we run the service as the local system account we do not have this problem, but that causes us other problems with the service (it needs domain account for other permissions). We don't have, have never had, any servers with the same name as the usernames we've tried.
Has anyone seen this problem with the username appearing here before? What is the fix?
All of the servers are Windows 2012 (not R2).
Best Answer
Glad you solved your own problem, but it doesn't sound like you understand why what you ran solved the problem.
Bottom line, the SPN needs to be set on the appropriate object. It sounds like you had the SPN set on the computer's object in AD that was running the service. That's why things started working if you changed the service to run as SYSTEM. But if you change it to run as a domain user, you need to move the SPN to that user. And it's important that you move it (read: delete it from the computer account) and not just copy it. Duplicate SPNs will break things.