0

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?

Aaron Carlson
  • 133
  • 8

1 Answers1

1

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:
        http/service.test.local

c:\>setspn -q http/service.test.local
Checking domain DC=test,DC=local:
CN=serviceUser,CN=Users,DC=test,DC=local:
        http/service.test.local
Aaron Carlson
  • 133
  • 8
  • 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. – LeeM Apr 04 '19 at 01: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 04 '19 at 14:12