I have a webservice running in IIS hosted in a Windows 2016 Nano server. I can access the service just fine if I go through http://servername/service/health

However, if i were to access it via http://[IP Address here]/service/health or http://service.company.com/service/health, it would prompt for AD login credential.

I looked through the DNS record and the IIS ApplicationHost.config and I can't really tell what's wrong with it. I might have missed a setting or two. Can anyone figure out where to look or what to do?


This looks like a Kerberos issue; if I'm correct, then the server's AD computer account(*) has a registered SPN for HTTP/SERVERNAME (this can be verified with the SETSPN command-line tool), thus automatic Kerberos authentication can happen when the web service is called using the computer's name; however, when calling the web service with any other name, this won't work.

If you want to be able to call the web service using a different name, then you need to add another SPN to the same AD computer account(*), with a command such as SETSPN -S HTTP/service.company.com SERVERNAME.

More info here.

(*) Or the user account which runs IIS's application pool, if you manually configured one.

  • When i do "setspn -L servername" I do see the servername in the list and I added HTTP/service.company.com, but it still won't work. Another thing I noticed is that servername.companyname.com is listed under the same service classes as servername, but using that will give me a prompt for credential. – Frosteeze Aug 23 at 17:49
  • 1
    The other thing is, the actual web application should be configured to accept that hostname; f.e. SharePoint needs a manual configuration for this. But I don't know your application, so I can't voice for that. – Massimo Aug 24 at 0:41
  • 1
    Quick mention of some SETSPN options which probably aren't the issue here, but might be useful in general when troubleshooting this. Use -Q (and -X) to search for any possible duplicate SPNs associated with the wrong account. But generally, if you're testing in IE, the client needs to consider the target site part of the Local Intranet Zone in order to automatically authenticate. (see parts of this answer serverfault.com/a/352180/35088 as well) – TristanK Aug 27 at 3:19

Service.company.com would need to be a registered Service Principal Name on the IIS server.

Also, Kerberos integrated authentication by default will not work with an IP address unless the system is configured to do so, and the IP address is a registered Service Principal Name.



One other check - it is possible your browser isn't passing credentials, forcing the login prompt.

In Internet Options, there is a security zone for Local Intranet; this zone will automatically pass your Windows credentials without the need for the AD dialog. The default setting will detect the server name as part of your network, but the full domain name is probably considered Internet zone and doesn't send the credentials. In the configuration page for Local Intranet, you can add the FQDN to no longer be prompted (or set it via Group Policy).

This all assumes you intend the site to run with Windows Credentials, and you are running internally; I'm not a security expert but personally, I wouldn't want to send my credentials automatically to a site across the internet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.