1

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

Greg
  • 463
  • 2
  • 10
  • 22

2 Answers2

3

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.

Ryan Bolger
  • 16,472
  • 3
  • 40
  • 59
  • Thanks Ryan. We did revisit the problem a few days after the fix, and it came down to user permissions. I'm not 100% sure yet what permissions are required, but if we run the service as a domain admin then it registered the SPN properly. Once the SPN is registered we then set the service back to it's normal user account. Probably doesn't need to be a domain admin but we didn't bother working out what it did need. – Greg May 18 '15 at 23:29
2

Found the solution here: http://blogs.technet.com/b/dcaro/archive/2013/07/04/fixing-the-security-kerberos-4-error.aspx

I ran:

setspn -A HTTP/$servername$.$domain$.com.au $username$

and that fixed the problem

Greg
  • 463
  • 2
  • 10
  • 22