locked
Server Manager requests HTTP/HOSTNAME001.domain.fqdn, that SPN is assigned to a service account, Kerberos Security Error ensues RRS feed

  • Question

  • I have a server in a data centre that I use for remote admin of other servers in the same site. I have added all of the servers in to Server Manager to get a dashboard view of the site. I am unable to add one of the servers to Server Manager, getting the error "Kerberos Security Error". Specifically:

    The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server hostname001$. The target name used was HTTP/HOSTNAME001.domain.fqdn. This indicates that the target server failed to decrypt the ticket provided by the client...

    This server is running IIS and a site is running under the context of a service account that has the SPN HTTP/HOSTNAME001.domain.fqdn assigned to it. I am aware that the "fix" described elsewhere is to either remove this SPN from the service account (not possible in this case) or to add the server to the trusted hosts list so that it uses NTLM auth (which seems ridiculous).

    My question is, why is Server Manager making Kerberos ticket requests for HTTP/HOSTNAME001.domain.fqdn when this is the sort of SPN that may well be associated with a service account, especially when there's a perfectly good WSMAN/HOSTNAME001.domain.fqdn SPN that is registered by default to the computer account object? No-one in their right mind is going to mess around with the WSMAN/ SPNs, so surely this should be the default request, right?

    Is there a registry key somewhere that will change the Kerberos ticket request type from HTTP/ to WSMAN/ ? Or is this something that can be changed in WinRM/WMF v5, or changed in an update rollup for Server 2012/2012R2?

    Thanks!

    Friday, August 12, 2016 11:26 AM

Answers

  • Hi,

    I did some research and found that Server Manager attempts with SPN HTTP/HOSTNAME001.domain.fqdn was an expected behavior but I could not find an official article which explains it.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    • Proposed as answer by Alvwan Tuesday, August 23, 2016 8:37 AM
    • Marked as answer by Alvwan Monday, August 29, 2016 2:37 AM
    Wednesday, August 17, 2016 8:46 AM

All replies

  • Hi,

    Thanks for your post.

    Regarding the error, you may find some useful information trough the below description:

    KRB_AP_ERR_MODIFIED    
       
    If a service returns KRB_AP_ERR_MODIFIED, it indicates that the service was unable to decrypt the ticket that it was given. The name of the error suggests that an attacker may have modified the ticket in order to gain access to a system. While this is possible, the most common reason is when the Service Principal Name (SPN) is registered to the wrong account. If Service A gets a ticket encrypted with Service B’s password, Service A cannot decrypt it using its password. There is no way for the service to know why it cannot decrypt the ticket, so it returns this error. To resolve this issue, determine which account is actually running the service and move the SPN to that account. If the service is running as Local System, Local Service, or Network Service, set the SPN on the computer account.

    Another possible cause is a duplicate SPN in two different domains in the forest. If it appears the SPN is registered to the correct account, search the entire forest for a duplicate SPN. For example: Say there is a service in Domain A that uses the SPN http/service.contoso.com and the same SPN exists in Domain B. If a user from Domain B tries to access the service in Domain A, it will fail with this error. The reason for this is the client in Domain B will first try to contact a domain controller in Domain B for that SPN. That domain controller will return a ticket for the account in Domain B.

    An interesting issue we see revolves around IIS7 and Kernel Mode Authentication. Typically, you should register the SPN to the account that is running the application pool. Kernel Mode Authentication speeds up authentication requests and performs the decryption in the context of the computer account. In the case of load balanced web servers, you cannot have multiple nodes using the computer different contexts to decrypt the ticket. Either disable Kernel Mode Authentication or use the useAppPoolCredentials in the applicationhost.config file of the web server. For more information, review:

    Kerberos errors in network captures

    https://blogs.technet.microsoft.com/askds/2012/07/27/kerberos-errors-in-network-captures/

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, August 15, 2016 7:10 AM
  • Hi Alvin,

    Thanks for the reply but I'm already very much aware of everything that you've said, and I'd have hoped that was clear from my original post. The issue is specifically that Server Manager, when connecting to a remote system, requests a ticket in the format HTTP/servername.domain.fqdn, and in this case that SPN has been registered to a service account. This isn't some violation of best practice and I doubt that I'm alone in doing this, so I'm asking why Server Manager requests an HTTP ticket instead of a WSMAN ticket, and whether this behaviour can be changed (through a registry key for example). If the behaviour can't be changed, please can this be escalated to the Server Manager team so that they can consider changing the default behaviour?

    Thanks,

    Joe

    Monday, August 15, 2016 9:36 AM
  • Hi,

    I did some research and found that Server Manager attempts with SPN HTTP/HOSTNAME001.domain.fqdn was an expected behavior but I could not find an official article which explains it.

    Best Regards,

    Alvin Wang


    Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    • Proposed as answer by Alvwan Tuesday, August 23, 2016 8:37 AM
    • Marked as answer by Alvwan Monday, August 29, 2016 2:37 AM
    Wednesday, August 17, 2016 8:46 AM
  • Hi Joe,

    I've recently become aware that we had exactly the same issue that you've described.

    I've stumbled across a 'fix'. In AD I removed the http/<servername> SPN from the service account and immediately Server Manager could access the server! Then I re-added the http/<servername> SPN back into the AD service account and the associated service (NDES in our case) appears to be working fine.

    Server Manager is still working too.

    I realise that this is an old call, but just in case you haven't found a solution this might be worth a try.

    Regards

    Friday, March 10, 2017 2:10 PM
  • Suffering from the same issue. I use a service account for SQL reporting and use a web portal. Server Manager is now broken. Any resolutions yet?
    Monday, March 20, 2017 3:26 PM