1

I have two new Domain Controllers on new Forest. Servers have DFS and IIS services installed. Everything seemed to go Ok for a While. After updating servers I got new errors. Now once in hour aditional Domain controller IIS2 is making these errors to event log:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server iis2$. The target name used was E3514235-4B06-11D1-AB04-00C04FC2DCD2/d170f7fc-6f05-4ea5-9dee-a657e3de019b/example.com@example.com. 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 (example.com) is different from the client domain (example.com), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

What does this really mean? What should I do to fix this problem? How to start...

Those server are new ones, I even tryed to reinstall servers with same roles. Every time same kind of kerberos erros occurs. Previous time it was somemethin to di with Ldap, and now this...

Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
Timo77
  • 111
  • 2
  • 5
  • 13

1 Answers1

1
  1. check if you have duplicate SPN (setspn -X)
  2. check if you have wrong DNS entry (where one name can bring client to two different machines unintentionally - I mentioned "unintentionally" because there are circumstances such setup is legit, such as you want to leverage DNS round-robin for load balancing/fault tolerance etc.).
strongline
  • 592
  • 2
  • 8
  • Ok. setspn -X gives me "found 0 group of duplicate SPNs" – Timo77 May 06 '15 at 14:35
  • I forget to tell on my original post that I have NLB setup too on those two Servers. How do I debug If it's wrong DNS entry? – Timo77 May 06 '15 at 14:36
  • 1
    simple NLB that doesn't involve kerberos can leverage 1 name->multiple IP setup. If SPN/kerberos is involved, I think you need a dedicate LB server at front that acts a single point of service provider - I am not an expert on NLB but the bottom line is, a kerberos ticket is encrypted under one server's account cannot be decrypted by another server account. – strongline May 06 '15 at 16:08
  • For example, you have serverA and serverB in your NLB, serverA has an SPN registered, let's say host\serverVirtualName. In DNS, you have A record "serverVirtualName" points to both A and B's IPs. When a client tries to access \\serverVirtualName, it request a ticket from AD, which finds serverA based on SPN. AD generates the ticket, encrypted it with serverA's hash. – strongline May 06 '15 at 16:09
  • Then the client present the ticket to serverB because DNS resolves "serverVirtualName" with serverB's IP. At this moment, event ID 4 is logged because serverB's hash can't be used to decrypted the ticket. This is not to say you have exactly same setup, but just one example why event ID 4 is logged. (sorry I had to split it to 3 comments). – strongline May 06 '15 at 16:09
  • Just wondering how I can Trace that event...? And how to correct it? Event happens once in hour... I'am not sure if it bothers any service at all, everyting seems to be working. – Timo77 May 06 '15 at 17:53
  • I Reconfigured My NLB. It were with default settings and shared all ports on Cluster address. We just need to share http 80 on that. After config change I have only one error message on system log. After that no erros at all... Could it be becouse of NLB settings...? – Timo77 May 07 '15 at 06:17
  • it could very well be. Please check with vendor doc how it should be set up. – strongline May 07 '15 at 12:36