I'm attempting to troubleshoot why windows authentication is failing for a website hosted in IIS at a customer site. When executing setspn -l serviceUser to list the spns associated with a service account we get the following output

Registered ServicePrincipalNames for CN=serviceUser,CN=Users,DC=test,DC=local:
        http/service.test.local test\serviceUser

However when we search for the spn using setspn -q http/service.test.local we get the following output:

Checking domain DC=test,DC=local

No such SPN found.

What would cause the spn to be found one way but not the other?


The issue ended up being that the customer actually created the SPN with the user name included in the SPN. I'm not sure how they did it, probably not by using setspn.

If I would have been paying closer attention I would have noticed that with the output of setspn -l serviceUser as it included the user name in the output of the spn.

Once that was corrected by removing the user name from the spn the output from setspn is as expected.

c:\>setspn -l serviceUser
Registered ServicePrincipalNames for CN=serviceUser,CN=Users,DC=test,DC=local:

c:\>setspn -q http/service.test.local
Checking domain DC=test,DC=local:
  • Good information. Setspn isn't actually too fussy about what text you use in the command - you can set a service name to pretty much anything, as long as it's something with text, a forward slash, and then some more text. I had to argue with SAP admins I would not be creating SPNs with the account PASSWORD in them, as had been their practice in the past. – Trix Apr 4 at 1:29
  • 1
    @Trix, Yikes! any one can query SPNs. Putting the account password in the SPN isn't too different from leaving the passwords in a text file on a shared drive that every one in the company has access to! – Aaron Carlson Apr 4 at 14:12

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.